Databricks-Spark-Assoc Structured Streaming Practice Question
You have a Structured Streaming job that reads from a Kafka topic and writes to a Delta table. You need to ensure that the job processes each record exactly once, even after failures. Which of the following should you configure?
⚠ Common exam trap
The trap here is assuming that any Delta table property or deduplication logic automatically ensures exactly-once semantics, when actually checkpointing is the core mechanism.
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
✓
Set the `checkpointLocation` option to a reliable storage location.
Exactly-once processing in Structured Streaming relies on checkpointing to record progress and idempotent sinks to avoid duplicates. The checkpoint location stores offset information, allowing the query to resume without reprocessing. Delta Lake supports idempotent writes when used with checkpoints. Other options like Change Data Feed or manual deduplication do not provide the necessary fault tolerance.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Configure the Kafka source with `startingOffsets` set to `earliest`.
Why it's wrong here
Setting `startingOffsets` to `earliest` only determines where to start reading when the query first starts or when no checkpoint exists. It does not provide fault tolerance or exactly-once processing. On restart, if a checkpoint exists, this setting is ignored. Therefore, it does not ensure exactly-once semantics.
- ✗
Enable idempotent writes by setting the Delta table property `delta.enableChangeDataFeed` to true.
Why it's wrong here
Enabling Change Data Feed allows reading change data from the Delta table but does not provide exactly-once semantics for streaming writes. It tracks row-level changes but does not deduplicate or manage offsets. Exactly-once requires checkpointing and idempotent writes, which are not provided by this property alone. Thus, it does not meet the requirement.
- ✗
Use `foreachBatch` to manually deduplicate records based on a unique key.
Why it's wrong here
While deduplication can help avoid duplicate processing, it does not by itself guarantee exactly-once semantics. You would still need to track offsets and ensure that the deduplication logic is applied atomically with the write. Without checkpointing, a failure could cause reprocessing of already processed data. Thus, this approach alone is insufficient.
- ✓
Set the `checkpointLocation` option to a reliable storage location.
Why this is correct
The checkpoint location stores the progress information of the streaming query, including which offsets have been processed. On restart, Spark uses this to resume from where it left off, ensuring each record is processed exactly once. Combined with idempotent sinks like Delta Lake, this provides end-to-end exactly-once guarantees. Therefore, setting a checkpoint location is essential.
About these practice questions
This Databricks-Spark-Assoc question is part of Courseiva's 295-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 Databricks exam blueprint
This Databricks-Spark-Assoc practice question is part of Courseiva's free Databricks 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 Databricks-Spark-Assoc exam.