DP-900 Describe an analytics workload on Azure Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Use Azure Data Factory to copy data and manually register the datasets in Purview.

  Why it's wrong here

  Manually registering datasets in Purview after an Azure Data Factory copy records only the existence and schema of the data assets; it does not create the implicit source-to-destination relationship that the copy activity establishes at runtime. Because the registration is decoupled from the actual data movement, Purview cannot derive column-level lineage or understand which pipeline produced a specific output, so lineage remains incomplete. This option lacks the automatic instrumentation that the native ADF–Purview integration provides, making it a fragmented approach for lineage tracking.

• ✓

  Use Azure Data Factory with Purview integration enabled to copy data.

  Why this is correct

  Enabling Purview integration on Azure Data Factory causes every executed copy activity to automatically emit lineage metadata to Purview, including the source and sink datasets and the column-level mappings defined in the activity. This is a first-class, out-of-the-box integration that captures lineage as part of the pipeline run rather than as a separate manual step. The result is reliable, up-to-date lineage without custom code, which is exactly what the data engineering team needs.

• ✗

  Use Azure Databricks to write data and call Purview's Atlas API to update lineage.

  Why it's wrong here

  Calling Purview's Atlas API from an Azure Databricks job is a programmatic, low-level approach that requires custom code to construct lineage entities, relationships, and status updates for every write operation. Purview does not automatically intercept Databricks transformations or write operations unless you build and maintain that instrumentation yourself, and even then, the Atlas API is an internal-facing interface intended for custom lineage solutions rather than routine pipeline telemetry. This option introduces significant development overhead and fragility compared to the native integration, making it a poorer fit for a designed pipeline.

• ✗

  Schedule Purview scans on the data lake after data ingestion.

  Why it's wrong here

  Scheduling Purview scans on the data lake after ingestion captures metadata such as schema, classifications, and glossary terms at rest, but scans cannot see the data movement path from source to destination. Lineage is about how data is transformed and moved between processes, which requires integration with the orchestration engine (e.g., ADF activity-level metadata) to reconstruct the relationship. A scan provides a point-in-time snapshot of data assets, not a causal chain between them, so it cannot satisfy the automatic lineage capture requirement.

Go deeper

Related to this question