IAM and least privilege for ML: MLA-C02 study notes and practice questions
What to know about IAM and least privilege for ML for the MLA-C02 exam, from the Operating, Monitoring, and Securing ML and AI Solutions domain (24% of the exam guide), then 2 free questions to test it. Part of the MLA-C02 study guide.
IAM questions ask how to give a job, endpoint, notebook or app exactly the access it needs, or why an action is denied.
Roles in ML workloads
SageMaker AI execution role: used by training jobs, processing jobs, endpoints, pipelines and Studio users to reach S3, ECR, CloudWatch Logs and KMS. Scope it to the buckets and prefixes the work needs.
Bedrock service roles for knowledge bases, model customization, batch inference and agents.
Lambda execution roles for agent action groups.
The trust policy controls who can assume a role; the permissions policy controls what it can do.
Narrowing access
Bedrock: grant bedrock:InvokeModel on specific model or inference profile ARNs in approved Regions instead of *.
SageMaker condition keys: require VPC settings, network isolation, volume encryption or specific instance types (such as sagemaker:VpcSubnets, sagemaker:NetworkIsolation, sagemaker:VolumeKmsKey, sagemaker:InstanceTypes).
Tags (ABAC) limit users to their own team’s resources.
SageMaker Role Manager builds least-privilege roles for common ML personas.
SCPs set guardrails across accounts, such as approved Regions or models.
IAM Identity Center for people; Studio domains map users to profiles and roles.
KMS and AccessDenied
When a bucket’s default encryption uses a customer managed KMS key, writers need kms:GenerateDataKey and readers need kms:Decrypt on that key, and the key policy must allow the role. Missing KMS permissions is a common cause of AccessDenied even when S3 permissions look right.
Cross-account
Both sides must allow: the role’s policy and the target’s resource policy (bucket policy, key policy, model package group policy), or assume a role in the target account.
Common traps
AmazonSageMakerFullAccess for production jobs.
bedrock:* on * when one model is approved.
Fixing AccessDenied by adding s3:* when the gap is KMS.
A regional bank's SageMaker AI training job fails after a few minutes with an AccessDenied error when it writes model output to an S3 bucket. The bucket's default encryption uses a customer managed AWS KMS key, and the job's execution role was created with access to the bucket.
The team wants to fix the failure with the least broad permissions, keeping the execution role limited to what the job needs.
Which change should the team make?
Choose one answer.
AA. Grant the execution role the KMS actions it needs on the customer managed key, and let the key policy trust the role.
BB. Attach the AdministratorAccess managed policy to the execution role, so that every action the job takes is allowed.
CC. Make the S3 bucket public for writes, since public access removes any need for a role to be authorized.
DD. Change the bucket to use SSE-S3 encryption, which needs no KMS key permissions, so that the role can write to it again.
B. Wrong: Administrator access grants far more than the job needs and fails the least-privilege requirement. The stem asks for the narrowest fix.
C. Wrong: Public write access is a serious security risk and does not follow least privilege. The option also removes the controls the bank requires.
D. Wrong: SSE-S3 needs no KMS permissions, but the bank's policy requires its customer managed key on this bucket. Switching encryption to meet the error would break that requirement.
Explanation
A bucket whose default encryption uses a customer managed KMS key requires the writer to have KMS permissions on that key, and the key policy must allow the role. Adding only those actions fixes the AccessDenied with least privilege. Administrator access, public writes and changing the bucket's encryption are broader or break the bank's policy.
A pet insurer has an application that calls Amazon Bedrock to summarize claim notes. The security team approved one foundation model in one Region for this use. The application's IAM role currently allows model invocation for every model in every Region, and an audit found it could call a model the team never approved.
The team wants the role to invoke only the approved model, and it wants the change limited to the role's policy without changing the application code.
Which change best meets these requirements?
Choose one answer.
AA. Keep the broad policy, and add a deny statement for the one model in the role's trust policy, since trust policies control what actions the role can take.
BB. Replace the wildcard resource in the invoke permission with the ARN of the approved model in its Region, so the role can invoke only that model.
CC. Create a new IAM user for the application with the same wildcard policy, and rotate its access keys every week.
DD. Add a network rule that blocks outbound traffic from the application to Bedrock endpoints in all other Regions.
Show the answer and explanation
Answer: B
A. Wrong: A trust policy controls who can assume the role, not which actions it can perform. The deny belongs in the permissions policy and is in the wrong place here.
C. Wrong: Rotating keys does not limit which models the identity can invoke, so the audit finding remains. The option does not address the permission scope.
D. Wrong: A network rule could limit Regions, but it does not restrict the model, and the stem asks for a change to the role's policy. It also does not match the audit finding about which model was called.
Explanation
Bedrock invoke permissions accept model resource ARNs, so the role's wildcard can be replaced with the approved model in the approved Region. Trust policies control who assumes the role, and key rotation or network rules do not restrict which model the role can call.
Want more on IAM and least privilege for ML? The 5 full-length practice sets have 10 more IAM and least privilege for ML questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →