DP-203 Develop data processing Practice Question
You are authoring an Azure Databricks notebook that reads Parquet files from Azure Data Lake Storage Gen2 and must write results to a Delta table. Users report that queries against the Delta table return stale data after each notebook run, even though the write succeeds. You need to ensure readers always see the latest committed data. What should you do?
⚠ Common exam trap
The trap here is blaming Delta's commit mechanism for stale reads, when caching in the reader session is the usual culprit.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Ensure the write commits through the Delta transaction log and readers query the table by name, not by a cached DataFrame
Delta Lake provides snapshot isolation via its transaction log, so a committed write is immediately visible to subsequent reads. Stale results typically come from caching a DataFrame or holding an old snapshot rather than from the table itself. Reading the table by name, without a cached DataFrame, ensures the reader resolves the latest committed version at query time.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Ensure the write commits through the Delta transaction log and readers query the table by name, not by a cached DataFrame
Why this is correct
Delta Lake guarantees snapshot isolation through the _delta_log transaction log; a successful commit makes new data visible to new queries. Stale reads usually occur when a DataFrame was cached earlier or when a reader holds an old snapshot. Writing through the log and querying the table by name ensures each read sees the latest committed version.
- ✗
Write the results with overwrite mode to the same Delta table path each run
Why it's wrong here
Overwrite mode replaces the table contents atomically, so readers should see the new data after the commit. If readers still see stale results, the issue is elsewhere, such as a cached DataFrame or a reader pinned to an old snapshot. Overwriting alone neither prevents nor explains stale reads, and it also destroys history if time travel is needed.
- ✗
Convert the Delta table to a Parquet table and rely on the file system for consistency
Why it's wrong here
Parquet tables lack a transaction log, so there is no atomic commit and readers can observe partially written files or inconsistent snapshots. This would make staleness and corruption more likely, not less. The scenario already benefits from Delta's ACID guarantees, so downgrading the format works against the stated requirement.
- ✗
Call refreshTable or invalidate the cache on the reader session after each write
Why it's wrong here
Refreshing metadata helps when the reader's catalog entry is stale, but in Databricks the Delta table metadata is refreshed automatically on read. The typical cause of stale results is a cached DataFrame or a long-lived cluster holding an old snapshot. Manually refreshing is a partial workaround rather than a root-cause fix for the described symptom.
Visual reference
Go deeper
Related to this question
About these practice questions
This DP-203 question is part of Courseiva's 509-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
This DP-203 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-203 exam.