Microsoft Azure Data Fundamentals Training Course

Almost every question on DP-900 eventually reduces to one judgment: how much structure does this data have, and therefore where should it live. Microsoft's exam outline opens with exactly this classification, and the rest of the syllabus — relational stores, non-relational stores, analytics services — is organized around it. Learn the three categories precisely and a large share of the exam becomes a lookup rather than a guess.

Structured data

Structured data conforms to a fixed, predefined schema. Every record has the same fields, in the same order, with the same data types. The classic representation is a table: columns define the schema, rows are instances of it. A Customers table with CustomerID as an integer, Name as text, and SignupDate as a date is structured because you cannot insert a row that omits a column or puts text where the integer belongs — the store rejects it.

That rigidity is the point. Because the shape is guaranteed, the storage engine can build indexes, plan queries efficiently, enforce relationships between tables, and validate data at write time. Structured data is what relational databases hold, and the language for working with it is SQL. On Azure that means Azure SQL Database, Azure SQL Managed Instance, SQL Server on Azure Virtual Machines, and the managed PostgreSQL and MySQL services.

The cost of structure is change. Adding a field means altering the schema, which affects every existing row and often every application that reads the table. When your data shape is stable and your integrity requirements are high — financial records, orders, inventory — that cost is worth paying.

Semi-structured data

Semi-structured data carries its own structure with it rather than depending on a schema declared in advance. A JSON document is the canonical example: field names and values travel together in the file, so a reader can discover the shape by parsing the document. Two documents in the same collection may legitimately have different fields.

Consider two product records. One is a book with author and pageCount; the other is a laptop with processor and ramGb. In a relational table you would need either a very wide table full of nulls or a separate table per product type. As JSON documents in the same collection, each simply carries the fields it needs. Semi-structured data also nests naturally — an order document can contain an array of line items inside it, where a relational design would use a second table and a foreign key.

The formats DP-900 associates with semi-structured data are JSON, XML, and YAML. The Azure services are Azure Cosmos DB, which stores documents natively, and Azure Table storage, where each entity carries its own set of properties. The trade-off is that validation moves from the database to the application: nothing stops you writing a document with a misspelled field name, so quality control becomes your responsibility rather than the engine's.

Unstructured data

Unstructured data has no internal organization that a data store can interpret. Images, video, audio, PDFs, scanned documents, and unformatted prose are the standard examples. The bytes mean something, but not something the storage layer can parse, index by field, or query with SQL.

Because you cannot query the contents directly, unstructured data is stored as whole objects and retrieved by name or by metadata attached alongside. On Azure this is Azure Blob storage: you put an object into a container, give it a name, optionally tag it with metadata, and read it back as a stream of bytes. To make the contents searchable you run a separate process over them — an AI service that transcribes audio or extracts text from a scanned form, writing the results into a store that can be queried.

Note the boundary carefully, because DP-900 tests it. A plain text file of prose is unstructured. A CSV file is not — it has rows and columns, and readers treat it as structured or semi-structured depending on how strictly the schema is enforced. The distinguishing question is not the file extension but whether a machine can identify fields without a human explaining the layout.

Why the classification drives the design

Once you can place data in one of the three categories, the storage decision usually follows. Structured data with strong integrity requirements and relationships between entities goes into a relational service. Semi-structured data with varying shape, high write volume, or a need for global distribution goes into Cosmos DB. Unstructured data goes into Blob storage, often into a data lake built on Azure Data Lake Storage Gen2 so that analytics engines can process it in place.

Real systems mix all three. A retail platform might keep orders in Azure SQL Database, product catalog documents in Cosmos DB, and product photography in Blob storage, then bring extracts of all three together in an analytics environment. DP-900 scenario questions frequently describe exactly this mixture and ask which service handles one specific part of it. Answer by classifying the data first and matching the service second, and you will avoid the common mistake of picking a service because it sounds modern rather than because it fits the shape of the data.