MLA-C01 Practice Question: A company deploys a model using SageMaker and…

A company deploys a model using SageMaker and enables data capture for monitoring. After a week, they notice that the captured data is not being written to the specified S3 bucket. The endpoint is running and invocations are successful. What is the most likely cause?

⚠ Common exam trap

Many candidates assume data capture fails due to endpoint misconfiguration (like missing CaptureOptions) or regional restrictions, when in fact the root cause is almost always an IAM permissions issue with the S3 bucket.

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

✓

The IAM role used for the endpoint does not have s3:PutObject permission for the capture bucket.

The most likely cause is that the IAM role associated with the SageMaker endpoint lacks the `s3:PutObject` permission for the target S3 bucket. Without this permission, the endpoint cannot write the captured inference data to S3, even though invocations succeed because the model itself does not require S3 write access to serve predictions.

Answer analysis

Option-by-option breakdown

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

✓
The IAM role used for the endpoint does not have s3:PutObject permission for the capture bucket.
Why this is correct
Data capture writes inference request and response records to S3 using the endpoint's execution role. Successful invocations confirm the model works, so the missing writes point to the role lacking s3:PutObject on the capture bucket, which silently blocks capture delivery.
✗
The capture bucket is in a different region.
Why it's wrong here
SageMaker data capture writes to an S3 bucket in the same Region as the endpoint, and cross-Region buckets are not supported, so a different-Region bucket would fail at configuration time rather than silently. It is tempting because S3 buckets are globally named, but capture requires a same-Region bucket.
✗
The endpoint is using a multi-model endpoint which does not support data capture.
Why it's wrong here
Multi-model endpoints do support data capture, so this premise is false. It is tempting because multi-model endpoints have documented feature limitations, but data capture is not among them; the actual cause lies in the S3 permissions or configuration.
✗
The DataCaptureConfig parameter in the endpoint configuration is missing the "CaptureOptions" field.
Why it's wrong here
CaptureOptions is optional and defaults to capturing both request and response data, so its absence would not stop S3 delivery. It is tempting because it is a real DataCaptureConfig field, but omitting it changes what is captured, not whether capture occurs.

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 company deploys a model using SageMaker and…

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question