MLA-C01 Practice Question: Secure access to a SageMaker real-time endpoint

A company wants to secure access to a SageMaker real-time endpoint. Which TWO actions should be taken? (Select two.)

⚠ Common exam trap

Watch out — candidates often confuse sts:AssumeRole with direct invocation permissions, or think that AWS WAF can be applied to any AWS service endpoint, when in fact SageMaker endpoints are not supported by WAF.

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

✓

Attach a resource-based policy to the endpoint.

Option B is correct because SageMaker real-time endpoints support resource-based policies (endpoint policies) that let you grant or restrict InvokeEndpoint access to specific principals, AWS accounts, organizations, or source VPC/VPC endpoint conditions, which directly secures who can invoke the endpoint. Option E is correct because configuring the endpoint as private within a VPC and accessing it through an interface VPC endpoint (AWS PrivateLink) keeps invocation traffic off the public internet and enforces network-level isolation. Option A is not correct because sts:AssumeRole is an IAM permission for obtaining temporary credentials, not a mechanism for securing endpoint invocation itself. Option C is not correct because AWS WAF protects HTTP(S) resources like CloudFront, ALB, and API Gateway, and cannot be attached to a SageMaker endpoint. Option D is not correct because CloudTrail provides auditing and logging of API activity, not access control or security enforcement.

Answer analysis

Option-by-option breakdown

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

✗
Use an IAM role with sts:AssumeRole for invocation.
Why it's wrong here
An IAM role with sts:AssumeRole governs which principal may call InvokeEndpoint, but it does not encrypt traffic or restrict access at the network layer. It is tempting because IAM roles are genuinely the mechanism for authorising SageMaker API calls, and they would be correct for granting a Lambda function or application permission to invoke the endpoint.
✓
Attach a resource-based policy to the endpoint.
Why this is correct
A resource-based policy on the endpoint defines which principals may invoke it, restricting access at the endpoint itself. This satisfies the requirement to secure access by controlling cross-account or explicit principal permissions, complementing identity-based IAM policies.
✗
Enable AWS WAF on the endpoint.
Why it's wrong here
AWS WAF filters HTTP request patterns at CloudFront or an Application Load Balancer; SageMaker real-time endpoints expose no such integration point, so WAF cannot attach to them. It is tempting because WAF genuinely protects public web endpoints from injection and bot traffic, and it would be correct for an API Gateway or ALB fronting the model.
✗
Use AWS CloudTrail to log all invocations.
Why it's wrong here
CloudTrail records control-plane and, where configured, data-plane API activity for auditing; it observes invocations after the fact and enforces nothing. It is tempting because CloudTrail genuinely provides compliance evidence and anomaly detection, and it would be correct when the requirement is traceability of who invoked which API rather than restricting access.
✓
Configure the endpoint to be private within a VPC and use VPC endpoints.
Why this is correct
Placing the endpoint in a VPC and reaching it through VPC endpoints keeps inference traffic on the private network, removing public internet exposure. This satisfies the security requirement by enforcing network-level isolation for endpoint invocation.

Go deeper

MLA-C01 Practice Question: Secure access to a SageMaker real-time endpoint

Why each option matters

Option-by-option breakdown

Related to this question