AI-200 data management services explained

Develop AI solutions by using Azure data management services is the largest AI-200 domain at 25–30%, and the newest. It covers three services: Azure Cosmos DB for NoSQL, Azure Database for PostgreSQL and Azure Managed Redis. Each stores embeddings and runs vector similarity search, so the exam tests both how each service works and which one fits a scenario.

Choosing between the three

Service	Reach for it when
Cosmos DB for NoSQL	Documents with flexible schema, global scale, change-driven processing
PostgreSQL with pgvector	Relational data with joins and constraints, SQL-based RAG with metadata filters
Azure Managed Redis	Sub-millisecond reads, caching, short-lived or frequently repeated lookups

The recurring trap is picking Redis as a primary store. It is a cache and a fast index. When a scenario needs durable system-of-record data, the answer is one of the other two.

Cosmos DB for NoSQL

Queries and Request Units

Every operation costs Request Units (RUs). You connect with the SDK, typically via CosmosClient and DefaultAzureCredential, and run SQL-like queries against a container. Two levers control RU cost:

Indexing policy. By default every property is indexed, which makes writes more expensive. Excluding paths you never filter on cuts write RUs. Composite indexes are needed for ORDER BY on more than one property.
Consistency level. From strongest to weakest: strong, bounded staleness, session, consistent prefix, eventual. Session is the default and suits most apps. Strong and bounded staleness cost more RUs on reads.

A query that filters on the partition key stays in one partition. A query that does not fans out across all of them and costs more. Partition key choice questions usually hinge on that.

Vector search

To store and search embeddings you define two things on the container:

A vector embedding policy: the property path, data type, number of dimensions and distance function (cosine, dot product or Euclidean).
A vector index in the indexing policy: flat, quantizedFlat or diskANN. Flat is exact but only suits small dimension counts; quantizedFlat and DiskANN trade a little accuracy for much better performance at scale.

You then query with VectorDistance() and ORDER BY to return the closest items. Exclude the embedding path from the regular range index, or every write pays to index hundreds of numbers it will never filter on.

Change feed processor

The change feed exposes inserts and updates on a container in order. The change feed processor reads it with three parts: the monitored container, a lease container that tracks progress and distributes work across instances, and a delegate that handles each batch. In the default latest-version mode, deletes do not appear, so a soft-delete flag is the usual workaround.

Typical scenario: new documents must be embedded as soon as they arrive. The answer is a change feed processor, or an Azure Functions Cosmos DB trigger built on it, not a timer that scans the container.

Azure Database for PostgreSQL

Schema and data types

Design tables as you would for any relational workload, with the embedding stored in a vector(n) column where n matches your model’s dimensions. The pgvector extension must be allowed on the server and then enabled with CREATE EXTENSION vector.

Vector indexes

Index	Build	Query	Notes
None	—	Exact, slow	Fine for small tables
IVFFlat	Fast, but needs data first	Approximate	Tune `lists` at build time and `probes` at query time
HNSW	Slower, more memory	Approximate, fast, high recall	Can be built on an empty table; tune `m`, `ef_construction`, `ef_search`

Queries use distance operators: <-> for Euclidean, <=> for cosine and <#> for negative inner product. The index only helps if the query’s operator matches the operator class the index was built with — a common reason an index is silently ignored.

Compute, memory and connections

Index builds for vectors are memory-hungry; raising maintenance_work_mem and choosing a memory-optimised compute tier shortens them. For throughput, the objective on connection optimisation points at connection pooling. Flexible Server has PgBouncer built in, which stops short-lived Functions or containers from exhausting connections.

RAG with metadata filters

Retrieval-augmented generation with PostgreSQL combines a vector distance ORDER BY with ordinary WHERE clauses, for example restricting results to one tenant or document category. That combination is a strong reason to pick PostgreSQL when the scenario involves structured filters alongside similarity.

Azure Managed Redis

Two objectives:

Data operations: caching with the cache-aside pattern, setting expiration with a TTL, and invalidating a key when the underlying data changes. Stale data after an update means invalidation is missing.
Vector indexing: Azure Managed Redis supports search indexes with vector fields for similarity search, which suits semantic caching of repeated prompts. Modules such as search are chosen when the cache is created.

Sample questions

Question 1. A container in Azure Cosmos DB for NoSQL is write-heavy. Queries only ever filter on customerId and status, but every write consumes more RUs than expected. What should you change?

A. Change the account consistency level to eventual
B. Add a composite index on every property
C. Update the indexing policy to exclude all paths except customerId and status
D. Increase the provisioned throughput

Show answer

Answer: C

Cosmos DB indexes every property by default. Excluding all paths except those used in filters reduces the index maintenance each write performs, lowering write RUs. Changing the consistency level affects reads, not index cost. Adding a composite index increases write cost. More throughput pays for the cost rather than reducing it.

Want more questions like this? Full AI-200 practice tests →

Question 2. You add an HNSW index to an embedding column in Azure Database for PostgreSQL, but EXPLAIN shows a sequential scan for your similarity query, which orders by embedding <-> query_vector. The index was created with vector_cosine_ops. What is the cause?

A. The query operator does not match the index operator class
B. HNSW indexes require data to exist before they can be built
C. The pgvector extension was not enabled
D. PgBouncer is bypassing the index

Show answer

Answer: A

The <-> operator computes Euclidean distance, while the index was built with the cosine operator class, so PostgreSQL cannot use it. Either query with <=> or rebuild the index with the Euclidean operator class. HNSW does not require data before building, a missing extension would make the column itself fail, and PgBouncer affects connections, not query plans.

Want more questions like this? Full AI-200 practice tests →

Question 3. An app caches product details in Azure Managed Redis using the cache-aside pattern. After a price change is saved to the database, users keep seeing the old price for hours. What should you implement?

A. Scale the cache to a larger tier
B. Invalidate the product’s cache key on update and set a TTL on cached entries
C. Read prices directly from the database and write them to the cache afterwards
D. Create a vector index over the product keys

Show answer

Answer: B

Deleting or updating the cache key when the database record changes removes the stale value, and a sensible TTL limits how long any missed invalidation can last. A larger cache tier holds the same stale data. Moving reads to the database abandons the cache. Vector indexes are for similarity search, not freshness.

Want more questions like this? Full AI-200 practice tests →

What to practise

Put the same embedded data set into Cosmos DB and PostgreSQL. In Cosmos DB, add a vector policy and index and write a VectorDistance query. In PostgreSQL, build IVFFlat and HNSW indexes, then check with EXPLAIN that your query actually uses them. Finish by caching one result in Redis with a TTL. That is most of the domain in an afternoon, and it makes the “which service” questions easy.