Microsoft DP-900: Choosing the Right Azure Data Workload

DP-900, Microsoft Azure Data Fundamentals, is about recognizing the shape of a data problem before selecting a service. A spreadsheet of invoices, an online shopping basket, an event stream and a marketing dashboard may all hold data, but they need different access patterns, consistency guarantees and operational designs. Candidates do not have to become database administrators. They do need enough practical vocabulary to explain why a relational transaction, document store, analytical warehouse or stream processor is appropriate in a particular setting. The current English objectives took effect July 21, 2026.

The certification is a starting point, not a requirement for Azure SQL administration or Fabric data engineering. It rewards thoughtful distinction between types of data, workloads and services rather than the recitation of a long product catalog. An introductory exam still benefits from concrete scenarios because similar-sounding features frequently solve different problems.

Identify the shape and purpose of the data

Structured data follows a defined representation: a customer table might have an identifier, legal name and billing address, with constraints limiting invalid entries. Semi-structured data can have recognizable fields without a fixed set of columns; JSON documents from an application are a common example. Unstructured material includes images, PDFs, audio and free text, although useful metadata can accompany each. These labels describe representation, not inherent quality. An unstructured document may be legally authoritative, while a perfectly structured spreadsheet may contain the wrong amounts.

Think about a subscription company receiving payment transactions, customer support chats and periodic survey responses. Payments call for strong consistency and traceable amounts. Chat transcripts may be stored as documents with metadata. Surveys could be aggregated into an analytical model for reporting. The company may link all three, but it should not force every data shape into a single storage model merely to simplify procurement. The goal is to preserve the characteristics that the business actually needs.

Data representation also affects operations. A stable schema can simplify validation and joins; flexible schemas can speed some changes but push consistency checks to the application. Both can become difficult if owners do not define identifiers, retention periods and who may change records. For DP-900, describe the consequences of a design choice in plain terms: what is stored, how it is queried and what happens when something changes.

Distinguish transactions from analytics

Online transaction processing generally handles many short operations such as creating orders, recording payments and updating inventory. Each must leave the business in a valid state, even when several users act concurrently. Online analytical processing tends to examine substantial datasets across time, customers or regions to find trends. The same company needs both, but an expensive analytical query should not block every checkout in the operational database.

Suppose a retailer wants to know which promotions increased repeat purchases last quarter. Its checkout system records individual sales as they happen. The analytics process joins historic sales to product, customer and campaign dimensions, applies agreed definitions and aggregates results. The reporting workload can often tolerate some delay in exchange for efficient scans and complex grouping, whereas the checkout workload needs rapid confirmation that a particular payment succeeded.

A star schema arranges measurable events in fact tables and descriptive context in dimensions. It is a common analytical pattern, though not a command to redesign every transactional database that way. Candidates should understand why denormalized analytical models may simplify reporting and why normalized transactional models help preserve business integrity. These are reasons, not slogans about one being always faster than the other.

Understand relational integrity and SQL's role

In a relational database, tables have defined relationships and can be queried with SQL. Keys identify records; foreign keys can enforce references between them. Transactions group changes that should succeed or fail together. Consider moving money between two internal accounts. Recording a debit without the corresponding credit is unacceptable; the system needs an all-or-nothing operation. This is the kind of requirement that makes transaction properties more than an academic term.

SQL can filter rows, join related tables, group results and calculate aggregates. Candidates should recognize what a simple SELECT, WHERE, GROUP BY or JOIN accomplishes, without treating DP-900 as a deep query-writing exam. Azure SQL Database, Azure SQL Managed Instance and SQL Server on Azure virtual machines provide different levels of managed service and control. The appropriate choice depends on compatibility, administration responsibility and application needs; the product with the most control also demands more operational work.

A team migrating a line-of-business application should assess its reliance on instance-level features, integrations and maintenance procedures. A fully managed database can reduce routine patching and backup burdens, while a virtual machine may preserve specific legacy dependencies. A cloud transition is not only a change of hosting location; it is a decision about which responsibilities Microsoft handles and which the organization retains.

Recognize non-relational patterns without caricaturing them

Non-relational services are a family of different models, not a single substitute for SQL. Key-value access can make simple lookups efficient. Document databases keep related attributes together when structures vary. Wide-column and graph approaches serve other kinds of relationships or scale patterns. Azure Cosmos DB supports document-oriented application designs with partitioning and configurable consistency behavior, while Azure Blob Storage holds objects such as images, backups and files. One is not merely a faster version of the other.

Consider a worldwide delivery application storing each driver's recent route observations. A document representation may accommodate optional sensor fields, but the partition strategy influences how data and requests are distributed. A partition key chosen only because it is easy to remember can create hotspots as traffic grows. At DP-900 level, the candidate should recognize that distribution, request cost, query shape and consistency matter, even if detailed implementation belongs in a specialist exam such as DP-420.

Data consistency can also be a business contract. A user might tolerate seeing a social reaction count a few seconds late, but probably not an inconsistent account balance after a confirmed transfer. Matching the consistency guarantee to user expectations is more useful than declaring one consistency option categorically superior. A cloud storage decision should include latency, geographical access, recovery needs and the consequences of stale reads.

Make cloud storage choices from retrieval and durability needs

Azure storage includes object, file, queue and table-related services with distinct purposes. Blob storage is suitable for large unstructured objects and can use access tiers based on expected frequency of retrieval. Azure Files supports shared file access for compatible workloads. Queue storage helps decouple components that do not need to complete simultaneously. The existence of several services is not a quiz of acronyms; each represents a different problem about how information is addressed and used.

A media archive holding years of footage may spend more time retaining files than serving them. Its storage economics favor an access strategy that accounts for retrieval frequency and recovery delays. A customer-facing product showing recently uploaded images has a different latency profile. Storage access tiers and redundancy choices can change cost and recovery behavior. A cheap tier may be expensive if data is retrieved constantly, while a highly replicated design may be justified when downtime carries substantial business cost.

Backups, replication and data recovery should not be treated as synonyms. Replication can make another copy available, but it does not necessarily protect against accidental deletion or a bad update propagated to all copies. An organization's recovery objective should say how much data loss and outage it can tolerate. Recognizing this distinction is foundational for any later cloud operations study.

Follow analytical data from ingestion to a useful decision

Data analytics begins when raw records are collected, prepared, transformed and served for interpretation. Batch processing handles data accumulated over a period; streaming processes arriving events continuously or with very low delay. Both can be appropriate. A nightly finance close is rarely a streaming requirement, whereas equipment telemetry used to identify a developing fault may need rapid ingestion and assessment.

Azure and Fabric offerings support pipelines, storage, querying and analytical presentation. Azure Data Factory and Fabric data engineering approaches can move and transform information, while Power BI is a familiar reporting layer. The technology name matters less than the work: ensure source records are identified, transformations can be reproduced and the output means what users think it means. A report that measures the wrong denominator is not improved by being refreshed more often.

If a warehouse dashboard shows rising returns, the analyst must distinguish returned units, refunded orders and monetary value. These measures may point to different operational problems. Their grain and business definitions need to be agreed before aggregation. Data literacy includes asking whether a reported trend was caused by a change in the underlying activity, a change in capture rules or a join that duplicated certain rows.

Recognize streaming and real-time tradeoffs

Real-time analytics helps when decisions depend on changing information: fraud signals during a payment attempt, sensor readings that indicate an unsafe temperature or website events used to detect an outage. Such systems ingest a flow, process it and expose timely results. Latency matters, but so do correctness and the handling of late or duplicated events. Streaming does not automatically mean that every event arrives exactly once or in the expected order.

Imagine warehouse scanners briefly losing connectivity. A record might arrive after the order status has already changed. If the analytical job assumes arrival time equals business event time, it can show impossible sequences. Windowing, timestamps and clear definitions help interpret late-arriving data. A fundamentals candidate need not implement a full streaming topology, but should understand why an event stream is not just a fast database query.

Compare this with a monthly inventory reconciliation. The organization may prefer a controlled batch load, documented source cutoffs and deliberate validation. Faster processing would not necessarily improve that report. The correct answer follows the question the business asks, the freshness requirement and the cost of errors.

Study by explaining tradeoffs, not memorizing service names

Build a small decision notebook containing several cases: a payment ledger, a customer profile service, scanned contracts, an event stream and a sales-performance model. For each, state the data representation, read/write pattern, consistency and update requirements, and likely storage or analytics strategy. Then change one condition. What if the customer profile must operate in multiple regions? What if the sales figures must reconcile exactly with the finance ledger? The answer should change only where the new requirement matters.

The comparison between AZ-900 and DP-900 can clarify scope: AZ-900 introduces the broader Azure platform and its operating model, while DP-900 concentrates on how data is represented, stored and analyzed. More advanced exams such as DP-800 add implementation depth to SQL-backed application design. DP-900 readiness is visible when someone can explain why a service fits a workload, what it gives up and which remaining questions a solution architect should ask.