Skip to content

Skill 3.3.11: Configure AI-specific pipeline orchestration for RAG system updates and knowledge base refresh cycles

Question 1 - RAG Ingestion Trigger Design

A financial services company operates a production Retrieval-Augmented Generation (RAG) system using Amazon Bedrock Knowledge Bases with Amazon OpenSearch Serverless as the vector store. The knowledge base contains regulatory compliance documents stored in an S3 bucket. Compliance officers frequently upload revised policy documents at irregular intervals throughout the business day.

The company requires that document updates be reflected in the vector index within minutes of upload, while minimizing operational overhead and avoiding unnecessary ingestion costs when no changes occur.

Which solution should the ML engineer implement? (Select ONE)

  • A) Configure an Amazon EventBridge rule with a cron expression that triggers a Bedrock ingestion job every 15 minutes during business hours.
  • B) Configure an S3 Event Notification that sends an event to Amazon EventBridge, which triggers an AWS Lambda function that calls the Bedrock StartIngestionJob API.
  • C) Configure Amazon CloudWatch to monitor the S3 bucket's NumberOfObjects metric and trigger an AWS Step Functions workflow to start the ingestion job when the metric crosses a threshold.
  • D) Configure an S3 Event Notification that directly invokes the Amazon Bedrock Knowledge Base StartIngestionJob API using a service-linked role.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: S3 Event Notifications natively publish events (e.g., s3:ObjectCreated:*) when new or updated objects are uploaded. Routing these events through Amazon EventBridge allows for robust event filtering and reliable decoupled invocation. A Lambda function receives the event and programmatically calls the Bedrock StartIngestionJob API. This design activates only when actual document changes occur—satisfying the cost-efficiency constraint—and delivers near-real-time refresh latency.

Distractor Analysis

  • A is Incorrect: A fixed 15-minute schedule is a valid pattern, but it introduces unnecessary latency for documents uploaded right after a scheduled run, and it triggers ingestion jobs even when nothing has changed—violating the cost-efficiency requirement.
  • C is Incorrect: Polling a CloudWatch bucket metric is an anti-pattern for event-driven ingestion. Metrics may lag behind real-time events, and using Step Functions adds unnecessary orchestration complexity compared to a direct event trigger.
  • D is Incorrect: S3 Event Notifications cannot invoke the Bedrock StartIngestionJob API directly. An event destination requires a compute target (e.g., Lambda, SQS, SNS) as a middleware. The "direct API invocation" described here is not a supported S3 event destination type.

Key Takeaway: Event-driven triggers (S3 Event Notification → EventBridge → Lambda) provide the lowest latency and most cost-effective refresh mechanism for irregular RAG data updates; scheduled triggers are better suited to predictable but low-change document corpora.

Question 2 - Incremental vs. Full Reindexing

A healthcare analytics company operates a RAG system using Amazon Bedrock Knowledge Bases with a vector index containing 2.5 million clinical document chunks. The engineering team recently updated the chunking strategy from fixed-size chunking (1,200 tokens) to semantic chunking with 300-token segments to improve retrieval precision.

The team needs to apply this change to the production knowledge base with minimal downtime and without serving inconsistent retrieval results during the transition.

Which approach should the ML engineer implement? (Select ONE)

  • A) Trigger a Bedrock ingestion resync (StartIngestionJob) on the existing data source with the new chunking configuration; Bedrock will automatically skip unchanged documents and re-embed only affected chunks.
  • B) Create a new Bedrock Knowledge Base data source with the new chunking configuration, run a full ingestion job to build a new vector index, validate retrieval quality, then switch the application's Knowledge Base ID to the new one.
  • C) Copy the existing OpenSearch Serverless index to a new collection using OpenSearch snapshot/restore, then update the chunking configuration on the copied collection.
  • D) Update the chunking configuration in the existing Bedrock Knowledge Base and rely on the next scheduled incremental ingestion to progressively re-chunk documents as they are accessed.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Changing the chunking strategy is a schema-level change that invalidates every existing vector embedding. All 2.5 million chunks must be re-parsed, re-chunked, and re-embedded under the new configuration. Creating a new Bedrock Knowledge Base data source with the updated chunking configuration produces a completely fresh vector index. This enables the team to validate retrieval quality in isolation before cutting over application traffic, ensuring zero downtime and no inconsistent results during the transition.

Distractor Analysis

  • A is Incorrect: An ingestion resync on Bedrock Knowledge Bases is designed for incremental document changes (add/update/delete). When the chunking configuration itself changes, Bedrock may require a full reingestion rather than a delta sync. More importantly, re-chunking documents in-place on the production index would serve mixed old/new chunk representations during the ingestion window—violating the consistency requirement.
  • C is Incorrect: Copying via OpenSearch snapshot/restore duplicates existing vectors, but those vectors were generated under the old chunking strategy. The copied index would contain stale vector representations that do not reflect the new chunking configuration.
  • D is Incorrect: Bedrock Knowledge Bases does not re-chunk documents lazily "as they are accessed." Ingested chunks are materialized at ingestion time. Delaying the update via an incremental sync would continue serving old chunk representations indefinitely for documents that are not accessed or explicitly re-ingested.

Key Takeaway: Distinguish between data-level updates (handled by incremental resync) and pipeline-level changes (chunking, embedding model, vector dimensions) that require a full reingestion into a fresh index—validated before cutover.

Question 3 - Orchestration for Multi-Source RAG Pipelines

A global e-commerce company maintains a RAG system that aggregates knowledge from three distinct sources: product catalogs (structured JSON in S3), customer support articles (HTML on an internal CMS), and engineering documentation (PDFs in a separate S3 bucket). Each source has a different refresh frequency requirement: product catalogs update hourly, support articles update daily, and engineering docs update weekly.

The ML engineer must design an orchestration pipeline using AWS native services that handles these varying refresh schedules with least operational overhead.

Which architecture satisfies these requirements? (Select ONE)

  • A) Deploy a single AWS Step Functions state machine that runs on an hourly schedule, checking each source for changes and conditionally triggering Bedrock ingestion jobs only for sources that have new data.
  • B) Create a separate EventBridge schedule rule for each data source with its own Bedrock Knowledge Base data source and ingestion frequency (hourly, daily, weekly), each independently triggering its specific StartIngestionJob call.
  • C) Use a single Amazon SageMaker Pipeline that runs a custom processing step on an hourly schedule to compare source timestamps and invoke Bedrock ingestion APIs for all three sources concurrently.
  • D) Configure one EventBridge rule that triggers a Lambda function on an hourly schedule; the Lambda function checks a DynamoDB table storing per-source last-modified timestamps and selectively triggers ingestion for sources that have changed.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Amazon Bedrock Knowledge Bases supports multiple data sources within a single knowledge base, or separate knowledge bases for different source types. Each data source can be independently triggered with its own StartIngestionJob call on its own schedule. Using multiple EventBridge Rule resources (or a single rule with multiple targets) with cron expressions matching each source's frequency (hourly, daily, weekly) is the most operationally efficient approach. Each source's ingestion job runs exactly when needed, with no custom logic to track changes.

Distractor Analysis

  • A is Incorrect: Running a single orchestrator every hour to check all three sources adds unnecessary complexity (custom change-detection logic) and wastes compute for the daily/weekly sources that are checked hourly but only ingested at their cadence.
  • C is Incorrect: SageMaker Pipelines is designed for ML training/inference workflow orchestration, not document ingestion triggering. Its hourly execution schedule and custom processing step introduce unnecessary cost and operational overhead compared to simple EventBridge schedules.
  • D is Incorrect: While this is a functional pattern, it requires building and maintaining a DynamoDB timestamp-checking Lambda and custom change-detection logic. The constraint asks for "least operational overhead"—a simple per-source EventBridge schedule rule avoids this custom logic entirely.

Key Takeaway: For RAG systems with multiple data sources at different refresh cadences, isolate ingestion triggers per data source using EventBridge schedules rather than building a custom central orchestrator that checks all sources on every tick.

Question 4 - Deletion Handling in RAG Ingestion

A legal technology company maintains a RAG system using Bedrock Knowledge Bases with a data source pointing to an S3 bucket containing case law documents. Due to a licensing dispute, the company must remove 50 specific documents from the knowledge base immediately. The documents exist in the vector index but their source files in the S3 bucket have been deleted.

The compliance team requires that queries no longer return content from these deleted documents. The RAG system uses Amazon Bedrock Knowledge Bases with incremental ingestion (ingestion resync).

Which action should the ML engineer take? (Select ONE)

  • A) Manually delete the corresponding vectors from the OpenSearch Serverless collection using a script that matches document metadata.
  • B) Trigger a Bedrock ingestion resync (StartIngestionJob) on the data source; Bedrock automatically detects deleted S3 objects and removes their corresponding chunks from the vector index.
  • C) Create an empty marker file in S3 with the same key name as each deleted document, then trigger an ingestion resync to overwrite the vectors.
  • D) Set an expiration policy on the OpenSearch Serverless index to automatically purge vectors whose source documents no longer exist.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Amazon Bedrock Knowledge Bases ingestion resync performs delta reconciliation between the S3 data source and the vector index. When objects are deleted from the source S3 bucket, the incremental ingestion job detects the absence of those objects during the sync process and automatically removes the corresponding chunks from the vector index. This is the native, supported mechanism for handling deletions without manual vector manipulation.

Distractor Analysis

  • A is Incorrect: Manually scripting vector deletions from OpenSearch is operationally fragile, violates the "least operational overhead" constraint, and risks deleting incorrect vectors. Bedrock Knowledge Bases abstracts this underlying storage—users should rely on the managed ingestion pipeline.
  • C is Incorrect: Creating marker files defeats the purpose of deletion and would not reliably replicate Bedrock's deletion detection logic. The marker file approach is a workaround that adds unnecessary complexity and may leave stale chunk IDs in the index.
  • D is Incorrect: OpenSearch index expiration policies (e.g., index state management) operate on index age or document age—they do not correlate with source object existence in S3. There is no native feature that automatically purges vectors when source documents are deleted without running an ingestion sync.

Key Takeaway: Bedrock Knowledge Bases ingestion resync automatically handles three-way delta reconciliation: newly added documents are indexed, modified documents are re-embedded, and deleted documents are removed from the vector store—no manual vector operations needed.

Question 5 - Embedding Model Change in RAG Pipeline

A research organization runs a RAG application using Amazon Bedrock Knowledge Bases with the Amazon Titan Text Embeddings v1 model. After evaluating model performance, the team decides to migrate to Amazon Titan Text Embeddings v2 (1024 dimensions) for improved retrieval accuracy.

The vector index currently stores embeddings with 1536 dimensions generated by the v1 model. The new v2 model will generate 1024-dimensional vectors.

What is the correct pipeline orchestration approach for this embedding model change? (Select ONE)

  • A) Update the embedding model configuration in the existing Bedrock Knowledge Base and trigger an ingestion resync; Bedrock will automatically re-embed only documents whose source has changed.
  • B) Update the embedding model in the existing knowledge base, then create a new OpenSearch Serverless collection with 1024 dimensions and perform a one-time migration of the existing vectors.
  • C) Create a new Bedrock Knowledge Base with the new embedding model, run a full ingestion of all documents from the S3 bucket, validate the new vector index, then redirect the application to the new knowledge base.
  • D) Update the embedding model configuration and run a full ingestion on the same knowledge base; Bedrock automatically detects the dimension mismatch and updates the vector index schema in place.
Click to reveal Answer & Explanation

Correct Answer: C

Correct Option Analysis

  • C is Correct: Changing the embedding model is a fundamental pipeline change because every vector in the index was generated under the old model's architecture. The vectors are dimensionally incompatible (1536-dim vs 1024-dim), so the existing OpenSearch index schema cannot accommodate the new embedding size. Creating a new Bedrock Knowledge Base with the new embedding model and running a full ingestion produces a completely fresh, dimensionally-consistent vector index. The team can validate retrieval quality before cutting over, ensuring production consistency.

Distractor Analysis

  • A is Incorrect: Bedrock ingestion resync only re-processes documents that have been added, modified, or deleted since the last sync. Documents that already exist in the index but have not changed would retain their old v1 embeddings (1536-dim), creating an inconsistent index where some vectors are dimensionally incompatible with the new embedding model.
  • B is Incorrect: Creating a new OpenSearch collection with 1024 dimensions is conceptually correct, but "migrating" existing vectors is impossible—the old vectors are 1536-dimensional and cannot be resized or projected into 1024 dimensions without re-embedding. Direct OpenSearch manipulation also bypasses Bedrock's managed indexing pipeline.
  • D is Incorrect: Bedrock Knowledge Bases cannot automatically migrate index schemas or transform existing vectors between different embedding dimensions. A full ingestion on the same knowledge base with a different embedding model would either fail validation or produce an inconsistent index with mixed vector dimensions.

Key Takeaway: Embedding model changes are structural pipeline changes requiring a full reingestion into a new or reinitialized index—incremental resyncs cannot migrate existing vectors to a new embedding space or dimension size.

Question 6 - CI/CD Integration for RAG Pipeline Changes

A fintech startup deploys updates to their RAG application multiple times per week. The application consists of three components: (1) the retrieval logic code (a Lambda function), (2) the Bedrock Knowledge Base configuration (including data sources and chunking parameters), and (3) the prompt template used by the foundation model.

The engineering team wants all three components to be versioned, tested, and deployed through a single CI/CD pipeline using AWS CodePipeline, with capability to rollback any individual component independently.

Which architecture satisfies these requirements with the least operational overhead? (Select ONE)

  • A) Store all three components in a single AWS CodeCommit repository; use CodePipeline stages that build, test, and deploy all three components together in every pipeline run.
  • B) Store each component as a separate AWS CloudFormation template in the same CodeCommit repository; use a single CodePipeline with CloudFormation deploy stages that support nested stacks for selective rollbacks.
  • C) Use three separate CodePipeline pipelines—one each for the Lambda function code (integrating with AWS Lambda), the Bedrock Knowledge Base infrastructure (using CloudFormation/Terraform), and the prompt template (using Amazon Bedrock Prompt Management versioning)—stored in separate CodeCommit repositories.
  • D) Use a single CodePipeline that deploys the Lambda function and prompt template together via CodeDeploy, and manage the Bedrock Knowledge Base configuration manually through the AWS Console to avoid infrastructure drift.
Click to reveal Answer & Explanation

Correct Answer: C

Correct Option Analysis

  • C is Correct: Each component has distinct deployment characteristics: (1) Lambda code follows a standard code deployment pipeline, (2) infrastructure changes to Bedrock Knowledge Bases (chunking, data sources, embedding model) are applied via IaC (CloudFormation/Terraform), and (3) prompts are versioned and released via Amazon Bedrock Prompt Management (which natively supports versioned prompt variants). Separate pipelines enable independent testing, deployment cadence, and rollback—satisfying the requirement for "independent rollback of any individual component" without coupling unrelated changes.

Distractor Analysis

  • A is Incorrect: Bundling all three components into a single repository and pipeline means any change (e.g., a prompt tweak) triggers a full rebuild and redeploy of all components. Rollback of one component would either require rolling back everything or manual intervention—violating the independent rollback requirement.
  • B is Incorrect: Storing all templates in one repo with nested CloudFormation stacks still couples the release process. Nested stacks support partial updates but rollback semantics at the pipeline level remain tightly coupled, and Bedrock Prompt Management has specific APIs for prompt versioning that are better managed via its own pipeline.
  • D is Incorrect: Manual management of Bedrock Knowledge Base configuration introduces drift risk and operational overhead. This approach also fails the "deployed through a single CI/CD pipeline" requirement for all three components.

Key Takeaway: In MLOps/AIOps CI/CD design, separate stateful components (code, infrastructure, prompts) into independent pipelines for independent rollback and release cadence; coupling reduces operational agility and increases blast radius.

Question 7 - Knowledge Base Refresh Validation Gates

A customer service company is implementing a CI/CD pipeline for their RAG knowledge base refresh cycle. Before any new document batch is promoted to production, the team must validate that the refreshed vector index meets quality standards: (1) retrieval relevance score improves or stays within 5% of baseline, (2) no sensitive data (PII) was ingested into the vector index, and (3) the refreshed index has no missing chunks for any source document.

Which testing strategy should the ML engineer integrate into the CodePipeline before the production deployment stage? (Select ONE)

  • A) In the test stage, run a SageMaker Processing job that executes automated evaluation scripts comparing relevance metrics from a golden query set against the baseline index, runs a PII detection scan on newly ingested chunks, and validates chunk count integrity for all source documents.
  • B) In the build stage, add unit tests to the application code that verify the retrieval API responses do not contain PII patterns, and rely on CloudWatch alarms post-deployment to detect relevance degradation.
  • C) In the test stage, use Amazon Bedrock Guardrails to automatically filter PII from the vector index and deploy the refreshed index with a canary traffic shift, monitoring relevance metrics during the baking period.
  • D) In the test stage, run AWS Glue DataBrew recipes to profile the source documents for PII and generate a quality report; manually review the report before promoting the knowledge base.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: This is the most comprehensive and automatable approach. A SageMaker Processing job can execute all three validation checks: (1) relevance evaluation using a golden query set with pre-computed ground truth or similarity scores, comparing against a stored baseline; (2) PII detection using Amazon Comprehend or SageMaker Clarify on the newly ingested chunk text; (3) chunk integrity validation by comparing source document IDs/checksums against the vector index contents. All checks are automated and can gate the deployment stage with clear pass/fail thresholds.

Distractor Analysis

  • B is Incorrect: Unit tests for application code (API routing, parameter handling) do not evaluate retrieval quality or PII content in the vector index. Relying on post-deployment CloudWatch alarms for relevance is reactive rather than preventative and does not satisfy the pre-production validation requirement.
  • C is Incorrect: Bedrock Guardrails provide content filtering and PII redaction for generation responses at inference time—they do not scan or filter the vector index itself. Canary deployments are a release strategy for validating new versions against real traffic, but they do not replace pre-deployment quality gates.
  • D is Incorrect: AWS Glue DataBrew is a visual data preparation tool for cleaning and transforming tabular datasets—it is not designed for RAG vector index validation. More critically, the manual review step violates the "automated testing" expectation in a CI/CD pipeline.

Key Takeaway: RAG pipeline validation gates must test three distinct layers: retrieval quality (golden query evaluation), content compliance (PII/toxicity scanning on ingested chunks), and index integrity (document-chunk completeness checks)—all as automated pre-deployment gates.

Question 8 - EventBridge Rule Targeting for Bedrock Ingestion

A media streaming company has a RAG system using Bedrock Knowledge Bases with a data source linked to an S3 bucket. The S3 bucket receives new content files from multiple ingestion workflows (e.g., subtitles, metadata, reviews) throughout the day. The company wants to trigger the Bedrock ingestion job automatically whenever new files are uploaded.

However, the engineering team is concerned about triggering too many ingestion jobs when large batches of files arrive simultaneously (e.g., 500 files in 10 seconds). They want to debounce the trigger so that only one ingestion job runs per 5-minute window, regardless of how many files arrive.

Which solution achieves this with the least operational overhead? (Select ONE)

  • A) Configure S3 Event Notifications to send events to an Amazon SQS queue, then configure a Lambda function that reads messages in batches and triggers the ingestion job only once per 5-minute interval using a DynamoDB lock table.
  • B) Configure S3 Event Notifications to send events to Amazon EventBridge, then create an EventBridge rule that triggers a Step Functions state machine with a built-in 5-minute wait state that starts the ingestion job.
  • C) Configure S3 Event Notifications to send events to an Amazon SQS queue with a 5-minute delay and a Lambda consumer that triggers the ingestion job once per polling cycle.
  • D) Configure S3 Event Notifications to send events to Amazon EventBridge, then create an EventBridge rule with a 5-minute input transformer that batches events and triggers the ingestion job.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: SQS provides a reliable buffer for incoming S3 events. A Lambda consumer can use a DynamoDB table with a conditional write (e.g., last_triggered_timestamp) to implement debouncing logic: if the last ingestion was started within 5 minutes, the Lambda function skips triggering another job. This approach is highly customizable, reliable, and avoids unnecessary ingestion costs. SQS also provides message retention and retry capabilities that EventBridge does not inherently offer for this debouncing pattern.

Distractor Analysis

  • B is Incorrect: A Step Functions state machine with a 5-minute wait state would still execute once per incoming event, resulting in 500 concurrent state machine executions for a burst of 500 files. This would trigger multiple ingestion jobs (albeit delayed by 5 minutes each), not debounce them into a single job.
  • C is Incorrect: SQS delay queues apply a delay to individual messages when they are first received, but the Lambda consumer would still process multiple delayed messages in a single polling cycle and trigger multiple ingestion jobs unless there is a separate debouncing mechanism.
  • D is Incorrect: EventBridge input transformers modify event payloads but do not include time-based debouncing or batching capabilities. Multiple events arriving within 5 minutes would each trigger the rule target independently, resulting in parallel ingestion jobs.

Key Takeaway: Debouncing high-frequency event triggers requires a stateful coordination mechanism (e.g., DynamoDB conditional writes or Step Functions distributed locking); SQS is the preferred buffer for event bursts before debouncing logic processes them.

Question 9 - Cross-Account RAG Data Source Access

A holding company has a centralized data lake in a shared services AWS account (Account A: 111122223333) and a RAG application deployed in a separate application account (Account B: 444455556666). The RAG application uses Amazon Bedrock Knowledge Bases to index documents from the shared data lake's S3 bucket.

The data lake bucket (s3://shared-datalake-prod) is encrypted with a KMS CMK owned by Account A. The company requires that the Bedrock Knowledge Base in Account B can ingest documents from this bucket while maintaining least privilege access.

Which configuration should the ML engineer implement? (Select ONE)

  • A) Create an IAM role in Account B with s3:GetObject and kms:Decrypt permissions, attach it to the Bedrock Knowledge Base, and update both the S3 bucket policy and KMS key policy in Account A to grant access to that role.
  • B) Replicate the S3 data from Account A to a new bucket in Account B using S3 Replication, then point the Bedrock Knowledge Base in Account B to the local bucket.
  • C) Create an IAM role in Account A with s3:GetObject permissions, and configure the Bedrock Knowledge Base in Account B to assume this cross-account role when ingesting documents.
  • D) Grant the Bedrock service-linked role in Account B access to Account A's S3 bucket via a bucket policy that allows the AWS service principal bedrock.amazonaws.com.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Option Analysis

  • A is Correct: Cross-account access requires permission grants on both sides. In Account B, the Bedrock Knowledge Base must be associated with an IAM role that has s3:GetObject (for reading documents) and kms:Decrypt (for decrypting the S3 objects encrypted with Account A's KMS key). In Account A, the S3 bucket policy must explicitly allow the Account B IAM role's ARN to perform s3:GetObject, and the KMS key policy must grant kms:Decrypt to the same role. This is the standard cross-account access pattern.

Distractor Analysis

  • B is Incorrect: While S3 Replication would functionally work, it introduces unnecessary data duplication, additional storage costs, and replication lag. The scenario requires the Bedrock KB to "ingest documents from this bucket"—direct cross-account access is the simpler and more cost-effective solution.
  • C is Incorrect: Bedrock Knowledge Bases cannot assume a role that lives in a different AWS account. The IAM role attached to the Bedrock Knowledge Base must exist in the same account as the Knowledge Base (Account B). Cross-account access is granted by the resource policies in Account A trusting Account B's role.
  • D is Incorrect: The Bedrock service principal bedrock.amazonaws.com in a bucket policy would grant access to any Bedrock resource across any AWS account—this is overly permissive and violates least privilege. More technically, Bedrock Knowledge Bases does not use a single shared service-linked role for data source access; it requires a customer-defined IAM role in the Knowledge Base's account.

Key Takeaway: Cross-account Bedrock Knowledge Base ingestion requires dual-side permissions: an IAM role in the Bedrock account with read/decrypt permissions, and S3 bucket + KMS key policies in the data account that explicitly trust that role's ARN.

Question 10 - RAG Knowledge Base Deployment Blue/Green Strategy

A healthcare AI company operates a production RAG system with Bedrock Knowledge Bases and OpenSearch Serverless. The company is preparing a major knowledge base upgrade that includes: (1) a new semantic chunking configuration, (2) a new embedding model, and (3) 25,000 new documents added to the corpus.

The company requires zero downtime during the transition, the ability to validate the new knowledge base before exposing it to users, and automatic rollback capability if the new version exhibits degraded retrieval performance.

Which deployment strategy should the ML engineer recommend? (Select ONE)

  • A) Use SageMaker Deployment Guardrails with a canary traffic shift on the Bedrock Knowledge Base endpoint, monitored by CloudWatch alarms on retrieval latency and error rates.
  • B) Create a new Bedrock Knowledge Base with the updated configuration and full document corpus, validate it in a staging environment, then update the application's knowledge_base_id parameter via a feature flag or route-based traffic shifting, with the old knowledge base retained for rollback.
  • C) Perform an in-place upgrade of the existing Bedrock Knowledge Base by updating the chunking configuration and embedding model; briefly pause ingestion traffic during the update, then trigger a full ingestion and resume traffic once complete.
  • D) Deploy the new knowledge base as a blue environment manually created in OpenSearch Serverless, and use AWS Application Load Balancer with weighted target groups to gradually shift traffic between the old and new knowledge base endpoints.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Option Analysis

  • B is Correct: Bedrock Knowledge Bases do not natively support SageMaker Deployment Guardrails-style blue/green traffic shifting at the endpoint level. The application references a specific knowledge_base_id when calling the Retrieve or RetrieveAndGenerate APIs. By creating a fully new knowledge base (with updated chunking, embedding model, and complete corpus), the team can validate it in isolation before production cutover. A feature flag or routing layer in the application enables gradual traffic shifting between the old and new knowledge bases, and instant rollback is achieved by reverting the feature flag to the old knowledge_base_id.

Distractor Analysis

  • A is Incorrect: SageMaker Deployment Guardrails apply to SageMaker real-time endpoints, not Bedrock Knowledge Bases. Bedrock Knowledge Bases do not expose an endpoint that supports canary traffic shifting at the service level—the traffic shift must occur at the application routing layer.
  • C is Incorrect: Updating the existing Knowledge Base in place introduces downtime and risk. When the embedding model or chunking configuration changes, existing vectors become incompatible with the new configuration. An in-place update would either require serving inconsistent results or pausing traffic entirely—violating the zero-downtime requirement.
  • D is Incorrect: Bedrock Knowledge Bases do not expose a load-balancer-compatible endpoint (e.g., HTTP endpoint with target groups). OpenSearch Serverless is the underlying vector store, but Bedrock manages the embedding, indexing, and retrieval API. An ALB cannot directly route traffic between two Bedrock Knowledge Base instances.

Key Takeaway: Blue/green deployment for Bedrock Knowledge Bases is achieved at the application layer via feature flags or routing logic that switches between knowledge_base_id values—not through SageMaker deployment guardrails or load balancers, which apply to different AWS service types.