DP-900: Choosing the Right Azure Data Services

DP-900, Microsoft Azure Data Fundamentals, establishes a working vocabulary for data stored, processed, and analyzed in cloud services. Its July 21, 2026 study guide includes core data concepts, relational data considerations, non-relational alternatives, analytical workloads, and the broad roles of Azure and Microsoft Fabric services. The exam is appropriate for people entering data-focused work, but the intended understanding goes beyond repeating terms such as SQL, NoSQL, and data lake. Candidates should explain why an application needs certain guarantees, how information moves from transactions to analytics, and which cloud services support those different responsibilities. The fundamentals credential is not a prerequisite for every specialist examination and does not imply advanced database-administration skills.

Begin with entities, records, and data types

Structured records use defined fields and types; semi-structured formats such as JSON allow more flexible representation; unstructured content includes many documents, images, and media files. These categories describe characteristics of information rather than the quality of its management. A document can be rigorously governed and a relational table can contain inaccurate values. Data types matter because they determine how values can be stored and compared. Treating money as a floating-point approximation can create rounding problems, while storing dates as inconsistent text complicates analysis across regions and time zones. A foundational data worker should be able to identify keys, missing values, duplicates, and the meaning of each field before choosing a storage engine.

A database record may represent an entity's current state or an event in its history. Confusing those patterns creates reporting mistakes: a customer's present address is not necessarily the address at the time of a past order. Primary keys identify records and foreign keys connect related entities in relational models. Constraints can prevent impossible combinations such as a missing required order reference. Good data design also documents what values mean and how they were collected. Two applications can both contain a field called “status” while using incompatible definitions; integrating them requires explicit interpretation rather than assuming shared spelling means shared semantics.

Distinguish transaction processing from analytics

Online Transaction Processing systems support frequent small reads and writes that update current business state. Online Analytical Processing emphasizes aggregations and comparisons across many records to answer questions over time. The same system can support some of both, but their performance patterns and correctness needs differ. A retail checkout should not depend on a long-running sales dashboard query, and a warehouse-level profitability analysis may need data from sources beyond the transactional database. Understanding workload purpose is more important than memorizing which service has a “warehouse” label. Data movement and freshness requirements are part of the design.

An analytical system often combines ingestion, transformation, storage, a semantic layer, and visualization. Batch ingestion suits periodic datasets; streaming can handle continuously arriving events, subject to lateness and duplicate handling. A report may show yesterday's complete figures while a live operations view shows a more current but still provisional estimate. Both can be useful if the distinction is communicated. A learner should ask what happens when a source sends corrected values or an event arrives late. A successful pipeline status does not guarantee that the resulting metric reconciles with financial records or business expectations.

Use relational data services for structured constraints

Relational systems represent data in tables with defined columns, relationships, and query operations expressed through SQL. Azure SQL Database, Azure SQL Managed Instance, and SQL Server deployed on virtual machines offer different models of operational responsibility and compatibility. An organization choosing among them should consider its application dependencies, desired control over the database engine and operating system, resilience needs, and staff capabilities. Azure SQL Database is not simply a virtual machine with a different name; platform-managed capabilities change aspects of provisioning, patching, and service operations. Conversely, a migration may require the compatibility of another SQL Server hosting model.

SQL concepts include selecting rows, filtering, joining related tables, grouping results, and inserting or updating records while preserving transaction consistency. A query asking for sales by region requires a correct relationship between orders, customers, and region definitions. If a join accidentally multiplies rows, the report may look plausible but be wrong. Administrators also care about indexing, backups, access permissions, and performance, although DP-900 requires conceptual recognition rather than expert tuning. The role-specific DP-300 database administration path is an appropriate next step for people who need to operate Azure SQL systems, not merely identify them.

Compare document, key-value, and object storage

Non-relational systems support data models and access patterns that do not always resemble tables joined through SQL. Azure Cosmos DB can serve document-oriented and other supported distributed data scenarios, with partitioning and consistency decisions that matter for scale. A document store may represent a product with variable attributes naturally, but it does not eliminate requirements for identity, validation, and appropriate authorization. Key-value access patterns suit cases where an application looks up information through a known key. The learner should recognize that the label NoSQL does not mean “no structure” or “no query language.” A flexible schema still benefits from controlled evolution and data contracts.

Azure Blob Storage stores objects such as documents, media, and logs, while Azure Files addresses managed file-sharing needs and Azure managed disks support virtual machines. These are different services with different access methods. Keeping a large file inside a relational row is not always the best choice when object storage can handle that content separately. Conversely, blob storage does not automatically offer the relational transactions required for processing account balances. Durability options, retention, access control, and cost depend on the service and configuration. An analyst should be able to justify why each information type is stored where it is, rather than using one storage product indiscriminately.

Recognize warehouses, lakes, and Fabric capabilities

An analytical data warehouse often organizes curated information for structured querying and business intelligence. A data lake can retain files in multiple formats for engineering and analytics workflows. Lakehouse approaches combine elements of file-based storage and analytical table management, aiming to reduce unnecessary movement between systems. Microsoft Fabric integrates storage and data workloads across engineering, warehousing, real-time intelligence, and Power BI experiences, but integration does not remove the need to define authoritative sources, permissions, and semantic meaning. Azure Databricks supports data engineering and analytical scenarios, while other Azure data services perform related but different functions.

A simple architecture example makes the distinction clear. A commerce system records orders in a transactional database, exports changes into an analytical environment, transforms raw events into trustworthy revenue facts, and publishes a semantic model used by reports. The operational source remains authoritative for order state; the analytical model provides consistent business interpretation. Fabric lakehouse architecture provides a natural bridge for those who later study data engineering or analytics. DP-900 requires recognizing the purpose of these stages rather than independently managing the full pipeline.

Understand real-time processing and data quality

Streaming systems process incoming events that may arrive out of order, be repeated, or be delayed by network and producer failures. A count of sensor alerts in the last minute might need a defined treatment of duplicates and late events. Batch processing is often easier to reconcile for financial reports, while streaming may support operations that require quick feedback. Neither is intrinsically superior; the choice follows freshness, completeness, and cost requirements. A service that advertises real-time processing still needs monitoring for lag and a strategy for consumer restarts. Learners should identify which conclusions are preliminary and which rely on final validated data.

Quality has several dimensions: accuracy, completeness, timeliness, consistency, uniqueness, and fitness for a business purpose. A report showing zero sales may indicate no sales or a missing feed; the interpretation matters enormously. Data governance adds ownership, lineage, retention, access control, and sensitivity classification. These are not just compliance details. Without lineage, a change to the source system can silently invalidate several reports; without ownership, nobody knows who may approve a correction. A foundational student should understand why trustworthy analytics require these controls before learning how specialized tools implement them.

Connect Power BI concepts to decisions

Power BI uses data models, relationships, measures, and visuals to help users analyze information. Selecting a visual starts with the question: trend, composition, comparison, distribution, or relationship. A line chart often fits a time series, while a table may be better for precise record-level review. A confusing color scale or unlabeled axis can mislead even when the underlying data is correct. A semantic model should provide consistent definitions, so multiple reports do not calculate “active customer” differently. Access restrictions must apply to underlying data as well as the visible dashboard presentation.

One practical DP-900 exercise is to describe the data journey of a neighborhood clinic's appointment system without using actual patient information. Identify transactional records, semi-structured form responses, stored documents, reporting needs, and which staff roles may see sensitive information. Decide when batch analysis is sufficient and when immediate operational alerts would matter. Explain how a correction to an appointment status reaches later reports and how a missing daily feed would be detected. The objective is to connect data concepts to reasonable service choices, not to write production code for every technology named in the exam. A coherent architecture explanation demonstrates real foundational understanding.

A final distinction worth practicing is descriptive versus predictive analysis. Descriptive reporting explains what happened using recorded data; predictive approaches estimate an outcome not yet known. Both depend on valid sources, but the second also requires evaluation of model performance and uncertainty. A dashboard can accurately summarize last month's sales without predicting next month's demand. Explaining this difference helps prevent confusion between business intelligence tools and the machine-learning services that may consume similar datasets.