Cloud Storage, Databases and Data Management

Introduction and Context

Cloud computing has transformed data management from a procurement problem into an architectural and governance problem. An organisation no longer needs to purchase a fixed storage array or operate every database server itself. Instead, it selects services with different guarantees for durability, availability, latency, consistency, elasticity, geographic reach, security, and cost. The central professional challenge is therefore not simply to “move data to the cloud,” but to match each data workload with an appropriate storage or data service.

This chapter develops a decision-oriented view of cloud data management. It distinguishes object, block, and file storage; compares relational, NoSQL, cache, lakehouse, and streaming platforms; and applies CAP, consistency, durability, lifecycle, data sovereignty, and recovery requirements to service selection. The discussion applies across major cloud providers, although product names and detailed guarantees vary by provider, region, service tier, and configuration.

Learning Objectives

By the end of this chapter, a student should be able to:

1. Explain the operating characteristics and use cases of object, block, and file storage.

2. Select relational, NoSQL, cache, lakehouse, or streaming services for different workloads.

3. Apply CAP, consistency, durability, latency, lifecycle, sovereignty, and recovery considerations to architecture decisions.

4. Distinguish backup, replication, high availability, and disaster recovery.

5. Design a governed data architecture using classification, encryption, retention, and access controls.

6. Critically evaluate trade-offs involving performance, cost, portability, and operational complexity.

1. A Framework for Cloud Data Decisions

A useful data architecture begins with workload requirements rather than product features. The following questions establish the decision context:

• What data model is required: files, records, graphs, time series, key-value items, or immutable events?
• What are the read and write patterns, including throughput, concurrency, burstiness, and object or record size?
• What latency is acceptable for individual operations and for analytical queries?
• What consistency model is required? Can users tolerate stale or eventually consistent results?
• How much data loss is acceptable after a failure, expressed as the recovery point objective (RPO)?
• How long may service restoration take, expressed as the recovery time objective (RTO)?
• What durability and availability commitments are required?
• Must data remain in a particular country, region, legal jurisdiction, or provider environment?
• How will data be retained, archived, deleted, encrypted, classified, and audited?
• What are the cost constraints, including storage, requests, transfer, compute, backups, and operational labour?

A useful distinction is between durability and availability. Durability is the probability that stored data will not be lost or corrupted over a specified period. Availability is the probability that the service can successfully respond when requested. A highly durable archive can be temporarily unavailable; a highly available system can still lose data if replication and recovery are poorly designed.

If independent components have availabilities A1, A2, and so forth, a serial dependency is available only when all components work, and its availability is approximately the product A1 × A2 × … × An. This approximation assumes statistical independence, which is often unrealistic because common causes such as regional outages or configuration errors can affect several components simultaneously. Consequently, architecture reviews must examine failure domains rather than relying only on vendor percentages.

2. Storage Abstractions

2.1 Object Storage

Object storage stores data as objects consisting of a payload, system-defined metadata, user-defined metadata, and a globally or account-scoped identifier. Objects are placed in logical containers commonly called buckets or similar terms. Access normally occurs through HTTP-based APIs rather than through a traditional mounted disk interface.

Object storage is well suited to unstructured and semi-structured data: documents, images, video, backups, software packages, logs, datasets, and static web assets. It scales to very large capacities and usually provides strong durability through internal replication or erasure coding. Its common advantages are elastic capacity, low cost per stored unit, rich lifecycle controls, versioning, immutable retention options, and integration with analytics services.

Object storage is not normally a replacement for a low-latency transactional disk. Operations are object-oriented: updating a portion of a large object may require a rewrite or a specialised multipart mechanism. Directory hierarchies may be simulated through key naming, but they do not necessarily have the semantics of a POSIX file system. Applications must also account for request latency, API limits, authorization, and consistency behaviour.

Typical uses include a data lake landing zone, backup repository, content distribution origin, scientific data archive, and event payload store. Versioning protects against accidental overwrite and ransomware, but it can increase cost unless old versions are governed by lifecycle rules.

2.2 Block Storage

Block storage exposes virtual volumes divided into fixed-size blocks. A virtual machine or database host formats the volume with a file system and manages files and directories itself. This arrangement provides familiar disk semantics and is appropriate when an operating system or application requires direct, low-latency random access.

Block volumes are commonly used for boot disks, transactional databases, enterprise applications, and high-performance computing. They usually provide configurable performance, such as capacity, input/output operations per second (IOPS), and throughput. However, block storage is generally attached to a limited set of compute instances and is not automatically a shared file system. Snapshot operations, resizing, multi-attachment, and cross-zone replication may have service-specific constraints.

A performance design must consider both IOPS and throughput. If each I/O operation transfers b bytes and the workload performs r operations per second, the idealised throughput is r × b bytes per second. In practice, protocol overhead, queueing, workload mix, and service limits reduce the achievable value. Large sequential transfers may be throughput-bound, whereas small random operations may be IOPS- or latency-bound.

2.3 File Storage

File storage presents a hierarchical namespace of files and directories, usually through protocols such as NFS or SMB. It is appropriate where many clients need shared access and applications depend on file locking, directory permissions, or existing file-based interfaces.

Common uses include shared enterprise home directories, content management, media workflows, software repositories, and legacy applications. File services reduce migration effort because applications can often continue using familiar paths. Their limitations may include higher cost than object storage, metadata and directory scaling constraints, protocol overhead, and more complex permission management. Distributed file systems also require careful analysis of locking, caching, consistency, and failure recovery.

2.4 Comparing the Three Storage Types

Object storage emphasises scale, durability, API access, and lifecycle economics. Block storage emphasises virtual disk performance and control. File storage emphasises shared hierarchical access and compatibility. A single architecture may use all three: block storage for a database engine, file storage for shared application content, and object storage for backups and analytical data.

A frequent design error is choosing storage based only on capacity price. The total cost includes requests, provisioned performance, snapshots, replication, retrieval, network transfer, support, and engineering effort. Another error is treating backup copies as a complete recovery design. A backup that cannot be restored within the required RTO is not an adequate operational solution.

3. Database Service Families

3.1 Relational Databases

Relational database management systems represent information in tables with rows, columns, keys, constraints, and relationships. SQL provides declarative querying, joins, aggregation, and transaction control. Relational systems remain the preferred choice when data has strong relationships, integrity rules, reporting requirements, or transactions involving multiple entities.

The ACID properties describe important transactional behaviour:

• Atomicity: a transaction is completed entirely or not applied.
• Consistency: a committed transaction preserves defined database constraints. This meaning is distinct from distributed-system consistency.
• Isolation: concurrent transactions appear to follow the selected isolation rules.
• Durability: committed data survives an acknowledged transaction according to the database and storage guarantees.

Managed relational services commonly provide automated patching, backups, monitoring, replicas, and failover. Nevertheless, the customer remains responsible for schema design, indexes, query behaviour, credentials, authorization, and often recovery testing. Read replicas can improve read scale but may be asynchronously replicated and therefore stale. Multi-zone high availability improves failure tolerance but does not automatically provide protection against logical deletion or region-wide disaster.

Relational systems can scale vertically and, in some services, horizontally through partitioning or distributed SQL. Horizontal distribution introduces challenges involving transaction coordination, cross-partition joins, hot keys, and operational complexity.

3.2 NoSQL Databases

NoSQL is a broad family rather than one model. Key-value stores retrieve values by keys; document stores manage JSON-like records; wide-column systems organise data by partition and clustering keys; graph databases represent vertices and relationships. These systems often relax relational joins in favour of horizontal scalability, flexible schemas, predictable access paths, or specialised relationship traversal.

NoSQL design is access-pattern-driven. Instead of beginning with a normalised conceptual schema and discovering queries later, architects identify critical reads and writes, then choose partition keys and data representations that support them. Denormalisation is common. The trade-off is duplicated data, more complex update logic, and possible inconsistencies between copies.

Partition-key selection is critical. A key that concentrates traffic creates a hot partition even when total system capacity appears sufficient. A key with excessive cardinality may distribute load well but make range queries difficult. Effective designs also define item size, index strategy, retry behaviour, idempotency, and handling of partial failure.

NoSQL does not mean “no consistency.” Services may offer strong, session, bounded-staleness, or eventual consistency, and the correct choice depends on the business operation. Product documentation must be consulted because terminology, scope, and guarantees differ.

3.3 In-Memory Caches

A cache stores frequently accessed or computationally expensive data closer to the application. In-memory key-value systems can deliver very low latency, but memory is more expensive and volatile than durable storage. A cache should therefore normally be treated as an optimisation, not as the authoritative source of business data.

Important design choices include cache-aside, read-through, write-through, and write-behind patterns. In cache-aside, the application reads the cache, retrieves missing data from the primary store, and populates the cache. It must define expiration, invalidation, and behaviour when stale values are returned. The hardest cache problem is often invalidation: a cached value may remain visible after the source has changed.

Eviction policies such as least recently used are useful but do not guarantee that the most valuable item remains present. Systems must tolerate cache misses, node failure, stampedes caused by simultaneous misses, and inconsistency during updates. Distributed locks or request coalescing may reduce stampedes but add failure modes.

3.4 Data Lakes and Lakehouses

A data lake stores raw or lightly processed data, often in object storage, with flexible schemas and multiple consumers. It supports economical retention of structured, semi-structured, and unstructured data. Without governance, however, a lake can become a “data swamp” containing duplicated, undocumented, inaccessible, or untrusted datasets.

A lakehouse combines low-cost open-format storage with table management, schema enforcement or evolution, transactions, catalogues, and analytical processing. Table formats may provide snapshots, time travel, partition management, and concurrent updates. These capabilities narrow the gap between data lakes and warehouses, but they do not eliminate the need for data modelling, quality controls, workload isolation, and cost management.

A mature lakehouse architecture separates raw, refined, and curated data while recording ownership, classification, lineage, quality measures, and retention rules. Open formats can improve portability, but portability is not automatic: cloud-specific catalogues, identity systems, compute engines, and proprietary optimisations can still create lock-in.

3.5 Streaming Platforms

Streaming systems process sequences of events as they are produced. An event normally includes a payload, key, timestamp, and metadata. Platforms differ in their treatment of ordering, partitioning, replay, retention, delivery semantics, and stateful processing.

A stream can support real-time fraud detection, observability, IoT telemetry, recommendation systems, and operational integration. Partitioning enables parallelism, but ordering is usually guaranteed only within a partition or key scope. Producers and consumers must define what happens when messages are duplicated, delayed, reordered, or rejected.

“Exactly once” is not a universal property of an entire business workflow. A platform may provide exactly-once processing within a defined boundary, while external side effects such as sending an email or charging a card remain non-transactional. Idempotent consumers, deduplication identifiers, transactional outboxes, and replayable event logs are practical techniques for controlling these effects.

4. Consistency, CAP, and Distributed-System Trade-offs

Consistency describes what values readers may observe after writes. Strong or linearizable consistency makes operations appear to occur in a single order consistent with real-time constraints. Eventual consistency guarantees that replicas converge if updates stop, but a reader may temporarily see an older value. Session guarantees, causal consistency, and bounded staleness occupy useful intermediate positions.

The CAP theorem states that in the presence of a network partition, a distributed system cannot simultaneously guarantee both strong consistency and availability for all requests. The theorem does not say that a system permanently chooses only two of the three properties. Rather, it highlights the unavoidable choice made when communication between nodes fails. Partition tolerance is generally necessary in geographically or independently operated distributed systems; the practical choice during a partition is often whether to reject or delay some operations to preserve consistency, or to continue serving potentially conflicting or stale results to preserve availability.

CAP should not be confused with ACID consistency, nor should it be used as a simplistic label for an entire product. A service may provide different modes, scopes, and guarantees for different operations. Architects should specify which data can be stale, which writes may conflict, whether a user must read their own write, and what happens during a partition.

For an online banking balance, strong transactional guarantees are generally more important than accepting every request during a partition. For a social-media “like” count, temporary divergence may be acceptable if the system remains responsive. For a shopping cart, a carefully designed merge or session-consistent model may provide a better experience than either strict global serialisation or uncontrolled eventual consistency.

5. Lifecycle, Sovereignty, Security, and Governance

Data has a lifecycle: creation, active use, sharing, modification, archival, retention, and deletion. Storage classes and automated policies can move infrequently accessed objects to cheaper tiers, expire temporary data, delete old versions, and retain regulated records for required periods. Lifecycle rules must account for minimum storage durations, retrieval charges, restore time, legal holds, and backup dependencies.

Data sovereignty concerns the legal authority and jurisdiction governing data. Residency requirements may specify where primary data, replicas, logs, encryption keys, and support access may exist. Selecting a region is therefore insufficient unless the provider’s replication, support, telemetry, and subcontracting arrangements are understood. Sovereignty is also distinct from privacy: data may be located within a country yet still be accessible under foreign legal authority.

Security controls should be layered. Encryption in transit protects network communication; encryption at rest protects stored media; customer-managed keys can improve control but introduce key availability and rotation responsibilities. Identity and access management should follow least privilege, separation of duties, short-lived credentials, and workload identities rather than shared passwords. Object storage requires careful controls against public exposure, insecure cross-account access, and deletion of versioned data.

Governance includes classification, ownership, cataloguing, lineage, quality, retention, access review, audit logging, and defensible deletion. Personally identifiable information, health data, financial records, and intellectual property may require different controls. Data minimisation is both a privacy principle and a cost-control strategy: retaining unnecessary data increases breach exposure, storage expense, and compliance burden.

Artificial intelligence increases the importance of governance. Training and retrieval datasets may contain copyrighted material, personal information, poisoned records, or sensitive operational data. Organisations should document provenance, consent and lawful basis where applicable, access boundaries, retention, evaluation data, and procedures for deleting or correcting information. AI-generated data should not automatically be treated as authoritative.

6. Recovery Engineering

Recovery planning begins with two business requirements. RPO is the maximum tolerable period of data loss measured backward from a disruptive event. RTO is the maximum tolerable time between disruption and restoration of an acceptable service. If an application can lose at most five minutes of transactions, its recovery design must limit effective replication or backup exposure to five minutes or less; a nightly backup cannot meet that requirement.

Backups are point-in-time copies used to recover data, whereas replication maintains additional copies, often for availability or read scaling. Replication can reproduce corruption, accidental deletion, or ransomware, so it does not replace independent backups. A sound strategy may include automated backups, immutable or write-once retention, cross-zone or cross-region copies, separate credentials, and tested restoration procedures.

Recovery patterns range from backup-and-restore, through pilot light and warm standby, to active-active operation. Backup-and-restore is economical but normally has the longest recovery time. Active-active can offer rapid recovery but requires conflict handling, synchronised configuration, replicated data, and substantially greater cost and complexity. Recovery must include application code, infrastructure definitions, secrets, schemas, queues, DNS, certificates, observability, and runbooks—not only database files.

A recovery design is incomplete until it has been tested. Restore tests should measure actual RTO and RPO, verify data integrity, examine dependencies, and test operator permissions. Disaster exercises should include regional failure, accidental deletion, credential compromise, and a failed restoration attempt. The resulting evidence is more valuable than an untested claim of resilience.

7. A Structured Service-Selection Method

A practical selection process can be organised into seven steps:

1. Classify the workload. Identify data model, sensitivity, volume, growth, access patterns, and ownership.

2. Define non-functional requirements. Specify latency, throughput, consistency, availability, RPO, RTO, retention, and jurisdiction.

3. Choose the primary abstraction. Select object, block, file, relational, NoSQL, cache, lakehouse, or stream according to the access model.

4. Design failure behaviour. Identify failure domains, retry rules, idempotency, replica lag, conflict resolution, and restoration paths.

5. Estimate total cost. Include capacity, operations, requests, provisioned performance, backups, data transfer, retrieval, and personnel.

6. Evaluate governance and portability. Examine encryption, auditability, deletion, legal constraints, open formats, and exit strategy.

7. Prototype and test. Use representative data and workloads; measure tail latency, not only averages, and conduct failure and recovery tests.

A weighted decision matrix can make assumptions explicit. For example, a regulated transaction system might assign high weights to consistency and recovery, while an archival repository might assign high weights to durability, lifecycle economics, and sovereignty. Scores should be evidence-based and accompanied by confidence levels; a numerical matrix does not remove architectural judgement.

8. Illustrative Case: National Health Research Platform

Background

A fictional national health research organisation receives clinical extracts from hospitals, stores medical images, supports a researcher portal, and operates near-real-time surveillance dashboards. Data includes personally identifiable and clinically sensitive information. Researchers need analytical access, hospitals need reliable exchange, and regulators require auditable retention and controlled residency.

Problem

The organisation initially proposes one relational database for all workloads. Early testing reveals that large image files consume database capacity, analytical queries interfere with clinical transactions, dashboards show stale or duplicated events, and cross-border replication conflicts with residency requirements. Recovery requirements also differ: the portal needs rapid restoration, while historical research data can tolerate a longer recovery window.

Analysis and Approach

The architecture team separates the workloads:

• A managed relational database stores patient, consent, study, and access-control records requiring transactions and constraints.
• Object storage stores medical images and raw extracts, with versioning, encryption, restrictive policies, and lifecycle transitions.
• A lakehouse stores de-identified analytical datasets in governed open table formats. Catalogues record lineage, quality, ownership, and permitted use.
• A streaming platform receives clinical events. Partition keys preserve ordering for each patient or facility where required, while consumers use event identifiers to achieve idempotent processing.
• An in-memory cache accelerates non-sensitive reference data and short-lived dashboard results; it is never the authoritative store.
• Separate recovery copies remain within permitted jurisdictions. Database point-in-time recovery supports a low RPO, while immutable object backups protect against logical deletion and ransomware.

The team applies least privilege through separate identities for ingestion, clinical operations, researchers, and platform administrators. Sensitive fields are tokenised or removed before research access. Key management, audit logging, legal holds, and deletion workflows are integrated into the data catalogue and operational procedures.

Outcome

Transactional workloads become predictable because analytical scans no longer compete for the primary database. Researchers gain scalable access to curated data without receiving unrestricted clinical records. Streaming dashboards tolerate duplicate delivery through idempotent consumers. Recovery exercises demonstrate that the portal meets its target RTO, while the analytical environment uses a lower-cost restoration strategy appropriate to its RPO and RTO.

Learning Points

The case demonstrates that cloud architecture is usually compositional rather than product-centric. Different data classes require different abstractions. Consistency must be selected per operation, not declared for an entire organisation. Governance, residency, and recovery must be designed with storage and processing, not added after deployment.

9. Challenges and Limitations

Cloud services reduce infrastructure administration but do not remove complexity. Provider abstractions can obscure replication topology, quota limits, failure modes, and cost drivers. Managed services may create dependence on proprietary APIs, identity systems, and export formats. Multi-cloud designs can improve bargaining power or resilience but often duplicate skills, monitoring, security controls, and data-transfer costs.

Performance is workload-dependent. Benchmark results obtained with synthetic data may not represent production distributions, hot keys, skew, large objects, or tail latency. Stronger consistency can increase coordination and latency, while eventual consistency can shift complexity into application logic. Data duplication improves read performance but complicates updates and governance.

Compliance certifications are useful evidence but do not prove that a particular architecture is compliant. Responsibility remains shared among provider, customer, application owner, and data controller. Finally, data gravity—the cost and latency of moving large datasets—can constrain future migration. Open standards, documented schemas, export tests, and periodic exit exercises reduce but do not eliminate this risk.

Best Practices

• Begin with workload and business requirements, not a preferred vendor product.
• Separate authoritative data from caches, replicas, derived datasets, and backups.
• Choose consistency per business operation and document stale-read tolerance.
• Design partition keys, indexes, and file layouts from measured access patterns.
• Use encryption, least privilege, private connectivity, logging, and regular access reviews.
• Automate lifecycle, retention, legal hold, and defensible deletion policies.
• Treat replication and backup as different controls; maintain immutable recovery copies.
• Test restoration, failover, data integrity, and operator access regularly.
• Measure tail latency, recovery performance, and total cost under realistic workloads.
• Document data lineage, sovereignty boundaries, ownership, and exit procedures.

Chapter Summary

Cloud data management requires matching storage and database abstractions to workload behaviour and business risk. Object storage provides scalable, durable, lifecycle-oriented storage for unstructured data; block storage provides virtual-disk performance; and file storage provides shared hierarchical access. Relational databases support transactions, constraints, and joins, while NoSQL systems support access-pattern-oriented horizontal scale and flexible models. Caches improve latency but are normally non-authoritative. Lakehouses combine economical object storage with governed analytical tables, and streaming platforms support replayable, event-driven processing.

CAP frames the unavoidable consistency-versus-availability decision during network partitions, but it must be applied precisely and distinguished from ACID terminology. Effective architecture also considers durability, latency, lifecycle, sovereignty, security, RPO, RTO, backup, replication, and recovery testing. A mature design is compositional, governed, measurable, and explicit about trade-offs. Cloud services provide capabilities; professional engineering determines whether those capabilities satisfy the organisation’s obligations.

Key Terms

Object storage: API-oriented storage of identifiable objects and metadata.

Block storage: Virtual disk storage presented as addressable blocks to a host.

File storage: Hierarchical shared storage accessed through file protocols.

Durability: Probability that stored data remains available without loss or corruption over time.

Availability: Probability that a service responds successfully when requested.

Consistency: Rules governing which values reads may observe after writes.

CAP theorem: Result stating that partitioned distributed systems cannot guarantee both strong consistency and availability during a partition.

ACID: Atomicity, consistency, isolation, and durability properties of transactions.

NoSQL: Family of non-relational data models including key-value, document, wide-column, and graph systems.

Cache: Temporary, faster copy used to reduce latency or backend load.

Data lake: Large-scale repository for raw or lightly processed data.

Lakehouse: Governed analytical architecture combining lake storage with table and transaction capabilities.

Streaming: Continuous processing of ordered or partitioned event sequences.

RPO: Maximum acceptable period of data loss after a disruption.

RTO: Maximum acceptable time to restore an acceptable service.

Replication: Maintaining additional copies of data, often for availability or scale.

Backup: Point-in-time copy intended for recovery.

Data sovereignty: Legal and jurisdictional control applicable to data and its processing.

Idempotency: Property whereby repeating an operation produces the same intended effect as performing it once.

Data lineage: Record of data origin, transformations, movement, and use.

Review Questions

Short Answer Questions

1. Distinguish object, block, and file storage.

2. Why should a cache normally not be treated as the authoritative data store?

3. Define RPO and RTO.

4. What decision does CAP highlight during a network partition?

5. State two differences between replication and backup.

Long Answer Questions

1. Compare relational and NoSQL databases in terms of data modelling, transactions, scalability, and operational trade-offs.

2. Explain how lifecycle management, data sovereignty, encryption, and access control contribute to cloud data governance.

3. Discuss the architecture and advantages of a lakehouse compared with a conventional data lake.

4. Explain streaming delivery, ordering, replay, duplication, and idempotent consumption.

5. Develop a structured method for selecting a cloud data service for a new workload.

Analytical / Application Questions

1. A retail platform requires strict inventory correctness but allows product recommendations to be several seconds stale. Propose suitable data services and consistency models for both workloads, and justify the separation.

2. A research organisation must retain 500 TB of data for ten years, keep it within one jurisdiction, and restore critical metadata within two hours. Design a storage, lifecycle, governance, and recovery strategy.

3. An event-processing system receives duplicate and out-of-order payment events during network instability. Analyse the likely causes and propose partitioning, identifiers, consumer, and recovery mechanisms that preserve correct business outcomes.

Multiple Choice Questions with Answers

Question 1

Which storage type is generally most appropriate for a large, durable repository of images, backups, and raw analytical files accessed through APIs?

A. Object storage

B. Block storage

C. CPU cache

D. Local register storage

Correct Answer: A. Object storage

Question 2

What is the primary purpose of an RPO?

A. To specify the maximum acceptable service restoration time

B. To specify the maximum acceptable amount of data loss measured in time

C. To specify the maximum database transaction size

D. To specify the maximum number of replicas

Correct Answer: B. To specify the maximum acceptable amount of data loss measured in time

Question 3

During a network partition, CAP highlights a trade-off between which two properties?

A. Durability and encryption

B. Latency and throughput

C. Strong consistency and availability

D. Compression and retention

Correct Answer: C. Strong consistency and availability

Question 4

Which database family is most directly associated with tables, joins, constraints, and SQL transactions?

A. Relational database

B. Key-value cache only

C. Object store

D. Streaming broker

Correct Answer: A. Relational database

Question 5

Why can replication fail to replace backups?

A. Replication never improves availability

B. Replicas can reproduce accidental deletion or corruption

C. Backups cannot be stored in object storage

D. Replication always violates data sovereignty

Correct Answer: B. Replicas can reproduce accidental deletion or corruption

Question 6

Which design choice is especially important for avoiding hot partitions in a distributed NoSQL database?

A. Selecting an appropriate partition key

B. Disabling all indexes

C. Using only sequential timestamps as keys

D. Storing every item in one partition

Correct Answer: A. Selecting an appropriate partition key

Question 7

What is a common role of a lakehouse?

A. To provide only operating-system boot volumes

B. To combine economical lake storage with governed analytical table capabilities

C. To replace all transactional databases without analysis

D. To provide network routing between regions

Correct Answer: B. To combine economical lake storage with governed analytical table capabilities

Question 8

In a streaming system, what is the purpose of an idempotent consumer?

A. To ensure repeated delivery does not create repeated business effects

B. To eliminate the need for event identifiers

C. To guarantee every external side effect is exactly once

D. To prevent all events from being replayed

Correct Answer: A. To ensure repeated delivery does not create repeated business effects

Question 9

Which statement best distinguishes durability from availability?

A. Durability concerns preservation of data; availability concerns successful response to requests

B. Durability and availability are identical vendor measurements

C. Durability concerns latency; availability concerns encryption

D. Durability applies only to caches; availability applies only to archives

Correct Answer: A. Durability concerns preservation of data; availability concerns successful response to requests

Question 10

A workload requires many clients to access a shared hierarchical namespace using familiar file semantics. Which storage type is the most natural initial choice?

A. File storage

B. Object storage only

C. A message stream

D. A relational index without storage

Correct Answer: A. File storage