Refer to the exhibit. A data scientist is trying to run a SageMaker training job using a script that reads data from the S3 bucket 'my-bucket' and writes the model artifact to the same bucket. The training job fails with an access denied error. What is the likely cause?
The policy only allows PutObject on training-data/*, but the model artifact might be saved to a different prefix (e.g., output/).
Why this answer
The training job fails with an access denied error because the IAM role used by SageMaker lacks the s3:PutObject permission (or equivalent write access) for the S3 bucket 'my-bucket'. While the script reads data from the bucket, writing the model artifact requires explicit write permissions on the same bucket. Without this, SageMaker cannot upload the model artifact, causing the job to fail.
Exam trap
The trap here is that candidates may focus on the read operation (data input) and overlook the write operation (model artifact output), or confuse S3 permissions with SageMaker-specific API actions like CreateModel.
How to eliminate wrong answers
Option B is wrong because sagemaker:CreateModel is a permission for creating a SageMaker model resource after training, not for writing to S3 during the training job; the error occurs during training, not model creation. Option C is wrong because s3:ListBucket is a read permission for listing objects, and the job already reads data successfully (the error is on write), so lack of ListBucket would cause a different error (e.g., 403 on list). Option D is wrong because ec2:DescribeInstances is unrelated to S3 access; it is used for managing EC2 instances, not for SageMaker training jobs writing to S3.