MLA-C01 Practice Question: A team is deploying a real-time inference…

A team is deploying a real-time inference endpoint in SageMaker. The model requires access to an S3 bucket containing customer data, which is encrypted with SSE-KMS. The team needs to ensure that the endpoint can decrypt the data. Which IAM role configuration is necessary?

⚠ Common exam trap

Many exam-takers confuse the permissions needed for encryption (kms:GenerateDataKey) with those needed for decryption (kms:Decrypt), or incorrectly think that S3 bucket policies can grant permissions to KMS keys.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Add kms:Decrypt permission to the SageMaker execution role for the specific KMS key.

The SageMaker execution role must have the kms:Decrypt permission for the specific KMS key that encrypted the S3 objects. When the endpoint reads data from the S3 bucket, SageMaker uses its execution role to call KMS to decrypt the data. Without this permission, the endpoint will fail with an access denied error, even if the S3 bucket policy allows s3:GetObject.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Add kms:GenerateDataKey permission to the SageMaker execution role.
Why it's wrong here
kms:GenerateDataKey lets the role create data keys for encryption, not decrypt existing ciphertext. It is tempting because GenerateDataKey appears in KMS policies for writing encrypted objects, and would be correct for a role uploading SSE-KMS objects, but reading requires kms:Decrypt on the customer managed key.
✗
Attach a policy to the S3 bucket granting s3:GetObject to the KMS key.
Why it's wrong here
S3 bucket policies govern S3 actions such as s3:GetObject; they cannot grant KMS key permissions, which live in key policies or IAM identity policies. It is tempting because the failure surfaces as an S3 access error, and a bucket policy granting s3:GetObject would be right for unencrypted objects, but SSE-KMS decryption needs kms:Decrypt.
✓
Add kms:Decrypt permission to the SageMaker execution role for the specific KMS key.
Why this is correct
Granting kms:Decrypt on the specific customer-managed key to the SageMaker execution role lets the endpoint's containers call the KMS Decrypt API, satisfying the SSE-KMS constraint. Without this key-policy or IAM allowance, S3 returns AccessDenied on GetObject, since the role, not the bucket, must hold decrypt rights.
✗
Configure the endpoint to assume the S3 bucket's IAM role.
Why it's wrong here
S3 buckets have bucket policies, not assumable IAM roles, so there is no bucket role for the endpoint to assume. It is tempting because cross-account access patterns often use role assumption, and that would be correct when the endpoint must access resources in another account, but here the SageMaker execution role simply needs kms:Decrypt.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

MLA-C01 Practice Question: A team is deploying a real-time inference…

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question