Skip to main content

AWS DVA-C02 Drill: Cross-Account KMS Key Policies - Enforcing Least Privilege Access

Jeff Taakey
Author
Jeff Taakey
21+ Year Enterprise Architect | AWS SAA/SAP & Multi-Cloud Expert.

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 which permissions belong to the KMS key policy versus the Secrets Manager resource policy or IAM roles. In production, this is about knowing exactly how least privilege works with cross-account KMS key usage for secret decryption. Let’s drill down.

The Certification Drill (Simulated Question)
#

Scenario
#

At CloudWorks Solutions, a developer is building a microservices app deployed in AWS AccountAlpha. The app needs to retrieve a secret stored in AWS Secrets Manager within AWS AccountBeta. This secret is encrypted using a KMS key owned by AccountBeta. The app’s IAM role in AccountAlpha already has Secrets Manager permissions to get the secret, but the KMS key policy in AccountBeta must explicitly permit the app’s role from AccountAlpha to use the key to decrypt the secret.

The Requirement:
#

Add the minimum required permissions in the AWS KMS key policy for AccountBeta’s key to grant least privilege cross-account access so the app’s role in AccountAlpha can decrypt the secret.

The Options
#

  • A) kms:Decrypt and kms:DescribeKey
  • B) secretsmanager:DescribeSecret and secretsmanager:GetSecretValue
  • C) kms:*
  • D) secretsmanager:*

Google adsense
#

leave a comment:

Correct Answer
#

A) kms:Decrypt and kms:DescribeKey

Quick Insight: The Developer Imperative
#

  • When decrypting a secret encrypted with a KMS key, the IAM principal must have kms:Decrypt permission on that key.
  • kms:DescribeKey is commonly included to allow the caller to inspect the key metadata.
  • Giving kms:* is over-permissive and violates least privilege.
  • Secrets Manager permissions alone don’t grant access to decrypt; the key policy must also allow kms:Decrypt.

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 A

The Winning Logic
#

The KMS key policy must allow the role in AccountAlpha to perform kms:Decrypt on the key to enable decrypting the secret’s ciphertext. Without this permission, Secrets Manager cannot use the KMS key to return plaintext. The kms:DescribeKey allows the caller to get key metadata, which is useful and commonly included but not sufficient alone. Least privilege means granting only the necessary permissions (kms:Decrypt and optionally kms:DescribeKey), so broad permissions like kms:* are excessive and insecure.

The Trap (Distractor Analysis):
#

  • Why not B? These permissions apply to Secrets Manager, not the KMS key. Even with these, decryption would fail if KMS key policy lacks permission.
  • Why not C? kms:* includes all permissions, violating least privilege by granting potentially dangerous abilities like kms:ScheduleKeyDeletion.
  • Why not D? Permissions on Secrets Manager alone do not control KMS key use — the KMS key policy must explicitly allow decrypt operations.

The Technical Blueprint
#

{
    "Version": "2012-10-17",
    "Id": "key-policy-cross-account-access",
    "Statement": [
        {
            "Sid": "AllowUseOfKeyForAccountAlphaRole",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::ACCOUNT_ALPHA_ID:role/YourAppRole"
            },
            "Action": [
                "kms:Decrypt",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        }
    ]
}

The Comparative Analysis (Mandatory for Associate/Pro/Specialty)
#

Option API Complexity Performance Impact Use Case
A Minimal & precise Low Least privilege KMS cross-account key use for decryption
B Misplaced permissions None Secrets Manager permissions, insufficient for KMS usage
C Overly broad Potential security risks Grants excessive KMS key permissions
D Overbroad Secrets Manager None No effect on KMS key permission requirement

Real-World Application (Practitioner Insight)
#

Exam Rule
#

“For the exam, always pick kms:Decrypt permission when you see cross-account decryption of Secrets Manager secrets using a KMS key.”

Real World
#

“In reality, properly scoped KMS key policies combined with resource policies and IAM roles form a layered security design to enforce least privilege and compliance.”


(CTA) Stop Guessing, Start Mastering
#


Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam.

The DevPro Network: Mission and Founder

A 21-Year Tech Leadership Journey

Jeff Taakey has driven complex systems for over two decades, serving in pivotal roles as an Architect, Technical Director, and startup Co-founder/CTO.

He holds both an MBA degree and a Computer Science Master's degree from an English-speaking university in Hong Kong. His expertise is further backed by multiple international certifications including TOGAF, PMP, ITIL, and AWS SAA.

His experience spans diverse sectors and includes leading large, multidisciplinary teams (up to 86 people). He has also served as a Development Team Lead while cooperating with global teams spanning North America, Europe, and Asia-Pacific. He has spearheaded the design of an industry cloud platform. This work was often conducted within global Fortune 500 environments like IBM, Citi and Panasonic.

Following a recent Master’s degree from an English-speaking university in Hong Kong, he launched this platform to share advanced, practical technical knowledge with the global developer community.


About This Site: AWS.CertDevPro.com


AWS.CertDevPro.com focuses exclusively on mastering the Amazon Web Services ecosystem. We transform raw practice questions into strategic Decision Matrices. Led by Jeff Taakey (MBA & 21-year veteran of IBM/Citi), we provide the exclusive SAA and SAP Master Packs designed to move your cloud expertise from certification-ready to project-ready.