Skip to content

Skill 3.2.11: Deploy agentic workflow infrastructure

Question 1 - Agent Runtime Session Isolation

A financial services company is building an AI assistant that handles account inquiries for customers. The assistant uses Amazon Bedrock AgentCore to manage agent execution. Each customer conversation session must be isolated so that one customer's in-progress working state (such as partially retrieved account details or intermediate tool call results) can never be accessed by another customer's session. The architecture must support thousands of concurrent sessions while maintaining isolation between them.

Which capability of the agent runtime is MOST responsible for satisfying this requirement?

  • A) Configuring a dedicated OpenSearch Serverless collection with per-session index partitions
  • B) Enabling Amazon Bedrock AgentCore session isolation that provisions separate execution environments per session
  • C) Creating a separate AWS account per customer to ensure complete isolation of all resources
  • D) Implementing application-level state encryption using KMS customer-managed keys before storing session state
  • E) Deploying the agent on a SageMaker endpoint with multi-model endpoint partitioning
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Amazon Bedrock AgentCore isolates each agent session in its own execution environment, ensuring that working state (intermediate tool calls, retrieved context, partial reasoning) is scoped to a sessionId. This is a built-in runtime capability designed for multi-tenant agent deployments.

Distractor Analysis

  • A is Incorrect: A vector store with per-session index partitions addresses data retrieval isolation but does not isolate the agent's execution environment, working memory, or intermediate state.
  • C is Incorrect: Creating a separate AWS account per customer is operationally impractical, violates the "least operational overhead" principle for thousands of concurrent sessions, and is not how AgentCore session isolation works.
  • D is Incorrect: Application-level KMS encryption protects data at rest but does not prevent one session from reading another session's runtime execution state.
  • E is Incorrect: SageMaker multi-model endpoint partitioning handles model artifact sharing on a single endpoint, not agent session state or execution isolation.

Key Takeaway: Agent runtime session isolation is a built-in execution environment boundary per session—not a data encryption or data store partitioning problem.

Question 2 - Agent Memory Architecture Design

A healthcare technology company is designing a patient-facing AI assistant for appointment scheduling and health history retrieval. The assistant must maintain conversational context within a single multi-turn interaction (e.g., patient says "reschedule my appointment," then follows up with "make it for Tuesday instead"). Additionally, returning patients should not have to re-provide their date of birth, insurance provider, and preferred clinic location on every new session.

Which of the following memory configurations should the engineering team implement? (Select TWO)

  • A) Configure long-term memory in Amazon Bedrock AgentCore with actor-scoped namespaces (e.g., /patients/{patientId}/) to persist patient preferences and facts across sessions
  • B) Use only short-term memory for all patient data, but increase the session timeout to 90 days
  • C) Implement short-term memory for conversation history within the current session using the sessionId to scope the context
  • D) Store all patient context in a DynamoDB table and manually pass the full context in every prompt without any built-in memory
  • E) Disable long-term memory and rely on retrieval-augmented generation to recall patient context from the knowledge base alone
Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

  • A is Correct: Long-term memory (LTM) in AgentCore persists user context across sessions using actor-scoped namespaces. This allows returning patients to retain preferences like insurance provider and clinic location without re-providing them during every new session.
  • C is Correct: Short-term memory maintains conversational context within a single session (scoped to the sessionId), enabling follow-up questions and clarifications to be understood during multi-turn conversations.

Distractor Analysis

  • B is Incorrect: Extending a session timeout to 90 days is not a substitute for long-term memory—it only keeps the working memory alive longer and does not persist across session termination, leading to stale or incomplete context.
  • D is Incorrect: Manually managing context in DynamoDB requires custom infrastructure and injection logic, defeating the purpose of AgentCore's native memory management and introducing unnecessary operational overhead.
  • E is Incorrect: RAG retrieves information from a vector index or knowledge base—it does not capture personalized user context or multi-session memory; relying on it alone would fail to remember patient-specific preferences across sessions.

Key Takeaway: Short-term memory handles current-session context; long-term memory persists across sessions. Choose both for natural multi-turn and cross-session user experiences.

Question 3 - Agent Tool Exposure Through Gateway

A retail company has an existing order management system exposed via internal REST APIs. They want to deploy a customer support agent in production. The agent must be able to call these existing order lookup and return-initiation APIs as tools. The team wants to avoid rebuilding these APIs as native AWS Lambda functions and minimize the exposure risk of the internal APIs.

Which AWS-native design should the architecture use to expose these existing services to the agent as tools?

  • A) Rewrite the REST APIs as AWS Lambda functions and expose them via SageMaker Inference Pipelines
  • B) Use Amazon Bedrock AgentCore's gateway to present the existing REST APIs as tools using an OpenAPI specification
  • C) Package the REST API code into a Docker container and deploy it as a SageMaker endpoint
  • D) Store the API documentation in an S3 bucket and rely on the agent's RAG capability to infer how to call the APIs
  • E) Use Amazon API Gateway to create a GraphQL resolver and embed the resolver directly into the agent's Bedrock prompt
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Amazon Bedrock AgentCore includes a gateway that allows existing APIs and functions to be exposed as agent tools. By providing an OpenAPI specification, the gateway translates the agent's tool invocation into HTTP calls against existing services—no rewrite required.

Distractor Analysis

  • A is Incorrect: Rewriting existing REST APIs as Lambda functions would eliminate the use of the existing system, introduces significant development overhead, and violates the requirement to "avoid rebuilding."
  • C is Incorrect: Containerizing API code and deploying it as a SageMaker endpoint changes the deployment target but does not address exposing the existing REST APIs to an agent as tool-executable functions; it also adds operational complexity.
  • D is Incorrect: Storing API docs in S3 and relying on RAG is not a reliable tool execution mechanism—RAG retrieves relevant text, not executable API contracts, and the agent could not deterministically call the APIs.
  • E is Incorrect: Embedding a GraphQL resolver directly into a Bedrock prompt is a non-standard, unsupported approach; the agent cannot execute GraphQL resolvers as tools via prompt injection alone.

Key Takeaway: AgentCore's gateway with OpenAPI specifications is the native AWS pattern for exposing existing microservices/APIs to agents as callable tools without rebuilding them.

Question 4 - Agent Observability and Traceability

A logistics company has deployed a shipping inquiry agent that occasionally provides incorrect answers about shipment status. The team suspects a tool call (such as querying the carrier's tracking API) returns unexpected data, causing the agent to respond incorrectly. The architecture must include observability that records each step the agent takes—including the tool name, input parameters, response payload, and intermediate reasoning—so the team can identify which step failed.

Which TWO AWS solutions provide the necessary observability? (Select TWO)

  • A) Configure agent tracing in Amazon Bedrock AgentCore to log invocation metrics and trace data to Amazon CloudWatch
  • B) Enable AWS X-Ray tracing on a SageMaker endpoint hosting the agent
  • C) Implement custom logging in a Lambda function that the agent calls before every tool invocation
  • D) Use Amazon OpenSearch Service to index agent prompts for fast search retrieval
  • E) Enable Amazon CloudWatch Logs and metrics as part of Bedrock AgentCore's built-in observability for each agent execution step
Click to reveal Answer & Explanation

Correct Answers: A and E

Correct Options Analysis

  • A is Correct: Bedrock AgentCore integrates with CloudWatch for logging and monitoring. Configuring agent tracing sends trace data to CloudWatch, capturing each step of the agent's execution—including tool calls and intermediate reasoning.
  • E is Correct: CloudWatch Logs is the native logging destination for Bedrock AgentCore. Enabling logging captures each step of the agent's execution—including tool call parameters and responses—so the team can analyze failures.

Distractor Analysis

  • B is Incorrect: AWS X-Ray tracing on SageMaker endpoints helps trace model inference latency and downstream calls, but it does not provide step-by-step agent execution tracing (tool name, input parameters, response payload) for Bedrock agents.
  • C is Incorrect: Custom Lambda logging captures only pre-tool invocation data (if the Lambda executes before each tool call), which is both incomplete and not the native observability pattern for AgentCore.
  • D is Incorrect: Indexing agent prompts in OpenSearch only retrieves past user prompts—it does not record tool call execution details or intermediate reasoning steps.

Key Takeaway: For agent failure analysis, enable Bedrock AgentCore CloudWatch integration (logging and tracing) to capture each step—especially every tool call's input and output.

Question 5 - Agent Identity and Tool Access Control

A pharmaceutical company is deploying a regulatory-compliance AI agent that must access sensitive internal resources: a clinical trial database, an FDA submission system, and an internal document repository. Compliance requirements mandate that every tool call the agent makes must be traceable to a specific identity, and the agent must have least-privilege access to only the resources its current task requires.

Which configuration best satisfies these requirements with the least operational overhead?

  • A) Create one long-lived IAM role with broad permissions and attach it to every agent session
  • B) Configure Amazon Bedrock AgentCore to use session-scoped, least-privilege IAM roles for the agent's tool invocations, with CloudTrail recording the identity of each call
  • C) Store database credentials in AWS Secrets Manager and have the agent retrieve them whenever it needs to call a tool
  • D) Use a Lambda function as a proxy that validates the agent's request and makes the actual tool call using a static IAM role
  • E) Assign each tool a separate IAM user with hardcoded API keys and rotate them manually on a quarterly basis
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Amazon Bedrock AgentCore supports session-scoped IAM roles that dynamically scope permissions to what the agent needs for the current task. CloudTrail logs each tool invocation with the associated identity, satisfying both traceability and least-privilege requirements with minimal operational overhead.

Distractor Analysis

  • A is Incorrect: A single broad IAM role violates the principle of least privilege—if the role is compromised, all agent sessions have access to all sensitive resources.
  • C is Incorrect: Static credentials in Secrets Manager retrieved by the agent create a single shared credential and do not enforce session-level least-privilege; this also adds operational complexity for rotation.
  • D is Incorrect: A Lambda proxy adds an intermediate layer but still uses a static IAM role; it does not provide per-session identity scoping and introduces additional architectural overhead.
  • E is Incorrect: Hardcoded API keys in IAM users are an anti-pattern for security, provide no session-level scoping, and manual rotation is operationally burdensome and prone to error.

Key Takeaway: Best-practice agent identity management leverages session-scoped IAM roles through the agent runtime, with CloudTrail providing call-level traceability—not shared credentials or broad static roles.

Question 6 - Multi-Agent Orchestration Infrastructure

A bank wants to automate complex mortgage application processing by deploying multiple specialized agents: one for document extraction, one for credit score analysis, one for risk assessment, and one for final decision support. These agents must communicate with each other, passing context (e.g., extracted income verification results) between them. The architecture must support workflow continuity and ensure each agent executes with its own isolated runtime context.

Which AWS-native infrastructure pattern should the solution architect use?

  • A) Deploy all agents on a single SageMaker endpoint with multi-model support and enable them to share memory
  • B) Use AWS Step Functions to orchestrate Lambda functions that emulate agent behaviors, bypassing Bedrock AgentCore
  • C) Use Amazon Bedrock AgentCore multi-agent orchestration, where each specialized agent runs in its own execution environment and passes context through the shared orchestration layer
  • D) Deploy each agent as a separate SageMaker endpoint behind a shared API Gateway REST API that manages state
  • E) Combine all agent logic into a single monolithic Bedrock agent to reduce orchestration complexity
Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

  • C is Correct: Bedrock AgentCore supports multi-agent orchestration, where each specialized agent runs as an independent execution environment with its own runtime context. The orchestration layer handles inter-agent communication and context passing, satisfying both isolation and workflow continuity requirements.

Distractor Analysis

  • A is Incorrect: A single SageMaker endpoint cannot host multiple agents with distinct execution isolation and inter-agent communication; it hosts model inference, not agent runtime orchestration.
  • B is Incorrect: Using Step Functions and Lambda bypasses Bedrock AgentCore entirely, requiring manual implementation of agent logic and state management—high operational overhead and no built-in agent memory or execution isolation.
  • D is Incorrect: Separate SageMaker endpoints for each agent under API Gateway provides hosting but not agent-to-agent orchestration or context-passing semantics; this would require significant custom state management.
  • E is Incorrect: A monolithic agent that handles all tasks violates the specialization and isolation requirements, creates a single point of failure, and does not leverage multi-agent orchestration.

Key Takeaway: For multi-agent workflows, Bedrock AgentCore's built-in multi-agent orchestration provides execution isolation and context passing without custom infrastructure.

Question 7 - Agent Runtime and Serverless Inference Integration

An e-commerce company is building a product recommendation agent that uses two components: a Bedrock agent for conversational understanding and a fine-tuned recommendation model for final product scoring. The recommendation model requires GPU acceleration and must be invoked from the agent's tool execution pipeline. The solution must minimize cold-start latency and operational overhead, while supporting variable traffic patterns with occasional bursts.

Which TWO AWS configuration choices satisfy these requirements? (Select TWO)

  • A) Deploy the recommendation model on a SageMaker real-time inference endpoint with GPU instances and configure auto scaling with high-resolution concurrency metrics
  • B) Deploy the recommendation model on SageMaker Serverless Inference to eliminate cold starts entirely
  • C) Register the SageMaker endpoint as a tool in the Bedrock agent configuration so the agent can invoke it during execution
  • D) Store the recommendation model in S3 and have the agent download it dynamically for each request
  • E) Use a batch transform job to precompute all recommendations daily
Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

  • A is Correct: A SageMaker real-time endpoint with GPU instances provides the necessary GPU acceleration. Configuring auto scaling with high-resolution concurrency metrics ensures the endpoint scales quickly during traffic bursts while minimizing idle capacity.
  • C is Correct: SageMaker endpoints can be registered as tools in a Bedrock agent's tool configuration (via OpenAPI spec or SageMaker integration), allowing the agent to invoke the recommendation model as part of its execution pipeline.

Distractor Analysis

  • B is Incorrect: SageMaker Serverless Inference does not support GPU acceleration; it is CPU-based, making it unsuitable for a GPU-accelerated recommendation model.
  • D is Incorrect: Dynamically downloading the model from S3 for each request introduces unacceptable latency and is not a valid inference pattern for real-time agent tool calls.
  • E is Incorrect: Batch transform precomputes recommendations offline and cannot support real-time interactive requests from an agent requiring dynamic, context-aware recommendations.

Key Takeaway: SageMaker real-time GPU endpoints with auto scaling + Bedrock agent tool registration is the standard pattern for GPU-accelerated inference within agentic workflows.

Question 8 - Agent State Management for Multi-Tenant Security

A SaaS company is deploying a multi-tenant AI agent for their customers' support portals. Each tenant (customer organization) must have their agent state and memory completely segregated. One tenant's support agent must never be able to access another tenant's conversation state or memory. The company needs the most operationally efficient solution that enforces isolation at the infrastructure level, not just at the application layer.

Which configuration best satisfies these requirements?

  • A) Use a single Bedrock AgentCore environment with a shared long-term memory store and rely on naming conventions to separate tenants
  • B) Create a separate Bedrock AgentCore agent instance for each tenant with its own dedicated long-term memory namespace and IAM role
  • C) Use a shared SageMaker endpoint with tenant-specific headers to filter memory access
  • D) Store all tenant memory in a single DynamoDB table with a partition key for tenant ID and use conditional writes for isolation
  • E) Deploy a separate VPC for each tenant and route all agent traffic through the tenant's dedicated VPC
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Creating a dedicated Bedrock AgentCore agent instance per tenant with isolated memory namespaces and IAM roles enforces infrastructure-level isolation. Each tenant's agent runs with its own identity and access scope, preventing cross-tenant data access at the infrastructure layer.

Distractor Analysis

  • A is Incorrect: A single shared environment with naming conventions relies on application-layer separation only—a misconfiguration or bug could expose one tenant's data to another; this does not meet the infrastructure-level isolation requirement.
  • C is Incorrect: Tenant-specific headers on a shared SageMaker endpoint only affect request routing, not memory isolation—the agent memory store would still be shared unless explicitly partitioned.
  • D is Incorrect: A shared DynamoDB table with partition keys and conditional writes is an application-layer isolation pattern, not infrastructure-level segregation; a single misconfigured access policy could compromise all tenants.
  • E is Incorrect: Deploying a VPC per tenant is overly complex, does not directly address agent memory isolation, and is not how Bedrock AgentCore determines tenant boundaries.

Key Takeaway: For hard multi-tenant isolation, separate agent instances with distinct IAM roles and memory namespaces provide infrastructure-level segmentation—not shared stores with naming conventions.

Question 9 - Agent Failure Recovery and Checkpointing

A weather monitoring company runs a long-running AI agent that gathers data from multiple meteorological APIs, processes it, and generates a forecast report. The agent sometimes takes up to 30 minutes to complete a full execution cycle. If the agent fails mid-execution (e.g., due to a transient API failure), the team wants the agent to resume from the last successful step rather than restart from the beginning. The solution must integrate with Amazon Bedrock AgentCore without requiring custom state management infrastructure.

Which AWS capability should the team leverage?

  • A) Enable Step Functions with Express Workflows to manage agent checkpointing
  • B) Implement a custom state machine using DynamoDB TTL items to track agent progress
  • C) Use Amazon Bedrock AgentCore's built-in state management with checkpoint and resume capabilities
  • D) Store agent state in an S3 bucket with versioning enabled and manually restore the last checkpoint
  • E) Use Amazon EFS mounted to the agent's container for persistent state storage
Click to reveal Answer & Explanation

Correct Answer: C

Correct Options Analysis

  • C is Correct: Amazon Bedrock AgentCore natively provides state management with checkpoint and resume capabilities. The agent can be configured to automatically checkpoint its execution state at each step, allowing it to resume from the last successful step after a failure without custom infrastructure.

Distractor Analysis

  • A is Incorrect: Step Functions Express Workflows are for orchestrating Lambda functions and AWS service calls, not for managing the internal state of a Bedrock agent—this would require a parallel orchestration layer that duplicates AgentCore's native capabilities.
  • B is Incorrect: Building a custom state machine with DynamoDB TTL items is an application-layer workaround that introduces significant operational overhead and does not leverage AgentCore's built-in checkpointing.
  • D is Incorrect: S3 with versioning stores object versions but does not provide agent execution checkpoint semantics or the ability to resume mid-execution from the last successful step.
  • E is Incorrect: EFS mounted to the agent's container provides a shared file system but requires the agent itself to implement and manage checkpoint persistence—this does not leverage the runtime's built-in resume capabilities.

Key Takeaway: Bedrock AgentCore's built-in state management with checkpoint/resume saves agent workflows from restarting from scratch—no custom state infrastructure needed.

Question 10 - Agent and Human-in-the-Loop Workflow

A legal firm wants to deploy a contract review agent that identifies risky clauses in legal documents. However, for compliance reasons, the agent cannot autonomously make recommendations or take actions on contracts—it must pause and wait for a human lawyer to approve or reject its findings before proceeding to generate the final review report. The solution must integrate with Amazon Bedrock AgentCore and provide a record of all human decisions.

Which AWS capability should the team use to implement this human-in-the-loop workflow?

  • A) Configure the agent to always stop execution after analyzing a document and ask the user to provide approval before continuing
  • B) Use Amazon Bedrock AgentCore's collaborative agent action groups with human approval routing that pauses the agent for human input
  • C) Implement a manual workaround using an SQS queue where the agent drops its findings and a separate application polls for human decisions
  • D) Use AWS Step Functions to orchestrate the agent's calls and insert an Approval state with an Activity that a human can signal
  • E) Store the agent's findings in a DynamoDB table and have a separate human review system modify the findings before the agent resumes
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Amazon Bedrock AgentCore supports human-in-the-loop (HITL) workflows through collaborative agent action groups, where the agent can pause execution, route a review request to a human, and wait for approval or rejection before continuing. This capability provides native integration with the agent runtime and records all human decisions for audit.

Distractor Analysis

  • A is Incorrect: Simply configuring the agent to stop and ask the user does not implement a deterministic human-in-the-loop workflow with routing and audit tracking—it is an ad hoc conversational prompt, not a structured approval mechanism.
  • C is Incorrect: Using an SQS queue for manual approval requires building a separate poller application and does not provide the native AgentCore HITL integration or an audit record of human decisions.
  • D is Incorrect: Step Functions with an Approval state and Activity is a valid HITL orchestration pattern for workflow engines, but it does not integrate with Bedrock AgentCore's agent runtime—the agent would need to be invoked as a separate service, not use its native execution environment.
  • E is Incorrect: A separate DynamoDB review system is an application-layer workaround that requires manual human interaction external to the agent runtime and does not benefit from AgentCore's native HITL capabilities.

Key Takeaway: Bedrock AgentCore's collaborative action groups with human approval routing provide native HITL workflows with built-in audit records—no external orchestration or manual workarounds needed.