MLA-C01 Practice Question: A model deployed on a SageMaker endpoint is…

A model deployed on a SageMaker endpoint is returning predictions. The team wants to log all predictions to an S3 bucket for auditing. What is the most efficient way to achieve this?

⚠ Common exam trap

The trap here is that candidates overcomplicate the solution by choosing a streaming or custom logging approach (like Kinesis or code modification), not realizing that SageMaker provides a built-in, zero-code feature (Data Capture) specifically designed for this auditing requirement.

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

✓

Enable SageMaker endpoint data capture to the S3 bucket.

SageMaker endpoint data capture is the native, most efficient way to log predictions to S3 because it automatically captures input payloads and output predictions for all requests to the endpoint, storing them directly in the specified S3 bucket without any custom code or additional infrastructure. This feature is designed specifically for auditing and monitoring, requiring only a DataCaptureConfig to be set on the endpoint.

Answer analysis

Option-by-option breakdown

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

✓
Enable SageMaker endpoint data capture to the S3 bucket.
Why this is correct
SageMaker endpoint data capture automatically streams request and response payloads to S3 without custom inference code, satisfying the audit-logging requirement. It captures input and output data at the endpoint level, so every prediction is recorded efficiently, unlike application-side logging or CloudWatch metrics, which lack full payload fidelity.
✗
Configure CloudWatch Logs to export to S3.
Why it's wrong here
CloudWatch Logs captures endpoint invocation metadata, not the prediction payloads themselves, and exporting adds latency rather than direct capture. It is tempting because CloudWatch is the default monitoring surface for SageMaker, and would be correct for tracking latency, errors or invocation counts rather than auditing prediction content.
✗
Modify the inference code to write logs to S3.
Why it's wrong here
Modifying inference code creates custom logging logic that must be maintained and can fail silently, whereas SageMaker Data Capture handles this natively. It is tempting because application-level logging is familiar, and would be correct when predictions require bespoke transformation or enrichment before storage.
✗
Use Amazon Kinesis Data Firehose to stream predictions to S3.
Why it's wrong here
Kinesis Data Firehose requires building a custom streaming pipeline from the endpoint, adding components the native data capture feature already provides. It is tempting because Firehose reliably delivers streams to S3, and would be correct for high-volume real-time ingestion from producers such as application logs or clickstream events.

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 model deployed on a SageMaker endpoint is…

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question