A machine learning team deploys a custom container image for an Amazon SageMaker training job. The container needs to access an S3 bucket that contains sensitive data. The team wants to follow the principle of least privilege. How should the team grant access?
This is the standard secure method.
Why this answer
Option A is correct because SageMaker training jobs use an IAM execution role to grant permissions to AWS services like S3. By creating a dedicated IAM role with only the necessary S3 actions (e.g., s3:GetObject, s3:PutObject) and assigning it as the SageMaker execution role, the team follows the principle of least privilege. SageMaker automatically assumes this role via AWS Security Token Service (STS) to access the S3 bucket on behalf of the container, without embedding credentials.
Exam trap
The trap here is that candidates confuse SageMaker's execution role mechanism with EC2 instance profiles, assuming you can attach an IAM role directly to the underlying instance, but SageMaker abstracts instance management and only supports execution roles for granting permissions.
How to eliminate wrong answers
Option B is wrong because SageMaker training jobs do not support attaching an IAM instance profile directly to the training instance; SageMaker manages the underlying EC2 instances and uses the execution role instead. Option C is wrong because a training job does not have an ARN that can be used in an S3 bucket policy; bucket policies grant access to IAM principals (users, roles, accounts) or VPC endpoints, not to job ARNs. Option D is wrong because storing AWS access keys in a container image violates security best practices (e.g., AWS IAM recommends never embedding long-term credentials) and makes key rotation difficult, increasing the risk of exposure.