A city’s multi-Region DR plan replicates compute templates and databases, but after failover the standby Region cannot decrypt application secrets. What dependency was likely missed?
Select an answer to reveal the explanation.
Short Explanation
Failover without keys is a locked vault in the backup building. Secrets and KMS must exist—or be replicable—in the secondary Region or decrypt fails even when servers boot. Compute templates alone are not a full DR kit.
Full Explanation
A city’s multi-Region DR plan that replicates compute templates and databases can still fail after failover if the standby Region cannot decrypt application secrets. The dependency commonly missed is availability of secrets and KMS keys—or their replicas—in the secondary Region. Servers that boot without ciphertext access, CMK permissions, or replicated Secrets Manager or Parameter Store material will not become healthy citizen-facing services even when AMIs and database replicas look ready.
Extra public IPv4 addresses in the primary Region only are unrelated to decrypt-after-failover and do not fix missing keys in the standby Region. Larger EBS gp2 volumes attached only to primary bastion hosts fail as an explanation because bastion disk size does not unlock application envelopes in the secondary Region. CloudTrail trails writing exclusively to the failed Region’s local disk are an observability anti-pattern and still do not provide KMS or secrets availability for decrypt.
Exam caveat: replicating secrets without also granting the standby roles decrypt permission on the correct CMKs still leaves failover broken. Operational check: inventory every secret and CMK the application needs, enable multi-Region keys or explicit replica keys and secret replication, test decrypt from the standby Region before declaring DR ready, and include key/secret checks in readiness reviews.