SAP-C02 Practice Question 35: Cross Region Encryption Keys
AWS Certified Solutions Architect – Professional (SAP-C02) · Test 4 · question 5 of 10
A healthcare platform encrypts patient documents on the client side with the AWS Encryption SDK before storing the ciphertext, using a customer managed AWS KMS key in us-east-1. About 500 TB of ciphertext has accumulated, and it is copied continuously to us-west-2 for disaster recovery.
A tabletop exercise exposed a gap: during a simulated us-east-1 impairment, the standby stack in us-west-2 could read the copied ciphertext but could not decrypt any of it. The fix must let the standby Region decrypt both the historical 500 TB and newly written documents with no dependency on us-east-1 being reachable, must not require re-encrypting the existing data, and must keep the key material inside AWS KMS at all times.
What should the solutions architect do?
Show answer and explanation
Answer:
Multi-Region keys are KMS keys in different Regions that can be used interchangeably: related multi-Region keys share the same key ID and the same key material, so data encrypted in one Region can be decrypted in another without re-encrypting it and without a cross-Region call to AWS KMS. AWS lists disaster recovery as the first use case and specifically names client-side encryption libraries, including the AWS Encryption SDK, as where multi-Region keys fit. The replica key is a fully functional, independent key that keeps working even if the primary and all other replicas are disabled, which is what makes the standby Region self-sufficient during an impairment. The one wrinkle the option names honestly is that an existing single-Region key cannot be converted to a multi-Region key, so historical data must be brought under the new key; the stem's requirement is that the 500 TB not be re-encrypted, which is satisfied by keeping the old key available for reads while new writes use the multi-Region key.
Option B is the re-encryption the stem rules out, on 500 TB, and it does not even fix the dependency: each object must first be decrypted with the us-east-1 key, so the job cannot run during the very outage it is meant to survive.
Option C leaves the single point of failure exactly where it is. A cross-Region grant still means every decrypt is an API call into us-east-1 KMS, so an impairment there stops decryption in the standby Region, the failure the exercise found.
Option D is not possible for a key whose material AWS KMS generated: key material never leaves AWS KMS unencrypted and cannot be exported. Even with imported material, a separately created key has a different key ID, and the ciphertext records the key it was encrypted under.
Reference: Multi-Region keys in AWS KMS