DVA-C02 Exam Dumps : AWS Certified Developer - Associate

To rotate database credentials without downtime, Secrets Manager recommends the alternating users (dual user) rotation strategy. With a single-user strategy, Secrets Manager changes the password for the same database user that the application is actively using. If the application continues using cached/old credentials during rotation, authentication failures and downtime can occur.

With the alternating users strategy, two database users exist (often named something like appuser and appuser_clone). Secrets Manager alternates which user is “active” in the secret. During rotation, Secrets Manager updates the inactive user’s password, verifies it, updates the secret to point to the newly updated user, and then (optionally) retires the old credentials. This approach minimizes disruption because there is always one known-good credential set while the other is being updated.

The question specifically requires regular rotation using Secrets Manager. That is achieved by enabling automatic rotation on the secret with a schedule (for example, every 30/60/90 days). Automatic rotation invokes the rotation Lambda (AWS-provided or configured) and performs the workflow without manual intervention.

Option D combines both requirements: automatic rotation plus the alternating users strategy for high availability and no downtime.

Option B mentions alternating users but “managed rotation” is not the standard term used in these choices as the primary differentiator—automatic rotation is the necessary capability to rotate regularly without manual effort.

Options A and C (single user) are more likely to cause downtime during rotation.

Therefore, configure automatic rotation with the alternating users rotation strategy.

By default, an Auto Scaling group uses EC2 status checks to determine instance health. EC2 status checks confirm that an instance is running and reachable at the infrastructure level, but they do not validate that the application is healthy behind the load balancer. In this scenario, the ALB is returning HTTP 502 errors and the target group shows instances as unhealthy, meaning the application is failing health checks (or not responding correctly). However, because the Auto Scaling group is using the default EC2 health check type, it does not consider these instances unhealthy for replacement.

AWS recommends configuring the Auto Scaling group to use ELB health checks when instances serve traffic behind an ALB or NLB. With ELB health checks enabled, Auto Scaling evaluates target health as reported by the load balancer target group. If the ALB marks an instance unhealthy, the Auto Scaling group will treat that instance as unhealthy and terminate and replace it automatically, restoring capacity with healthy targets.

Why the other options are insufficient:

Cooldown period (A) affects scaling timing, not health replacement logic.

Lifecycle hook changes (B) can help with initialization timing, but they do not cause Auto Scaling to replace instances based on ALB target health unless ELB health checks are enabled.

Health check grace period (D) delays health evaluation after launch, which can reduce premature replacement, but it still won’t replace instances based on ALB target group status unless the health check type is ELB.

Therefore, switching the Auto Scaling group health check type to Elastic Load Balancing (ELB) is the correct fix.

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.