DynamoDB and AWS Data Stores for Developers (DVA-C02)

Every DynamoDB table is defined by its primary key, and the partition key half of that key decides how work spreads across the table's underlying storage partitions. DynamoDB hashes the partition key value to place each item, so a key with many distinct, evenly requested values — a high-cardinality key — balances reads and writes across partitions. A low-cardinality key (a status flag, a date, a handful of tenant ids) funnels traffic into a hot partition that throttles even though the table as a whole has spare capacity. Adaptive capacity softens the blow by shifting throughput toward busy partitions, but it cannot rescue a fundamentally skewed key. Design the key first.

You choose between two primary key shapes: a simple key (partition key only, every item addressed by one value) and a composite key (partition key plus sort key, where the partition key groups related items and the sort key orders them within the group). The composite shape is what makes Query powerful: one partition, a range of sort keys.

Walk through a multi-tenant orders table. Requirements: fetch one order by id, and list a tenant's recent orders. If you make tenantId the partition key, one large tenant concentrates traffic on one partition. A better design uses orderId — unique and high-cardinality — as the partition key so single-order GetItem calls balance perfectly, plus a global secondary index with partition key tenantId and sort key createdAt for the tenant listing. If one tenant still dominates, apply write sharding: suffix the index partition key (tenantId#0 through tenantId#9) and fan queries out across the shards.

One hard limit to memorize: an item, including all attribute names and values, cannot exceed 400 KB. Store large payloads in Amazon S3 and keep a pointer in the item.

Secondary indexes give a table alternate access paths without duplicating it by hand. A global secondary index (GSI) defines a completely new partition key (and optional sort key) and behaves like a shadow table with its own throughput. A local secondary index (LSI) keeps the table's partition key and swaps in a different sort key, staying local to each partition.

Projection decides which attributes the index copies: KEYS_ONLY, INCLUDE (named attributes), or ALL. Project only what your queries read — a slim GSI costs less to write and store, but querying an attribute that is not projected forces an expensive fetch back to the base table.

Choosing between them is a staple exam question. Reach for a GSI when you need to query on a different partition key entirely (orders by customer instead of by order id) or when the table already exists. Reach for an LSI only when you need an alternate sort order within the same partition and strongly consistent reads on that index — and remember you must decide at table creation. A useful pattern either way is the sparse index: only items that carry the index key are copied in, so indexing an attribute that exists solely on, say, unshipped orders yields a small, cheap index of exactly those items.

Query and Scan both return sets of items, but they work in opposite ways. Query requires an equality condition on the partition key, optionally narrowed by a sort key condition (equals, less-than, greater-than, between, begins_with), and reads only the matching items in that one partition. Scan reads every item in the table or index, page by page, and evaluates any filter afterward.

The cost difference is the exam's favorite angle. A filter expression does not reduce consumed capacity: filtering happens after items are read, so a Scan with a filter that returns three items still pays read capacity for every item scanned. Both operations return at most 1 MB of data per call and hand back a LastEvaluatedKey for pagination, so a whole-table answer also means many round trips.

When a question asks for the approach with the least read capacity, lowest latency, or lowest cost, the answer is to restructure access around Query — usually by adding a GSI that turns the filter attribute into a partition key — or to use GetItem and BatchGetItem for known keys. Scan is legitimate for genuine whole-table work: occasional exports, migrations, analytics sweeps. For those, a parallel scan (the Segment and TotalSegments parameters) splits the table across workers, and using a smaller page size or eventually consistent reads softens the impact on live traffic.

Distractor alert: an option that adds a filter expression to reduce cost is wrong by definition, and a projection expression reduces the network payload but not the consumed capacity either.

DynamoDB replicates every item across multiple Availability Zones, and its read consistency model follows from that. An eventually consistent read (the default) may hit a replica that has not yet received the latest write, so it can briefly return stale data. A strongly consistent read returns the most recent successful write, at the price of higher latency, no support on global secondary indexes, and double the read capacity. You opt in per request by setting ConsistentRead to true on GetItem, Query, or Scan — it applies to base tables and LSIs only. When several items must change together, TransactWriteItems and TransactGetItems provide ACID guarantees at twice the capacity cost of standard operations.

Capacity math shows up in developer-level questions, and the units are stable facts worth memorizing. One read capacity unit (RCU) is one strongly consistent read per second of an item up to 4 KB — or two eventually consistent reads of that size. One write capacity unit (WCU) is one write per second of an item up to 1 KB. Larger items round up: a strongly consistent read of a 6 KB item costs 2 RCUs, while an eventually consistent read of it costs 1.

You also choose a throughput mode. Provisioned capacity sets RCUs and WCUs ahead of time (optionally with auto scaling) and throttles with ProvisionedThroughputExceededException when exceeded — the SDKs retry with exponential backoff automatically. On-demand mode bills per request and absorbs spiky traffic without capacity planning, which makes it the exam's answer for new, unknown, or bursty workloads.

Persisting application objects means converting them to the target store's wire format and back. DynamoDB stores items as typed attributes, not raw JSON: strings (S), numbers (N), binary (B), booleans (BOOL), null, lists (L), maps (M), and string, number, and binary sets (SS, NS, BS). In the low-level API every value arrives as an explicitly typed structure — and numbers travel as strings, which preserves precision across programming languages. Binary values are base64-encoded in transit.

You rarely hand-build that structure. Every SDK ships a document-style client or marshaller — the JavaScript DynamoDBDocumentClient, Python's resource-level Table, Java's Enhanced Client — that converts native objects (dicts, POJOs, plain JavaScript objects) to DynamoDB attribute types on write and back to native types on read. Nested JSON maps cleanly onto M and L attributes, so a document that would be one opaque JSON blob elsewhere becomes queryable structure in DynamoDB. The exam expects you to know that the SDK, not your application code, owns this translation.

Two design consequences follow. First, serialize only what you query or must retrieve together: item size drives both the 400 KB ceiling and per-request capacity, so a compact item holding an S3 pointer beats an item embedding a large payload. Second, choose attribute types deliberately — storing a timestamp as N (epoch seconds) enables sort key range conditions and DynamoDB TTL, while an ISO-8601 string sorts correctly as S and stays human-readable. Either works; mixing the two across items breaks range queries.

Choosing between relational and non-relational stores is an access-pattern decision, not a popularity contest. Amazon RDS and Amazon Aurora give you full SQL: ad hoc queries, multi-table joins, complex transactions, and compatibility with existing ORM-based codebases. They fit when query patterns are unknown up front or genuinely relational — reporting, normalized schemas, aggregations across entities. The developer-level trade-offs: connection management matters (many concurrent Lambda invocations can exhaust a connection pool, the problem RDS Proxy exists to solve), and scaling writes means scaling the instance. DynamoDB inverts the model: you design the table around known access patterns, and in exchange you get single-digit-millisecond latency at any scale, no connection pooling, native IAM authentication, and per-request pricing. Exam questions signal DynamoDB with phrases like key-value access, massive scale, serverless, or unpredictable traffic — and signal RDS or Aurora with joins, complex queries, or an existing SQL application.

Skill 1.3.9 adds specialized stores chosen by access pattern. Amazon OpenSearch Service is the answer for full-text search, relevance ranking, fuzzy matching, and log analytics — patterns DynamoDB serves badly because they cannot be expressed as key lookups. A common architecture streams DynamoDB changes into OpenSearch so the table remains the system of record while OpenSearch answers search queries. Amazon MemoryDB is a Redis-compatible in-memory database with multi-AZ durability via a distributed transaction log: unlike a cache, it can serve as the primary database when you need microsecond reads on data you cannot afford to lose. Amazon Athena rounds out the pattern list — SQL directly over data sitting in S3, for analytics without loading a database at all.

Placing data on the right storage service is the other half of this task. Amazon S3 is object storage: HTTP-addressed, effectively unlimited, the default home for user uploads, static assets, exports, and any payload too large for a database item. Amazon EBS is block storage — a network-attached disk bound to an EC2 instance in a single Availability Zone, right for self-managed databases or anything expecting low-latency block access. Amazon EFS is a shared NFS filesystem that many EC2 instances, containers, or Lambda functions can mount simultaneously — the answer when multiple compute nodes must read and write the same files.

Distinguish persistent from ephemeral storage. Lambda's /tmp directory (512 MB by default, configurable up to 10 GB) survives only as long as the execution environment does — use it as scratch space, never as a store of record. EC2 instance store volumes are physically attached and fast, but their data is lost when the instance stops or terminates. Anything that must outlive the compute belongs in S3, EBS, EFS, or a database.

S3 storage classes and data lifecycles

S3 storage classes trade retrieval speed for cost: Standard for hot data, Intelligent-Tiering when access patterns are unknown (it moves objects between tiers automatically), Standard-IA and One Zone-IA for infrequently accessed data, and the Glacier classes for archives. Lifecycle rules automate the journey — transition objects to cheaper classes after a set age, expire them entirely, or clean up incomplete multipart uploads. On the DynamoDB side, TTL does the lifecycle job: designate a number attribute holding an epoch-seconds timestamp, and a background process deletes expired items at no write cost. Deletion is not instantaneous — expired items can linger briefly and still appear in reads, so filter them out in code if exactness matters; TTL deletes also flow into DynamoDB Streams for downstream cleanup.

A cache sits between your code and the data store to cut latency and read load, and the exam tests the strategies more than the services. With lazy loading (cache-aside), code checks the cache first and, on a miss, reads the database and writes the result into the cache. Only requested data is cached, but every miss pays a penalty and entries can go stale. With write-through, code updates the cache on every database write: reads are always fresh, but you cache data nobody may read and every write does double work. Real systems combine both and attach a TTL to every entry so stale or orphaned data ages out; explicit invalidation (deleting keys on update) tightens freshness where TTLs are too blunt. A read-through cache moves the miss-handling out of your code entirely — the cache itself fetches from the store, which is exactly the model DAX implements.

DAX is the trigger-word answer when a question pairs DynamoDB with microsecond latency or asks to accelerate reads without modifying application logic — its client is API-compatible with the DynamoDB SDK and caches GetItem and BatchGetItem results (item cache) plus Query and Scan results (query cache). Choose ElastiCache instead when caching anything other than DynamoDB — RDS query results, session state, computed aggregates — or when you need Redis data structures. Boundary note: caching whole HTTP responses at the edge is CloudFront's job, and encrypting cached or stored data belongs to Domain 2.