Design and develop database solutions35–40%The schema and the code, before anyone worries about who may read it or how it ships. Objects first: ordinary tables and their specialised cousins that exist for one purpose each, columns that hold JSON documents rather than scalars, the constraints and sequences that keep values honest, and the partitioning that decides how a large table is physically carved up. Then the code that lives in the database rather than above it, as views, functions of two shapes, procedures and triggers. Then the T-SQL itself at a level past everyday querying: recursive and layered expressions, calculations that look sideways at neighbouring rows, functions that read and shred JSON, pattern matching over text, similarity scoring between two strings that are nearly but not quite equal, traversal across a graph structure, queries whose inner half depends on the outer, and error handling that turns a failure into something the caller can act on. The newest slice sits here too, and it is small but distinctive: writing this code with an AI assistant in the loop, deciding what the assistant may see, wiring it to tool endpoints, steering it with instruction files, and understanding what that convenience costs in exposure.
≈ 19 h Secure, optimize, and deploy database solutions35–40%Everything that stands between working code and a solution somebody is willing to run. It has four movements. Access control and confidentiality: which values are encrypted and where the keys live, which values are shown blurred to whom, which rows a given caller may see at all, which objects they may touch, how a connection authenticates without a password in it, what gets written to an audit trail, and how the newer endpoint surfaces are locked down when the database starts talking to model endpoints and to REST, GraphQL and protocol servers. Then performance, read from evidence rather than instinct: server and database settings, the isolation and concurrency choices that trade consistency against throughput, and the tooling that shows what a query actually did, including the diagnosis of one session waiting on another. Then the release path, built on database projects held in source control: tests, reference data, project models, branches and pull requests, secrets, and the detection of a target that has drifted away from the declared schema, all the way through to controlled deployment pipelines. Last, the seams to the rest of Azure: publishing database objects as APIs, watching the result, and reacting to changes in the data as events rather than by polling.
≈ 19 h Implement AI capabilities in database solutions25–30%The smallest share and the reason the exam exists. Three questions, in order. Which model, and how do the embeddings stay current: choosing between models on capability, language coverage, size and output shape; registering one so the engine can call it; deciding which columns are worth embedding at all; cutting long text into pieces that fit and still mean something; and picking the mechanism that regenerates an embedding when its source row changes, which is the part most designs get wrong. Then retrieval: keyword search, similarity search over vectors, or both fused into one ranking; how vector data is typed, indexed and sized; the exact-versus-approximate trade-off and what an approximate index costs in recall; and how to tell whether the result set is actually good. Last, generation grounded on what was retrieved: recognising the cases where retrieval-augmented generation is the right answer, calling an external endpoint from inside the database, shaping structured rows into something a language model can read, and getting a usable answer back out of the response.
≈ 13 h 
Alex