Skip to content

Skill 1.1.1: Extract data from data sources

Question 1 - Agent State Management Design for Multi-Session Memory

A financial services company is building an AI-powered customer support agent using Amazon Bedrock AgentCore. The agent handles account inquiries, transaction disputes, and personalized financial advice. The architecture requires that the agent maintain conversation context within a single session (short-term memory) while also remembering customer preferences, previously resolved issues, and account details across separate login sessions (long-term memory). Compliance mandates that all agent state data must be encrypted at rest and must not exceed a 30-day retention period.

Which TWO configuration choices should the machine learning engineer implement to meet these requirements? (Select TWO)

  • A) Configure AgentCore Memory with both session-scoped state (for multi-turn conversations) and actor-scoped namespaces under /preferences/{actorId}/ for cross-session persistence.
  • B) Use only the built-in session state because AgentCore automatically promotes frequently accessed session data to long-term memory.
  • C) Implement a custom DynamoDB table for long-term memory and disable AgentCore Memory retention beyond 30 days using a TTL attribute.
  • D) Enable AgentCore Memory with default retention settings, as AgentCore automatically applies GDPR-compliant 30-day retention.
  • E) Configure the agent runtime with strict session isolation and rely on the gateway to persist state across sessions for returning users.
Click to reveal Answer & Explanation

Correct Answers: A and C

Correct Options Analysis

  • A is Correct: AgentCore Memory natively supports two memory scopes: session-scoped state (short-term memory for multi-turn conversations within a single session) and actor-scoped namespaces (long-term memory keyed by user identity, e.g., /preferences/{actorId}/). Configuring both satisfies the requirement for contextual dialogue and cross-session persistence.
  • C is Correct: For compliance with the 30-day retention mandate, a custom DynamoDB table with a TTL attribute gives explicit control over data expiry. DynamoDB encrypts data at rest by default (AES-256) and supports fine-grained lifecycle management.

Distractor Analysis

  • B is Incorrect: AgentCore does not automatically promote session data to long-term memory. Long-term memory must be explicitly configured with actor-scoped namespaces and extraction strategies.
  • D is Incorrect: AgentCore Memory does not automatically enforce a 30-day retention policy. Retention settings are configurable but require explicit policy definition; default settings may retain data indefinitely.
  • E is Incorrect: The gateway (e.g., API Gateway) handles tool exposure and protocol translation, not state persistence. Session isolation prevents cross-session leakage but does not provide memory continuity.

Key Takeaway: Long-term memory in AgentCore requires explicit actor-scoped namespace configuration; retention compliance is a design decision, not a default behavior.

Question 2 - Session Isolation in Multi-Tenant Agent Runtime

A healthcare technology company is deploying an AI agent using Amazon Bedrock AgentCore to assist patients with appointment scheduling and medication reminders. The agent serves multiple hospital tenants, and HIPAA compliance requires strict data isolation: one patient's conversation state must never be accessible to another patient or tenant, even during concurrent sessions. The system must also record every tool call an agent makes for forensic auditing.

Which configuration achieves these requirements with LEAST operational overhead? (Select ONE)

  • A) Deploy a separate AgentCore runtime instance per tenant, with a dedicated VPC and KMS key for each tenant.
  • B) Use AgentCore's built-in session isolation by passing a unique sessionId per user session, and enable Amazon CloudWatch logging of the orchestration trace for tool calls.
  • C) Implement a custom session management layer using Amazon ElastiCache for Redis with client-side encryption and manual tool call logging.
  • D) Store all agent state in a shared Amazon S3 bucket with prefix-level IAM policies and periodic batch auditing.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: AgentCore automatically isolates execution environments per sessionId, ensuring that working memory, intermediate reasoning, and tool outputs for one session are not accessible by another. Enabling CloudWatch logging captures the orchestration trace, including every tool invocation, satisfying the forensic audit requirement without custom code.

Distractor Analysis

  • A is Incorrect: Deploying a dedicated runtime per tenant significantly increases operational overhead. AgentCore's session isolation already provides per-session separation; per-tenant deployment adds unnecessary complexity and cost unless there are distinct compliance boundaries (e.g., separate AWS accounts).
  • C is Incorrect: Building a custom session management layer on Redis introduces significant operational burden (clustering, backups, encryption, patching) when AgentCore natively provides the required isolation and observability.
  • D is Incorrect: Storing agent state in S3 does not provide real-time session isolation for active agent execution. S3 is object storage, not a session store, and batch auditing does not fulfill the real-time forensic recording requirement.

Key Takeaway: AgentCore's built-in session isolation (via sessionId) is the low-overhead way to achieve tenant separation; augment with CloudWatch logs, not custom infrastructure.

Question 3 - High-Resolution Scaling for Streaming Inference

A media company hosts a real-time video captioning model on Amazon SageMaker AI. The model receives concurrent inference requests during live events, and each request streams tokens back over a period of 10–30 seconds. The current auto scaling policy uses SageMakerVariantInvocationsPerInstance (1-minute resolution), causing scale-out delays when viewership spikes rapidly. This results in increased latency and dropped connections.

Which action should the engineer take to reduce scale-out latency for this workload? (Select ONE)

  • A) Increase the target value of the existing SageMakerVariantInvocationsPerInstance policy to allow more requests per instance.
  • B) Replace the policy with a target-tracking policy on a high-resolution concurrency metric such as ConcurrentRequestsPerModel.
  • C) Add a scheduled scaling action that increases instance count 10 minutes before each live event.
  • D) Switch the endpoint to a serverless configuration with provisioned concurrency set to the peak expected load.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: High-resolution concurrency metrics (e.g., ConcurrentRequestsPerModel or ConcurrentRequestsPerCopy) are published at sub-minute intervals (10-second granularity). For streaming responses where requests remain "in flight" for extended periods, concurrency captures the sustained demand better than invocation count. Target tracking on this metric triggers scale-out within seconds of a surge.

Distractor Analysis

  • A is Incorrect: Raising the target value for invocations per instance forces each instance to handle more traffic before scaling out, which worsens the latency problem rather than solving it.
  • C is Incorrect: Scheduled scaling actions are useful for predictable events with a fixed start time but cannot dynamically respond to unexpected viewership spikes mid-stream. Sudden spikes still cause delayed scaling.
  • D is Incorrect: Serverless endpoints are not generally suited for high-throughput streaming inference; they also do not resolve real-time scaling issues, as they scale on fixed concurrency levels rather than dynamically based on load.

Key Takeaway: Use high-resolution concurrency metrics for streaming or long-running inference workloads; invocation count lags behind sustained demand.

Question 4 - Cross-Stack Networking Reference for Endpoint Deployment

A large enterprise has separate teams for network infrastructure and machine learning operations. The networking team owns an AWS CloudFormation stack that creates VPC subnets and security groups. The ML team needs to deploy a SageMaker AI real-time endpoint into those subnets without hardcoding subnet IDs and security group IDs into their own stack.

What mechanism allows the ML team's stack to reference the networking team's resources dynamically? (Select ONE)

  • A) Define a custom resource in the ML stack that queries AWS Resource Groups for subnet IDs.
  • B) Use CloudFormation cross-stack references: the networking stack exports its subnet and security group IDs, and the ML stack imports them with Fn::ImportValue.
  • C) Store subnet IDs in AWS Secrets Manager and have the ML stack retrieve them via a Lambda-backed custom resource.
  • D) Use a CloudFormation parameter in the ML stack that the team manually populates with subnet IDs copied from the VPC console.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: CloudFormation cross-stack references are the canonical way to share resource values between stacks owned by different teams. The networking stack declares Export in its Outputs section for Subnet IDs and Security Group IDs. The ML stack then uses Fn::ImportValue to reference those exported values, ensuring automatic updates when the network stack changes.

Distractor Analysis

  • A is Incorrect: AWS Resource Groups is not designed for dynamic infrastructure reference; querying it via a custom resource adds unnecessary complexity and does not provide the direct policy-managed integration that CloudFormation exports offer.
  • C is Incorrect: Storing subnet IDs in Secrets Manager and retrieving them via Lambda introduces unnecessary operational overhead and latency. CloudFormation exports are purpose-built for this cross-stack use case.
  • D is Incorrect: Hardcoding subnet IDs into parameters creates configuration drift and breaks silently if the networking team modifies subnets. This violates the principle of avoiding manual copying between stacks.

Key Takeaway: Cross-stack references via Fn::ImportValue / Export are the AWS-native way to share VPC resources between stacks without copying IDs.

Question 5 - VPC Endpoint for Model Artifact Access

A financial institution requires that all SageMaker AI endpoint traffic, including model artifact retrieval from Amazon S3 and calls to Amazon ECR, must never traverse the public internet. The endpoint will be deployed in a VPC with private subnets that have no internet gateway. During startup, the endpoint fails because it cannot reach the S3 bucket containing the model artifacts.

What configuration should the engineer implement to resolve this issue? (Select ONE)

  • A) Add a NAT Gateway to the private subnets and update the route table to send all traffic through it.
  • B) Create an S3 Gateway VPC Endpoint and an ECR VPC Endpoint, and update the route tables and security groups accordingly.
  • C) Move the model artifacts to an Amazon EFS file system mounted on the endpoint instance.
  • D) Attach the endpoint to a security group with an outbound rule allowing 0.0.0.0/0 access for port 443.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: To access S3 privately, an S3 Gateway VPC Endpoint must be created and added to the private subnet's route table. For ECR (API and Docker layer), the recommended approach is an ECR VPC Endpoint (AWS PrivateLink) along with an S3 Gateway endpoint for the image layers. This ensures all traffic to S3 and ECR stays on the AWS private network backbone.

Distractor Analysis

  • A is Incorrect: A NAT Gateway allows outbound internet access by routing traffic through the public internet, which directly violates the compliance requirement that traffic must not leave the private network.
  • C is Incorrect: Migrating artifacts to EFS resolves S3 access but is architecturally incorrect for model artifacts, which SageMaker expects to be stored and retrieved from S3. It also adds unnecessary storage infrastructure overhead.
  • D is Incorrect: Opening port 443 to 0.0.0.0/0 would permit outbound internet traffic, violating the private network compliance mandate.

Key Takeaway: Private network compliance requires VPC endpoints (S3 Gateway + ECR PrivateLink) instead of NAT gateways or open security groups.

A legal research platform uses Amazon Bedrock Knowledge Bases to ingest case law documents and provide retrieval-augmented generation (RAG) answers. The business requires that queries retrieve both semantically similar passages and exact statutory citations (e.g., "42 U.S.C. § 1983"). The team needs a vector store that supports hybrid search—combining dense vector similarity with sparse keyword matching—in a single query.

Which vector store configuration satisfies this requirement? (Select ONE)

  • A) Use Amazon OpenSearch Serverless as the vector store and configure it with a filterable text field to support hybrid search.
  • B) Store embeddings in an Amazon S3 bucket and use Amazon Athena to run SQL queries combining vector and keyword search.
  • C) Use an Amazon RDS for PostgreSQL instance with pgvector and rely on full-text search indexes for exact citations.
  • D) Use a graph database like Amazon Neptune to store embeddings and traverse relationships between case citations.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Options Analysis

  • A is Correct: Amazon OpenSearch Service (including Serverless) supports hybrid search within Bedrock Knowledge Bases. Hybrid search requires a filterable text field in the index that stores the original text chunk, enabling BM25-based lexical search to run alongside k-NN vector similarity in a single query.

Distractor Analysis

  • B is Incorrect: S3 is object storage, not a queryable vector index. Amazon Athena is a SQL query engine for structured data and does not support vector similarity search or hybrid retrieval.
  • C is Incorrect: While Postgres with pgvector supports vector search, it lacks native hybrid search integration with Bedrock Knowledge Bases in the same way OpenSearch does. Full-text search indexes in PostgreSQL would require manual blending, increasing complexity.
  • D is Incorrect: Neptune is designed for graph relationship traversal, not hybrid vector-lexical retrieval. It would add architectural complexity without providing hybrid search capabilities.

Key Takeaway: Hybrid search in Bedrock Knowledge Bases requires OpenSearch Service with a filterable text field. Other vector stores (S3, relational DBs, graph DBs) lack this capability.

Question 7 - Metric Selection for GPU Inference Scaling

An AI startup deploys a computer vision model for real-time object detection on SageMaker AI using an ml.g5.12xlarge instance (4 GPUs). The workload's cost driver is GPU utilization, not request count. Under-utilized instances waste significant cost, while overloaded instances cause inference latency spikes. The team wants auto scaling decisions based on GPU utilization.

Which approach should the team implement? (Select ONE)

  • A) Use a target-tracking policy on the built-in SageMakerVariantInvocationsPerInstance metric.
  • B) Publish a custom metric for GPU utilization to Amazon CloudWatch and configure a target-tracking policy on that metric.
  • C) Use a scheduled scaling action that adjusts instance count based on historical GPU usage patterns.
  • D) Enable Application Auto Scaling with a step scaling policy using the built-in CPUUtilization metric.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: SageMaker AI does not provide a built-in GPU utilization metric that Application Auto Scaling can directly use for scaling decisions. For GPU-bound workloads, the engineer must publish a custom metric (e.g., via the CloudWatch agent installed in the container, or by running inference inside a custom container that emits amdgpu or nvidia-smi metrics). Configure a target-tracking policy on CustomGPUUtilization to add/remove instances based on actual GPU load.

Distractor Analysis

  • A is Incorrect: SageMakerVariantInvocationsPerInstance measures request throughput per instance, not GPU utilization. For workloads where GPU load is the bottleneck, request count does not correlate with actual hardware saturation.
  • C is Incorrect: Scheduled scaling is useful for predictable workloads but cannot dynamically react to variable inferences that drive GPU utilization in unpredictable bursts.
  • D is Incorrect: CPUUtilization is not the appropriate signal for GPU-bound workloads. GPU-intensive models can exhibit low CPU usage while GPUs are saturated. Step scaling on CPU would misallocate capacity.

Key Takeaway: GPU-bound scaling requires custom metrics; built-in invocation and CPU metrics fail to capture actual accelerator saturation.

Question 8 - Container Registry Versioning for Production Endpoints

A production SageMaker AI endpoint is configured to pull its inference container from Amazon ECR. The ML team has been updating the image with the latest tag after every code change. Recently, a faulty image was pushed with latest, causing the endpoint to fail when it scaled out to serve inference traffic. The team needs to prevent future failures by ensuring that the endpoint always pulls a known, tested container image.

What is the MOST cost-effective solution that minimizes operational overhead? (Select ONE)

  • A) Implement a blue/green deployment strategy using two separate ECR repositories for staging and production images.
  • B) Apply immutable tags for each container image version and update the endpoint configuration to reference a specific image tag (e.g., v1.3.2).
  • C) Create a Lambda function that scans the latest tag after each push and automatically reverts to the previous image if tests fail.
  • D) Use SageMaker Model Registry to approve images and update the endpoint with the approved version using a deployment pipeline.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Enforcing immutable tags (i.e., version tags like v1.3.2 that are never overwritten) and updating the endpoint configuration to reference a specific tagged image ensures that every redeploy pulls the exact same tested container. This is the simplest, lowest-overhead approach.

Distractor Analysis

  • A is Incorrect: Blue/green deployment adds operational complexity without solving the root cause. The failure occurs because the latest tag is mutable and can point to broken code; separate repositories still suffer from the same issue if latest is used.
  • C is Incorrect: Building a Lambda function to monitor and revert images adds custom infrastructure and still uses the mutable latest tag. The problem is not detection but prevention.
  • D is Incorrect: While Model Registry and CI/CD pipelines are valuable, they introduce significant overhead that is unnecessary for this constraint. Version pinning is the immediate, least-cost fix.

Key Takeaway: Pin production endpoints to immutable, versioned ECR image tags. Never use latest for production hosting.

Question 9 - Bedrock Knowledge Base Index Dimension Mismatch

A team is creating an Amazon Bedrock Knowledge Base using Amazon OpenSearch Serverless as the vector store. The team selects Amazon Titan Text Embeddings v2 (which produces 1024-dimensional vectors) but creates the OpenSearch index with dimension: 1536. During ingestion, all documents fail with an error.

What is the root cause of the failure? (Select ONE)

  • A) The OpenSearch Serverless collection is not encrypted with a customer-managed key.
  • B) The index dimension does not match the embedding model's output dimension.
  • C) The ingestion job is missing the required IAM permissions to write to OpenSearch.
  • D) The S3 bucket containing the source documents has versioning enabled, which interferes with ingestion.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: Vector dimensions are fixed at index creation time and must match the embedding model's output. Titan Text Embeddings v2 produces 1024-dimensional vectors. Creating the index with dimension: 1536 causes a mismatch, so every ingestion attempt fails when writing embeddings.

Distractor Analysis

  • A is Incorrect: While encryption policy misconfiguration can block access, it would produce a permission or security error, not an embedding dimension failure. The question states embeddings fail, indicating the vector size issue.
  • C is Incorrect: IAM permission issues manifest as access-denied errors during ingestion, not embedding-specific failures. The symptom points to a vector dimension mismatch.
  • D is Incorrect: S3 bucket versioning does not interfere with Bedrock Knowledge Base ingestion. It may affect object version selection but would not cause dimension-related ingestion failures.

Key Takeaway: Always match OpenSearch index dimensions to the embedding model's output. Dimension changes require reindexing.

Question 10 - Agent Tool Gateway Protocol Translation

A company wants to expose legacy internal REST APIs (SOAP-based, with complex authentication) to an Amazon Bedrock AgentCore agent. The agent's model should be able to call these APIs as tools without custom code for each integration. The security team requires that all tool calls remain within the corporate VPC.

Which solution satisfies these requirements with the LEAST operational overhead? (Select ONE)

  • A) Deploy a custom Lambda function for each API that wraps the SOAP call and exposes it as a JSON API, then register each Lambda as a tool in AgentCore.
  • B) Use AgentCore's gateway (API gateway + OpenAPI/Swagger spec) to expose the legacy APIs as MCP (Model Context Protocol) tools, deploying the gateway inside the VPC.
  • C) Rebuild the legacy APIs as serverless functions using AWS Lambda and expose them via Amazon API Gateway with VPC endpoints.
  • D) Create a SageMaker Processing job that synchronously calls the legacy APIs on behalf of the agent, bridging the protocol mismatch.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Options Analysis

  • B is Correct: AgentCore's gateway is designed to expose existing APIs as tools using standard specifications (OpenAPI/Swagger, MCP). Deploying the gateway inside the VPC ensures tool calls stay within the private network. This approach avoids rebuilding or wrapping legacy services, aligning with the minimal overhead constraint.

Distractor Analysis

  • A is Incorrect: Writing a Lambda wrapper for each API introduces significant operational overhead and requires custom code, violating the least-overhead constraint.
  • C is Incorrect: Rebuilding legacy APIs as serverless functions is a full re-architecture that introduces high overhead. The gateway pattern exists precisely to avoid this.
  • D is Incorrect: SageMaker Processing jobs are asynchronous batch compute for data processing, not a real-time service gateway. They cannot bridge protocol translation for interactive agent tool calls.

Key Takeaway: AgentCore Gateway provides protocol translation (e.g., SOAP to MCP) via configuration, not custom code; deploy it within the VPC for private connectivity.