Skip to content

Skill 1.1.1: Configure Scalable Vector Databases for AI Applications

Question 1 - OpenSearch Serverless vs. Managed Cluster for RAG

A financial services company is building a retrieval-augmented generation (RAG) application using Amazon Bedrock and Amazon OpenSearch Service. The application must support unpredictable query volumes ranging from near-zero at night to thousands of similarity searches per second during market hours. The company wants to minimize operational overhead and eliminate manual capacity planning. However, the security team requires that the vector database reside within specific VPC subnets they control.

Which solution meets these requirements? (Select ONE)

  • A) Use Amazon OpenSearch Serverless with a vector collection, configured with the latest stability and feature release compatibility.
  • B) Use a managed Amazon OpenSearch Service domain with dedicated master nodes, UltraWarm storage, and auto-scaling policies for both data nodes and shard replicas.
  • C) Use Amazon OpenSearch Serverless with a vector collection, then configure VPC endpoints with endpoint policies that restrict access to the security team's subnets.
  • D) Use a managed Amazon OpenSearch Service domain deployed inside the security team's VPC subnets, with Graviton3 data nodes and automated snapshot schedules.
Click to reveal Answer & Explanation

Correct Answer: D

Correct Answer Analysis

  • D is Correct: Amazon OpenSearch Serverless (while operationally simpler) does not support deployment into customer VPCs directly. It runs in an AWS-managed VPC and is accessed via VPC endpoints where the endpoint lives in your subnets, but the collection itself stays in the service's VPC. If the security team explicitly requires the vector database to reside within specific VPC subnets, a managed OpenSearch domain deployed into those subnets is the only correct choice. Graviton3 instances provide cost-performance benefits for vector workloads, and automated snapshots ensure durability without operational overhead.

Distractor Analysis

  • A is Incorrect: OpenSearch Serverless cannot be deployed into customer VPC subnets; it runs in an AWS-managed VPC. This violates the security team's explicit requirement.
  • B is Incorrect: While this describes a valid managed domain configuration with scaling, the question does not mention VPC placement. A managed domain must be explicitly deployed into the security team's subnets. Moreover, UltraWarm storage is for hot/warm tiering of time-series data, not typically for vector indexes.
  • C is Incorrect: Although you can configure VPC endpoints with endpoint policies restricting access to your subnets, the OpenSearch Serverless collection itself still resides in the AWS-managed VPC, not within the customer's controlled subnets. This fails the security requirement.

Key Takeaway: OpenSearch Serverless provisions capacity automatically and removes operational burden, but it cannot deploy into a customer's own VPC; use managed domains when VPC residency and control is a strict requirement.

Question 2 - pgvector vs. Purpose-Built Vector Database

A startup has built a multi-tenant SaaS application on Amazon RDS for PostgreSQL. The application stores relational records for documents, users, and permissions. The product team now wants to add semantic search so that each tenant can search only their own documents. The embeddings are roughly 1,536 dimensions and total fewer than 1 million vectors per tenant. The team is small (three developers), has no dedicated ops staff, and needs acid-tight consistency between vector metadata and relational records (e.g., a document deletion must immediately make its vector unsearchable).

Which storage architecture BEST meets these requirements? (Select ONE)

  • A) Migrate embeddings to Amazon OpenSearch Service (managed cluster) for search. Use DynamoDB Streams to sync deletion events from the application's metadata table to the OpenSearch index.
  • B) Enable the pgvector extension on the existing RDS for PostgreSQL instance, storing embeddings in a column within the documents table using vector(1536) column type.
  • C) Store embeddings in an S3 bucket with a JSON manifest file, using Amazon Athena for nearest-neighbor queries.
  • D) Use Amazon OpenSearch Serverless with a vector collection, and write a Lambda function that listens for relational delete events to remove the corresponding vector.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: The pgvector extension allows vector similarity search directly within PostgreSQL, alongside the existing relational data. This provides atomic consistency: when a document row is deleted via a SQL transaction, its embedding is deleted in the same transaction. No data movement or external sync is required. With fewer than 1 million vectors per tenant and small team, this adds zero additional operational overhead since the RDS instance is already managed by AWS.

Distractor Analysis

  • A is Incorrect: This introduces significant operational complexity: a second data store (OpenSearch), plus a streaming pipeline (DynamoDB Streams → Lambda) to keep the index in sync with relational data. This violates the "no dedicated ops staff" constraint and introduces eventual consistency instead of transactional consistency.
  • C is Incorrect: Amazon Athena is a SQL query engine over S3 objects, not a vector database. It does not support nearest-neighbor similarity search natively.
  • D is Incorrect: OpenSearch Serverless would require moving vectors outside the relational database and maintaining sync via Lambda. Eventual consistency between RDS and OpenSearch violates the "acid-tight consistency" requirement. Additionally, the team's size makes managing this sync burdensome.

Key Takeaway: When embeddings need transactional consistency with relational records (single-source-of-truth), extend the existing RDS PostgreSQL database with pgvector rather than introducing a separate vector DB that requires data synchronization.

Question 3 - S3 vs. Vector Database for Batch Embedding Pipeline

A machine learning team is preprocessing a large corpus of 50 million documents for a batch semantic similarity analysis pipeline. They will run embedding generation once per quarter using Amazon SageMaker batch transform jobs. The similarity search will only be run in batch mode using Apache Spark on Amazon EMR, reading the embeddings directly from shared storage. There is no online querying requirement, and the team wants the most cost-effective storage for this use case.

Which storage service should the team use for the generated embeddings? (Select ONE)

  • A) Amazon OpenSearch Service with k-NN index and 3 dedicated data nodes.
  • B) Amazon OpenSearch Serverless with a vector collection.
  • C) Amazon S3 in Parquet format, with a prefix structure that allows partition pruning by document type.
  • D) Amazon RDS for PostgreSQL with pgvector extension on a large instance class.
Click to reveal Answer & Explanation

Correct Answer: C

Correct Answer Analysis

  • C is Correct: For batch similarity search using Apache Spark, storing embeddings as Parquet files in S3 is the most cost-effective solution. Spark can read S3 directly, apply columnar optimizations on Parquet, and perform vector operations in-memory across the cluster. No vector database is required if all searches are executed as batch jobs. S3 storage costs are orders of magnitude cheaper per GB than managed database storage, and there's no idle CPU cost between quarterly jobs.

Distractor Analysis

  • A is Incorrect: OpenSearch brings online low-latency k-NN querying capabilities, but the scenario is purely batch. Dedicated data nodes incur ~\(0.30–\)0.60/hour per node 24/7, resulting in massive idle costs between quarterly jobs.
  • B is Incorrect: OpenSearch Serverless reduces idle CPU costs, but vector collections still bill per compute unit (OCU) hour and have storage overhead for inverted indexes. Still far more expensive than S3 for batch-only workloads.
  • D is Incorrect: RDS PostgreSQL with pgvector provides online vector search with transactional DB features, but the use case is purely batch. Provisioning a large instance to hold 50M vectors would cost hundreds to thousands of dollars per month, regardless of idle time.

Key Takeaway: Use S3 with a columnar format (Parquet/ORC) for embeddings that are queried exclusively in batch; use a managed vector database only when online, low-latency similarity search is required.

Question 4 - Vector Database Capacity and Dimension Configuration

A company is deploying Amazon OpenSearch Service for a new recommendation system. The embedding model produces vectors of dimension 384. The initial corpus contains 100 million items, and the data science team expects this to grow by 10% monthly. Initial benchmarks show that 3 shards with 2 replicas each provide adequate query performance. However, the VP of Engineering noticed a multi-tenant requirement: different departments (marketing, support, product) will query the same index but with different filters on metadata.

The ML engineer needs to reconfigure the index to ensure efficient memory usage and optimal query performance. Which configuration should the engineer select? (Select ONE)

  • A) Reduce the number of replicas to 1, since multi-tenant filtering reduces overall query volume.
  • B) Keep 3 shards and 2 replicas, but add a routing parameter that directs each department's queries to a specific shard.
  • C) Increase the data node instance size to accommodate the growing vector index, then enable automatic snapshot scheduling.
  • D) Keep 3 shards and 2 replicas, but ensure that each shard's vector data fits within the JVM heap of the data nodes (roughly 50% of total RAM) and increase shard count only when size limits are reached.
Click to reveal Answer & Explanation

Correct Answer: D

Correct Answer Analysis

  • D is Correct: OpenSearch data nodes hold vector indexes in memory for efficient k-NN queries. The general rule is that the vector data must fit within 50% of the JVM heap (or follow OpenSearch's published guidance: no more than 70% of heap for all shard data). With 100M items at 384 dimensions using 4-byte floats, that's roughly 100M × 384 × 4 bytes ≈ 154 GB of raw vector data. This must be distributed across shards so each shard fits comfortably within a single node's heap. The engineer must monitor shard size and increase shard count (or add nodes) as the corpus grows 10% monthly.

Distractor Analysis

  • A is Incorrect: Multi-tenant filtering doesn't reduce query volume. Reducing replicas would lower read throughput capacity and data redundancy, potentially degrading performance and availability for concurrent departmental queries.
  • B is Incorrect: OpenSearch's routing parameter sends documents to specific shards based on a routing key. However, multi-tenant filtering is handled by metadata queries (filter context), not by routing. Incorrectly routing by department could lead to uneven shard distribution (hot shards).
  • C is Incorrect: While increasing instance size helps with memory, the question asks for an immediate reconfiguration decision. The core issue is whether existing shards can hold the growing vector data within the heap. Size increase alone without capacity planning (shard count, replica placement) is insufficient.

Key Takeaway: In OpenSearch, vector index memory is the critical capacity constraint—each shard's k-NN data must fit within the JVM heap of its data node; monitor shard size and scale shards proactively as embeddings grow.

Question 5 - OpenSearch Serverless vs. Managed Domain for Low-Volume App

An engineering team is building a semantic search feature for an internal document management system with moderate query volume (about 50 QPS peak, 5 QPS average). The embeddings are generated by a fine-tuned model and stored in Amazon OpenSearch Service. However, the team would prefer to avoid managing the low-level infrastructure (nodes, shards, replicas, scaling policies) and wants automatic scaling for cost optimization. The team also requires SAM, AOSS style security with IAM-based authentication only.

Which service configuration should they choose? (Select ONE)

  • A) Amazon OpenSearch Serverless with a vector collection, configured with IAM-based access policies only.
  • B) Amazon OpenSearch Service with a single-node t3.small.search instance, IAM authentication enabled, and no replica shards.
  • C) Amazon OpenSearch Serverless with a vector collection, but configure a network policy that restricts access to a specific VPC endpoint only.
  • D) Amazon OpenSearch Service with a 3-node cluster of m6g.large.search instances, enabling IAM-based auth and auto-tune.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

  • A is Correct: OpenSearch Serverless eliminates infrastructure management. Capacity is automatically provisioned and scaled up/down based on workload, so it's cost-effective for low-volume and bursty workloads. It natively supports IAM-based authentication and authorization via data access policies—matching the team's requirement.

Distractor Analysis

  • B is Incorrect: A single-node t3.small.search instance is an extremely small instance likely insufficient even for moderate vector workloads, and it provides no high availability. More importantly, this misses the team's stated desire to avoid managing infrastructure.
  • C is Incorrect: While adding a network policy for VPC endpoint access is a valid security practice, the question only specifies IAM-based authentication. Adding a VPC endpoint policy introduces an additional constraint not requested, and may complicate access for internal users accessing from outside the VPC.
  • D is Incorrect: A managed 3-node cluster provides better availability than option B, but it requires the team to perform capacity planning and potentially scale instances manually. This directly contradicts the team's preference for zero infrastructure management.

Key Takeaway: If the team wants to avoid managing infrastructure and the workload is low/moderate volume, OpenSearch Serverless is the correct choice over managed domains (which require node sizing and scaling policy management).

Question 6 - pgvector Index Selection (HNSW vs. IVFFlat)

A data engineer is optimizing the pgvector extension on an Amazon RDS for PostgreSQL instance. The dataset contains 2 million product embeddings (768 dimensions) that are updated every hour via a batch ETL job. The team notices that after each ETL job completes, the existing vector index becomes stale. The team wants to balance high recall (accuracy) with manageable index build time during ETL, and queries must return results in less than 50 ms.

Which index configuration should be used? (Select ONE)

  • A) Use an IVFFlat index with lists = 100 and re-run REINDEX after each ETL job.
  • B) Use an HNSW index with m = 16 and ef_construction = 64, rebuilding via REINDEX after each ETL job.
  • C) Use no index; perform exact nearest-neighbor search on each query.
  • D) Use an HNSW index with m = 8 and ef_construction = 32, but the index will auto-update as new rows are inserted.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: HNSW indexes provide the highest recall (accuracy) for a given query time, especially at 2 million vectors. With m = 16 (connection per node) and ef_construction = 64, it balances build time with accuracy. Since the data is updated via hourly batch ETL, rebuilding the index with REINDEX after each ETL job guarantees the index stays fresh. HNSW's query speed (<50 ms) meets the latency requirement.

Distractor Analysis

  • A is Incorrect: IVFFlat divides vectors into lists' clusters. Withlists = 100and 2 million vectors, each cluster would hold 20,000 items. When searching, only a few lists are probed, significantly reducing recall compared to HNSW unlesslists` is much larger (e.g., 500–1000), but even then HNSW typically achieves better recall at similar latency.
  • C is Incorrect: Exact nearest-neighbor search scans all 2 million × 768-dimensional vectors per query, which will likely take seconds to compute in PostgreSQL—not milliseconds. This does not meet the 50 ms latency requirement.
  • D is Incorrect: HNSW indexes in pgvector are not automatically updated when rows are inserted. After each batch insert/update, you must run REINDEX (or VACUUM) to rebuild the index. Without this, recall quickly degrades and query performance drops.

Key Takeaway: For high-accuracy, low-latency vector search in pgvector, use HNSW (which requires manual REINDEX after bulk inserts); IVFFlat is faster to build but yields lower recall at the same latency.

Question 7 - Multi-Model Vector Storage in S3 with OpenSearch

A company is building a multi-modal AI application that performs text-to-image retrieval using embeddings from two different models: one text encoder (output 768-dim) and one image encoder (output 512-dim). They are using OpenSearch Service for vector search. The application sends queries that compare text embeddings against the combined vector space. However, they also need to store the raw image files as references for retrieval (thumbnail URLs, original image metadata).

The engineering team wants to minimize per-query overhead and avoid cross-region data transfer. Which storage architecture is correct? (Select ONE)

  • A) Store raw images in S3 in the same region as OpenSearch. In OpenSearch, store only the vector embeddings (one text field, one image field) and the image metadata with a URL pointer to S3.
  • B) Store raw images directly as binary blobs inside the OpenSearch index fields, so retrieval is atomic.
  • C) Store raw images in an S3 bucket in a different region than OpenSearch, but use Transfer Acceleration for faster retrieval.
  • D) Store raw images in Amazon EFS and mount the same EFS to the OpenSearch data nodes for local access.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

  • A is Correct: OpenSearch is optimized for storing searchable vector data and metadata fields, not large binary objects like images. Raw images should live in S3 (in the same region to minimize latency and cost). The OpenSearch index holds embeddings (both text and image vectors), plus metadata such as image IDs, S3 object keys, thumbnail URLs, and description fields. When a text query arrives, the system compares the query embedding against the image embedding field, retrieves the top-k results, and references the S3 URLs for final image delivery.

Distractor Analysis

  • B is Incorrect: Storing raw image binary data directly in OpenSearch makes documents huge, increases memory/disk usage dramatically, slows indexing, and degrades vector search performance. OpenSearch is not a BLOB store.
  • C is Incorrect: Storing raw images in a different region increases latency and data transfer costs. S3 Transfer Acceleration helps with upload/download from the internet, not database-to-S3 access. Cross-region transfer charges also apply.
  • D is Incorrect: Amazon EFS cannot be mounted to OpenSearch Service data nodes; OpenSearch is a managed service and does not expose the underlying EC2 instances for filesystem mounting.

Key Takeaway: For multi-modal vector stores, keep raw data (images, audio, video) in S3 and store only embeddings + metadata (with S3 URL pointers) in the vector database for optimal query performance and cost.

Question 8 - pgvector High Availability and Scaling

A SaaS company is running its core recommendation service on Amazon RDS for PostgreSQL with pgvector enabled. The service supports high availability across multiple AZs, and they have enabled Multi-AZ deployments with a standby replica. Recently, the company noticed that during heavy query bursts, the primary instance becomes CPU-bound, affecting both vector search and transactional workloads. The team wants to offload read-heavy vector search queries without modifying application code.

Which solution best achieves this? (Select ONE)

  • A) Promote the Multi-AZ standby to primary, then scale the primary vertically to a larger instance class.
  • B) Add read replicas to the RDS instance and use them for serving vector search SELECT queries, keeping the primary for write operations that insert new embeddings.
  • C) Move the vector search to OpenSearch Service and use an outbox pattern to sync data from RDS.
  • D) Disable the pgvector extension on the primary and enable it on the standby only.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: Amazon RDS read replicas provide additional read capacity and can serve SELECT queries (including vector similarity searches using pgvector) without modifying application code (as long as you use the appropriate reader endpoint). This offloads the CPU burden from the primary, which continues handling writes and the most critical transactional operations. It's the most efficient way to scale read-heavy vector loads on RDS.

Distractor Analysis

  • A is Incorrect: Promoting the standby doesn't increase throughput capacity; it just replaces the primary with the standby node (same or different hardware depending on configuration). Vertical scaling might help, but the standby promotion is a high-availability action, not a read-scaling solution.
  • C is Incorrect: Migrating to OpenSearch would require significant application changes (new client libraries, new query syntax, data synchronization logic). This violates the requirement "without modifying application code." The architecture change brings operational complexity.
  • D is Incorrect: The Multi-AZ standby in RDS for PostgreSQL is an internal replication mechanism; you cannot selectively enable/disable extensions on standby vs. primary. The standby is an exact copy of the primary.

Key Takeaway: RDS read replicas are the standard method to scale read-heavy vector search workloads in PostgreSQL (pgvector), while keeping the primary available for writes. Multi-AZ standby is for availability, not read scaling.

Question 9 - Vector Index Dimension Mismatch Troubleshooting

An ML engineer is building a RAG pipeline that uses Amazon Bedrock to generate text embeddings (1536 dimensions) and stores them in a pgvector vector(1024) column in Amazon RDS for PostgreSQL. The pipeline successfully ingests all documents into the table. However, when a search query is executed, PostgreSQL returns the following error:

ERROR: different vector dimensions (1536 vs. 1024)

Which action will resolve the issue? (Select ONE)

  • A) Update the column type to vector(1536) and re-ingest all rows since the existing rows with vector(1024) cannot be automatically upgraded.
  • B) Use the VECTOR_DIM function to convert the stored vectors from 1024 dimensions to 1536 on-the-fly.
  • C) Increase the PostgreSQL shared_buffers parameter to accommodate larger vectors.
  • D) Truncate the table and re-ingest, but this time use vector(1536) column type with a default value.
Click to reveal Answer & Explanation

Correct Answer: A

Correct Answer Analysis

  • A is Correct: The pgvector extension enforces that all vectors in a column have the same dimension when using a fixed-dimension vector(N) column type. If the initial table was created with vector(1024), attempting to insert or compare a 1536-dimensional vector to a 1024 one produces a dimension mismatch error. The correct fix is to ALTER TABLE ... ALTER COLUMN ... TYPE vector(1536) and re-ingest the data with the correct dimensions.

Distractor Analysis

  • B is Incorrect: There is no VECTOR_DIM function to transform vector dimensions in pgvector. The extension does not provide dimension conversion.
  • C is Incorrect: Increasing shared_buffers affects how much PostgreSQL caches in memory; it does not address vector dimension mismatches. Dimension enforcement happens at a type/column level, unrelated to memory configuration.
  • D is Incorrect: Truncating and re-creating the table with the correct vector(1536) type would work, but it's an unnecessarily destructive solution compared to simply altering the column type and re-ingesting.

Key Takeaway: Always verify the embedding model's output dimension matches the pgvector column type before building an ingestion pipeline; dimension mismatches are detected at insert/query time and require schema changes.

Question 10 - Kinesis Data Streams Integration with OpenSearch

A streaming application ingests high-velocity event data into Amazon Kinesis Data Streams and writes transformed embeddings to an OpenSearch Service vector index via an Amazon Managed Service for Apache Flink (Flink) application. The system was working fine for initial test volumes, but after a surge in incoming events, the Flink application shows evidence of backpressure, with increasing latency and OpenSearch write throttling. The Kinesis stream has plenty of available shard capacity, and the Flink job has no idle CPU.

What is the most likely cause and the correct fix? (Select ONE)

  • A) The Kinesis stream is under-provisioned; increase the number of shards on the Kinesis stream.
  • B) The OpenSearch domain is the bottleneck; scale up OpenSearch data nodes or increase the write index's shard count/replica count.
  • C) The Flink application has insufficient parallelism; increase the parallelism of the Flink operator.
  • D) The embedding transformation is CPU-intensive; switch from Flink to AWS Lambda for processing.
Click to reveal Answer & Explanation

Correct Answer: B

Correct Answer Analysis

  • B is Correct: The scenario explicitly states the Kinesis stream has plenty of available shard capacity (not under-provisioned) and the Flink job has no idle CPU (which would rule out CPU-bound transformation bottlenecks). The write target (OpenSearch) is the binding constraint, evidenced by write throttling and backpressure building up in Flink. Scaling up OpenSearch by adding data nodes (to increase indexing throughput), increasing shard count, or reducing replica count (or using async writes with retries) will allow the pipeline to keep up.

Distractor Analysis

  • A is Incorrect: The Kinesis stream is explicitly stated to have "plenty of available shard capacity," so adding more shards will not resolve an OpenSearch write bottleneck. It would simply increase stream capacity that the downstream Flink can't consume fast enough.
  • C is Incorrect: The Flink job has "no idle CPU," meaning it is not CPU-bound. Increasing parallelism may help if the bottleneck is network I/O or if multiple pipelines can process in parallel, but the evidence points to downstream write throttling as the root cause. Extra parallelism would just block on OpenSearch write calls, moving the queue further upstream.
  • D is Incorrect: Lambda is not suited for this workload. Flink is the right engine for stateful streaming transformations. Switching to Lambda would dramatically increase complexity and may even worsen the problem due to Lambda's concurrency and duration limits when handling high-velocity streams.

Key Takeaway: When a streaming pipeline shows backpressure despite ample stream capacity and compute, the downstream write target is the bottleneck—scale or optimize the database/index, not the stream or consumers.