1.2.2. Data, Messaging, and Observability Building Blocks
💡 First Principle: Non-compute services each exist to absorb one specific failure mode of a naive architecture. Cosmos DB absorbs global scale and schema drift; PostgreSQL absorbs relational integrity plus vectors; Redis absorbs repeated reads; Service Bus absorbs bursts; Event Grid absorbs "tell everyone something happened"; Key Vault absorbs leaked credentials; OpenTelemetry + KQL absorb the mystery of where it broke. Name the failure mode in the scenario and you've named the service.
Building on the anatomy from 1.1.1, every non-compute box in that diagram maps to a specific Azure service you'll master in Phases 2–5. This table is your map of the rest of the guide — each row states the job to be done, because exam scenarios describe jobs, not service names.
| Job the scenario describes | Service | Where covered |
|---|---|---|
| Store documents/conversations at global scale, flexible schema | Azure Cosmos DB for NoSQL | 2.1 |
| Relational data + vector search in one engine (RAG) | Azure Database for PostgreSQL + pgvector | 2.2 |
| Sub-millisecond reads, caching, semantic cache | Azure Managed Redis | 2.3 |
| Guarantee processing of commands/work items; absorb bursts | Azure Service Bus | 4.1.1 |
| React to things that happened; fan out notifications | Azure Event Grid | 4.1.2 |
| Run small code on triggers with declarative service connections | Azure Functions | 4.2 |
| Keep secrets out of code and config | Azure Key Vault | 5.1.1 |
| Centralize non-secret settings and feature flags | Azure App Configuration | 5.1.2 |
| Follow one request across five services | OpenTelemetry tracing | 5.2.1 |
| Ask questions of your logs and metrics | KQL in Azure Monitor | 5.2.2 |
Two distinctions in this table generate a disproportionate share of exam questions, so plant them now. Messages versus events: a message (Service Bus) is a command — "process this document" — where the sender expects work to happen and nothing may be lost. An event (Event Grid) is a fact — "a document was uploaded" — broadcast to whoever cares. Secrets versus configuration: a secret (Key Vault) grants access and must be guarded, rotated, and audited; configuration (App Configuration) shapes behavior and merely needs versioning and refresh. When you can classify the payload, you've picked the service.
⚠️ Exam Trap: "Store the API key in App Configuration" is always wrong — App Configuration holds references to Key Vault secrets, never the secrets themselves. Similarly, "use Event Grid to queue work for guaranteed processing" confuses events with messages; Event Grid pushes notifications, it is not a work queue.
Reflection Question: Your RAG chatbot re-embeds the same top-50 FAQ questions thousands of times a day. Which building block absorbs this waste, and why is it not the vector database's job?
