Skip to content

Skill 4.3.3: Configure IAM Policies and Roles for Users and Applications in ML and AI Systems

Task 4.3: Operating, Monitoring, and Securing ML and AI Solutions – Secure ML and AI Workloads and Model Endpoints

Core objective: Bind every ML principal — human engineer, notebook, training job, endpoint, pipeline — to the smallest set of operations and resources its job requires, and eliminate long-lived static credentials. Every ML object (dataset, artifact, endpoint, FM) needs its own access answer.

Policy Types & Where Each Applies

Policy Attached to Answers ML Example
Identity-based IAM user/role/group What can this principal do? SageMaker execution role
Resource-based The resource itself Who may reach me? S3 bucket policy, KMS key policy, ECR repo policy
Trust policy The role Who may assume me? sagemaker.amazonaws.com
Permissions boundary IAM user/role Maximum ceiling Cap an analyst role
SCP OU / account Org-wide guardrail Deny non-approved Regions
Session policy AssumeRole session Downscope on the fly Temporary narrower access
VPC endpoint policy Interface/Gateway endpoint What may traverse the endpoint Pin S3 access to one bucket

Effective permission = intersection of ALL applicable policies. An identity-based allow is useless if an SCP, boundary, key policy, or endpoint policy denies.

Roles vs. Users (non-negotiable)

  • Workloads → IAM role + STS temporary credentials. Never IAM users with long-lived access keys for training jobs, endpoints, or applications.
  • Humans → federated identity (IAM Identity Center / SSO) that assumes a role; MFA for privileged deploy/approve actions.
  • Keep human identity separate from workload identity — a workload should never inherit a person's permissions or session lifetime.
  • Trust policy = who; permission policy = what. Two separate documents; exam tests which one is missing or wrong.

SageMaker Execution Role — the highest-yield pattern

Every training job, processing job, hosted endpoint, and notebook requires an execution role ARN.

  • Trust policy principal: sagemaker.amazonaws.com
  • Typical permissions: S3 read on training data prefix, S3 write on model-artifact output prefix, ECR pull on the training image, CloudWatch Logs write, KMS Decrypt on encrypted inputs.
  • Inference role: ECR pull + S3 read on model artifact + KMS Decrypt. No training-data access, no write, no sagemaker:*.

iam:PassRole gotcha: The principal that starts the job (user, Lambda, Step Functions, pipeline role) must have iam:PassRole on the execution role. Missing it fails job creation even when the execution role is perfectly correct. Grant PassRole to the caller, never to the execution role itself.

Credential Type for Foundation Model Access

Credential Backing identity Lifetime Intended use Production
Short-term Bedrock API key Inherits the generating identity's permissions Expires with the session Exploration / experimentation ❌
Long-term Bedrock API key Its own identity, fixed expiry set at creation Long-lived Development / exploration ❌
IAM role + temporary credentials (STS) Own identity, auto-rotated Short-lived Applications & pipelines ✅
  • Where a static secret genuinely must exist → AWS Secrets Manager (with rotation). Never in code, a container image, or an environment file.

Least Privilege Across ML Artifacts

  • S3: scope to bucket + prefix (s3:prefix conditions); separate roles for raw data, processed data, and model artifacts; deny unencrypted puts.
  • ECR: pull-only for training/inference roles; push restricted to the build/pipeline role.
  • Model Registry / Model Packages: gate CreateModelPackage, UpdateModelPackage, and approval/promotion actions to specific roles — not to every data scientist.
  • Feature Store: split ingestion (write) from read-only consumer roles.
  • Bedrock: scope bedrock:InvokeModel to specific model ARNs and guardrail ARNs — not *.
  • KMS: each key's policy must grant the execution role Encrypt/Decrypt; IAM permission alone is insufficient.

Security, Network & Audit Controls That Interlock With IAM

  • KMS: encryption at rest. Access = IAM allow ∩ key policy grant. Rotate keys; decrypt is attributable via CloudTrail.
  • VPC endpoints: interface endpoints (PrivateLink) let private subnets reach APIs without internet; endpoint policies further restrict what may traverse them. Gateway endpoints for S3/DynamoDB.
  • IAM Access Analyzer: detects externally/public-accessible resources, flags unused permissions, and generates least-privilege policies from CloudTrail activity.
  • Secrets Manager: store + rotate API keys and DB credentials; app retrieves at runtime.
  • CloudTrail: records which principal called which operation, when, from where.

Data events gotcha: InvokeEndpoint, InvokeModel, and Converse are data-plane (data) events. A default trail records only management events — an audit expecting model invocations in an unconfigured trail finds nothing and wrongly concludes nothing happened.

Anti-Patterns & Distractor Traps

Trap Correct Answer
sagemaker:* or s3:* wildcards Scope to explicit ARNs and prefixes
Long-lived access keys in code/image/env Role + STS temporary credentials
Widening a policy to clear AccessDenied Read the error — it names the operation and the resource to grant
Missing iam:PassRole Add to the caller, not the execution role
"IAM allows it, so KMS will work" Key policy must also grant — intersection required
Encrypting a bucket to fix a connectivity failure Encryption ≠ routing; use a VPC endpoint
Confusing trust vs. permission policy Trust = who may assume; permission = what they may do
Giving an endpoint role full-bucket S3 access Scope to the model-artifact prefix only
Guardrail filters mistaken for access control Safeguards filter content; IAM decides who can call

One-line discriminator: If the symptom is a denial → it's IAM. If the symptom is a timeout/no route → it's networking. If the symptom is no record → it's CloudTrail data events. Never solve one with the wrong control.