A company uses Amazon SageMaker for its ML process. A compliance audit discovers that an Amazon S3 bucket for training data uses server-side encryption with S3 managed keys (SSE- S3). The company requ

Question

Options

• AUpdate the IAM policy that is attached to the execution role for the training jobs. Include the
• BUpdate the S3 bucket policy that is attached to the S3 bucket. Set the value of the
• CUpdate the IAM policy that is attached to the execution role for the training jobs. Include the
• DUpdate the IAM policy that is attached to the user that created the training jobs. Include the

• A
  3% (1)
• B
  8% (3)
• C
  74% (29)
• D
  15% (6)

Explanation

Switching from SSE-S3 to SSE-KMS introduces a new authorization layer: every principal that reads or writes encrypted data must have explicit kms:GenerateDataKey and kms:Decrypt permissions on the customer managed key. SageMaker training jobs run under an execution role, so the fix is to add those KMS permissions to the IAM policy attached to that execution role - which is exactly what option C prescribes.

Why the distractors fail:

• A also targets the execution role but likely specifies incorrect KMS actions or the wrong resource ARN, making it insufficient to resolve the AccessDenied error.
• B is wrong because the bucket policy controls S3 access, not KMS access - the AccessDenied originates from KMS, not S3, so changing the bucket policy doesn't help.
• D is wrong because SageMaker jobs authenticate as the execution role, not as the IAM user who submitted the job; granting the user KMS permissions has no effect on the running job.

Memory tip: Think "who is actually making the API call?" - SageMaker jobs impersonate the execution role, not the human who triggered them. Any time you add SSE-KMS to a resource used by a service, ask "does the service's execution/service role have kms:GenerateDataKey and kms:Decrypt?" If not, that's your fix.

No community discussion yet for this question.