AWS SOA-C02 Drill: KMS Key Policy Configuration - Managing Cross-Account Access

Jeff’s Note

#

Unlike generic exam dump questions, ADH analyzes this scenario through the lens of a Real-World Site Reliability Engineer (SRE).

For SOA-C02 candidates, the confusion often lies in how to correctly grant least-privilege, cross-account KMS key access without creating needless IAM users or violating AWS best practices. In production, knowing exactly which AWS principal (role versus user) should be authorized in the KMS key policy—and why relying on the default AWS-managed keys often isn’t sufficient for vendor integrations—is vital. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

DataVine Inc. is a data analytics company partnering with a third-party service provider, SecureAnalytics, which operates in a separate AWS account. To facilitate integration, DataVine’s sensitive customer data must be stored in SecureAnalytics’ Amazon S3 bucket. For compliance reasons, DataVine needs all data to be encrypted using their own AWS Key Management Service (KMS) key. SecureAnalytics has provided DataVine with an IAM role ARN from their AWS account that will be assumed during data processing.

The Requirement:

#

As the Site Reliability Engineer for DataVine, you must ensure that DataVine securely configures cross-account KMS encryption so SecureAnalytics’ IAM role can decrypt the data in their S3 bucket. What is the best way to implement this?

The Options

#

• A) Create a new customer-managed KMS key in DataVine’s account. Add SecureAnalytics’ IAM role ARN to the key policy with decrypt permissions. Provide the KMS key ARN to SecureAnalytics to configure S3 encryption.
• B) Create a new customer-managed KMS key. Create a new IAM user. Attach an inline policy allowing decrypt to SecureAnalytics’ IAM role. Share the new IAM user ARN with SecureAnalytics.
• C) Use the default AWS-managed S3 KMS key. Add SecureAnalytics’ IAM role ARN to the key policy of the default key. Provide the key ARN to SecureAnalytics.
• D) Use the default AWS-managed S3 KMS key. Create a new S3 bucket. Attach a bucket policy granting SecureAnalytics’ IAM role access. Provide the S3 bucket ARN to SecureAnalytics.

Google adsense

#

leave a comment:

Correct Answer

#

A

Quick Insight: The SysOps Imperative

#

• KMS key policies are the primary control points that specify which IAM principals can use the key.
• Default AWS-managed S3 keys cannot be directly edited to add cross-account principals.
• Creating unnecessary IAM users adds complexity and security risk.
• Bucket policies alone don’t grant decryption rights—KMS key access must be explicitly granted.

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

#

This is the security best practice for cross-account access to customer-managed KMS keys:

• By creating a new KMS key in DataVine’s account, they retain ownership and control of the key material, ensuring compliance.
• Adding the third-party IAM role ARN directly to the key policy enables least-privilege delegation without creating any additional IAM users or unnecessary policies.
• This approach aligns with the principle that access to a key is always governed primarily by its key policy, not by IAM permissions alone.
• Providing the KMS key ARN to SecureAnalytics allows them to configure server-side encryption when writing data to their S3 bucket.

The Trap (Distractor Analysis):

#

• Why not B? Creating a new IAM user and assigning permissions via an inline policy is unnecessary, violates least privilege, and complicates credential management. Permissions for KMS keys should be granted via the key policy or correct IAM roles, not users.
• Why not C? AWS-managed S3 keys are default keys and cannot be modified to add cross-account permissions. You cannot update their key policies to authorize external principals.
• Why not D? Bucket policies control access to the bucket, but they cannot grant permissions to decrypt data encrypted with a KMS key. KMS key access must be explicitly granted in the key policy.

The Technical Blueprint

#

# Example Key Policy snippet to allow cross-account role assume and decrypt
aws kms put-key-policy --key-id <kms-key-id> --policy-name default --policy '{
  "Version":"2012-10-17",
  "Statement":[
    {
      "Sid":"Allow use of the key by SecureAnalytics Role",
      "Effect":"Allow",
      "Principal":{
        "AWS":"arn:aws:iam::123456789012:role/SecureAnalyticsRole"
      },
      "Action":[
        "kms:Decrypt",
        "kms:Encrypt",
        "kms:GenerateDataKey"
      ],
      "Resource":"*"
    }
  ]
}'

The Comparative Analysis (SysOps)

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the exam, always create a new CMK (customer-managed key) when you need fine-grained control for cross-account encryption.”

Real World

#

“In real deployments, CMKs provide accountability and key lifecycle control, critical for compliance and security audits. Avoid AWS-managed keys when your data ownership or access model crosses AWS accounts.”

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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