DP-900: Understanding Azure Data Before Choosing a Platform

Data professionals frequently talk past one another because they use familiar words differently. A database, an analytics platform, a lake, and a cache all hold information, but they make different promises about consistency, query behavior, scale, and cost. DP-900, Microsoft Azure Data Fundamentals, is designed to establish this vocabulary. It is a foundational certification, not a practical database-administration examination and not a prerequisite for Microsoft’s role-based data credentials. The important skill is recognizing what problem a data service solves before evaluating a particular product.

Microsoft's July 21, 2026 study outline organizes DP-900 around core data concepts, relational data on Azure, non-relational data, and analytical workloads. Those subjects span traditional transaction processing through modern analytics. The level of detail is intentionally conceptual: a learner should know why a relational schema imposes constraints, what a document store changes, and why an analytical warehouse is optimized differently, without pretending to be a production database administrator after passing the exam.

Distinguish data shapes and their operational consequences

Structured data follows a schema that gives fields clear types and relationships. A payroll table might contain employee identifiers, approved pay periods, amounts, and foreign keys. A semistructured document could contain the same underlying business event but allow nested attributes and optional fields. Unstructured objects, such as images and recordings, do not fit neatly into a single tabular row. None of these categories identifies a storage product automatically: organizations often move data among formats during processing.

Schema is useful because it makes errors visible. A customer identifier stored as unconstrained text can contain empty strings, misspellings, and multiple formatting conventions. A relational constraint can prevent some classes of invalid data from entering a table. By contrast, a document-oriented model may give an application flexibility to evolve attributes without a coordinated table migration. That flexibility shifts responsibility toward validation, indexing, consistency, and consumer expectations.

Before choosing storage, ask whether the operation changes a few specific records or analyzes millions of records. A shopping cart needs reliable transaction updates under concurrent access. A year-over-year sales report needs broad scans and aggregations but seldom updates each individual transaction during the query. Trying to satisfy both with one badly configured operational store can produce slow transactions or expensive reporting. Separate operational and analytical responsibilities when service boundaries or workloads justify it.

Data formats matter even when the exam is conceptual. JSON can express nested records conveniently; CSV is common but does not carry robust schema information; columnar formats help analytical scans when many rows share a relatively small set of accessed columns. A file’s extension is not a complete data contract. Data types, character encoding, compression, schema evolution, and missing-value rules must be understood by the systems that read it.

Understand the relational model without confusing it with SQL syntax

A relational database organizes information into tables related by keys and governed by constraints. Normalization can reduce duplicated facts and update anomalies: customer address information need not be repeated on every order line if it can be held in a separate, correctly related structure. Normalization is not an absolute requirement for every workload; analytical models often denormalize for efficient grouping and predictable business reporting. The purpose of the model should drive that decision.

SQL is a language used to query and manipulate relational data, not a synonym for one vendor’s database product. Statements such as SELECT, INSERT, and UPDATE have common concepts across systems, but platform-specific dialects and administrative features differ. A simple join can return unexpected row counts when relationships are one-to-many. Understanding keys, filtering, and grouping is more valuable to a beginner than memorizing many syntax variations without knowing their effect.

Azure relational offerings differ in how much infrastructure the customer manages. Azure SQL Database provides a managed database service; Azure SQL Managed Instance supports additional instance-oriented compatibility scenarios; SQL Server on an Azure virtual machine gives more control over the installed server and its operating environment. Those choices affect patching, feature compatibility, resilience, and operational responsibility. A managed service shifts work to the provider but does not absolve the customer of access control, data quality, and appropriate configuration.

For a concise technical follow-on, the distinctions among SQL, PL/SQL, and T-SQL illustrate why recognizing a language family is different from mastering a particular implementation. DP-900 candidates should be able to explain what a primary key does, why a relationship exists, and when a managed relational solution makes sense, rather than treating all relational systems as interchangeable branded boxes.

Explore non-relational storage through access patterns

Non-relational storage is not a single category of 'unstructured database.' Document stores can hold flexible objects, key-value stores provide efficient access by identifiers, graph stores describe connected entities, and wide-column systems support different scale and access tradeoffs. In Azure, Cosmos DB is an important example of globally distributed database capabilities with APIs and consistency choices that must be understood in context. Azure Storage also provides object and file storage for different purposes.

A customer profile application may benefit from a document model when individual profiles have nested or evolving attributes. A bank ledger with strict relationships may continue to require strong transactional relational design. A recommendation application could use graph relationships, but that does not mean every customer interaction belongs in a graph database. The correct question is what queries the application must support, how data changes, and what failures the business can tolerate.

Microsoft Cosmos DB is useful for exploring partitioning, geographical distribution, consistency, and throughput choices. Partition-key design is not just a performance trick; it determines how records are grouped and which queries can be efficiently served. Poorly chosen keys can concentrate traffic and cost on a small number of partitions even when total data size seems modest.

Storage options have different cost components. Some systems charge for provisioned capacity, operations, or throughput; others emphasize data size, transactions, or compute time. Choosing the least expensive-looking unit is rarely sufficient. Compare expected read/write frequency, retention, replication, availability, data transfer, and the staff needed to operate the system. A non-relational service can simplify a particular application while complicating ad hoc reporting if the data model is poorly matched to analytical needs.

Recognize analytics architecture and workload boundaries

Analytics begins by converting raw business activity into trustworthy comparisons. Operational applications collect events and transactions; analytical systems clean, integrate, aggregate, and expose information for reporting and decision-making. A data warehouse often presents curated, relationally modeled data for repeatable queries. A data lake can hold files in multiple shapes and formats, while a lakehouse architecture combines file-backed data with table structures and analytical tooling. These labels describe design patterns rather than mandatory deployment stages.

The difference between batch and streaming is another conceptual boundary. A batch might calculate a daily balance from an overnight extract. A stream can detect changes as events arrive, but 'real time' is always relative to ingestion latency, event processing, and consumer freshness requirements. Late events, duplicates, and corrected history make continuous analytics more complex than simply replacing a nightly job with an event queue.

Microsoft Fabric provides a way to integrate several analytical experiences, and Fabric lakehouse architecture can help learners connect OneLake, curated data, and downstream reporting. DP-900 learners should understand that a lakehouse is not a replacement for fundamental data modeling or governance. A dashboard built on incorrect definitions will still be incorrect even if it runs on a modern unified analytics platform.

For reporting, know how a dataset becomes useful through dimensions, measures, and visualization. A measure of active customers requires a documented time window and definition of active. A change to that definition can alter every dashboard that reuses it. Analysts, data engineers, and database administrators therefore need shared semantic definitions even when their daily tools differ. Analytics architecture succeeds when consumers know where a number came from and can assess its freshness.

Separate data roles, security, and governance responsibilities

The database administrator maintains availability, access controls, backup and recovery, configuration, and performance of relevant database systems. The data engineer designs and operates ingestion and transformation workflows that deliver usable data. The analyst interprets measures, validates business questions, and communicates findings. In a small team one person may fulfill several roles, but the responsibilities remain distinct and explain why different certifications have different objectives.

Security is part of fundamentals, not an advanced afterthought. Sensitive personal information may need encryption, limited access, retention constraints, and auditability. Authorization should be designed so that employees can perform legitimate tasks without receiving broad access to unrelated data. Data governance adds ownership, classifications, documentation, quality standards, and lineage. A copy of a protected source table does not become harmless simply because it was moved into an analytics workspace.

A practical example is a healthcare appointment dashboard. An analyst might need daily appointment counts but not patient names. A data engineer can create an appropriately aggregated dataset, and an administrator can restrict access to source records. The system should also control whether drill-through reports reveal individual patients and whether exports create uncontrolled copies. This is a business design decision as much as a technical permissions exercise.

The foundation-level exam should not be confused with advanced implementation. DP-700 addresses the operation of Fabric data engineering solutions, and DP-800 focuses on developing AI-enabled database applications. DP-900 builds the common language needed to decide which specialization is appropriate, not a shortcut to the responsibilities those roles carry.

Build intuition with small comparative exercises

Create a small fictional business scenario with orders, products, customers, and clickstream activity. Sketch a normalized transactional model, then design an analytical view that measures sales by day and product. Consider which source fields are structured, which events arrive as flexible documents, and which raw objects should be stored as files. Explain where constraints help, where denormalization is deliberate, and which parts need frequent updates.

Next, describe two Azure deployment options for the transactional component: a managed relational service and a self-managed server in a virtual machine. Compare who handles operating-system maintenance, application compatibility, backup configuration, and access policy. For the clickstream, consider whether a document, event, or file-oriented design best supports the questions the business actually asks. Avoid claiming there is one correct service without a defined workload.

Finally, write a data glossary with terms such as transactional workload, analytical workload, relational schema, partition key, data lake, warehouse, pipeline, and lineage. Test whether you can explain each to a colleague without relying on vendor marketing vocabulary. The examination becomes much easier when a diagram or scenario can be translated into these concrete concepts.

DP-900 is valuable as a conceptual map, not as proof of production operations expertise. Use Microsoft's current official objective list to confirm which services and descriptions are within scope, and keep the distinction between product names and underlying workload requirements clear. The most durable lesson is simple: choose a data architecture because it preserves the meaning, accessibility, and reliability the business needs, not because a product label sounds modern.