SAA-C03 Design Secure Architectures Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Update the application code to supply the correct encryption context "purpose" = "myapp-secrets" when calling decrypt (and encrypt if rotating).

  Why this is correct

  The correct fix is to make the decryption call supply the exact encryption context used at encryption time, i.e., `"purpose" = "myapp-secrets"`. AWS KMS treats the encryption context as authenticated additional data (AAD): it is not stored encrypted, but it must be provided during decryption or the operation fails. If the KMS key policy condition requires `kms:EncryptionContext:purpose` to equal that value, then every decrypt request must include that context key and value to satisfy the policy. Updating the application code to consistently pass this context—both when encrypting new secrets and when decrypting existing ones—resolves the failure without weakening the key policy or forcing key rotation, and it preserves the integrity check that the context provides.

• ✗

  Add kms:Decrypt to the IAM role attached to the application without changing the key policy.

  Why it's wrong here

  Granting `kms:Decrypt` to the IAM role addresses only the IAM authorization layer; it does nothing to satisfy the separate KMS key policy condition that constrains decryption. In AWS KMS, an operation is allowed only if both the IAM policy and the key policy (and any grants) permit it—the authorization is intersectional. The key policy here explicitly evaluates the `kms:EncryptionContext` condition, and since the application's decrypt call uses a mismatched context, the request is denied even if the role has `kms:Decrypt`. Adding the IAM permission is therefore ineffective and does not resolve the actual cause, which is the encryption-context mismatch in the API call itself.

• ✗

  Disable the encryption context condition in the KMS key policy to avoid future failures.

  Why it's wrong here

  Disabling the encryption context condition in the key policy would allow the decrypt call to succeed, but it defeats the purpose of the condition, which is to restrict the KMS key's use to a specific application purpose (`myapp-secrets`). Encryption context conditions in key policies are a security best practice that provides an additional authorization boundary and also helps prevent ciphertext from being decrypted by other principals or workflows that do not know the context. Removing the condition would permit any caller with `kms:Decrypt` permission to decrypt data using this key, broadening the attack surface and violating the original security design; it is a workaround that fixes the symptom by eliminating the control, not by addressing the bug in the application code.

• ✗

  Rotate the KMS key immediately and re-encrypt all secrets with a different key ID.

  Why it's wrong here

  Rotating the KMS key or re-encrypting secrets with a new key ID is an unnecessary and disruptive remedy because key rotation does not change the encryption context requirements for existing ciphertext. When you rotate a KMS key, AWS KMS retains the old backing key for decryption of previously encrypted data, and the same KMS key ID continues to be used for both encrypt and decrypt operations—so a new key ID would break all references and force you to re-encrypt every secret. More importantly, the decryption failure is caused by the missing or incorrect encryption context in the application's decrypt call, not by the key's age or cryptographic material. Changing keys would add operational overhead and still leave the application's decrypt logic broken for any ciphertext that was created with the correct context, since that context must still be supplied to decrypt successfully.

Go deeper

Related to this question