ExamFinch.com My Study

Study guide

8.1 IAM Least Privilege & Resource Policies for Bedrock

Practice this exam

AWS Certified Generative AI Developer - Professional AIP-C01

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Exam Overview & Foundation Model Fundamentals

1.1 AIP-C01 Exam Structure, Logistics & Passing Strategy 1.2 AIP-C01 Scoring & Professional Decision Strategy 1.3 Foundation Model Landscape & Model Selection on Amazon Bedrock 1.4 Model Abstraction, Controlled Switching & Resilience 1.5 Customization Spectrum: Prompting vs RAG vs Fine-Tuning vs Continued Pre-training 1.6 Custom Model Deployment & Lifecycle Management

2 Chapter 2: Bedrock Knowledge Bases & RAG Architectures

2.1 Managed RAG Architecture with Bedrock Knowledge Bases 2.2 Knowledge Source Integration, Synchronization & Freshness 2.3 Data Ingestion, Parsing & Chunking Strategies 2.4 Embedding Models & Vector Representations 2.5 Vector Index Scale, Migration & Retrieval Evaluation 2.6 Vector Database Selection: OpenSearch Serverless vs Aurora pgvector vs Managed Stores 2.7 Vector Store Security, Multi-Tenancy & Connectivity

3 Chapter 3: Advanced Vector Search, Indexing & Data Compliance

3.1 Hybrid Search, Metadata Filtering & Semantic Reranking 3.2 Metadata Filtering, Reranking & Query Transformation 3.3 Fine-Tuning & Continued Pre-Training Data Pipeline Engineering 3.4 Data Validation, Multimodal Processing & Model Formatting 3.5 Data Privacy, Data Residency & Compliance Governance 3.6 Privacy Preservation, Source Lineage & Audit Evidence

4 Chapter 4: Prompt Engineering & Bedrock Runtime APIs

4.1 Advanced Prompt Engineering Techniques & Inference Parameters 4.2 Inference Parameters, Prompt Governance & Regression 4.3 Converse API vs InvokeModel API & Message Formatting 4.4 Tool Calling, FM API Resilience & Model Routing 4.5 Streaming Architectures & Asynchronous Event Processing 4.6 Resilient Streaming, Deployment & Asynchronous Processing

5 Chapter 5: Amazon Bedrock Agents & Tool Integration

5.1 Agentic Architecture, ReAct Reasoning Loops & Orchestration 5.2 Agent Frameworks, MCP & Lifecycle Management 5.3 Action Groups, OpenAPI Schemas & AWS Lambda Integration 5.4 Agent Memory, Session State & Multi-Agent Collaboration Patterns 5.5 Persistent State & Multi-Agent Coordination 5.6 Advanced Agent Prompt Templates & Flow Customization 5.7 Agent Safeguards, Tool Reliability & Cost Control

6 Chapter 6: Workflow Orchestration & Application Integration

6.1 Amazon Bedrock Prompt Flows & Visual Orchestration 6.2 Step Functions Orchestration & Human-in-the-Loop Workflows 6.3 Enterprise Integration: API Gateway, AppSync, and EventBridge 6.4 Hybrid Integration, GenAI Gateways & CI/CD Tooling

7 Chapter 7: AI Safety & Guardrails for Amazon Bedrock

7.1 Guardrails Architecture, Denied Topics & Content Filters 7.2 Content Safety, Defense in Depth & Threat Detection 7.3 Sensitive Information Filters & PII Redaction/Masking 7.4 Contextual Grounding Checks & Hallucination Prevention

8 Chapter 8: Security, Access Control & Network Architecture

8.1 IAM Least Privilege & Resource Policies for Bedrock 8.2 PrivateLink VPC Endpoints & Network Isolation 8.3 Encryption with AWS KMS & Cross-Account Access Patterns

9 Chapter 9: Governance, Auditing & Operational Logging

9.1 SageMaker Model Cards & AI Governance Frameworks 9.2 Lineage, Fairness, Transparency & Continuous Governance 9.3 Invocation Logging, CloudTrail Auditing & Observability 9.4 Responsible AI, Bias Mitigation & Red Teaming Methodologies

10 Chapter 10: Performance, Throughput & Cost Optimization

10.1 On-Demand vs Provisioned Throughput & Capacity Planning 10.2 Capacity Measurement, Scaling Patterns & Resilience 10.3 Batch Inference & Bedrock Intelligent Prompt Routing 10.4 Intelligent Prompt Routing & Application Eligibility 10.5 Prompt Caching, Token Optimization & Latency Reduction

11 Chapter 11: Testing, Evaluation & Troubleshooting GenAI Solutions

11.1 Amazon Bedrock Model Evaluation (Automatic & Human Workflows) 11.2 Human, RAG & Continuous Evaluation 11.3 Evaluation Metrics & RAG Quality Benchmarking (Ragas, ROUGE, BLEU) 11.4 RAG and Agent Performance Evaluation 11.5 CloudWatch Metrics, Throttling & Operational Observability 11.6 Quota Diagnosis, Retry Control & Operational Troubleshooting 11.7 Troubleshooting Common GenAI Failure Modes & Agent Traces 11.8 Prompt Maintenance, Content Handling & Deployment Validation

8.1 IAM Least Privilege & Resource Policies for Bedrock

Key Takeaways Explain This Topic AI

Amazon Bedrock strictly segregates control-plane management APIs (bedrock:*) from data-plane runtime APIs (bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, bedrock:Retrieve, bedrock:RetrieveAndGenerate, and bedrock:InvokeAgent).

Least-privilege security mandates scoping data-plane permissions to exact resource ARNs, noting that AWS-managed foundation models use an empty account ID in their ARN (arn:aws:bedrock:{region}::foundation-model/{model-id}) whereas custom models and provisioned throughput include the 12-digit account ID.

Service execution roles for Bedrock Knowledge Bases and Bedrock Agents must define an explicit trust policy with the service principal bedrock.amazonaws.com and implement aws:SourceAccount and aws:SourceArn condition keys to eliminate the confused deputy vulnerability.

Bedrock Agent execution roles require delegated IAM permissions to invoke foundation models (bedrock:InvokeModel), execute Action Group Lambda functions (lambda:InvokeFunction scoped to specific function ARNs), and query Knowledge Bases (bedrock:Retrieve).

Attribute-Based Access Control (ABAC) using conditions like aws:ResourceTag/Environment and aws:PrincipalTag/Department provides scalable, dynamic governance, eliminating hardcoded policy sprawl across multi-tenant environments.

Last updated: September 2026

8.1 IAM Least Privilege & Resource Policies for Bedrock

This independent study guide by ExamFinch helps candidates prepare for the AWS Certified Generative AI Developer - Professional (AIP-C01) examination. Securing enterprise generative AI architectures requires rigorous application of the principle of least privilege across identity and access management (IAM). Foundation models, custom fine-tuned weights, knowledge base document repositories, and autonomous agent action groups represent high-value enterprise assets. A single overly permissive IAM wildcard ( bedrock:* on * ) can expose sensitive model configurations, incur massive financial charges via unmetered inference or provisioned throughput creation, and breach corporate compliance boundaries.

To construct production-grade security boundaries, developers must master the demarcation between control-plane and data-plane operations, the precise ARN formatting rules for AWS-managed versus customer-owned resources, the mechanics of service execution roles, and condition-based policy enforcement.

Control Plane vs. Data Plane IAM Architecture

Amazon Bedrock separates administrative lifecycle management from runtime model inference. IAM policies must align with these distinct operational tiers:

Operational Tier Primary IAM Actions Resource Scope Typical IAM Principals

Control Plane (Management) bedrock:CreateKnowledgeBase ; bedrock:CreateAgent ; bedrock:CreateModelCustomizationJob ; bedrock:CreateProvisionedModelThroughput ; bedrock:CreateGuardrail Account-level or specific resource ARNs Platform engineers, DevOps CI/CD pipelines, MLOps administrators

Data Plane (Inference & Retrieval) bedrock:InvokeModel ; bedrock:InvokeModelWithResponseStream ; bedrock:ApplyGuardrail Foundation model ARNs, Custom model ARNs, Provisioned model ARNs Application microservices, backend Lambda functions, ECS tasks

Agent & RAG Runtime bedrock:Retrieve ; bedrock:RetrieveAndGenerate ; bedrock:InvokeAgent ; bedrock:InvokeFlow Knowledge Base ARNs, Agent Alias ARNs, Flow Alias ARNs Frontend API Gateways, client applications, orchestrated state machines

Important

A common architectural requirement on the AIP-C01 exam is ensuring that application runtime identities have zero control-plane permissions. A microservice responsible for generating customer responses should only be granted bedrock:InvokeModel or bedrock:InvokeModelWithResponseStream on a specific model ARN, never broad actions like bedrock:* or administrative actions like bedrock:GetFoundationModel .

Granular Resource ARN Scoping

Unlike traditional AWS services where resources always reside within a specific AWS account, Amazon Bedrock hosts both AWS-managed foundation models and customer-managed artifacts. Scoping IAM policies requires understanding these ARN syntax nuances:

1. Foundation Model ARNs (AWS-Managed)

Foundation models provided by third-party model providers (Anthropic, Meta, Mistral, Cohere, AI21) and Amazon (Titan, Nova) are owned and managed by AWS. Consequently, their ARN contains an empty account field (two consecutive colons :: ): arn:aws:bedrock:{region}::foundation-model/{model-id}

Example: arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0 Example: arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0

Warning

If an IAM policy specifies arn:aws:bedrock:us-east-1:123456789012:foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0 , the policy will fail to authorize inference . Because the foundation model is AWS-managed, inserting an account ID creates an invalid ARN that does not match the service-evaluated identity.

2. Custom Model ARNs (Customer-Owned)

When a team fine-tunes a model or performs continued pre-training, the resulting customized model weights belong to the customer account. The ARN includes the 12-digit account ID and custom model identifier: arn:aws:bedrock:{region}:{account-id}:custom-model/{model-name}/{custom-model-id}

3. Provisioned Model Throughput ARNs

Provisioned Throughput is a customer resource used for supported reserved-capacity needs, but it still requires quota, error, and latency monitoring: arn:aws:bedrock:{region}:{account-id}:provisioned-model/{provisioned-model-id}

4. Knowledge Base & Agent ARNs

Managed RAG and autonomous agent resources are customer-scoped:

  • Knowledge Base: arn:aws:bedrock:{region}:{account-id}:knowledge-base/{knowledge-base-id}
  • Agent: arn:aws:bedrock:{region}:{account-id}:agent/{agent-id}
  • Agent Alias: arn:aws:bedrock:{region}:{account-id}:agent-alias/{agent-id}/{agent-alias-id}
  • Guardrail: arn:aws:bedrock:{region}:{account-id}:guardrail/{guardrail-id}
  • Production IAM Policy: Least-Privilege Inference with Guardrail Enforcement

In enterprise environments, developers often need to enforce mandatory safety guardrails alongside model invocations. IAM policies can use the bedrock:GuardrailIdentifier condition key, including a numbered guardrail version ARN, to require the approved guardrail on supported inference actions: {

  • "Version": "2012-10-17",
  • "Statement": [
  • {
  • "Sid": "AllowScopedModelInvocationWithGuardrail",
  • "Effect": "Allow",
  • "Action": [
  • "bedrock:InvokeModel",
  • "bedrock:InvokeModelWithResponseStream"
  • ],
  • "Resource": [
  • "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0",
  • "arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0"
  • ],
  • "Condition": {
  • "ArnEquals": {
  • "bedrock:GuardrailIdentifier": "arn:aws:bedrock:us-east-1:123456789012:guardrail/a1b2c3d4e5f6"
  • }
  • }
  • },
  • {
  • "Sid": "AllowApplyGuardrail",
  • "Effect": "Allow",
  • "Action": "bedrock:ApplyGuardrail",
  • "Resource": "arn:aws:bedrock:us-east-1:123456789012:guardrail/a1b2c3d4e5f6"
  • }
  • ]
  • }

Under this policy, if an API client submits an InvokeModel request without supplying the required guardrail ID in the request headers or parameters, Bedrock evaluates the condition as unsatisfied and returns an AccessDeniedException .

Service Execution Roles & Trust Relationships

Amazon Bedrock features autonomous services—specifically Knowledge Bases and Agents—that act on your behalf to access other AWS services (Amazon S3, OpenSearch Serverless, AWS Lambda). These services require dedicated Service Execution Roles .

1. The Trust Policy (AssumeRole)

Both Knowledge Bases and Agents must establish a trust policy with the Amazon Bedrock service principal ( bedrock.amazonaws.com ): {

  • "Version": "2012-10-17",
  • "Statement": [
  • {
  • "Sid": "BedrockTrustPolicyWithConfusedDeputyProtection",
  • "Effect": "Allow",
  • "Principal": {
  • "Service": "bedrock.amazonaws.com"
  • },
  • "Action": "sts:AssumeRole",
  • "Condition": {
  • "StringEquals": {
  • "aws:SourceAccount": "123456789012"
  • },
  • "ArnLike": {
  • "aws:SourceArn": "arn:aws:bedrock:us-east-1:123456789012:knowledge-base/*"
  • }
  • }
  • }
  • ]
  • }
  • Mitigating the Confused Deputy Vulnerability

The confused deputy problem occurs when an entity that doesn't have permission to perform an action coerces a privileged service into performing it. To prevent another AWS account from using Bedrock to assume your execution role and exfiltrate data, you must always include the aws:SourceAccount and aws:SourceArn condition keys in the trust policy.

2. Knowledge Base Execution Role Permissions

A Knowledge Base execution role requires a permissions policy that grants access to:

S3 Data Source: s3:GetObject and s3:ListBucket on the document repository bucket.

Embedding Model: bedrock:InvokeModel on the embedding model ARN (e.g., amazon.titan-embed-text-v2:0 ).

Vector Store: aoss:APIAccessAll for Amazon OpenSearch Serverless (or RDS permissions for Aurora pgvector).

KMS Decryption: kms:Decrypt if data sources or vector stores are encrypted with Customer Managed Keys.

3. Bedrock Agent Execution Role Permissions

An Agent execution role requires permissions to:

Invoke Foundation Model: bedrock:InvokeModel on the LLM that powers the agent's ReAct reasoning loop.

Execute Action Groups: the target Lambda function needs a resource-based policy that permits the bedrock.amazonaws.com service principal to invoke it, restricted by source account and agent ARN as appropriate.

Query Knowledge Bases: bedrock:Retrieve scoped to the attached knowledge base ARNs.

Attribute-Based Access Control (ABAC) with Tags

In large enterprises with multiple development teams sharing an AWS account, managing individual IAM policies for every developer or model leads to policy explosion and operational friction. Attribute-Based Access Control (ABAC) solves this by granting permissions based on matching tags.

Tagging Bedrock Resources

Tags can be attached to custom models, provisioned throughput, knowledge bases, guardrails, and agents (e.g., Environment = Production or Department = Finance ).

ABAC Policy Example

The following policy allows developers to invoke foundation models or custom models only if the resource's Environment tag matches the developer's IAM principal tag: {

  • "Version": "2012-10-17",
  • "Statement": [
  • {
  • "Sid": "DynamicABACInvocation",
  • "Effect": "Allow",
  • "Action": [
  • "bedrock:InvokeModel",
  • "bedrock:InvokeModelWithResponseStream"
  • ],
  • "Resource": "arn:aws:bedrock:us-east-1:123456789012:custom-model/*",
  • "Condition": {
  • "StringEquals": {
  • "aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"
  • }
  • }
  • }
  • ]
  • }

When a developer tagged with Environment = Development attempts to invoke a custom model tagged with Environment = Production , Bedrock denies the request automatically without requiring manual policy edits.

Common Exam Traps & High-Stakes Scenarios

Trap: Specifying an Account ID in Foundation Model ARNs. AWS-managed foundation models have no account ID. Writing arn:aws:bedrock:us-east-1:123456789012:foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0 will result in access denied. Always remember the empty double colon ( ::foundation-model/ ).

Trap: Conflating bedrock:Retrieve and bedrock:RetrieveAndGenerate . The bedrock:Retrieve action queries the knowledge base and returns raw document chunks and relevance scores. The bedrock:RetrieveAndGenerate action queries the knowledge base and passes the chunks to a foundation model to synthesize a completed response. An application that sends a prompt directly to a model needs the applicable inference action, such as bedrock:InvokeModel or bedrock:InvokeModelWithResponseStream. bedrock:Retrieve is for Knowledge Base retrieval and does not invoke a foundation model by itself.

Trap: Putting action-group invocation permission in the wrong policy. The action Lambda needs a resource-based lambda:InvokeFunction permission for the bedrock.amazonaws.com service principal. Restrict it with the relevant source account and agent ARN; changing only the Lambda execution role does not authorize the service invocation.

Trap: Omitting Confused Deputy Protection. Questions regarding security audits or SOC2 compliance will flag Bedrock trust policies that lack aws:SourceAccount and aws:SourceArn .