1.1.7

Question	Answer & Explanation
### Question 1 - OpenSearch Serverless for High-Scale Visual Search An e-commerce platform is building a visual search feature that allows users to upload an image and find similar products. The engineering team has generated 500 million image embeddings (1,536 dimensions each) using a deep learning model. The application requires sub-50 millisecond p99 latency for similarity queries, and the operations team mandates a solution with the least operational overhead for managing the underlying infrastructure. The solution must automatically scale to handle unpredictable traffic spikes. Which AWS service configuration BEST meets these requirements? (Select ONE) - A) Provision an Amazon OpenSearch Service managed cluster with high-memory instances (e.g., r6g family) and manually configure auto-scaling for data nodes. - B) Use Amazon RDS for PostgreSQL with the pgvector extension and configure an HNSW index on the embeddings table. - C) Create an Amazon OpenSearch Serverless collection with the vector search collection type and ingest the embeddings. - D) Store the embeddings in Amazon S3 and use Amazon Athena to run approximate nearest neighbor queries using a custom user-defined function (UDF).	Correct Answer: C Correct Option Analysis: - C is Correct: Amazon OpenSearch Serverless is purpose-built for vector search workloads. It automatically scales compute and storage resources to match traffic patterns, eliminating the need for manual cluster management and instance type sizing. It provides the low latency required for real-time applications like visual search. Distractor Analysis: - A is Incorrect: While OpenSearch Service can handle vector search, it requires manual provisioning of instances, shard allocation, and auto-scaling policies, introducing high operational overhead compared to the serverless option. - B is Incorrect: While pgvector can handle vector search, a dataset of 500 million high-dimensional embeddings would severely strain a PostgreSQL database's memory and compute resources, making it unsuitable for sub-50ms latency at this scale without massive over-provisioning. - D is Incorrect: Amazon Athena is an interactive query service and is not designed for sub-50ms low-latency nearest neighbor queries. Running ANN queries as a UDF in Athena is not a supported or performant pattern. > Key Takeaway: For highly scalable vector search with minimal operational overhead and low latency, Amazon OpenSearch Serverless is the preferred AWS native choice over provisioned OpenSearch or relational databases.
### Question 2 - RDS pgvector for Relational Proximity Search A financial services company maintains a highly structured PostgreSQL database containing customer profiles, transaction histories, and account metadata. The data science team wants to implement a fraud detection feature that identifies customers with similar transaction behavior using vector embeddings. The team needs to perform similarity searches that strictly filter by relational attributes (e.g., "accounts opened in the last 30 days in New York") before calculating vector distance. Moving the relational data to a dedicated vector database is prohibited due to compliance rules requiring data residency in the existing managed database. Which approach meets these requirements with the LEAST operational complexity? (Select ONE) - A) Enable the pgvector extension on the existing Amazon RDS for PostgreSQL instance and write SQL queries combining relational filtering with vector similarity operators. - B) Export the relational data nightly to Amazon S3, ingest the vectors into Amazon OpenSearch Serverless, and use OpenSearch's search API for hybrid queries. - C) Use AWS Glue to extract the data, compute embeddings in AWS Lambda, and store them in Amazon DynamoDB with a custom vector search implementation. - D) Set up an Amazon EMR cluster with Apache Spark to perform nearest neighbor searches in memory using the Spark MLlib library.	Correct Answer: A Correct Option Analysis: - A is Correct: The pgvector extension for Amazon RDS PostgreSQL allows storing and querying vectors directly alongside relational data. This enables hybrid queries (SQL filtering + vector similarity) in a single transactional database without moving data or introducing new distributed systems, perfectly satisfying the compliance and complexity constraints. Distractor Analysis: - B is Incorrect: Exporting data to S3 and OpenSearch violates the compliance rule requiring data residency in the existing managed database and introduces unnecessary data pipeline complexity. - C is Incorrect: DynamoDB does not natively support vector similarity search. Building a custom implementation would require massive operational overhead and would not easily support complex relational pre-filtering. - D is Incorrect: Amazon EMR is designed for batch processing, not low-latency online queries for fraud detection. It introduces significant cluster management overhead. > Key Takeaway: When embeddings must be queried alongside structured relational data and data movement is restricted, Amazon RDS for PostgreSQL with pgvector is the most operationally efficient and compliant architecture.
### Question 3 - Cost-Effective Storage for Batch Vector Retrieval A media streaming company is building an offline recommendation model that requires accessing 50 billion user interaction embeddings (768 dimensions each). The data science team runs large batch jobs once a week to retrieve all vectors and retrain the models. Real-time query latency is not a requirement, but the solution must be highly cost-effective and scale storage automatically without managing capacity. The team wants to avoid provisioning large memory-optimized compute instances just to hold the vector index. Which AWS service is the MOST cost-effective solution for storing these embeddings? (Select ONE) - A) Amazon OpenSearch Service with warm storage enabled. - B) Amazon RDS for PostgreSQL with pgvector using standard storage. - C) Amazon S3 vector buckets and vector indexes. - D) Amazon SageMaker Feature Store Offline Store.	Correct Answer: C Correct Option Analysis: - C is Correct: Amazon S3 vector buckets and vector indexes are designed to hold large vector sets in object storage. This is the most cost-effective solution for datasets that are accessed in large batches and tolerate less frequent querying, as it avoids the memory-optimized compute costs associated with in-memory vector databases. Distractor Analysis: - A is Incorrect: Amazon OpenSearch Service requires memory-optimized instances to hold vector indices for fast retrieval. Storing 50 billion vectors in OpenSearch would be prohibitively expensive for a weekly batch job. - B is Incorrect: RDS for PostgreSQL is not designed to hold 50 billion vectors efficiently. It would require massive storage and compute resources, making it unsuitable for this scale of batch processing. - D is Incorrect: While SageMaker Feature Store can store vectors, its offline store is built on S3 and Glue, but S3 vector buckets specifically optimize the vector indexing and retrieval process for this exact use case at a lower cost for pure vector batch retrieval. > Key Takeaway: For massive vector datasets accessed infrequently in batch processing, object storage like Amazon S3 vector buckets provides the lowest cost by avoiding the expensive in-memory compute required by real-time vector databases.
### Question 4 - OpenSearch k-NN Distance Metrics A natural language processing (NLP) engineering team is configuring an Amazon OpenSearch Service cluster to store document embeddings for a semantic search application. The embeddings were generated using a sentence-transformer model that normalizes the output vectors to a length of 1. The team must configure the k-NN distance metric in the OpenSearch index settings to ensure semantic relevance. The chosen metric must mathematically align with the properties of the normalized vectors to optimize search accuracy and computational performance. Which distance metric should the engineer configure? (Select ONE) - A) L1 (Manhattan distance) - B) L2 (Euclidean distance) - C) Cosine similarity - D) Inner product (Dot product)	Correct Answer: D Correct Option Analysis: - D is Correct: When vectors are normalized to a length of 1 (L2 norm), the inner product (dot product) is mathematically equivalent to the cosine similarity. However, computing the inner product is computationally cheaper than calculating the cosine similarity function because it skips the magnitude normalization step. Therefore, for normalized vectors, the innerproduct metric provides the best performance while maintaining search accuracy. Distractor Analysis: - A is Incorrect: L1 distance is typically used for grid-like pathfinding and does not perform well for high-dimensional semantic embeddings. - B is Incorrect: While L2 distance can be used, it is computationally more expensive than the inner product for normalized vectors and does not offer a benefit in this specific scenario. - C is Incorrect: Cosine similarity is the intended semantic measure, but explicitly configuring it in OpenSearch forces the engine to perform magnitude calculations. Since the vectors are already normalized, innerproduct is the optimized equivalent. > Key Takeaway: For vectors already normalized to length 1, configuring the k-NN space type as innerproduct in OpenSearch is the most computationally efficient way to perform cosine similarity.
### Question 5 - pgvector Indexing Strategies An ML engineer is using Amazon RDS for PostgreSQL with the pgvector extension to store 5 million high-dimensional embeddings for an image retrieval application. The current exact nearest neighbor search (using standard ORDER BY ... LIMIT) is taking too long and is missing the p99 latency target of 100ms. The engineer needs to configure an Approximate Nearest Neighbor (ANN) index to drastically improve query speed. The application's traffic is highly unpredictable, with sudden spikes in concurrent queries. The solution must handle high-throughput concurrent searches efficiently without bottlenecking on CPU resources during index updates. Which index type and configuration should the engineer use? (Select ONE) - A) Create an IVFFlat index with a low number of lists. - B) Create an HNSW index with a moderate m (connections) and ef_construction value. - C) Create a B-Tree index on the vector column. - D) Create a GiST index on the vector column.	Correct Answer: B Correct Option Analysis: - B is Correct: The HNSW (Hierarchical Navigable Small World) index in pgvector provides better query recall and speed compared to IVFFlat. While it uses more memory, it is highly efficient for concurrent queries and has faster query times, which suits the p99 latency and traffic spike requirements. Distractor Analysis: - A is Incorrect: IVFFlat is faster to build and uses less memory, but it generally has slower query performance and lower recall than HNSW. It is less ideal for strict latency targets and high concurrent traffic spikes. - C is Incorrect: B-Tree indexes are for standard scalar data sorting and do not support vector similarity search algorithms. - D is Incorrect: GiST indexes in PostgreSQL are used for geometric data and full-text search, not for high-dimensional vector similarity search. > Key Takeaway: For low-latency, high-throughput vector search in pgvector, the HNSW index is preferred over IVFFlat, provided the database has sufficient memory to hold the graph.
### Question 6 - OpenSearch Serverless Security and Encryption An AI engineering team is configuring an automated ingestion pipeline for an enterprise knowledge base using Amazon OpenSearch Serverless. The pipeline must parse unstructured PDF documents, generate vector embeddings, and store them in an encrypted vector collection. Compliance policies mandate that the vector index at rest must be encrypted using a customer-managed key (CMK) in AWS KMS, and access must be strictly limited to specific IAM roles. The team must configure these security settings before ingesting any data. Which TWO steps should the engineer perform to fulfill these requirements? (Select TWO) - A) Define an encryption policy in Amazon OpenSearch Serverless specifying the KMS customer-managed key (CMK) ARN prior to creating the vector collection. - B) Enable SSE-S3 default encryption on the source S3 bucket to automatically encrypt the downstream OpenSearch Serverless collection. - C) Create a data policy in Amazon OpenSearch Serverless granting aoss:* permissions to the specific IAM roles. - D) Configure an IAM role for the OpenSearch collection with a trust policy allowing es.amazonaws.com to assume it. - E) Enable client-side encryption using an AWS Lambda function before writing embeddings to the collection.	Correct Answers: A and C Correct Options Analysis: - A is Correct: Encryption policies in OpenSearch Serverless must be defined and attached before or during collection creation. Specifying the KMS CMK ARN guarantees at-rest encryption for the vector index according to compliance rules. - C is Correct: Data policies in OpenSearch Serverless manage access control. Granting the appropriate permissions (e.g., aoss:CreateCollectionItems, aoss:Read) to specific IAM roles restricts access to the collection securely. Distractor Analysis: - B is Incorrect: SSE-S3 encryption only protects objects in the S3 bucket itself; it does not extend to OpenSearch Serverless collections. - D is Incorrect: OpenSearch Serverless uses standard IAM execution roles for ingestion, but collection-level access is managed through OpenSearch Serverless data policies, not service-linked roles. - E is Incorrect: Client-side encryption via Lambda is unnecessary and complex. OpenSearch Serverless natively supports KMS encryption at rest. > Key Takeaway: In OpenSearch Serverless, security is decoupled into Encryption Policies (for KMS at-rest encryption) and Data Policies (for IAM-based access control), both of which must be configured prior to data ingestion.
### Question 7 - Optimizing pgvector for High Dimensions A machine learning team is using Amazon RDS for PostgreSQL with the pgvector extension to store text embeddings generated by a large language model. The embeddings have a dimensionality of 4,096. The team is experiencing high CPU utilization and slow query times during similarity searches. The database instance is memory-optimized (e.g., db.r6g.xlarge), but the queries still perform full table scans instead of using the HNSW index. The team needs to modify the query or index parameters to ensure the ANN index is utilized. Which configuration will ensure the HNSW index is used for the queries? (Select ONE) - A) Increase the maintenance_work_mem parameter to 2GB. - B) Set the ivfflat.probes parameter to a higher value. - C) Set the hnsw.ef_search parameter to a lower value. - D) Ensure the query uses the same distance operator as the index operator class (e.g., <=> for cosine distance).	Correct Answer: D Correct Option Analysis: - D is Correct: PostgreSQL will only use an index if the query operator matches the operator class defined in the index. For pgvector, if an HNSW index is built for cosine distance (vector_cosine_ops), the query must use the <=> operator. Using <-> (Euclidean) or <#> (Inner Product) will bypass the index and cause a sequential scan. Distractor Analysis: - A is Incorrect: maintenance_work_mem affects the speed of building the index, not the query execution plan. - B is Incorrect: ivfflat.probes is relevant only for IVFFlat indexes, not HNSW indexes. - C is Incorrect: hnsw.ef_search controls the search tradeoff between accuracy and speed, but if the operator doesn't match, the index isn't used at all. > Key Takeaway: In pgvector, an ANN index is only utilized if the query explicitly uses the distance operator (<->, <=>, <#>) that exactly matches the operator class used to build the index.
### Question 8 - OpenSearch Vector Engine Configuration An AI startup is using Amazon OpenSearch Service (managed cluster) as a vector database for a Retrieval-Augmented Generation (RAG) chatbot. The vectors are 1,536 dimensions and the dataset is rapidly growing past 50 million records. The engineering team notices that the k-NN search latency spikes unpredictably, and JVM garbage collection pauses are frequently occurring on the data nodes. The team needs to optimize the OpenSearch cluster specifically for large-scale vector workloads to reduce GC pauses and stabilize latency. They want to achieve this without provisioning larger instances if possible. Which configuration change BEST addresses the JVM memory pressure? (Select ONE) - A) Enable vector quantization (e.g., PQ or Binary Quantization) in the k-NN settings to reduce the memory footprint of the vectors. - B) Increase the number of primary shards to distribute the vectors across more nodes. - C) Switch from the lucene k-NN engine to the nmslib engine. - D) Increase the JVM heap size to 32GB on the existing instances.	Correct Answer: A Correct Option Analysis: - A is Correct: Vector quantization (like Product Quantization or Binary Quantization) drastically reduces the memory required to store the vector index. By compressing the vectors in memory, it significantly lowers JVM heap usage, reducing garbage collection pauses and stabilizing query latency. Distractor Analysis: - B is Incorrect: While sharding helps distribute data, it doesn't reduce the total memory footprint per vector. The JVM GC pressure on each individual node remains the same if the shard size is unchanged. - C is Incorrect: The nmslib engine generally uses more memory than the lucene engine and would likely worsen the GC issue. - D is Incorrect: The standard recommendation for OpenSearch JVM heap is not to exceed 31GB to avoid compressed oops pointer limits. Scaling vertically to larger instances is also constrained by the prompt. > Key Takeaway: For large-scale OpenSearch vector workloads, enabling vector quantization (PQ/Binary) is the most effective way to reduce JVM heap consumption and avoid garbage collection pauses without necessarily increasing instance size.
### Question 9 - Hybrid Search Architecture in pgvector A healthcare startup is building a patient record retrieval system. They store patient metadata (age, gender, diagnosis codes) and medical notes in an Amazon RDS for PostgreSQL database. They want to find patients with similar medical notes using embeddings, but they must strictly filter the results to only include patients within a specific age range and diagnosis code set. The team is using the pgvector extension. However, the current queries are slow because PostgreSQL filters the relational data after fetching the top 100 nearest neighbors, often missing relevant patients whose vectors were not in the top 100. How should the ML engineer rewrite the query to ensure the relational filter is applied efficiently alongside the vector search? (Select ONE) - A) Use a subquery to first filter by age and diagnosis code, and then apply the ORDER BY embedding <=> $1 LIMIT 100 on the filtered set. - B) Fetch the top 1000 nearest neighbors without filtering, and filter the age and diagnosis codes in the application layer. - C) Create a standard B-Tree index on the embedding column and use the <=> operator. - D) Use the EXPLAIN ANALYZE command to force a sequential scan on the table.	Correct Answer: A Correct Option Analysis: - A is Correct: By using a subquery (or a Common Table Expression) to pre-filter the relational data (age, diagnosis codes) and then applying the vector similarity operator (<=>) on that reduced dataset, PostgreSQL can leverage its standard B-Tree indexes for the relational filters before calculating the vector distances. This ensures the top 100 results actually satisfy the constraints. Distractor Analysis: - B is Incorrect: Post-filtering in the application layer after fetching 1000 results is inefficient, does not guarantee the final 100 records are the closest matches, and wastes bandwidth. - C is Incorrect: B-Tree indexes cannot index vector data for similarity search; they are for scalar sorting. - D is Incorrect: Forcing a sequential scan will check every row, which is extremely slow for large datasets and ignores the ANN index entirely. > Key Takeaway: In pgvector, when combining strict relational pre-filtering with vector search, push the relational filters into a subquery (CTE) to narrow the dataset before applying the vector similarity operator to ensure accurate and efficient results.
### Question 10 - Ingesting Vectors into OpenSearch Serverless A data engineer is setting up an automated pipeline to ingest millions of text chunks from documents into an Amazon OpenSearch Serverless collection. The engineer is writing a Python script using the OpenSearch Python SDK to batch insert the embeddings. The script frequently fails with 429 Too Many Requests or timeout errors when attempting to insert large batches during peak business hours. The engineer needs to modify the ingestion logic to handle the OpenSearch Serverless capacity limits gracefully with the least code complexity. Which approach should the engineer implement to resolve the throttling issues? (Select ONE) - A) Manually scale up the OpenSearch Serverless collection's OpenSearch Compute Units (OCUs) before running the script. - B) Implement an exponential backoff and retry mechanism in the Python script for throttled requests, and reduce the bulk request batch size. - C) Switch from the Python SDK to a Bash script using curl commands to reduce client-side overhead. - D) Write the vectors to an Amazon Kinesis Data Stream and configure a Kinesis Firehose delivery stream to OpenSearch Serverless.	Correct Answer: B Correct Option Analysis: - B is Correct: Reducing the batch size limits the payload of individual requests, and implementing exponential backoff allows the script to gracefully handle 429 Too Many Requests errors by pausing and retrying as the serverless collection auto-scales its capacity (OCUs). This is a standard best practice for interacting with serverless APIs with burst limits. Distractor Analysis: - A is Incorrect: OpenSearch Serverless automatically scales capacity based on traffic. While you can configure OCU limits, manual scaling intervention contradicts the serverless model and doesn't solve burst limit issues at the API level. - C is Incorrect: The client language (Python vs. Bash) has no impact on the server-side throttling limits of OpenSearch Serverless. - D is Incorrect: While Firehose can deliver to OpenSearch, it adds infrastructure complexity. Adjusting the script's batch size and adding retries is a much simpler code-level fix for an ingestion script. > Key Takeaway: When bulk ingesting data into OpenSearch Serverless, always implement client-side exponential backoff and tune the batch size to gracefully handle API throttling (429 errors) during auto-scaling events.