Domain 2 · Develop AI solutions using Azure data management services
This is the largest domain on the exam, and it is really one question asked three times: where do the embeddings live? Cosmos DB, PostgreSQL with pgvector, and Azure Managed Redis can each act as a vector store for a retrieval-augmented generation pipeline, and each brings a different set of trade-offs around scale, cost, and query flexibility. Study them as alternatives to one another rather than as three unrelated products — the exam will hand you a scenario and expect you to choose.
Azure Cosmos DB for NoSQL
Cosmos DB is the globally distributed option: elastic scale, tunable consistency, and a change feed that makes it a natural event source. It is also the service with the most exam surface area, so it repays careful study.
Throughput & cost (Request Units)
Everything in Cosmos DB is priced in Request Units (RU/s), and understanding that abstraction is what most throughput questions are testing. Exceeding your provisioned RU/s returns HTTP 429 (Too Many Requests); the SDK retries with backoff automatically, but the durable fix is increasing RU/s or enabling autoscale. When you see a 429 in a scenario, do not reach for a code change first.
Cost control comes from the access pattern. Point reads — ReadItem by id plus partition key — are the cheapest operation available, so prefer them over queries whenever you already know the key. Beyond that, tune indexing policies so you are only paying to index the paths you actually query.
Partitioning
Partitioning is the decision you cannot easily undo. Choose a high-cardinality partition key that spreads both request volume and storage evenly; a low-cardinality key concentrates traffic into a hot partition that throttles long before the account's total provisioned throughput is consumed.
Consistency levels (strong → eventual)
Cosmos DB lets you trade consistency for latency and cost along a five-point scale:
| Level | Guarantee |
|---|---|
| Strong | Linearizable; most expensive |
| Bounded staleness | Lag bounded by time/versions |
| Session | Read-your-writes + monotonic reads per session token (great default) |
| Consistent prefix | Reads never see out-of-order writes |
| Eventual | Cheapest; no ordering guarantee |
Session is the default for good reason and the most common correct answer: it gives a single client read-your-writes without paying for global linearizability. Reach past it to Strong only when a scenario genuinely requires every reader everywhere to see the same write immediately.
Vector search
To use Cosmos DB as a vector store you need two pieces of configuration, and questions often omit one to see whether you notice. Define a vector embedding policy — path, data type, distance function, and dimensions — and a matching vector index. Queries then rank by similarity using the VectorDistance() system function.
Change feed
The change feed is a persistent, ordered log of changes to a container, and it is the bridge between Domain 2 and the event-driven material in Domain 3. You consume it either through the change feed processor, which manages leases and checkpoints and distributes work across instances, or through the Azure Functions Cosmos DB trigger that is built on top of it.
One behaviour is tested more than any other: the default latest-version mode emits inserts and updates but not deletes. If a scenario needs deletions to propagate, you must either switch to all-versions-and-deletes mode or model deletion as a soft delete — an update the feed will happily report.
Azure Database for PostgreSQL + pgvector
PostgreSQL is the choice when your embeddings need to sit alongside relational data and be filtered by it. Vector support arrives through the pgvector extension: allow-list it, run CREATE EXTENSION vector, and store embeddings in a vector column.
Similarity search only performs with an approximate-nearest-neighbour index. pgvector offers HNSW and IVFFlat, each created with the operator class matching your distance metric — vector_cosine_ops for cosine similarity, for instance. A B-tree index cannot accelerate vector distance ordering at all, which is a distractor worth recognising.
The pattern that makes Postgres compelling for RAG is metadata filtering: combining the similarity ORDER BY with an ordinary WHERE clause such as tenant_id = $1, so a multi-tenant retrieval stays both correct and fast in a single query. Two operational notes complete the picture. Bursty serverless clients should go through a connection pooler — PgBouncer or the built-in pooling — or they will exhaust the Postgres connection limit under load. And vector workloads are memory-hungry, so right-size compute, memory, and storage deliberately rather than accepting defaults.
Azure Managed Redis
Redis is the latency play. Its classic role is caching with TTL — SET key value EX 3600 expires an entry automatically, and you invalidate early by deleting or overwriting the key. Applied to AI workloads this becomes the semantic cache: store expensive model responses so repeated or near-identical prompts never reach the model.
Redis is also a genuine vector store in its own right. The Redis query engine can create a vector index over embedding fields and serve KNN and similarity queries, which makes it the answer when a scenario emphasises very low retrieval latency over rich relational filtering.
Quiz · Domain 2
Queries against your Cosmos DB for NoSQL container are returning HTTP 429 (Too Many Requests) under load. What is the most direct cause and fix?