Skill 4.3.3: Configure IAM policies and roles for users and applications in ML and AI systems

Question 1 - Granular IAM Policy for SageMaker Endpoint Invocation

A financial services company has deployed a fraud detection model on Amazon SageMaker with a real-time inference endpoint. The company needs to grant its fraud monitoring application permission to invoke this endpoint. However, the security team has mandated that the application must be able to invoke only this specific endpoint and cannot access any other SageMaker resources in the account.

The application runs on an Amazon EKS cluster with IAM Roles for Service Accounts (IRSA) already configured. The ML engineer needs to create an IAM policy that follows the principle of least privilege.

Which IAM policy should the engineer attach to the application's service account role? (Select ONE)

A)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sagemaker:InvokeEndpoint",
    "Resource": "arn:aws:sagemaker:us-east-1:123456789012:endpoint/fraud-detection-endpoint"
  }]
}

B)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sagemaker:InvokeEndpoint",
    "Resource": "*"
  }]
}

C)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sagemaker:*",
    "Resource": "arn:aws:sagemaker:us-east-1:123456789012:endpoint/fraud-detection-endpoint"
  }]
}

D)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sagemaker:InvokeEndpoint",
    "Resource": "arn:aws:sagemaker:us-east-1:123456789012:endpoint/*"
  }]
}

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: This policy grants exactly one permission—sagemaker:InvokeEndpoint—on exactly one resource—the specific endpoint ARN. The combination of a narrow action and a fully-qualified resource ARN is the textbook definition of least privilege access for model invocation. The application cannot call any other SageMaker API or touch any other endpoint resource.

Distractor Analysis

B is Incorrect: Using "Resource": "*" allows the application to invoke any SageMaker endpoint in the account, including other production and staging models. This violates the explicit requirement to restrict access to only the fraud detection endpoint.
C is Incorrect: Granting sagemaker:* on the resource is overly permissive and technically meaningless for a single endpoint resource—it includes actions that don't apply to an endpoint (e.g., CreateTrainingJob, StopHyperParameterTuningJob). The principle of least privilege requires the narrowest action necessary (InvokeEndpoint).
D is Incorrect: Using "Resource": "arn:aws:sagemaker:us-east-1:123456789012:endpoint/*" widens access to all endpoints in the account. If future endpoints are added, the application automatically gains permission to invoke them, violating the "only this specific endpoint" constraint.

Key Takeaway: For least privilege IAM policies, use the narrowest action (InvokeEndpoint) with the fully-specified resource ARN (not a wildcard) to restrict access to a single model endpoint.

Question 2 - Cross-Account Model Access with IAM Roles

A healthcare organization uses a multi-account AWS architecture. The central Machine Learning team in Account A (production) has deployed a medical imaging classification model on Amazon SageMaker. A data science team in Account B (research) needs to invoke this endpoint for batch evaluation.

The security policy dictates that:

The data science team in Account B must not have direct access to Account A resources.
Access must be granted through a role that can be assumed.
All cross-account access must be auditable.

Which TWO steps are required to configure this cross-account access correctly? (Select TWO)

A) Create an IAM role in Account A (the endpoint account) with a trust policy that allows Account B to assume it, and attach the sagemaker:InvokeEndpoint permission for the endpoint ARN.

B) Create an IAM role in Account B that grants the data science team sts:AssumeRole permission and then have them call AssumeRole to obtain temporary credentials for invoking the endpoint.

C) Export the SageMaker endpoint ID to Account B and add it to Account B's resource policy to allow direct endpoint invocation without role assumption.

D) Generate a long-term static API key in Account A and share it with the data science team in Account B via AWS Secrets Manager across accounts.

E) Attach the sagemaker:InvokeEndpoint permission directly to the data science team's IAM users in Account B using a resource policy on the endpoint.

Click to reveal Answer & Explanation

Correct Answers: A and B

Correct Options Analysis

A is Correct: The IAM role in the resource account (Account A) must have a trust policy specifying the principal from Account B as an allowed entity to assume it, along with permissions to invoke the endpoint. This is the resource-side half of the cross-account trust.
B is Correct: The identity in Account B must have sts:AssumeRole permission for the Account A role ARN. The AssumeRole API call returns temporary credentials that can then be used to call sagemaker:InvokeEndpoint on the endpoint in Account A.

Distractor Analysis

C is Incorrect: SageMaker endpoints do not support resource-based policies that allow cross-account invocation directly. Cross-account access to SageMaker is implemented exclusively through identity-based policies combined with role assumption.
D is Incorrect: SageMaker endpoints are not invoked via long-term API keys. This option also violates the requirement for auditable access—static keys shared across accounts lack robust principal attribution and cannot be tied back to individual users cleanly.
E is Incorrect: You cannot attach an identity-based policy from one AWS account directly onto IAM users in another account. SageMaker also does not support attaching a resource-based policy to endpoints the way Lambda or S3 do.

Key Takeaway: Cross-account SageMaker access is built with a role assumption pattern—trust policy on the resource account's role + sts:AssumeRole permission on the calling identity.

Question 3 - Bedrock Foundation Model Access via IAM

A startup is building a customer support chatbot using Amazon Bedrock with the Amazon Titan Text foundation model. The application is running as an AWS Lambda function. The ML team needs to grant the Lambda function permission to call the foundation model.

The company's security policy requires using temporary, automatically rotated credentials and the most restrictive permissions possible.

Which IAM policy should be attached to the Lambda function's execution role? (Select ONE)

A)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "bedrock:InvokeModel",
    "Resource": "arn:aws:bedrock:us-east-1::foundation-model/amazon.titan-text-premier-v1:0"
  }]
}

B)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "bedrock:*",
    "Resource": "*"
  }]
}

C)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "bedrock:ListFoundationModels",
    "Resource": "*"
  }]
}

D)

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "arn:aws:iam::123456789012:role/bedrock-invocation-role"
  }]
}

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: This policy grants precisely one permission—bedrock:InvokeModel—on exactly one foundation model resource ARN. The ARN format for Bedrock foundation models includes the model ID and version, allowing tight restriction to a single model. This satisfies both the least privilege requirement and the temporary credentials requirement (Lambda execution roles automatically provide temporary STS credentials).

Distractor Analysis

B is Incorrect: Granting bedrock:* on "Resource": "*" allows invoking any foundation model and performing any Bedrock action including creating agents, knowledge bases, and guardrails. This is severely over-permissive and violates the security mandate.
C is Incorrect: bedrock:ListFoundationModels is a read-only management API that lists available foundation models. It does not grant permission to invoke any model (InvokeModel / Converse are separate actions).
D is Incorrect: iam:PassRole is used when a service (like Bedrock) needs to assume a role passed by the caller for downstream actions—such as creating a Bedrock Agent or Knowledge Base that uses a role for S3 access. It does not grant the Lambda function permission to invoke a foundation model.

Key Takeaway: Bedrock foundation model invocation requires bedrock:InvokeModel (or Converse) scoped to the specific model ARN—not just ListFoundationModels—and Lambda execution roles provide temporary credentials automatically.

Question 4 - IAM Roles for SageMaker Training Jobs

A machine learning engineering team is building a SageMaker training pipeline that:

Reads training data from an S3 bucket (s3://ml-training-data/images/)
Writes model artifacts to another S3 bucket (s3://ml-model-artifacts/production/)
Cannot access any other S3 buckets in the account

The team is configuring the SageMaker training job role. Which IAM policy satisfies the requirement? (Select ONE)

A)

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::ml-training-data/images/*"},
    {"Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::ml-model-artifacts/production/*"}
  ]
}

B)

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::ml-training-data/*"},
    {"Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::ml-model-artifacts/*"}
  ]
}

C)

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": "s3:*", "Resource": "*"}
  ]
}

D)

{
  "Version": "2012-10-17",
  "Statement": [
    {"Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::ml-training-data/images/*"},
    {"Effect": "Allow", "Action": "s3:PutObject", "Resource": "*"}
  ]
}

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: The policy restricts read access (GetObject) to objects only under the images/ prefix of the training bucket, and write access (PutObject) only under the production/ prefix of the model artifacts bucket. This precisely matches the stated requirements—the job can read exactly the training data it needs and write only to the specified artifacts location.

Distractor Analysis

B is Incorrect: While it restricts access to only the two named buckets, using /* on both buckets widens access beyond the stated scope. The training job could read other prefixes (e.g., s3://ml-training-data/other-data/) and write to other prefixes in the artifacts bucket (e.g., s3://ml-model-artifacts/staging/), violating the "only" restriction.
C is Incorrect: Granting s3:* with "Resource": "*" gives the training job read/write/delete/list access to every S3 bucket in the account, including sensitive data stores. This is the most dangerous option—violating least privilege, data isolation, and security best practices.
D is Incorrect: While the GetObject scope is correctly narrowed, the "Resource": "*" for PutObject allows writing model artifacts to any S3 bucket in the account. This widens access beyond the stated requirement and could lead to model artifacts being written to unintended locations.

Key Takeaway: When scoping S3 permissions, use both the bucket name and the appropriate prefix to satisfy "only this bucket and this folder" requirements—wildcards on the bucket name alone are too broad.

Question 5 - SageMaker Studio Notebook IAM Best Practices

A data science team uses Amazon SageMaker Studio notebooks daily for experimentation. A security audit finds that:

All data scientists share a single IAM user with AdministratorAccess policy.
A single SageMaker execution role is used by all Studio users.
The execution role has broad s3:* access.

The security team asks for a re-architecture that provides:

Per-user attribution for actions
Least privilege access for development environments
Minimal operational overhead going forward

Which TWO changes should the engineer implement? (Select TWO)

A) Configure SageMaker Studio to use IAM Identity Center for single sign-on, creating individual user identities per data scientist.

B) Continue using the shared IAM user but rotate the access key every 90 days to satisfy the audit.

C) Create separate SageMaker execution roles for different user groups with scoped-down S3 permissions (e.g., per-team prefixes) and attach them to user profiles.

D) Grant all data scientists s3:GetObject on "Resource": "*" to ensure they can access any dataset, then rely on bucket policies for security.

E) Replace all IAM permissions with a single DirectManagedPolicy stored in AWS Secrets Manager that grants temporary access tokens.

Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

A is Correct: IAM Identity Center (successor to AWS SSO) integrates with SageMaker Studio to enable individual user identities with single sign-on. Each user's actions are attributed to their own identity in CloudTrail, addressing the per-user attribution requirement while simplifying user management.
C is Correct: Rather than broad s3:* on all buckets, creating separate execution roles per user group (e.g., "image-team," "nlp-team") allows scoping S3 access to team-specific prefixes. SageMaker Studio user profiles support assigning specific execution roles, enabling least privilege while keeping operational overhead manageable.

Distractor Analysis

B is Incorrect: Rotating access keys on a shared IAM user does not solve the attribution problem—everyone still acts as the same principal. This also embeds long-term credentials (access keys) into workflows, which is discouraged for interactive development when IAM Identity Center is available.
D is Incorrect: Granting s3:GetObject on "*" is the opposite of least privilege. Users could read any bucket in the account, including production data, secrets, and other restricted stores. This does not address the audit findings.
E is Incorrect: "DirectManagedPolicy" is not a real AWS feature. IAM permissions come from policies attached to users, groups, or roles. AWS Secrets Manager stores secrets (API keys, passwords), not IAM permissions or policies.

Key Takeaway: SageMaker Studio per-user attribution and least privilege are achieved with IAM Identity Center (individual identities) and scoped execution roles per user profile—not by sharing a single IAM user or using wildcard permissions.

Question 6 - IAM Policy to Protect Model Artifacts in S3

An ML platform team manages a model registry in S3. Trained model artifacts are stored under s3://ml-model-store/. Multiple SageMaker training jobs from various teams write to this bucket.

The platform team must enforce the following:

Training jobs can write to only their team's prefix (e.g., teama/, teamb/).
No training job can delete any object in the bucket.
Object deletion requires a separate elevated permission held only by the platform team.

Which IAM policy statement should be included in each team's training job role? (Select ONE)

A)

{
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:GetObject"],
  "Resource": "arn:aws:s3:::ml-model-store/teama/*"
}

B)

{
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:GetObject", "s3:DeleteObject"],
  "Resource": "arn:aws:s3:::ml-model-store/teama/*"
}

C)

{
  "Effect": "Allow",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::ml-model-store/teama/*"
}

D)

{
  "Effect": "Allow",
  "Action": ["s3:PutObject", "s3:GetObject"],
  "Resource": "arn:aws:s3:::ml-model-store/*"
}

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: By granting only PutObject and GetObject scoped to teama/*, the training job can write and read its own team's model artifacts. The absence of DeleteObject in the policy ensures the job cannot delete any object, regardless of prefix. The platform team would hold a separate role with s3:DeleteObject permission for elevated operations.

Distractor Analysis

B is Incorrect: Including s3:DeleteObject explicitly grants deletion rights to the training job. This violates the requirement that no training job can delete objects in the bucket—even within its own prefix.
C is Incorrect: While PutObject is needed to write artifacts, GetObject is also needed for training jobs to read back previously stored artifacts or checkpoints from their prefix. Omitting GetObject results in an overly restrictive policy that may break legitimate workflows (e.g., re-loading a previous model). However, it is not the best answer because it breaks expected functionality.
D is Incorrect: "Resource": "arn:aws:s3:::ml-model-store/*" allows writing and reading across all team prefixes in the bucket. Team A's training job could read or overwrite Team B's model artifacts. This violates the prefix-scoping requirement.

Key Takeaway: Restricting destructive actions like s3:DeleteObject is done by omission from the allow list—simply removing it from the action list ensures training jobs cannot delete model artifacts, while scoping the Resource ensures prefix-level isolation.

Question 7 - IAM Conditions for Bedrock Guardrails and Model Access

A regulated financial company uses Amazon Bedrock with Guardrails to block investment recommendations from a large language model. The application is a Lambda function behind API Gateway.

The information security team now requires that:

The Lambda function can invoke the model only when a specific guardrail is attached to the request.
The guardrail must not be the only security control—it must be combined with IAM-based access control.
Administrative actions on Bedrock must remain restricted to a separate platform team.

Which TWO actions should the ML engineer take? (Select TWO)

A) Attach an IAM policy to the Lambda role that grants bedrock:InvokeModel on the specific foundation model ARN.

B) Create an additional IAM policy that grants bedrock:CreateGuardrail and bedrock:UpdateGuardrail to the Lambda role to enforce guardrail configuration at runtime.

C) Use the bedrock:GuardrailIdentifier condition key in the Lambda role's IAM policy to restrict InvokeModel calls to those that pass a specific guardrail.

D) Modify the Lambda function to download the guardrail policy JSON from a public S3 bucket and enforce it client-side before calling Bedrock.

E) Apply the guardrail directly in the InvokeModel / Converse API call, and enforce additional bedrock:InvokeModel IAM permissions on the Lambda role.

Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

A is Correct: The Lambda function needs bedrock:InvokeModel permission on the foundation model resource ARN to invoke it. This is the baseline IAM access control—without it, the Lambda cannot call the model even with a guardrail attached.
C is Correct: AWS Bedrock supports IAM condition keys such as bedrock:GuardrailIdentifier to restrict which guardrails can be used with InvokeModel calls. This ensures the Lambda can only invoke the model when the specified guardrail ARN is passed in the request, providing defense-in-depth at the IAM layer. (This is also referenced as a valid IAM condition key pattern for Bedrock.)

Distractor Analysis

B is Incorrect: Granting bedrock:CreateGuardrail and bedrock:UpdateGuardrail to the Lambda role gives runtime application code the ability to modify or create guardrails—this violates separation of duties. Administrative guardrail changes should be performed only by the platform team through infrastructure-as-code or CI/CD.
D is Incorrect: Downloading guardrail policies from a public S3 bucket and enforcing them client-side is both insecure (guardrail policies become publicly readable) and fails to satisfy the "IAM-based access control" requirement. Bedrock Guardrails are enforced server-side by the service, not via client-side JSON parsing.
E is Incorrect: While attaching the guardrail to the API call is correct and having InvokeModel IAM permission is necessary, this option is redundant with A and C, and it doesn't describe the "only when a specific guardrail is used" condition. It doesn't add anything beyond what A and C already achieve.

Key Takeaway: Bedrock Guardrails and IAM are complementary controls—use IAM condition keys like bedrock:GuardrailIdentifier to enforce that only a specific guardrail can accompany a model invocation, while administrative guardrail operations stay restricted.

Question 8 - SageMaker Endpoint Access via IAM vs. Security Groups

A company has deployed a SageMaker endpoint within a VPC that hosts an internal ML inference service. The endpoint is accessed by:

An application running in an EC2 instance in the same VPC
A batch processing Lambda function outside the VPC

The security team wants to enforce a zero-trust model where:

Only applications with explicit IAM permission can invoke the endpoint.
Network security groups alone must not confer invoke rights.
The endpoint should not be invocable by an anonymous principal under any circumstance.

Which TWO configurations correctly implement this? (Select TWO)

A) Attach an IAM policy to the EC2 instance role granting sagemaker:InvokeEndpoint on the endpoint ARN.

B) Allow all inbound traffic from the VPC CIDR range on the endpoint's security group to ensure internal access.

C) Attach an IAM policy to the Lambda execution role granting sagemaker:InvokeEndpoint on the endpoint ARN.

D) Create a resource policy on the SageMaker endpoint that allows "Principal": "*" and relies solely on security groups for access control.

E) Remove IAM permissions entirely and rely on VPC security groups for access control, since SageMaker endpoints inside a VPC are automatically restricted.

Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

A is Correct: The EC2 instance role needs sagemaker:InvokeEndpoint on the endpoint ARN to invoke the endpoint. IAM permission is a prerequisite—without it, even network access through a security group will not allow invocation.
C is Correct: The Lambda function executing outside the VPC also needs an IAM policy granting sagemaker:InvokeEndpoint on the endpoint ARN. Since SageMaker endpoints do not support resource-based policies, all authorization is via identity-based policies.

Distractor Analysis

B is Incorrect: Allowing all inbound traffic from the VPC CIDR range is over-permissive and violates zero-trust principles. The security group should only allow traffic from specific security groups or IP ranges that actually require access, not the entire VPC CIDR.
D is Incorrect: SageMaker endpoints do not support resource-based policies. Therefore, you cannot attach a policy with "Principal": "*" to an endpoint. Invocation is always authorized via the caller's identity-based policy.
E is Incorrect: SageMaker endpoints in a VPC are not automatically restricted to IAM-authorized callers or the VPC—network isolation via security groups operates at the network layer, while IAM operates at the API authorization layer. Removing IAM permissions entirely would result in AccessDenied errors even if the caller is in the same security group.

Key Takeaway: SageMaker endpoints use identity-based IAM policies only (no resource-based policies), so both network access (security groups) and IAM authorization (sagemaker:InvokeEndpoint) are required—neither replaces the other.

Question 9 - IAM Role Chaining for SageMaker Pipeline Steps

A company is building a SageMaker Pipeline that includes three steps:

A processing step that reads raw data from s3://raw-data/private/
A training step that reads processed data and writes model artifacts to s3://model-output/prod/
A model registration step that writes metadata to SageMaker Model Registry

The platform team uses separate IAM roles for each pipeline step for strict separation of duties. The roles are:

ProcessingRole: S3 read on raw-data/private/, SageMaker ProcessingJob submit
TrainingRole: S3 read on processed data, S3 read/write on model-output/prod/
RegistrationRole: SageMaker Model Registry write access

The pipeline definition is authored by a senior engineer. Which IAM consideration is critical for the pipeline execution role? (Select ONE)

A) The pipeline execution role must include iam:PassRole permissions for the ProcessingRole, TrainingRole, and RegistrationRole so it can pass them to the respective pipeline steps.

B) The pipeline execution role must be granted sagemaker:* on all resources to ensure all steps can run without interruption.

C) The pipeline execution role must be combined with the TrainingRole into a single role to avoid role chaining overhead.

D) The pipeline execution role does not need any IAM permissions itself—the individual step roles handle all authorization at runtime.

Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

A is Correct: SageMaker Pipeline steps are configured to execute under specific IAM roles. The pipeline execution role (the one used to create/start the pipeline) must have iam:PassRole permission for each of those step roles. Without PassRole, the pipeline cannot pass the step-specific roles to the processing, training, and registration jobs, resulting in an AccessDeniedException when the pipeline attempts to start those steps.

Distractor Analysis

B is Incorrect: Granting sagemaker:* on all resources to the pipeline role is a clear violation of least privilege. The pipeline role should only need sagemaker:StartPipelineExecution and iam:PassRole for the step roles—not broad administrative permissions across all SageMaker resources.
C is Incorrect: The scenario explicitly states the platform team uses separate roles for separation of duties. Combining TrainingRole back into the pipeline role collapses the boundary between pipeline orchestration and training execution privileges, increasing blast radius if one role is compromised.
D is Incorrect: The pipeline execution role must have at minimum sagemaker:StartPipelineExecution on the pipeline ARN and iam:PassRole on the step roles. It cannot have zero permissions—even the act of starting the pipeline requires authorization.

Key Takeaway: In SageMaker Pipelines with step-specific roles, the pipeline execution role must have iam:PassRole for each step role—this is a common oversight that causes AccessDenied errors on pipeline start.

Question 10 - IAM-Based Model Endpoint Protection for Bedrock Custom Models

A company has fine-tuned a custom model using Amazon Bedrock Custom Model Import. The fine-tuned model is used by a production web application that requires low-latency inference.

The security team wants to:

Ensure only the production application can invoke the custom model.
Prevent any user in the same AWS account from accidentally invoking the custom model via the Bedrock console.
Maintain an audit trail of every invocation.

Which THREE actions should the team implement? (Select THREE)

A) Create a dedicated IAM role for the production application with bedrock:InvokeModel on the custom model ARN, and deny all other IAM principals from invoking this model using an explicit deny policy on the model ARN.

B) Attach an IAM policy to all IAM users in the account that grants bedrock:InvokeModel to allow console-based testing.

C) Configure AWS CloudTrail to log bedrock:InvokeModel data events for the custom model so that every invocation is recorded.

D) Use an IAM permissions boundary on the production application's role that limits it to only Bedrock actions and nothing else.

E) Remove the custom model from the Bedrock console by deleting its model registry entry.

Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

A is Correct: A dedicated IAM role for the production application with bedrock:InvokeModel scoped to the custom model ARN provides least privilege access. An explicit Deny policy on the model ARN for all other principals (or using a condition that restricts to the production role) ensures no other user or role can invoke the model even with broader permissions—implementing the "only the production application" requirement.
C is Correct: CloudTrail data events for bedrock:InvokeModel on the custom model record every API invocation with principal, timestamp, source IP, and model identifier. This satisfies the audit trail requirement.

Distractor Analysis

B is Incorrect: Granting bedrock:InvokeModel to all IAM users so they can test via the console directly contradicts the requirement to prevent any user from accidentally invoking the model. This would open up invocation access broadly.
D is Incorrect: An IAM permissions boundary sets the ceiling of permissions for the production role but does not prevent other IAM users or roles in the account from invoking the model. It controls the production application's maximum permissions but doesn't implement cross-principal denial. The question asks for 3 actions but only 2 are correct—this option is not a necessary action for the requirement.
E is Incorrect: Deleting the model registry entry does not remove the fine-tuned model's availability via the API (custom models are referenced by ARN and cannot be "removed" from the console to deny invocation). This option also doesn't establish an audit trail or a control mechanism.

Key Takeaway: To restrict custom model invocation to a single application, use an explicit Deny on the model ARN for all other principals (or a restrictive allow-only policy), and ensure CloudTrail data events capture all invocation calls for auditability.

Exam Tip: IAM for ML/AI workloads follows the same least privilege principles as general AWS IAM—the key differences are the specific actions (sagemaker:InvokeEndpoint, bedrock:InvokeModel) and resources (model ARNs, endpoint ARNs). Always check whether you need iam:PassRole when services like SageMaker Pipelines delegate roles, and remember that SageMaker endpoints use identity-based policies only—no resource-based policies. CloudTrail data events must be configured separately to audit invocation-level activity.