Free DP-900 practice test

What makes a database a database is its management layer: query engines, indexing, concurrency control, and transactional integrity over the data it holds. A file store persists blobs/files without interpreting them. Option B is backwards-ish nonsense — databases store many types. Option C fails for any workload needing queries or transactions. Option D is obviously false (Azure SQL, Cosmos DB).

Data engineers design and operate the pipelines and integration processes that move and transform data across the estate. Backups, availability, and security administration (D) belong to the database administrator; reports and visualizations (B) to the data analyst. Option A is not a data-platform role responsibility at all.

Parquet is a columnar format: values for each column are stored together, so an analytical query reading 3 of 200 columns touches only those columns' data — with excellent compression. CSV (B) and JSON (D) are row-oriented text formats; XML (C) is a verbose hierarchical text format. None of the other three offers columnar storage.

Data flows from ingestion (capturing from sources), through processing/transformation, into analytical storage (data lake and/or warehouse), and finally into semantic models, reports, and visualizations. The other orders put consumption before the data exists or aren't analytics lifecycles at all.

Data analysts turn data into insight: profiling, modeling for analysis, and building reports and dashboards. Infrastructure provisioning (C) and server patching (B) sit with platform/DBA roles; large-scale ingestion pipelines (D) are the data engineer's domain.

JSON documents with varying, optional, or nested fields are the classic example of semi-structured data: there is structure (keys, values, nesting) but no rigid schema that every record must follow. Structured/relational data (A, D) requires a fixed schema. Unstructured (C) would mean no consistent internal organization at all, like raw images or free-text files.

Because the price exists once, updating it can't leave stale copies scattered through order records — the update anomaly normalization exists to prevent. Normalization doesn't speed full scans (A); if anything joins add work. Options B and D have nothing to do with schema normalization.

Azure offers managed PaaS versions of the popular open-source relational engines: PostgreSQL, MySQL (and MariaDB). Cosmos DB and Table Storage (A) are NoSQL. Blob and Files (C) are storage services, not databases. SQL Managed Instance (D) hosts Microsoft SQL Server, which is not open-source.

Relational integrity comes from keys: each customer row is uniquely identified by a primary key, and the orders table stores that value as a foreign key, which the engine can enforce. Option B duplicates data — exactly what normalization eliminates. Options C and D are organizational conventions with no enforcement whatsoever.

Data Definition Language manipulates the schema — tables, views, indexes — while Data Manipulation Language works with the rows inside them. Option C swaps the definitions. Option A invents a NoSQL/relational split that doesn't exist. Option B is false — the distinction is fundamental SQL vocabulary the exam expects.

Normalization organizes data so each fact is stored once — splitting entities into separate related tables — which prevents duplication and the inconsistencies that arise when the same fact must be updated in many places. It can actually make some reads slower (more joins), so option D is wrong. Options A and B are unrelated to normalization entirely.

Blob storage is Azure's object store for unstructured files at massive scale, with HTTP access and lifecycle policies that transition blobs across Hot → Cool → Archive tiers automatically. SQL Database (B) isn't built to store terabytes of video. Table Storage (C) stores small key-value entities, not media. Cosmos DB (D) has per-item size limits, making it wrong for video files.

Gremlin is Cosmos DB's graph API: data as vertices and edges, queried by traversing relationships — ideal for social graphs, recommendations, and network analysis. Flat file exports (B) belong in Blob/data lake storage. File shares (A) are Azure Files. Warehouse aggregation (C) is an analytical workload for Synapse/Fabric-style engines.

Azure Files was built for exactly this: the application keeps using an SMB path while the share lives in Azure — no code changes. Cosmos DB for Table (B) is a NoSQL API, requiring a rewrite. Blob via REST (C) would require replacing file I/O with API calls — code changes the requirement forbids. Option D keeps the hardware they're trying to retire.

Reacting within seconds to a continuous event stream requires real-time stream processing — Azure Stream Analytics (or Fabric's Real-Time Intelligence) is purpose-built for it. Nightly batch (A), monthly Excel (D), and quarterly reloads (C) all introduce latency measured in hours to months, far too slow for second-level anomaly detection.

Line charts are the canonical way to show a measure changing over a continuous time axis, making trends and seasonal patterns visible. A pie chart (B) shows composition at one moment, not change over time. A card (C) shows one value with no trend. A treemap (D) shows hierarchical proportions, not time series.

Fact tables store the measurable events (sales amounts, counts) and foreign keys to dimensions; dimension tables store the descriptive context (product name, region, calendar attributes) you slice and dice by. Option C reverses the roles. Option D is false. Option B is the opposite of how a star schema works — the joins are the whole point.

Second-level dashboard freshness requires a real-time (hot path) pipeline: streaming ingestion and real-time analytics feeding live visuals — Fabric Real-Time Intelligence or Stream Analytics into Power BI streaming datasets. Nightly batch (B) and weekly PDFs (C) are far too slow. An OLTP schema with no reporting layer (D) isn't an analytics solution at all.

A star schema places a central fact table of measurable events (sales with quantity and revenue) surrounded by dimension tables that describe the context (product, customer, date) — the standard analytical warehouse design. Full normalization (B) is an OLTP goal that adds joins analytics tries to avoid. Key-value (C) and graph (D) are non-relational models for different workloads.

Pie/donut charts show parts of a whole — each slice's share of the total — which matches proportion-of-total questions. Line charts (B) show trends over a continuous axis like time. Scatter plots (C) show correlation between two numeric variables. A gauge (D) shows a single value against a target, not a category breakdown.