Microsoft Certified: Azure Data Fundamentals

The exam is organised around a distinction that governs a great deal of technical decision-making: what data looks like when it is structured in advance against what it looks like when structure is imposed on reading. Every storage service follows from that, as does most of what goes wrong afterwards. People who never learn this distinction spend years reaching for whichever tool they met first, and this paper is an unusually efficient way to acquire it.

• Relational concepts: tables, keys, normalisation, and the transactional guarantees that make a relational store the default rather than a fashion.
• Non-relational stores: document, key-value, graph and column-family, each with the access pattern it was designed for.
• Analytics workloads: the separation between the system recording transactions and the system answering questions about them.
• Roles: administrator, engineer and analyst, which is the part hiring managers wish more candidates understood.
• No SQL is written. Reading a simple statement is enough; nothing asks you to compose one.

The one table to carry out of the exam

Most of the paper is that table in disguise. A stem describes a workload, a shape of data and an access pattern, and asks which kind of store fits or which role owns the problem. Candidates fail it not by lacking knowledge of any one row but by never having compared the rows, which is why a spreadsheet person who reads the table properly often outscores a developer who has only ever used one database and assumes it is the answer to everything.

Forty-five minutes, and then forever

Between forty and sixty questions, a pass at 700 on the 1,000-point scale, twelve languages including German, and delivery by Pearson VUE or, for students and educators, Certiport. Microsoft requires nothing beforehand and recommends familiarity with relational and non-relational data and with the transactional-versus-analytical split, which is a description of the table above. The certificate never expires, which is the right design for a paper that certifies concepts rather than a product version: the concepts have not moved in decades and the product names change yearly.

Who should sit it is the question that follows, and it is wider than for most fundamentals papers. Analysts who commission reports, product managers who argue about which system is the source of truth, engineers who know one database well and are about to be asked to choose another, and anyone on the business side of a data platform decision all leave with a vocabulary that shortens meetings. The people who should not are the ones already doing data engineering, for whom the associate data papers test the work rather than the words.