Databricks-DE-Pro Data Transformation, Cleansing, Quality Practice Question
Exhibit
{
"type": "Table",
"constraints": {
"check": "price > 0",
"not_null": ["id", "transaction_date"]
}
}Refer to the exhibit. A Data Engineer is attempting to merge data into a table with these constraints defined. If the incoming batch contains rows that violate these rules, what is the default behavior of the Delta Lake engine during the merge operation?
⚠ Common exam trap
Candidates often believe that Delta Lake will silently drop, quarantine, or ignore invalid rows during a merge operation, missing the strict ACID transaction failure behavior.
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
✓
The transaction fails entirely, and no changes are committed to the Delta table.
Delta Lake maintains strict ACID compliance. When a transaction violates defined CHECK or NOT NULL constraints, the engine throws an error, and the entire transaction is rolled back. This behavior prevents data corruption and ensures that only valid state transitions occur. This is essential for maintaining data integrity in complex ETL pipelines where maintaining a 'known good' state is preferred over partial updates or silent failures.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The engine silently ignores the invalid rows and completes the merge for valid records only.
Why it's wrong here
Delta Lake prioritizes data integrity and does not perform silent drops by default. Any violation of a table constraint results in the failure of the atomic transaction. This prevents the silent loss of data and forces engineers to address the underlying quality issue rather than allowing corrupt data to propagate.
- ✓
The transaction fails entirely, and no changes are committed to the Delta table.
Why this is correct
Constraints in Delta Lake are hard requirements. If an operation violates these rules, the commit fails, and the transaction is aborted. This guarantees that the table remains in a consistent state and prevents invalid data from entering the storage layer, which is crucial for maintaining reliable audit trails and reports.
- ✗
The invalid rows are automatically routed to a hidden sidecar table for later review.
Why it's wrong here
Delta Lake does not automatically create sidecar tables for rejected rows during standard Merge operations. While Delta Live Tables supports this via 'expectations' with 'fail' or 'drop' policies, standard SQL merge operations require explicit handling of invalid data or will simply fail the entire transaction if constraints are violated.
- ✗
The engine automatically updates the invalid rows to the default column value.
Why it's wrong here
Delta Lake does not modify incoming data to satisfy constraints automatically. Attempting to insert a null value into a column marked as NOT NULL will trigger a runtime exception. The engine assumes the input data must be cleaned before ingestion or that the logic should be handled by the application code.
About these practice questions
One of 267 original Databricks-DE-Pro practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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-DE-Pro 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-DE-Pro exam.