AWS Learning Material Certification Cheatsheets
AIP-C01 Domain 2

Task 2.1: Implement agentic AI solutions and tool integrations

Implementation and Integration · 5,219 words · source: Certified-Generative-AI-Developer-Professional-AIP-C01/domain-2/task-2-1-cheat-sheet.md

Domain 2: Implementation and Integration

Task Statement 2.1: Implement agentic AI solutions and tool integrations

Domain 2 is 26% of scored exam content. Task 2.1 focuses on building agentic systems that can reason, use tools, coordinate models or agents, preserve useful state, involve humans when needed, and stay inside operational and security boundaries.

Use this sheet for scenario questions that ask how to build agents, choose between Bedrock Agents and Strands Agents, integrate tools through action groups or MCP, orchestrate reasoning workflows with Step Functions, add safeguards, coordinate specialized models, or add human review.

Official Study Path

Use these in order:

  1. AWS Skill Builder: Exam Prep Plan: AWS Certified Generative AI Developer - Professional (AIP-C01)
  2. AWS Skill Builder: Domain 2 Review: AWS Certified Generative AI Developer - Professional
  3. AWS Skill Builder: Domain 2 Task 2.1 review and practice questions
  4. AWS Exam Guide: Domain 2, Task Statement 2.1
  5. AWS Docs: Amazon Bedrock Agents, Amazon Bedrock AgentCore, Strands Agents, MCP tools, Step Functions prompt chaining, and Amazon Bedrock Guardrails

Exam Objective Map

You should be able to:

Official skill What to know for the exam
Skill 2.1.1: Develop intelligent autonomous systems with memory and state Choose Bedrock Agents, Strands Agents, AWS Agent Squad, AgentCore Runtime, AgentCore Memory, session IDs, session attributes, DynamoDB, or workflow state depending on whether the agent is managed, custom, stateless, session-aware, or long-running
Skill 2.1.2: Create advanced problem-solving systems Use Step Functions, prompt chaining, ReAct-style loops, planning steps, parallel branches, retries, and explicit state transitions when reasoning needs deterministic workflow control
Skill 2.1.3: Develop safeguarded AI workflows Add stopping conditions, timeouts, least-privilege IAM, parameter validation, guardrails, circuit breakers, bounded retries, and human escalation
Skill 2.1.4: Create model coordination systems Route work to specialized FMs or agents, combine outputs, use model cascading, ensembles, voting, ranking, or aggregation logic, and optimize for cost, latency, and quality
Skill 2.1.5: Develop collaborative AI systems with human expertise Use Step Functions approvals, return-of-control action groups, API Gateway feedback collection, review queues, and audit logs when humans must approve, correct, or provide judgment
Skill 2.1.6: Implement intelligent tool integrations Define tools with clear schemas, validate parameters in Lambda, handle tool errors, use Bedrock action groups, Strands tools, or MCP clients, and never trust model-generated inputs
Skill 2.1.7: Develop model extension frameworks Use MCP for standardized tool access; use Lambda for lightweight stateless MCP tools and Amazon ECS or AgentCore Runtime for complex or long-running tool servers

One-Minute Mental Model

Task 2.1 is about turning an FM from a text generator into a controlled system that can plan, call tools, remember context, collaborate, and recover from failure.

User goal
  -> agent instructions and state
  -> reasoning/orchestration plan
  -> tool/model/human actions
  -> validation and guardrails
  -> final response or approved action
  -> trace, metrics, feedback, and memory update

Exam shortcut:

Managed configurable agent -> Amazon Bedrock Agents.
Custom framework or multi-agent patterns -> Strands Agents on Bedrock / AgentCore.
Enterprise tool exposure at scale -> AgentCore Gateway with MCP-compatible tools.
Explicit workflow control -> Step Functions.
Long-running or approval workflow -> Step Functions + human-in-the-loop.
Tool calls to AWS or APIs -> action groups, Lambda, MCP tools, least privilege.
Agent needs conversation continuity -> session ID + session memory/state store.
Agent must not run forever -> timeout + max iterations + circuit breaker + fallback.

What Task 2.1 Is Really Testing

The exam is not asking whether an agent can chat. It is testing whether you can implement agents as production systems.

Exam area What that means in practice
Autonomy The FM can choose steps, call tools, ask clarifying questions, and synthesize results
State Conversation/session state is explicitly managed and protected
Tool use Tools have schemas, descriptions, permissions, validation, error handling, and auditability
Reasoning control Complex work is decomposed into bounded steps, not left as an unbounded model loop
Safeguards Agent behavior is limited by instructions, IAM, guardrails, validation, stop conditions, timeouts, and human approval
Coordination Specialized models or agents are used only when their quality gain is worth coordination cost
Human augmentation Humans review high-risk, low-confidence, regulated, subjective, or irreversible outcomes
Observability Traces include model calls, tool calls, inputs/outputs, latency, errors, and decisions

Core AWS Services and Frameworks

Service or framework Exam-level role
Amazon Bedrock Agents Fully managed agents that orchestrate FMs, instructions, action groups, knowledge bases, tracing, versions, and aliases
Bedrock action groups Define actions an agent can perform through OpenAPI schemas, function definitions, Lambda executors, or return of control
Amazon Bedrock Knowledge Bases Add enterprise context to agents so they can ground answers in organizational data
Amazon Bedrock Guardrails Apply safety controls to model inference, agents, knowledge bases, and flows
Amazon Bedrock AgentCore Runtime Host and scale agents or tools using protocols such as HTTP, MCP, A2A, or AG-UI
Amazon Bedrock AgentCore Gateway Convert APIs, Lambda functions, and services into MCP-compatible tools for agents
Amazon Bedrock AgentCore Memory Persist session and semantic memory for AgentCore-hosted agents
Amazon Bedrock AgentCore Identity Manage agent authentication, authorization, and credentials for AWS and third-party services
Strands Agents Open-source SDK released by AWS for model-first autonomous agents, tools, MCP integration, multimodal agents, and multi-agent patterns
AWS Agent Squad Multi-agent orchestration framework referenced in the AIP-C01 learning path for routing and coordinating specialized agents
MCP Standard protocol for exposing context and tools to agents across local, HTTP, and remote tool servers
AWS Step Functions Deterministic orchestration for prompt chains, ReAct-style loops, parallel branches, human approvals, retries, catches, and timeouts
AWS Lambda Tool implementation, action group executor, parameter validation, post-processing, error handling, lightweight MCP server
Amazon ECS / AWS Fargate Host complex MCP servers or custom agent services that exceed Lambda's simplicity or duration fit
Amazon API Gateway / AWS AppSync Expose agent APIs, collect feedback, validate requests, and integrate with applications
Amazon DynamoDB Store conversation state, task state, tool results, checkpoints, feedback, idempotency keys, and audit metadata
IAM / IAM Identity Center / Amazon Cognito Authenticate users and enforce least privilege for agent, tool, model, and data access
AWS KMS / Secrets Manager Encrypt sensitive state and manage API keys, OAuth secrets, and tool credentials
CloudWatch / CloudTrail / X-Ray / ADOT Observe model calls, agent traces, tool calls, errors, latency, token use, and security events

Agent Pattern Selection

Requirement clue Best-fit pattern Why
"Quickly build an agent that uses Bedrock models, action groups, and knowledge bases" Amazon Bedrock Agents Managed configuration, built-in orchestration, versions, aliases, tracing
"Use custom Python/TypeScript agent logic, third-party frameworks, or flexible model providers" Strands Agents or custom framework on AgentCore Runtime More implementation control and framework flexibility
"Expose many enterprise APIs as reusable tools" AgentCore Gateway with MCP tools Central discovery, authentication, and tool exposure
"Need a simple tool that validates parameters and calls one AWS API" Bedrock action group backed by Lambda Low operational overhead
"Need complex, long-running, stateful, or dependency-heavy tool server" ECS/Fargate or AgentCore Runtime with MCP Better fit than Lambda for complex runtime needs
"Need deterministic multistep process with retries and approval" Step Functions orchestration Explicit state machine, retries, catch paths, wait states, human steps
"Need multiple specialized experts" Multi-agent supervisor/collaborator pattern or Strands multi-agent pattern Route work to agents with focused capabilities
"Need one agent to use another agent as a capability" Built-in multi-agent collaboration or A2A/MCP pattern Avoid inventing fake tool calls for agent-to-agent messages
"Need user approval before action" Return of control, Step Functions approval, or human review queue Keeps irreversible actions out of fully autonomous flow

Exam trap: do not make everything an agent. If a deterministic function can do the job, use a tool or workflow step. Promote a capability to a sub-agent only when it needs independent reasoning, planning, or conversation.

Amazon Bedrock Agents

Amazon Bedrock Agents are a strong answer when the scenario wants a managed AWS-native agent with minimal custom orchestration.

Capability What to remember
Instructions Define the agent's role, scope, behavior, and when to use tools
Action groups Define APIs/functions the agent can invoke, usually backed by Lambda or return of control
Knowledge bases Add enterprise or domain context for grounded responses
Advanced prompts Customize pre-processing, orchestration, knowledge base response generation, and post-processing behavior
Tracing Inspect the agent's reasoning path, tool choices, and intermediate steps
Versions and aliases Promote prepared agent versions through environments and route production traffic via aliases
Guardrails Apply safety controls to prompts sent to the agent and responses returned from it
Session ID Maintain conversation continuity across turns

Implementation cues:

  • Create or update the agent configuration.
  • Add action groups and knowledge bases as needed.
  • Run prepare-agent after every configuration change.
  • Create an alias for controlled deployment.
  • Invoke through the runtime API with a sessionId.
  • Use tracing for debugging, but treat trace data as sensitive because it can include user inputs, retrieved context, tool parameters, and intermediate reasoning.

Exam shortcuts:

Agent not using the new action group -> check whether the agent was prepared after the change.
Production traffic to an agent -> use versions and aliases, not an unversioned draft.
Agent must call business logic -> action group with clear descriptions and Lambda executor.
Human or external app must execute the action -> return of control.

Action Groups and Tool Schemas

Action groups are how Bedrock Agents take actions. The exam often tests whether the tool contract is well defined and safe.

Action group style Use when Key implementation detail
OpenAPI schema The tool maps cleanly to REST-style operations Operation and parameter descriptions must be clear because the agent uses them to decide when to call the tool
Function definition You want a simpler named function and parameter schema Define types, required fields, and descriptions for each function and parameter
Lambda executor AWS-side business logic should execute the action Lambda must validate parameters, authorize the action, handle errors, and return the expected response shape
Return of control The application or human workflow must execute the action Agent returns proposed action details to the caller instead of invoking Lambda

Tool design checklist:

Design point Exam-ready answer
Tool name Clear, specific, and stable
Tool description Explain when to use it and when not to use it
Parameters Use strict types, required/optional flags, descriptions, and constraints
Validation Treat all agent-provided parameters as untrusted input
Authorization Check user identity and permissions before action execution
Idempotency Use idempotency keys for actions that create, update, pay, submit, or delete
Error handling Return structured errors the agent or workflow can reason over
Observability Log tool name, request ID, outcome, latency, and sanitized parameters
Least privilege Scope Lambda, API, and data permissions to the exact resources needed

Exam trap: model-generated tool arguments are not reliable just because they came through a schema. Validate, sanitize, authorize, and bound every action.

Strands Agents

Strands Agents is a strong answer when a scenario needs code-level flexibility, multi-agent patterns, MCP integration, and AWS service integration while still using Amazon Bedrock models.

Feature Exam-level meaning
Model-first design The FM drives agent behavior, tool choice, and reasoning
Tools Custom functions or external services extend the agent's capabilities
MCP integration Agents can consume tools from MCP servers consistently
Multi-agent patterns Supervisor, graph, swarm, workflow, or agent-as-tool patterns can coordinate specialized agents
AWS integration Can connect to Amazon Bedrock, Lambda, Step Functions, and other AWS services
Model flexibility Can use Bedrock models and, where architecture allows, other model providers

When to choose Strands:

  • The app needs custom agent loop behavior.
  • You need to integrate MCP tools directly.
  • You need a flexible multi-agent implementation.
  • You want to deploy an agent framework on AgentCore Runtime, ECS, EKS, or another container platform.
  • You need to combine Bedrock with custom code, custom tools, and production observability.

When to choose Bedrock Agents instead:

  • The scenario emphasizes managed configuration, action groups, knowledge bases, and fast AWS-native agent setup.
  • The team does not need custom agent loop control.
  • Built-in versions, aliases, tracing, guardrails, and action group patterns are sufficient.

MCP and AgentCore Gateway

MCP standardizes how agents discover and call tools. In AWS scenarios, AgentCore Gateway is the managed way to expose APIs, Lambda functions, and existing services as MCP-compatible tools at scale.

MCP deployment model Use when Notes
Local stdio Development, testing, simple local tools Low overhead, not a production sharing pattern
Local SSE/HTTP Local tools that need process separation Useful for more complex local development
Remote streamable HTTP Production or shared tools Scalable, centrally managed, supports remote agent access
AgentCore Gateway Enterprise APIs, Lambda, and services should become discoverable MCP tools Managed ingress/egress auth and scalable tool exposure

AgentCore Gateway exam cues:

  • Converts APIs, Lambda functions, and existing services into MCP-compatible tools.
  • Uses OpenAPI, Smithy, or Lambda target definitions.
  • Requires clear operation descriptions so tools are usable by agents.
  • Supports authentication patterns such as IAM, API key, and OAuth depending on the target.
  • Keep credentials out of code and command history; use service-managed credential providers or Secrets Manager patterns.
  • Monitor gateway errors, latency, and audit control plane activity with CloudWatch and CloudTrail.

Model extension decision table:

Tool requirement Prefer
Lightweight stateless tool Lambda
HTTP API already exists AgentCore Gateway from OpenAPI/Smithy
Complex runtime, custom dependencies, long processing, or many tools ECS/Fargate or AgentCore Runtime
Tool-centric agent interoperability MCP protocol
Agent needs to provide tools to other agents AgentCore Runtime with MCP protocol

AgentCore Runtime, Memory, Identity, and Observability

AgentCore is an exam signal for production-grade custom agents and tools.

AgentCore capability Use for
Runtime Deploy and scale custom agents or tools using protocol contracts
Gateway Expose APIs, Lambda functions, or services as MCP tools
Memory Persist session context and semantic memory across agent invocations
Identity Manage inbound caller authentication and outbound credentials for tools and external APIs
Observability Collect CloudWatch metrics, traces, spans, logs, and agent execution details

Runtime protocol chooser:

Scenario clue Protocol
Existing REST-style agent or web framework HTTP
Agent exposes tools through MCP MCP
Agents communicate directly with other agents A2A
Frontend-connected agent with event stream UI AG-UI

Memory and state cues:

Need Use
Stateless single request No persistent memory; pass all needed context in request
Multi-turn conversation Session ID plus session memory
Long-running workflow Step Functions execution state and task tokens
Fast app state lookup DynamoDB
Cross-session personalization Long-term/semantic memory with explicit privacy and retention controls
Sensitive session context Minimum TTL, KMS encryption, access controls, and retention limits

Observability cues:

  • Track invocation count, latency, error rate, token usage, model ID, tool calls, and step outcomes.
  • Use ADOT/OpenTelemetry instrumentation for richer agent traces.
  • Include input, output, tool calls, and step latency in traces when agent evaluations need to score quality.
  • Encrypt logs and traces that can contain prompts, responses, tool parameters, or PII.

Step Functions for Agentic Reasoning

Step Functions is the exam answer when agentic work must be explicit, auditable, bounded, or approved.

AWS docs show Bedrock plus Step Functions examples for sequential prompt chains, iterative processing, parallel prompts, human-in-the-loop workflows, multi-persona debate, and agents that interact with external APIs.

Pattern Use when Step Functions feature
Sequential prompt chain One model output feeds the next prompt State sequence
ReAct-style loop The system alternates reasoning, tool action, observation, and next step Choice state, loop counter, retry/catch
Parallel analysis Multiple prompts/models evaluate the same input Parallel state
Map over items Process many documents, claims, records, or generated ideas Map state
Human approval A person must approve, select, or correct an output Wait for task token, callback pattern, approval Lambda/API
Timeout and stop Agent must stop after time, iterations, or unsafe output TimeoutSeconds, counters, Choice states
Fallback workflow Model/tool failure needs alternate path Retry, Catch, fallback state
Audit trail Need explicit record of each step Execution history and logs

ReAct-style mental model:

Question
  -> think/planning prompt
  -> choose tool
  -> validate tool input
  -> call tool
  -> observe result
  -> decide continue/stop/escalate
  -> final answer

Bound the loop:

max_iterations
max_duration
allowed_tools
allowed_resources
confidence threshold
human escalation path
fallback answer

Exam trap: chain-of-thought is not a license to expose internal reasoning to users. For production, the important exam point is structured decomposition and controlled steps. Return concise explanations or evidence, not raw hidden reasoning.

Safeguarded Agentic Workflows

Agentic systems are risky because they can call tools, combine data, and take actions. The professional-level answer adds controls around every boundary.

Risk Control
Infinite loop Max iterations, workflow timeout, stopping condition
Long-running tool call Lambda timeout, Step Functions timeout, async job status polling
Repeated downstream failure Circuit breaker and fallback path
Prompt injection in user input Guardrails, prompt attack filters, instruction hierarchy, tool allowlist
Indirect prompt injection in retrieved context or tool output Treat retrieved/tool content as untrusted; validate and guard untrusted content
Unauthorized action IAM least privilege, user authorization check, resource scoping
Malformed tool parameters Schema validation and defensive parsing in Lambda/tool server
Dangerous or irreversible action Human approval, return of control, idempotency, audit log
Sensitive data leakage KMS, Secrets Manager, redaction, log encryption, retention limits
Bad final answer Output validation, groundedness checks, human review, fallback response

Guardrails integration cues:

Guardrail placement Use when
Model inference Direct model calls need prompt and response filtering
Agents All prompts to and responses from a Bedrock Agent need safety controls
Knowledge bases Retrieval and generation need controlled output
Flows Prompt or knowledge base nodes need filtering
ApplyGuardrail API Content needs pre-screening or standalone evaluation before model use

Production guardrail reminders:

  • Pin a numbered guardrail version in production.
  • Do not rely on mutable draft versions for production controls.
  • Use IAM or organization-level enforcement when guardrails are mandatory.
  • Encrypt and restrict logs because prompts, responses, traces, and guardrail details can contain sensitive data.

Model and Agent Coordination

Task 2.1 includes model coordination systems. The exam expects you to choose coordination only when it improves quality or efficiency enough to justify latency and complexity.

Coordination pattern Use when Tradeoff
Task-based routing Different task types need different models Requires reliable task classification
Model cascading Cheap/small model handles easy work; stronger model handles hard or failed cases Adds routing and fallback logic
Specialist agents Subtasks need independent reasoning or domain-specific tools Coordination overhead and trace complexity
Ensemble voting Multiple models answer and a judge/aggregator chooses Higher cost and latency
Parallel critique One model drafts, another critiques or verifies Improves quality for high-value outputs
Aggregation/ranking Multiple outputs must be combined into one final answer Requires deterministic merge and conflict handling
Supervisor-worker Supervisor routes to focused collaborators Supervisor must know collaborator capabilities

Service mapping:

Need AWS fit
Bedrock-managed multi-agent collaboration Amazon Bedrock Agents multi-agent pattern where supported
Code-level multi-agent orchestration Strands Agents multi-agent patterns
Explicit branch/aggregate workflow Step Functions Parallel/Map states and Lambda aggregation
Model selection based on task or metrics Model gateway, AppConfig routing, Step Functions, or custom router
Tool discovery across many tools AgentCore Gateway and MCP tool discovery

Anti-patterns:

  • Using a sub-agent for a deterministic single API call.
  • Giving every agent every tool.
  • Supervisor instructions that do not describe collaborator capabilities.
  • No convergence criteria for swarm or debate patterns.
  • No budget limit for multi-model or multi-agent loops.

Human Augmentation Patterns

Choose human augmentation when the system needs judgment, accountability, approval, or correction.

Scenario clue Pattern
"Approve before submitting order/refund/payment/change" Step Functions approval workflow or return of control
"Legal, medical, financial, HR, or compliance-sensitive decision" Human review before final action
"Low confidence, conflicting evidence, or failed validation" Escalate to reviewer
"Need feedback to improve future outputs" API Gateway feedback endpoint, DynamoDB feedback table, evaluation dataset update
"Domain expert must select the best candidate" Parallel model outputs plus human selection
"Human must provide missing information" Agent asks clarifying question or pauses workflow

Reference workflow:

Agent drafts recommendation
  -> validation and guardrail checks
  -> confidence / risk decision
  -> if low risk: return answer
  -> if high risk: Step Functions waits for reviewer
  -> reviewer approves/edits/rejects
  -> final action runs with audit log

Exam shortcut:

Irreversible action + external impact -> human approval.
Subjective quality -> human evaluation.
Unclear user intent -> ask clarification before tool call.
Low confidence -> escalate or fallback, do not pretend certainty.

Secure Tool Integration Checklist

Use this checklist for any agent that calls tools, APIs, databases, or workflows.

Layer What to implement
Identity Authenticate the user and agent; pass user context to authorization checks
Authorization Enforce least privilege by user, tenant, resource, and action
Tool schema Clear descriptions, strict parameters, enums, bounds, required fields
Input validation Parse and validate all model-generated arguments
Secrets Store credentials in Secrets Manager or AgentCore credential providers, not prompts or code
Network Use VPC/private connectivity where required; restrict outbound access
Idempotency Add request IDs and deduplication for state-changing tools
Timeout Bound tool runtime and workflow duration
Error contract Return structured, non-sensitive error messages
Audit Log who requested what, which tool ran, result status, and sanitized metadata
Data protection Encrypt state, logs, traces, and stored tool outputs
Human approval Require approval for high-risk actions

Common Architecture Patterns

Managed Bedrock Agent:

Client
  -> application API
  -> InvokeAgent with sessionId
  -> Bedrock Agent
  -> optional Knowledge Base retrieval
  -> action group
  -> Lambda tool with validation and IAM
  -> final response

Strands agent with MCP tools:

Client
  -> custom agent service
  -> Strands Agent with Bedrock model
  -> MCP client discovers allowed tools
  -> AgentCore Gateway / MCP server
  -> API, Lambda, database, or enterprise system
  -> validated response

Step Functions controlled agent loop:

Start workflow
  -> planning prompt
  -> choose action
  -> validate action
  -> call tool or model
  -> check stop condition
  -> approve/escalate/fallback
  -> final answer/action

Multi-agent supervisor:

User goal
  -> supervisor agent
  -> route to specialist agent A/B/C
  -> specialists use narrow tools and data
  -> supervisor aggregates and validates
  -> final answer or human review

Human-in-the-loop:

Agent output
  -> risk/confidence check
  -> Step Functions wait for approval
  -> reviewer decision through API Gateway/app
  -> approved action or rejection response
  -> audit trail

Scenario Decision Table

If the question says... Choose...
"Build an agent quickly without managing infrastructure" Amazon Bedrock Agents
"Agent must call enterprise APIs defined by OpenAPI" Bedrock action group or AgentCore Gateway depending on reuse/scale
"Tool should be shared across many agents through a standard protocol" MCP tool exposed through AgentCore Gateway
"Need custom multi-agent orchestration in code" Strands Agents with Bedrock models
"Need AWS-native routing across specialized agents" AWS Agent Squad, Strands multi-agent patterns, or Bedrock multi-agent collaboration depending on managed-vs-code needs
"Need deterministic workflow, retries, approvals, and audit trail" Step Functions orchestration
"Need conversation continuity across requests" Session ID plus Bedrock session attributes, DynamoDB, or AgentCore Memory
"Need long-term agent memory" AgentCore Memory or explicit memory store with retention controls
"Agent must execute code or analyze data in sandbox" Bedrock/AgentCore code interpreter capability where supported
"Agent action group update not visible at runtime" Prepare the Bedrock Agent after configuration changes
"Production rollout of agent changes" Agent versions and aliases
"Agent must ask a human before final action" Return of control or Step Functions human approval
"Tool call inputs could be unsafe" Lambda/tool validation, authorization, and sanitization
"Agent must not exceed time/cost limits" Max iterations, timeouts, token budgets, circuit breaker, fallback
"Many specialized models could solve parts of the problem" Model coordination with routing, aggregation, and budget limits
"Agent output needs safety filtering" Bedrock Guardrails on agents, inference, KBs, or flows
"Need to troubleshoot agent behavior" Enable tracing/observability; inspect tool calls, model steps, errors, and latency

Production Anti-Patterns

Anti-pattern Better answer
Giving an agent broad AWS permissions Least-privilege role scoped to required actions and resources
Letting an agent call tools without validation Validate, sanitize, authorize, and bound every tool invocation
Using agents for deterministic one-step work Use a Lambda function, workflow step, or direct API call
No session ID Pass session ID for continuity when multi-turn behavior matters
Storing all memory forever Use minimum TTL, retention policy, encryption, and user consent/controls
No stop condition in ReAct loop Add max iterations, timeout, fallback, and escalation path
No human review for irreversible action Add approval workflow or return of control
Hardcoding API keys in prompts or environment variables Use Secrets Manager or AgentCore credential providers
Agent logs contain raw PII/secrets Redact, encrypt, restrict access, and set retention
Using every tool in every agent Restrict tools by task, role, tenant, and risk level
Supervisor agent communicates with collaborators through invented tools Use built-in multi-agent collaboration, A2A, or an explicit supported integration pattern
No version or alias strategy Use prepared versions, aliases, canary/blue-green rollout, and rollback
No observability Log model ID, prompt/version, session ID, tool calls, latency, token use, errors, and outcomes

Exam Traps

Trap Correct thinking
"Agent" means fully autonomous Production agents need boundaries, tool controls, stop conditions, and human escalation
"MCP is the tool itself" MCP is the protocol; tools still need secure implementation and authorization
"Action group schema is enough security" Schema helps selection; Lambda/tool code must still validate and authorize
"Memory is always good" Memory increases privacy, retention, and correctness risk; use only what the use case needs
"Chain-of-thought should be shown to the user" Use structured reasoning internally; return concise answer, evidence, and relevant explanation
"More agents means better results" More agents add coordination cost, latency, and failure modes
"Guardrails replace IAM" Guardrails filter content; IAM enforces resource access
"Human-in-the-loop is only for training" Human review is also for approvals, accountability, low confidence, and high-risk actions
"Trace everything freely" Traces can contain sensitive prompts, retrieved context, tool parameters, and intermediate outputs
"Prepare-agent is optional" Bedrock Agents must be prepared after configuration changes

Study Checklist

Before moving to Task 2.2, make sure you can:

  • Explain Domain 2 weight and Task 2.1 scope.
  • Choose between Amazon Bedrock Agents, Strands Agents, AgentCore Runtime, Step Functions, and a direct tool/API call.
  • Design action groups with Lambda, OpenAPI/function schemas, return of control, and least-privilege permissions.
  • Explain why every tool parameter from an agent is untrusted input.
  • Use MCP and AgentCore Gateway for standardized enterprise tool integration.
  • Choose Lambda vs ECS/AgentCore Runtime for model extension tools.
  • Design a bounded ReAct-style or prompt-chaining workflow with Step Functions.
  • Add safeguards: max iterations, timeouts, IAM boundaries, guardrails, circuit breaker, and fallback path.
  • Design multi-agent or multi-model coordination without unnecessary sub-agents.
  • Add human approval and feedback workflows for high-risk or subjective outputs.
  • Manage state with session IDs, AgentCore Memory, DynamoDB, or Step Functions execution state.
  • Identify observability requirements for agent traces, tool calls, latency, errors, and token use.

Sources