|
| 1 | +### YamlMime:ModuleUnit |
| 2 | +uid: learn.wwl.optimize-vector-search-azure-database-postgresql.knowledge-check |
| 3 | +title: Module assessment |
| 4 | +metadata: |
| 5 | + title: Module Assessment |
| 6 | + description: Module assessment |
| 7 | + ms.date: 01/26/2026 |
| 8 | + author: jeffkoms |
| 9 | + ms.author: jeffko |
| 10 | + ms.topic: unit |
| 11 | +azureSandbox: false |
| 12 | +durationInMinutes: 5 |
| 13 | +content: "Choose the best response for each of the following questions." |
| 14 | +quiz: |
| 15 | + questions: |
| 16 | + - content: "You're tuning PostgreSQL for a vector search workload with 2 million 1536-dimensional embeddings. Queries are slow and you observe a cache hit ratio of 85%. Which configuration change should you prioritize?" |
| 17 | + choices: |
| 18 | + - content: "Increase `shared_buffers` to keep more data in the PostgreSQL cache" |
| 19 | + isCorrect: true |
| 20 | + explanation: "Correct. A cache hit ratio of 85% indicates that 15% of data page reads require disk access. Increasing `shared_buffers` allows PostgreSQL to cache more vector data and indexes in memory, reducing disk I/O and improving query latency for vector workloads." |
| 21 | + - content: "Decrease `random_page_cost` to encourage more index scans" |
| 22 | + isCorrect: false |
| 23 | + explanation: "Incorrect. While lowering `random_page_cost` encourages index usage, it doesn't address the root cause of the problem. The 85% cache hit ratio indicates insufficient memory caching, not incorrect query planning. The planner settings won't help if the data isn't in cache." |
| 24 | + - content: "Increase `ivfflat.probes` to search more index partitions" |
| 25 | + isCorrect: false |
| 26 | + explanation: "Incorrect. Increasing `ivfflat.probes` improves recall by searching more partitions, but it doesn't address the caching issue. The low cache hit ratio suggests data is being read from disk repeatedly, which is the primary performance bottleneck." |
| 27 | + - content: "You need to create a vector index for a dataset of 5 million product embeddings that receives frequent batch updates (daily full refresh). Build time must be under 30 minutes. Which index configuration should you choose?" |
| 28 | + choices: |
| 29 | + - content: "IVFFlat with lists set to sqrt(rows)" |
| 30 | + isCorrect: true |
| 31 | + explanation: "Correct. IVFFlat indexes build faster than HNSW indexes, making them practical for datasets that require frequent rebuilding. For 5 million rows, setting lists to approximately 2,200-2,500 provides good partitioning while keeping build time manageable." |
| 32 | + - content: "HNSW with m=16 and ef_construction=64" |
| 33 | + isCorrect: false |
| 34 | + explanation: "Incorrect. HNSW indexes provide excellent query performance but have long build times that increase more than linearly with data size. For 5 million vectors, an HNSW index typically takes 2-6 hours to build, far exceeding the 30-minute requirement." |
| 35 | + - content: "HNSW with m=8 and ef_construction=32" |
| 36 | + isCorrect: false |
| 37 | + explanation: "Incorrect. Even with reduced parameters, HNSW build times for 5 million vectors would likely exceed the 30-minute target. Lower parameter values also reduce graph quality, potentially defeating the purpose of using HNSW over IVFFlat." |
| 38 | + - content: "Your filtered vector search query filters by `category_id` and then orders by vector similarity. The query plan shows a sequential scan on the products table. What should you check first?" |
| 39 | + choices: |
| 40 | + - content: "Verify that a B-tree index exists on the `category_id` column" |
| 41 | + isCorrect: true |
| 42 | + explanation: "Correct. Without a B-tree index on `category_id`, PostgreSQL can't efficiently filter rows before applying vector similarity. Creating the index allows the planner to reduce the candidate set before vector operations, significantly improving performance for filtered queries." |
| 43 | + - content: "Verify that the vector index uses the same operator class as the query" |
| 44 | + isCorrect: false |
| 45 | + explanation: "Incorrect. While operator class matching is important for vector index usage, the sequential scan in this case is likely due to the metadata filter. If there's no efficient way to filter by `category_id`, PostgreSQL might scan the entire table regardless of vector index configuration." |
| 46 | + - content: "Increase `hnsw.ef_search` to expand the search space" |
| 47 | + isCorrect: false |
| 48 | + explanation: "Incorrect. The `hnsw.ef_search` parameter affects recall and speed for HNSW index searches, but it doesn't address why a sequential scan is being used. The problem is that metadata filtering isn't being handled efficiently, which requires a B-tree index on the filter column." |
| 49 | + - content: "You're implementing connection management for an AI application that makes 500 vector queries per second during peak traffic. Your Azure Database for PostgreSQL instance supports 1,719 max connections. Which approach should you use?" |
| 50 | + choices: |
| 51 | + - content: "Enable PgBouncer in transaction mode with a pool size appropriate for your application instances" |
| 52 | + isCorrect: true |
| 53 | + explanation: "Correct. PgBouncer in transaction mode multiplexes many client connections across fewer database connections. Clients hold server connections only during transactions, allowing hundreds of concurrent requests to share a smaller pool. This prevents hitting connection limits while maintaining throughput." |
| 54 | + - content: "Create a new database connection for each query request" |
| 55 | + isCorrect: false |
| 56 | + explanation: "Incorrect. Creating connections per request incurs 50-200ms overhead for TCP handshake, TLS negotiation, and authentication on each query. At 500 queries per second, this approach would also quickly exhaust the 1,719 connection limit, causing connection failures." |
| 57 | + - content: "Enable PgBouncer in session mode to maintain persistent connections" |
| 58 | + isCorrect: false |
| 59 | + explanation: "Incorrect. Session mode holds database connections for the entire client session, providing minimal connection reduction. For high-throughput workloads with many concurrent requests, session mode doesn't provide the connection multiplexing benefits needed to stay within limits." |
| 60 | + - content: "You're scaling a recommendation engine that currently runs on a General Purpose 8 vCore instance. CPU utilization averages 75% and P95 query latency is 150 ms, but you need to achieve sub-50ms latency. What scaling approach should you try first?" |
| 61 | + choices: |
| 62 | + - content: "Upgrade to a Memory Optimized tier with more vCores" |
| 63 | + isCorrect: true |
| 64 | + explanation: "Correct. High CPU utilization (75%) combined with slow queries suggests compute constraints. Memory Optimized tiers provide more memory per vCore, which helps keep vector indexes cached. More vCores enable parallel query execution. Vertical scaling is simpler to implement and should be tried before adding architectural complexity." |
| 65 | + - content: "Add read replicas to distribute query load" |
| 66 | + isCorrect: false |
| 67 | + explanation: "Incorrect. Read replicas help when total query volume exceeds what one server can handle, but they don't improve single-query latency. Since the problem is that individual queries take 150ms, adding replicas won't reduce that time. You first need to make single queries faster." |
| 68 | + - content: "Implement application-level caching with Azure Cache for Redis" |
| 69 | + isCorrect: false |
| 70 | + explanation: "Incorrect. While caching can reduce database load for repeated queries, recommendation queries typically have high cardinality (many unique query vectors), making cache hit rates low. The primary issue is single-query performance, which requires database-level optimization before considering caching." |
0 commit comments