Jeff’s Note #
Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.
For DVA-C02 candidates, the confusion often lies in the subtleties of cross-account KMS key policies and how to correctly enable encryption when copying data between accounts. In production, this is about knowing exactly how to configure KMS keys for cross-account access without replicating keys or relying on incorrect defaults. Let’s drill down.
The Certification Drill (Simulated Question) #
Scenario #
Tech Solutions Inc. manages two AWS accounts: one for production workloads and one for development tasks. Production stores sensitive user data in an Amazon S3 bucket encrypted with a customer managed AWS KMS key under their production account. The development team needs to copy this data into an S3 bucket located in the development account. For compliance reasons, the data in the development bucket must also be encrypted using a KMS key, but this key must be accessible — with proper permissions — from the production account to support seamless data transfer operations.
The Requirement: #
Establish a secure, compliant method to use a KMS key in the development account that can be accessed from the production account to encrypt data copied from production, without replicating keys improperly or violating cross-account access best practices.
The Options #
- A) Replicate the customer managed KMS key from the production account to the development account. Specify the production account in the key policy.
- B) Create a new customer managed KMS key in the development account. Specify the production account in the key policy.
- C) Create a new AWS managed KMS key for Amazon S3 in the development account. Specify the production account in the key policy.
- D) Replicate the default AWS managed KMS key for Amazon S3 from the production account to the development account. Specify the production account in the key policy.
Google adsense #
leave a comment:
Correct Answer #
B
Quick Insight: The Developer Imperative #
- AWS SDKs and API operations require explicit trust relationships when accessing KMS keys across accounts.
- You cannot replicate customer managed keys across accounts; they must be created per account.
- AWS managed keys cannot be shared or replicated because they are account-specific and managed by AWS.
- Proper cross-account access requires creating a new CMK in the target account with key policies granting the source account permission.
Content Locked: The Expert Analysis #
You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?
The Expert’s Analysis #
Correct Answer #
Option B
The Winning Logic #
- A new customer managed KMS key (CMK) must be created in the development account because KMS keys are region- and account-specific resources that cannot be “replicated” across accounts.
- The key policy of this new CMK in the dev account must explicitly grant the production account permission to use this key for encryption operations.
- This setup allows the production account to encrypt data when writing to the development account’s S3 bucket without sharing or copying keys insecurely.
- This approach follows AWS best practices for least privilege and cross-account security in KMS.
The Trap (Distractor Analysis): #
-
Why not A?
KMS keys cannot be replicated between accounts. You cannot “copy” a customer managed key to another account. -
Why not C?
AWS managed keys are created, owned, and managed by AWS per service per account and cannot be shared or modified to allow cross-account access. -
Why not D?
Default AWS managed keys cannot be copied or replicated across accounts. They do not support custom key policies and cannot grant cross-account permissions.
The Technical Blueprint #
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowProductionAccountToUseKey",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::PRODUCTION_ACCOUNT_ID:root"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "*"
}
]
}
Snippet: Example KMS key policy granting the production account usage permissions on a dev account CMK.
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Invalid - not supported | N/A | Attempting to replicate CMKs across accounts (impossible) |
| B | Moderate - Create new CMK and update key policy | Good | Recommended pattern for cross-account encryption using CMK |
| C | Low - uses AWS managed key but cannot grant permissions | N/A | AWS Managed keys cannot support cross-account grants |
| D | Invalid - default keys can’t be replicated | N/A | Default keys are account specific and cannot be shared |
Real-World Application (Practitioner Insight) #
Exam Rule #
For the exam, always pick “Create a new Customer Managed Key” in the target account and set explicit cross-account key policies when encryption involves multiple AWS accounts.
Real World #
In production, sometimes we automate the creation of the CMK with Infrastructure as Code (IaC) tools and tightly scope permissions with IAM roles to further secure cross-account workflows beyond just the key policy.
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the DVA-C02 exam.