Develop AI solutions by using Azure data management services

A service that answers questions from your own documents looks like artificial intelligence from the outside; from the database's side it is three ordinary jobs, namely write a row and read it back, keep a hot read from ever reaching the database, and rank stored vectors against one you just built from the user's question. That is the organizing idea of the whole domain: it never asks you to design a model, it asks you to operate three data engines correctly, and each of them answers the same three questions. How you reach it is connecting, proving who you are, and then getting at data, whether by addressing one known item, searching for the ones that match, or following changes as they land. What makes it cheap is which resource the engine meters and which dial moves the bill, and how you search it by meaning is the vector path, from declaring a vector on the store to writing the one query shape an index can actually serve. Azure Cosmos DB for NoSQL (Cosmos DB for short), Azure Managed Redis, and Azure Database for PostgreSQL flexible server (PostgreSQL flexible server below) each answer all three, which is why the trap to watch for is the scenario that mentions embeddings, chunks, or grounding and pulls you toward an answer about a model, when what is actually broken is a partition key, a missing expiry, an index built for the wrong operator, or a connection pool.

This is the largest of the exam's four domains, the other three carry equal weight, and twelve of the exam's twenty-seven subtopics sit inside it, so read them in order and the same three questions come round three times. Cosmos DB goes first and its four pages set the vocabulary the rest of the domain reuses: Connect to and query Azure Cosmos DB for NoSQL with the SDK settles one client per process, the separate data-plane role an identity needs before it may read an item, and the split between addressing a known item and searching for matches; Optimize Cosmos DB RUs with indexing policies and consistency levels prices that work in request units (RUs) and names the dials that lower it; Store embeddings and run vector similarity search in Cosmos DB adds the declarations a container needs before a similarity query can use an index; and Implement a Cosmos DB change feed processor adds the third way to read, following a container forward from a remembered position. Azure Managed Redis then takes the cheap question first, because that is its whole reason to exist: Implement Azure Managed Redis caching, expiration, and invalidation covers which reads never reach the database and the two unrelated reasons a key disappears, and Implement Azure Managed Redis vector indexing for similarity search puts a searchable index over that same keyspace. PostgreSQL flexible server runs the longest pass, from Connect and query Azure Database for PostgreSQL with SDKs and Model PostgreSQL schemas, data types, and indexes, through the vector trio of Optimize query latency and reduce pgvector compute, Configure compute, memory, and storage for vector workloads, and Run vector similarity search and RAG on PostgreSQL, and finally Optimize PostgreSQL connections for throughput and latency, which closes the domain back on the reach question at the scale where it starts to hurt.

Across all three engines the documented fix for a resource complaint is almost never to provision more. A Cosmos DB container returning HTTP 429 because one logical partition is hot does not improve when you raise the account's request units per second, because throughput divides evenly across physical partitions and the extra capacity lands on the partitions that were never busy. An application that runs out of PostgreSQL connections is not fixed by a larger max_connections either: Microsoft advises against raising it, because every connection is a server process holding memory, and points at the built-in PgBouncer in transaction mode instead. The same instinct catches the Redis instance under memory pressure whose keys were written without expiries, since the default eviction policy only considers keys that have one, and the PostgreSQL server scaled up to build a vector index faster, since Azure computes the memory server parameters when the server is created and a later resize does not move them. Narrow the scan, set the expiry, match the operator, pool the connections, and buy the bigger thing only once the shape is already right.