Passed Exam Today DVA-C02

The workload is a classic “hot key / hot dataset” pattern: many reads repeatedly target a small subset of items. The best way to improve performance and reduce latency is to add a caching layer so the application does not hit DynamoDB for every read.

Option B is purpose-built for DynamoDB read acceleration: DynamoDB Accelerator (DAX) is an in-memory cache that sits in front of DynamoDB and is API-compatible for many DynamoDB operations. DAX can dramatically reduce read latency (often to microseconds) for frequently accessed items and offload read traffic from the table.

Option A can also help: ElastiCache (Redis/Memcached) can be used as an application-managed cache. This is useful when the application wants more control over caching strategy, TTLs, and non-DynamoDB data caching. For ECS applications, ElastiCache is a common high-performance caching choice.

Why not the others:

C (strongly consistent reads) typically increases latency and capacity consumption; it does not improve performance for repeated reads.

D (increase read capacity) can reduce throttling, but it does not reduce latency as effectively as caching and can be more expensive for hot-read patterns.

E (adaptive capacity) helps DynamoDB handle uneven workloads, but it is not a direct performance boost like caching for repeated reads of a small dataset.

Therefore, adding caching via ElastiCache and/or DAX best improves performance. With “select two,” A and B are correct.

AWS Secrets Manager supports multi-Region secret replication, which is designed specifically for redundancy, disaster recovery, and multi-Region applications. With this feature, the primary secret resides in one Region (here, us-west-1) and Secrets Manager automatically maintains a replica in another Region (us-east-1). This provides local read access and resilience if one Region is impaired.

Option A accurately describes the standard configuration: enable secret replication and add us-east-1 as the replica Region. Because encryption keys are Region-scoped, the replica secret in us-east-1 should be encrypted with a KMS key in us-east-1 (either the default Secrets Manager key for that Region or a customer managed key), satisfying encryption requirements and proper key locality.

Option B is incorrect because you don’t configure replication “from the destination.” Replication is configured on the primary secret, and the replica uses a KMS key in the replica Region, not in the source Region.

Option C is not how Secrets Manager replication works. Replication is not only during rotation; it maintains replicas continuously. The “replication rule during rotation” framing is not the standard mechanism.

Option D is inappropriate and insecure/operationally complex: exporting secrets to S3 for replication is not the recommended pattern and introduces unnecessary exposure.

Therefore, enable Secrets Manager multi-Region replication and encrypt replicas with a KMS key in the destination Region.