Task 1.3: Use data stores in application development

• APartition key set to the reading date, rounded to the day; sort key set to deviceId and timestamp

  Incorrect

  A creation date rounded to a day is a poor partition key: every write on a given day goes to the same key value.

• BPartition key set to the reading's status, such as OK, WARN or ERROR; sort key set to the timestamp

  Incorrect

  A status code with only a few possible values concentrates traffic on a few keys, the same problem as deviceType.

• CKeep deviceType as the partition key and add a local secondary index on deviceId

  Incorrect

  A local secondary index keeps the base table's partition key, so every write still lands on one of the four deviceType values.

• DPartition key set to deviceId; sort key set to the timestamp

  Correct

  deviceId has many distinct values, so writes spread across partitions, and a Query on one deviceId with a timestamp range serves each read.

Choose a partition key with many distinct, evenly accessed values; low cardinality keys such as types, statuses or dates create hot partitions.

• AAdd a global secondary index with customerId and orderDate as keys, and Query it

  Correct

  A global secondary index can have a different key schema from the table, so a Query on one customerId with a sort key condition reads only that customer's recent orders.

• BKeep the Scan and add a ProjectionExpression that returns only the needed attributes

  Incorrect

  A projection only trims the attributes returned. The Scan still reads every item in the table.

• CKeep the Scan and move the customer and date checks into a FilterExpression

  Incorrect

  A filter expression is applied after the Scan reads the data, so it consumes the same read capacity.

• DCreate a local secondary index with customerId as its sort key

  Incorrect

  A local secondary index keeps the table's partition key, orderId, so it cannot find all orders of one customer.

Design for Query: add an index whose keys match the access pattern instead of scanning and filtering.

• ARead the profile from a global secondary index of the table instead

  Incorrect

  All reads from a global secondary index are eventually consistent, so they can also return old data.

• BWait one second before the GetItem call and read again if the data looks old

  Incorrect

  An eventually consistent read should return the newer item after a short time, but nothing guarantees it on any given attempt.

• CSet ConsistentRead to true on the GetItem call

  Correct

  A strongly consistent read returns the most up-to-date data, reflecting all prior successful writes. Tables and local secondary indexes support it.

• DRead the latest change for the profile from the table's DynamoDB stream

  Incorrect

  Reads from DynamoDB Streams are eventually consistent, and strongly consistent reads from a stream are not supported.

GetItem, Query and Scan are eventually consistent by default; ConsistentRead set to true gives read-after-write on tables and local secondary indexes, at twice the read cost.

• ASend both instances' changes in one BatchWriteItem call

  Incorrect

  Each put or delete in a batch is atomic on its own, but BatchWriteItem as a whole is not, and it does not compare the item with what was read.

• BStore a version number and write only if the version is still unchanged

  Correct

  This is optimistic locking: the conditional write succeeds only if the version still matches, and a stale writer gets a failed condition check and can reread and retry.

• CRead the item with ConsistentRead set to true before every change

  Incorrect

  A strongly consistent read returns the latest data at read time, but another writer can still change the item before the PutItem call.

• DCall PutItem with ReturnValues set to ALL_OLD and compare the old item afterward

  Incorrect

  ALL_OLD returns the item that was replaced, which only shows after the fact that a newer change was overwritten.

Condition expressions make writes conditional; a version attribute turns them into optimistic concurrency control.

• AA Lambda function triggered by the table's stream that deletes each session 24 hours after it is written

  Incorrect

  A stream trigger reacts when an item changes, not a day later, and the deletes it issues are ordinary writes.

• BPoint-in-time recovery with a recovery period of 1 day

  Incorrect

  Point-in-time recovery keeps continuous backups for restoring the table. It does not delete items from the live table.

• CA scheduled function that deletes expired sessions with BatchWriteItem in groups of 25

  Incorrect

  Batching reduces the number of calls, but each delete in the batch is still a write against the table's capacity.

• DTime to Live on an expiresAt attribute that holds epoch seconds and is reset on each activity

  Correct

  With TTL enabled, DynamoDB deletes items whose expiration time has passed without consuming write throughput, typically within a few days of expiry.

TTL is the built-in, no-cost way to expire items; store the timestamp as a Number in epoch seconds and filter expired items out of reads if needed.

• AWrite every product to the cache each time it is written to the database, with keys that never expire

  Incorrect

  Write-through keeps cached data fresh, but it fills the cache with products that may never be read, which breaks the first requirement.

• BPut DynamoDB Accelerator (DAX) in front of the Aurora database

  Incorrect

  DAX is a DynamoDB-compatible cache. It caches DynamoDB tables, not an Aurora database.

• COn a cache miss, read the product from the database and then store it in the cache

  Correct

  Lazy loading loads data into the cache only when it is requested, so products that nobody reads never take up cache space.

• DKeep cached items until the cache runs out of memory and evicts them

  Incorrect

  Without an expiry, a lazily loaded item is never refreshed after the database changes, so it can stay stale far longer than 5 minutes.

• ESet a time to live of 300 seconds on every key written to the cache

  Correct

  When a key expires, the next read is treated as a miss and reloads the product from the database, which bounds staleness at 5 minutes.

Lazy loading caches only what is read; adding a TTL to each key limits how stale that data can get.

• A20

  Incorrect

  One RCU covers one strongly consistent read per second only for items up to 4 KB; these items are larger.

• B30

  Incorrect

  This is what eventually consistent reads would need, at half the strongly consistent rate.

• C45

  Incorrect

  Dividing 9 KB by 4 KB without rounding up gives 2.25 units per read; capacity is rounded up to whole units.

• D60

  Correct

  9 KB divided by 4 KB, rounded up, is 3 RCUs per strongly consistent read, and 3 times 20 reads per second is 60.

RCUs use 4 KB steps rounded up per item; eventually consistent reads need half as many.

• AWrite-through, updating the cache whenever the database is written

  Correct

  Write-through adds or updates data in the cache every time it is written to the database, so cached data is never stale.

• BLazy loading only, with a longer TTL on all of the cached catalog entries

  Incorrect

  Lazy loading updates the cache only on misses, and a longer TTL keeps stale prices even longer.

• CA larger cache node type with more memory

  Incorrect

  More memory holds more entries but does not refresh them when prices change.

• DMore replicas of the cache cluster for reads

  Incorrect

  Replicas spread read load; they do not update data when the database changes.

Combine write-through with lazy loading and TTLs when data must stay current in the cache.

• AAn Amazon RDS for MySQL DB instance of the largest available instance size

  Incorrect

  A large fixed instance is paid for all day while it sits idle most of the time.

• BAn Amazon RDS for MySQL DB instance with a read replica

  Incorrect

  A read replica adds read capacity but is another fixed-size instance; capacity does not follow demand.

• CAn Amazon Aurora MySQL cluster that uses Aurora serverless capacity

  Correct

  Aurora serverless adjusts capacity automatically with demand and is suited to development, test and unpredictable workloads.

• DA DynamoDB table in on-demand capacity mode

  Incorrect

  DynamoDB is not MySQL-compatible, so the application would need to be rewritten.

For variable, unpredictable relational workloads, Aurora serverless capacity scales with demand.

• ATurn on S3 Versioning so that every write is kept as a version

  Incorrect

  Versioning keeps every write as a new version; later writes still become the current object.

• BCall HeadObject first and write only when the object does not exist

  Incorrect

  Two workers can both see no object and then both write, because the check and the write are separate requests.

• CSend PutObject with the If-None-Match header

  Correct

  If-None-Match makes S3 accept the write only when no object with the same key exists, which prevents overwrites.

• DAdd an Object Lock retention period to the bucket

  Incorrect

  Object Lock protects object versions from deletion and overwrite of those versions, but new versions can still be written for the key.

S3 conditional writes give atomic create-only semantics without a separate locking service.

• AA read replica in another Availability Zone, promoted by a script on failure of the primary

  Incorrect

  Read replicas are updated asynchronously, so recent writes can be lost, and promotion is not automatic failover.

• BA Multi-AZ DB instance deployment with a standby in another Availability Zone

  Correct

  RDS keeps a synchronous standby in another Availability Zone and fails over to it automatically.

• CDaily automated snapshots copied to another Region

  Incorrect

  Restoring a snapshot is a manual recovery that loses data written since the snapshot.

• DA larger instance class with more vCPUs and memory

  Incorrect

  A bigger instance still runs in one Availability Zone.

Multi-AZ standbys provide high availability; they do not serve reads, for which read replicas are used.