Scope the CMK key policy to S3/DynamoDB/Lambda/EKS and deny unencrypted S3/DynamoDB via SCP

SCS-C02 By islever Editorial Last updated

Design and implement controls that provide confidentiality and integrity for data at rest. Design, implement, and troubleshoot authorization for AWS resources.

Short answer

C Scope the CMK key policy to S3, DynamoDB, Lambda, and EKS, and use an SCP to deny unencrypted S3/DynamoDB creation.

Question

A company uses AWS Organizations to manage several AWS accounts. The company processes a large volume of sensitive data. The company uses a serverless approach to microservices. The company stores all the data in either Amazon S3 or Amazon DynamoDB. The company reads the data by using either AWS Lambda functions or container-based services that the company hosts on Amazon Elastic Kubernetes Service (Amazon EKS) on AWS Fargate. The company must implement a solution to encrypt all the data at rest and enforce least privilege data access controls. The company creates an AWS Key Management Service (AWS KMS) customer managed key. What should the company do next to meet these requirements?
  1. Create a key policy that allows the kms:Decrypt action only for Amazon S3 and DynamoDB. Create an SCP that denies the creation of S3 buckets and DynamoDB tables that are not encrypted with the key.
  2. Create an IAM policy that denies the kms:Decrypt action for the key. Create a Lambda function than runs on a schedule to attach the policy to any new roles. Create an AWS Config rule to send alerts for resources that are not encrypted with the key.
  3. Create a key policy that allows the kms:Decrypt action only for Amazon S3, DynamoDB, Lambda, and Amazon EKS. Create an SCP that denies the creation of S3 buckets and DynamoDB tables that are not encrypted with the key. Correct Answer
  4. Create a key policy that allows the kms:Decrypt action only for Amazon S3, DynamoDB, Lambda, and Amazon EKS. Create an AWS Config rule to send alerts for resources that are not encrypted with the key.

Key Takeaways

Least privilege is enforced at the key layer by limiting kms:Decrypt to the specific services, and at the account layer by an SCP that blocks creating unencrypted S3/DynamoDB resources. Option C names all four consuming services (S3, DynamoDB, Lambda, EKS) in the key policy and pairs it with the preventive SCP. D drops the SCP for a reactive Config alert; A omits Lambda and EKS from the key policy. C is correct.

To encrypt all data at rest (S3, DynamoDB, Lambda, EKS) and enforce least privilege, create a CMK whose key policy allows kms:Decrypt only for those services' principals, and add an SCP that denies creation of any S3 bucket or DynamoDB table not encrypted with that key. The key policy enforces least privilege; the SCP prevents unencrypted data stores org-wide.

Common mistake: Choosing D (Config alert instead of SCP)—Config only notifies after the fact and does not prevent unencrypted creation, so it fails the 'enforce' requirement. Choosing A—its key policy omits Lambda and EKS, the two remaining data-access paths, weakening least privilege. B's scheduled-Lambda IAM attachment is brittle and not preventive.

Expert Analysis

Why the Answer Is Correct

The CMK key policy restricts kms:Decrypt to exactly the services that read the data (S3, DynamoDB, Lambda, EKS), implementing least privilege at the key layer. The SCP then prevents any account in the organization from creating S3 buckets or DynamoDB tables that are not encrypted with that key, enforcing encryption at rest preventively. Together they meet both requirements.

Why the Other Options Are Wrong

A limits the key policy to only S3 and DynamoDB, omitting Lambda and EKS, so it under-covers the stated services. B attaches a deny IAM policy via a scheduled Lambda—reactive and fragile. D replaces the preventive SCP with a Config alert, which notifies but does not stop unencrypted creation, failing the enforcement requirement. C is correct.

Community Comment Notes

Community voted C (100). Commenters reasoned the key policy must allow Decrypt only for the specified services (least privilege) and the SCP must deny creation of unencrypted S3/DynamoDB. One dissenter picked D over the S3-bucket encryption nuance, but the majority confirmed C.

Official Reference

These links open the official vendor documentation in a new tab.

Community Votes

C
100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 4 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 4

  1. heatblur 👍 3
    Answer is C because: 1. Allowing the kms:Decrypt action only for the specified services, enforcing encryption. 2. Creating an SCP to deny the creation of any unencrypted S3 buckets and DynamoDB tables. This approach ensures that all sensitive data is encrypted at rest using the customer-managed key, while still allowing the necessary access to the specified AWS services.
  2. nischal77777 👍 1 Answered C
    Key Policy: The key policy limits the kms:Decrypt action to specific services, enforcing least privilege access, which is good practice. SCP to Deny Creation: The SCP would prevent the creation of any unencrypted S3 buckets and DynamoDB tables across the entire organization
  3. PegasusForever 👍 1 Answered D
    The S3 bucket API does not support passing an explicity deny condition for unencrypted S3 bucket, it is allowed just at the object level, for that reason I am going with D.
  4. xekiva3329 👍 3 Answered C
    answer: C

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Preserve EC2 forensic evidence by isolating first, then capturing memory before stopping the instance

S-grade

Grant the report Lambda Security Hub read-only access because findings are already in Security Hub

S-grade

Deny inbound MySQL 3306 and allow outbound TLS 443 with ephemeral return in a custom NACL

S-grade

Prepare a PHI/public-bucket audit with Macie, Audit Manager, and Security Hub FSBP

S-grade

← Back to SCS-C02 Study Guide