Microsoft DP-900: Azure Data Fundamentals for Modern Workloads

DP-900 introduces the reasoning behind cloud data platforms: what data is, how databases organize it, when analytical systems are appropriate and what responsibilities come with using managed Azure data services. Microsoft refreshed the skills outline for July 21, 2026. The exam is intended for people entering data work or collaborating with engineers and analysts, not as a substitute for deep database administration. It rewards clarity about relational and nonrelational workloads, transactional guarantees, analytics patterns and the difference between choosing a service and implementing a production architecture.

Imagine a retailer with point-of-sale transactions, supplier catalogs, inventory messages and weekly management dashboards. These data sets are related but do not require one physical database or one storage representation. An order-payment workflow needs integrity and a consistent business state. A management trend report needs many records aggregated efficiently. An event log must absorb high write volumes and often tolerates an append-oriented data shape. DP-900 asks the candidate to recognize those needs before choosing products.

Recognize structured, semi-structured and unstructured data

Relational tables describe entities through columns and keys. An order table can reference a customer and contain line items, while a product table supplies details such as category or tax treatment. Constraints and relationships enforce some assumptions about valid business records. JSON events are semi-structured: different events may carry different properties while retaining a predictable envelope. Documents, emails and recorded conversations often contain unstructured text or media that requires different processing to become searchable or analyzable.

Data classification matters because the meaning of a field governs security and retention. Customer email addresses are personal information; product SKUs generally are not. Business identifiers may appear in log messages or free-text support notes even when their source schema did not declare them as sensitive. A platform decision must consider the actual content, not just whether it arrived as a structured table. Candidates should understand common operations such as ingestion, cleansing, transformation, storage, querying and visualization without assuming every workflow happens in the same system.

Batch and streaming describe arrival patterns rather than trustworthiness. A nightly vendor feed might deliver a full snapshot; an inventory sensor may emit events every second. Both can contain duplicate values, late records or incorrect timestamps. Ask how consumers will detect freshness and whether repeated processing must be idempotent. That question introduces the operational thinking needed beyond the exam's introductory scope.

Understand what makes relational databases reliable

Relational databases organize data into tables with keys and relationships and commonly use SQL for querying. Transactions matter when a business operation must change several pieces of state together. Suppose a payment record is created but the associated invoice status fails to update: users may see an inconsistent order. Atomic transaction handling reduces that class of failure when supported by the design. ACID is a useful vocabulary for understanding consistency expectations, though implementation guarantees vary by system and operation.

Indexing accelerates searches by organizing access paths, but an index consumes storage and introduces maintenance work on writes. Creating an index for every column is not sensible. Start with the queries users actually run and evaluate their selective filters, joins and ordering. The candidate should distinguish an operational database optimized for changing individual records from a warehouse optimized for scanning and summarizing larger bodies of historical information.

Azure SQL services offer choices about management responsibility, compatibility and deployment model. Azure SQL Database and Azure SQL Managed Instance are managed options, while SQL Server on Azure virtual machines leaves more operating-system and infrastructure work to the customer. These choices are not ranked from "bad" to "good"; they reflect migration requirements, application dependencies, high-availability design and administrative control. The more specialist DP-300 examines what it takes to administer such platforms in depth.

Distinguish nonrelational data models and service choices

Not every useful data set fits a rigid relational schema. Key-value systems favor fast lookup by a known identifier; document databases store records whose fields may vary; graph systems represent interconnected entities and relationships. Column-family and time-series designs can support specialized access patterns. The important question is how a workload reads and writes its data, what consistency it requires and how keys or partitions are chosen. A flexible schema is helpful when records evolve, but it does not eliminate data-quality rules.

Azure Cosmos DB provides options for globally distributed application data, and its partition key is a fundamental part of performance and cost design. A low-cardinality partition key may concentrate traffic and create hotspots; a key chosen only for easy reading may make common cross-partition queries expensive. DP-900 candidates need the basic service purpose, while DP-420 goes much deeper into application design, indexing, partitions and throughput. Keep the two competency levels distinct during preparation.

An illustrative scenario is a mobile loyalty application with user profiles spread across regions. Availability expectations and latency can motivate a globally distributed database, but teams must still understand conflicting updates, consistency options and privacy obligations. Do not assume that replicating data everywhere is automatically desirable. Residency requirements and deletion obligations can constrain replication strategy.

See how warehouses, lakes and analytics differ

Analytical systems emphasize answering questions across many records, not necessarily accepting millions of tiny transactional updates with relational constraints. A warehouse brings curated, queryable structures; a lake can hold files in many formats; a lakehouse combines some lake storage flexibility with table management and analytical capabilities. Azure and Microsoft Fabric expose services at different layers of the data journey. DP-900 is concerned with recognizing the pattern, not memorizing each platform's deepest tuning controls.

A management dashboard summarizing sales by region and month often requires data from multiple operational systems. Those sources may use inconsistent customer IDs, different currency units and conflicting return policies. The analytical pipeline must define business rules before aggregation. A dashboard that appears attractive but doubles a customer across joined tables is not a successful implementation. The same basic idea leads to DP-600, which examines analytical semantics and governed measures, and DP-700, which covers engineering dependable Fabric data flows.

Modern analytics may use SQL, notebooks, query languages and reporting models. Candidates should know that query tools have distinct purposes and that data preparation is part of the answer, not an inconvenient preliminary step. Choosing between real-time and batch reporting should reflect business tolerance for stale data. A financial close may value verified consistency over second-by-second freshness, while an operations center may accept provisional metrics to identify incidents quickly.

Describe security and governance as shared responsibilities

Managed cloud services reduce some infrastructure tasks, but organizations still decide access, data classification, encryption policy, retention, network exposure and lawful processing. Identity-based permissions should follow least privilege. Logging and auditing help reconstruct changes; backups and recovery testing protect availability; data-quality controls protect decisions. A stored dataset can be technically available and still be unfit for use if users do not know its source or intended meaning.

Consider a student dataset used for a training analytics project. Developers may need synthetic or de-identified records instead of the original sensitive data. Analysts may be allowed aggregate reports but not raw personal identifiers. Role assignments, views or security filters should enforce these boundaries. A clear data glossary prevents a measure called "active" from changing meaning as a business unit evolves. These governance principles apply across relational, NoSQL and analytical services.

Cost is another stewardship issue. Data copied between regions, high-throughput database settings and long retention can increase spend. Developers should know what drives usage so they can design sensible limits and alerts. Lowering the storage price while increasing query transfer charges may not reduce total cost. The correct cost comparison includes expected access frequency, availability objectives, administrative effort and the consequences of failure.

An additional way to learn data fundamentals is to classify failure modes. For a transactional system, the primary question may be whether an order was committed exactly once. For an analytical system, the question may be whether every authorized transaction for the period has arrived. For a document search system, it may be whether a result is relevant and current. These are different meanings of reliability, and a cloud service selection is incomplete until the team says which one matters for the workload.

Review the relationship between latency and accuracy with a realistic example. A transport dashboard can display provisional location updates within seconds, while invoicing should rely on a verified delivered status. Attempting to force both processes onto the same immediate-consistency workflow may introduce needless complexity. Instead, describe the lifecycle of the event, which stage is authoritative and when the resulting data can support a contractual or financial decision.

DP-900 candidates should also know when a managed service does not eliminate work. Cloud providers handle parts of the infrastructure, but customers still configure identities, decide retention, manage sensitive data and recover business logic after erroneous changes. In a shared-responsibility review, distinguish service availability from application correctness. That reasoning applies whether the candidate eventually specializes in SQL, Microsoft Fabric, AI applications or software development.

Prepare with examples that connect services to needs

Create three small scenarios: an invoice application requiring transactions, a flexible customer-profile service with rapid lookup and a reporting workload aggregating history. For each, write down the data model, primary operations, consistency need, access controls and appropriate Azure service category. Explain why the rejected alternatives are less suitable. This exercise is more useful than remembering product names disconnected from business requirements.

Use the July 2026 official DP-900 skills outline and Microsoft Learn practice questions to identify terminology gaps. Practice reading a scenario and explaining its workload before looking at answer choices. Cloud terminology changes quickly, but the durable learning remains the same: trustworthy data storage depends on matching structure, consistency, scale, security and analysis to the underlying problem.