SAP-C02 Practice Question 53: Secrets Across Regions
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 6 · question 3 of 10
A payments API runs active in eu-west-1 with a pilot light standby in eu-central-1. Database credentials and third-party API keys are held in AWS Secrets Manager in eu-west-1, and the secrets rotate automatically every 30 days.
A failover rehearsal failed. The standby stack started but every request errored, because the application in eu-central-1 was calling the eu-west-1 Secrets Manager endpoint, which was deliberately unavailable in the simulated Region outage. The team's earlier attempt to fix this (creating a second copy of each secret in eu-central-1) drifted out of sync the first time rotation ran.
The fix must let the standby Region read the current secret value from its own Region during a failover, must keep one rotation schedule so a rotated value cannot diverge between Regions, and must not involve a copy job the team writes and maintains.
What should the solutions architect do?
Show answer and explanation
Answer:
Secrets Manager replicates secrets to other Regions specifically to support applications spread across Regions with Regional access and low latency requirements, copying the encrypted secret data and metadata such as tags and resource policies. The rotation behaviour is the detail that fixes the drift the team hit: AWS states that if you turn on rotation for the primary secret, Secrets Manager rotates it in the primary Region and the new value propagates to all associated replica secrets, so you don't manage rotation individually for each replica. There is one schedule and one authoritative value. The replica's ARN differs from the primary's only in the Region, so the standby application reads the secret from its own Region with essentially the same identifier and no cross-Region call in the failover path. A replica can also be promoted to a standalone secret later if the standby becomes primary.
Option A replaces a managed capability with the copy job the stem rules out, and a scheduled copy is exactly the mechanism that lets a rotated credential go stale between runs.
Option B is what failed during the rehearsal. A VPC peering connection does not make the eu-west-1 Secrets Manager service endpoint reachable during a Region impairment; the standby must not depend on the Region it is recovering from.
Option C produces two secrets and two rotation functions. Rotating a database credential twice independently means one Region's stored value stops matching the credential the database accepts, which is the divergence the requirement forbids.
Reference: Replicate AWS Secrets Manager secrets across Regions