DP-600 · Practice set 7 of 8
Dependency Impact Analysis: 10 practice questions
10 free DP-600 practice questions on Dependency Impact Analysis, with an explanation for every answer. Untimed. The full mock exam and the timed version are in the app.
-
Question 1 of 10
What should impact analysis identify before a deployed schema is changed?
- ADownstream consumers that the change might break
- BInternal calculations that return correct values
- CRefresh failures that occurred after deployment
- DGit commits that changed the source definition
Show the answer
Impact analysis is the preventive dependency checkpoint; model validation, version history, and post-deployment troubleshooting answer different questions.
Next → 1 / 10 -
Question 2 of 10
When should impact analysis run for a proposed schema change?
- AAfter consumers report broken content
- BWhile validating internal model calculations
- CAfter completing data freshness troubleshooting
- DBefore making the proposed schema change
Show the answer
The analysis is preventive: it exposes downstream consumers while the schema change is still being considered.
Next → 2 / 10 -
Question 3 of 10
Which capability supports data freshness troubleshooting after deployment?
- ALineage view after deployment
- BSource-control history review
- CPre-change impact analysis
- DSchema comparison before release
Show the answer
Lineage view serves the post-deployment freshness investigation; impact analysis serves the earlier dependency-risk decision.
Next → 3 / 10 -
Question 4 of 10
What is the relevant dependency checkpoint before changing a lakehouse schema?
- ARun XMLA checks for internal measure results
- BRun lineage view for a completed refresh failure
- CRun impact analysis for downstream consumers
- DRun deployment promotion without dependency review
Show the answer
For a lakehouse schema change, impact analysis identifies exposed downstream consumers before the change proceeds.
Next → 4 / 10 -
Question 5 of 10
What should a team review before approving a warehouse schema change?
- ACommit authors listed in version history
- BConsumers exposed by the impact analysis
- CMeasure results returned by XMLA validation
- DFreshness incidents found after deployment
Show the answer
The warehouse decision depends on its downstream consumer exposure; validation and history provide different evidence.
Next → 5 / 10 -
Keep the ones you got wrong
In the app, every question you miss comes back exactly when you’re about to forget it.
-
Question 6 of 10
Which question does dataflow impact analysis answer before a schema revision?
- AWhich calculations have already passed validation?
- BWhich downstream consumers might the revision break?
- CWhich branch contains the approved source files?
- DWhich refresh failed after the revision was deployed?
Show the answer
Impact analysis evaluates consumer exposure from the proposed dataflow schema revision, not model correctness or deployment history.
Next → 6 / 10 -
Question 7 of 10
How do impact analysis and lineage view differ in the lifecycle?
- AImpact analysis repairs refreshes; lineage view approves proposed schema changes
- BImpact analysis records commit history; lineage view compares model schemas
- CImpact analysis validates calculations; lineage view promotes approved content
- DImpact analysis precedes schema changes; lineage view troubleshoots deployed freshness
Show the answer
The distinction is temporal and operational: assess downstream risk before change, then use lineage for deployed freshness investigation.
Next → 7 / 10 -
Question 8 of 10
A shared semantic model column will be renamed, and several reports may consume it. What should the team do first?
- ARun impact analysis and review downstream consumers
- BUse lineage view only after reports have broken
- CRename the column and wait for refresh failures
- DPromote the model and review its commit authors
Show the answer
The proposed semantic-model schema change creates dependency risk, so the team should identify exposed report consumers before renaming the column.
Next → 8 / 10 -
Question 9 of 10
A warehouse team plans to remove a field but cannot identify every consuming item. Which action addresses the immediate risk?
- APerform impact analysis before removing the field
- BRemove the field and inspect later refresh failures
- CValidate semantic-model measures without reviewing dependencies
- DPromote the change through deployment before assessing consumers
Show the answer
The uncertainty is downstream exposure from a warehouse schema change, which impact analysis addresses before removal.
Next → 9 / 10 -
Question 10 of 10
A deployed report is stale after its upstream dataflow changed. The change is complete, and the team must trace freshness. What should it use?
- AVersion history as the downstream dependency map
- BLineage view for the deployed freshness issue
- CDeployment promotion as the freshness diagnostic
- DImpact analysis as approval for the completed change
Show the answer
Because the issue is post-deployment data freshness, lineage view is the operational troubleshooting tool; impact analysis belonged before the dataflow change.
Next → 10 / 10 -
You’ve finished this set
That’s 10 questions on Dependency Impact Analysis. In the app the ones you miss come back exactly when you’re about to forget them.
The whole course, on your phone
Lessons you can read, audio you can listen to on the way to work, and practice that remembers what you got wrong.