DP-203 Develop data processing Practice Question
Your team is developing a data processing solution that uses Azure Databricks to transform streaming data from Azure Event Hubs. The transformation includes joining the stream with a static reference table stored in Azure Data Lake Storage Gen2. You need to implement the join efficiently. Which approach should you use?
⚠ Common exam trap
DP-203 often tests the misconception that stream-stream joins are always required for joining streaming data, but when one side is static, a broadcast join is more efficient and simpler.
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
✓
Use a broadcast join with the static DataFrame loaded from Delta Lake
A broadcast join is the most efficient approach when joining a streaming DataFrame with a static reference table. The static table is loaded as a DataFrame from Delta Lake, and Spark broadcasts it to all executors, avoiding a shuffle of the large streaming data. This is ideal because the static table is typically small enough to fit in memory, and it eliminates the need for watermarking or state management required in stream-stream joins.
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 a watermark on both sides and perform a stream-stream join
Why it's wrong here
Watermarking both sides is meaningless for a static reference table, which has no event-time column, and forces unnecessary stateful processing. It is tempting because watermarks are the correct approach when joining two live streams where late-arriving events must be bounded.
- ✓
Use a broadcast join with the static DataFrame loaded from Delta Lake
Why this is correct
The static reference table is small, so broadcasting it to every executor node eliminates the shuffle required by a sort-merge join. Loading it from Delta Lake gives a cached, versioned DataFrame, making the stream-to-static join efficient.
- ✗
Use foreachBatch to micro-batch the stream and perform a batch join
Why it's wrong here
foreachBatch re-executes a batch join per micro-batch, discarding Databricks' native stream-static join optimisation and adding latency and overhead. It is tempting because foreachBatch is the correct approach when the join logic requires operations unsupported in continuous streaming, such as MERGE or non-deterministic writes.
- ✗
Use a stream-stream join by converting the static table to a stream
Why it's wrong here
Converting the static table to a stream forces a stateful stream-stream join, requiring watermarking and state retention for data that never changes. It is tempting because stream-stream joins are the correct approach when both sides are genuinely continuous event streams needing time-window correlation.
Go deeper
Related to this question
Learn chapter
Orchestrate Data Movement and Transformation
Key term
Azure Databricks
Azure Databricks is a fast, easy, and collaborative Apache Spark-based analytics platform optimized for Azure that lets data teams prepare data, run machine learning models, and build data pipelines using a single workspace.
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.