Free Databricks Certified Data Engineer Professional - October 9 onwards Sample Questions

Correct answers: A, B — `GRANT USAGE, CREATE ON SCHEMA main.analytics` plus `GRANT USAGE ON CATALOG main` to the analyst, enabling new function registration.; `GRANT EXECUTE ON FUNCTION main.analytics.existing_func` to the analyst, enabling the analyst to call the function someone else owns.

• A. Registering a new function requires `USAGE` and `CREATE` on the target schema together with `USAGE` on the containing catalog; without both, the registration attempt fails with a permission error.
• B. Calling a function owned by another principal requires an explicit `EXECUTE` grant on that function; ownership of the schema or catalog alone does not confer the right to run someone else's function.
• C. `MODIFY` is not the privilege that governs invoking a function; running a function is controlled by the `EXECUTE` privilege, and `MODIFY`-style grants do not substitute for it.
• D. Granting metastore-wide `ALL PRIVILEGES` is a far broader change than needed for either failure and is not the targeted grant Unity Catalog uses to resolve schema-level or function-level permission errors.
• E. Transferring ownership of the whole schema is unnecessary and overly broad just to let one analyst create functions there, and it still would not resolve the separate failure to call another owner's existing function.
• F. `SELECT` is a table- and view-level privilege; it has no effect on the ability to invoke a function, so granting it on the schema would not resolve either reported failure.

Correct answer: A — Point the bundle's `whl` library entry at a workspace file or Unity Catalog volume path, since storing library files in the DBFS root is deprecated and disabled by default on Databricks Runtime 15.1 and above.

• A. Storing library files in the DBFS root is deprecated and disabled by default starting with Databricks Runtime 15.1, so a `whl` entry pointing at a `dbfs:/` path stops resolving on those runtimes. Moving the wheel to a workspace file or Unity Catalog volume path is the supported replacement location.
• B. There is no `dbfs_root_enabled` cluster spec setting; Databricks Runtime 15.1 disables DBFS root library storage by default rather than gating it behind a flag that jobs can re-enable, so adding this setting would not fix the failure.
• C. Downgrading the runtime does not address the underlying storage-location problem and abandons current runtime features solely to work around a deprecation; it also misstates which runtimes support wheel installs from arbitrary locations.
• D. Maven coordinates resolve Java or Scala artifacts from a Maven repository and are not a valid packaging format for a Python wheel, so repackaging the wheel this way does not bypass the DBFS root restriction or make the library installable.

Correct answer: A — Declare `warehouse_size` once under the top-level `variables` block, then override it under `targets.dev.variables` and `targets.prod.variables` with the size for each.

• A. Declaring the variable once and overriding it per target is the intended pattern for values that should differ by environment; the job definition stays single-sourced while `dev` and `prod` each substitute their own size at deploy time.
• B. Splitting into two differently named variables and picking between them based on the git branch adds indirection the bundle format does not need, since target-scoped variable overrides already solve this without branch-sensitive logic in the job definition.
• C. Maintaining two near-duplicate job files defeats the goal of a single definition; `include:` also loads all matched files unconditionally rather than selecting one based on the active target.
• D. The `artifacts` block configures how build artifacts like wheels are produced; it does not host bundle variables, and variable overrides belong under each target's `variables` key instead.

Correct answer: A — The `dlt` module is replaced by `pyspark.pipelines`, commonly imported as `dp`; existing `import dlt` pipeline code keeps running unchanged, but Databricks recommends migrating to `dp` decorators such as `@dp.table`.

• A. This correctly describes the rebrand: `pyspark.pipelines`, imported as `dp`, is the current recommended API, replacing the `@table`/`@view` decorators formerly imported from `dlt`, while existing `dlt`-based pipeline code continues to run without any required migration.
• B. The `dlt` module was not removed and existing pipelines built with `import dlt` continue to run without modification; Databricks recommends adopting the new names going forward, but no rewrite is required for old code to keep working.
• C. The distinction between `dlt` and `pyspark.pipelines` is not a SQL-versus-Python split; both relate to the Python API naming, and SQL pipeline definitions are a separate, unaffected syntax, so this description misstates the change entirely.
• D. The decorator rename did not introduce a new physical dataset type; `@dlt.table` and `@dp.table` are the old and new names for the same underlying streaming-table concept, so mixing them does not produce two independent copies of a table.

Correct answer: B — A streaming table, because it processes each newly arrived record exactly once through incremental append-mode computation, matching the append-only source at low latency and cost.

• A. Materialized views recompute results as needed against the current state of the source, which is useful for changing or joined data but wastes compute reprocessing an append-only stream that never needs a full recalculation.
• B. A streaming table is the correct choice here because it maintains a streaming flow over an append-only source, so Lakeflow processes only the newly arrived clickstream files each micro-batch instead of recomputing history, which minimizes both latency and compute cost.
• C. Checkpoints are what let a streaming table track which records it already processed exactly once; disabling them would break incremental processing and force reprocessing, which is the opposite of the low-cost goal.
• D. Materialized views do not use continuous refresh to force full historical joins for ordering; continuous mode only controls how often the pipeline checks for new data, and this description misrepresents how materialized views compute results.

Correct answer: B — The suggestion cannot be applied, because serverless notebooks only support Performance Optimized mode, built for low-latency, always-warm interactive sessions.

• A. Standard performance mode exists for Lakeflow Jobs and Lakeflow Spark Declarative Pipelines, but it is not offered as a selectable option for serverless notebooks, so this evaluation misstates what's configurable.
• B. Serverless notebooks are restricted to Performance Optimized mode precisely because interactive sessions need warm, low-latency compute, which correctly explains why the teammate's suggestion isn't something the analyst can turn on.
• C. Serverless compute does support notebooks as one of its core workload types, so claiming notebooks require classic compute misrepresents the platform's current capabilities.
• D. The memory tier and the performance mode are independent settings in the notebook's Environment panel, so enabling High memory has no bearing on which performance mode is selectable.

Correct answer: C — Complete

• A. Append mode only writes new rows that will never change again, such as finalized windows once the watermark has passed, and it does not rewrite the full result table on each trigger.
• B. Update mode writes only the rows whose aggregate value changed since the last trigger, which is more efficient than a full rewrite but is not what this description asks for.
• C. Complete mode rewrites the entire result table to the sink after every trigger, which requires retaining full aggregation state indefinitely and matches the behavior described.
• D. Continuous is a low-latency processing mode, not an output mode, so it does not fit alongside append, update, and complete as an answer to this question.

Correct answers: A, B — `AUTO CDC INTO` consumes a continuous stream of row-level events, such as insert, update, and delete records emitted by a CDC log or message bus.; `AUTO CDC FROM SNAPSHOT` is designed for sources that periodically expose a full table snapshot rather than a stream of discrete change events.

• A. `AUTO CDC INTO` is the API built around an incoming stream of discrete change events, matching sources like a CDC log or a message bus that emit one record per insert, update, or delete.
• B. `AUTO CDC FROM SNAPSHOT` targets sources that only ever expose a full point-in-time snapshot rather than a change feed, and it works by diffing successive snapshots to derive the effective inserts, updates, and deletes.
• C. The availability is reversed from this claim: `AUTO CDC INTO` is supported in both SQL and Python, while `AUTO CDC FROM SNAPSHOT` is the one restricted to the Python interface only.
• D. An explicit operation-type column is only needed to identify which rows represent deletes via `APPLY AS DELETE WHEN`; ordinary insert and update rows do not require such a column, so this is not a universal requirement of every incoming row.
• E. Tables produced by Lakeflow pipelines, including those written by either CDC API, are Delta tables managed as Unity Catalog streaming tables; external Iceberg access is an optional add-on via table properties, not a restriction that excludes Unity Catalog governance.

Correct answer: A — Grant `USE CONNECTION` on the connection to each group, then grant `USE CATALOG` plus `SELECT` on just the one foreign catalog assigned to that group.

• A. `USE CONNECTION` lets a principal query through catalogs that reference the connection without exposing the stored host, port, or secret values, and scoping `USE CATALOG`/`SELECT` to just one foreign catalog per group keeps each group limited to its assigned data without letting any group create new catalogs.
• B. Granting `CREATE FOREIGN CATALOG` would let every group independently create catalogs from the shared connection, which violates the requirement that only the admin controls how many foreign catalogs exist.
• C. `ALL PRIVILEGES` on the connection includes catalog-creation and ownership-transfer rights well beyond read access, and connection-level options such as the stored credential remain outside what any grant exposes to a non-owner querying through it, but the privilege scope here is far broader than required and risky to hand to three separate groups.
• D. Transferring `OWNER` hands full control of the connection, including the ability to alter its credentials and drop it, to a group member — a much larger blast radius than the read-only, catalog-scoped access the scenario calls for.

Correct answer: A — Change tracking and CDC are not supported on SQL Server read replicas, so the connector must point at the primary instance instead.

• A. SQL Server's change tracking and CDC features are only available against the primary instance; secondary replicas cannot serve as a CDC source, so the connector must be pointed at the primary regardless of its available capacity.
• B. Lakeflow Connect supports SQL Server across on-premises deployments, EC2, Azure VMs, Azure SQL, and Amazon RDS, so the connector is not restricted to Azure-hosted deployments.
• C. Authentication is handled through the Unity Catalog connection's stored credentials and is independent of whether the target instance is primary or secondary; the failure here is about CDC support, not authentication.
• D. Network reachability is a separate concern from CDC support; even with working connectivity, change tracking and CDC simply are not exposed on secondary replicas.

Correct answer: A — `variant_get(raw, '$.store.bicycle[0].price')`

• A. This path string mirrors the shorthand exactly: it navigates into the `store` object, then `bicycle`, indexes the first array element, and finally reads `price`, matching the intended nested lookup field for field.
• B. This path swaps the array index and the field name, indexing into `price` rather than into `bicycle`, so it does not describe the same nested location as the original shorthand expression.
• C. This path string omits the required `.` immediately after the leading `$` root marker, which makes it a malformed JSON path rather than an equivalent way of expressing the same navigation.
• D. This path wraps the `bicycle` key in unquoted brackets as if it were a variable or index rather than a field name, which does not correctly express navigating into the `bicycle` object key.

Correct answers: A, D, E — A row is excluded from `silver_line_items` if it violates either the `valid_price` rule or the `valid_qty` rule.; Both `valid_price` and `valid_qty` are tracked as separate named expectations in the pipeline's data quality metrics.; Replacing `expect_all_or_drop` with `expect_all` would cause violating rows to be written to the table while still recording violation counts for both rules.

• A. The or-drop group decorator removes a row if it fails any one of the rules in the dictionary, so violating either the price rule or the quantity rule is enough to exclude that row from the target table.
• B. Rolling back the entire update on the first violation describes the fail variant of the group decorator, not the drop variant, which instead removes offending rows and keeps the update running.
• C. The or-drop decorator drops a row as soon as it fails any single rule in the set, so a row violating only one of the two rules is still excluded rather than being written through.
• D. Each key in the rules dictionary becomes its own named expectation, so the pipeline's data quality metrics report violation counts for `valid_price` and `valid_qty` independently.
• E. The plain warn variant of the group decorator keeps every row in the output regardless of rule failures while still tallying how many rows violated each named rule, unlike the drop variant used in the snippet.
• F. The dictionary keys are just user-chosen expectation names for tracking purposes and have no requirement to match any column name in the source table.

Correct answer: A — `ai_query('system.ai/llama-4-70b', 'Classify sentiment as positive, negative, or neutral: ' || ticket_text) AS sentiment`

• A. Foundation model endpoints take a single STRING request; concatenating an explicit instruction with the column value produces a prompt the model can act on to return a sentiment label.
• B. A named_struct request is the pattern for custom model-serving endpoints that expose named input features; pay-per-token foundation model endpoints expect a plain STRING prompt, so this call would not classify correctly.
• C. Passing the raw column value with no instruction text gives the model nothing to classify against, so even though the returnType and failOnError syntax is valid, the model has no directive to produce a sentiment label.
• D. `model_input` is not a recognized ai_query parameter name; ai_query's parameters are `endpoint` and `request`, so this call raises an error rather than running.

Correct answer: A — `GROUP BY ROLLUP (region, product_category)`, which produces the detail-level groups plus subtotals for `region` and a grand total, following the hierarchical order of the listed columns.

• A. Correct. `ROLLUP (region, product_category)` produces the full detail grouping, then a subtotal per `region` (dropping `product_category`), then a single grand total, matching the hierarchical requirement described without needing a `product_category`-only subtotal.
• B. Incorrect for this requirement. `CUBE` also produces a `product_category`-only subtotal (with region dropped) that was not requested, so it returns a superset of the needed groupings rather than the specific hierarchical set the report calls for.
• C. Workable but not the right construct here. Manually unioning three separately grouped queries can reproduce the same rows, but it requires three separate scans and aggregations and more code than the purpose-built rollup syntax designed for exactly this hierarchical subtotal pattern.
• D. Incorrect. Spark SQL's `GROUP BY` clause has no `WITH TOTALS` syntax; that construct does not exist in Spark SQL and the query would fail to parse.

Correct answer: A — Set an autotermination window on the clusters and update `owned_by` to the team that uses them, so idle time stops accruing and future usage attributes correctly.

• A. Enforcing autotermination directly removes the root cause of idle spend, and correcting `owned_by` restores accountability so the team responsible can monitor and control the cluster's cost going forward.
• B. System tables are read-only records generated by the platform from actual account activity; deleting rows from them is not a supported operation and would not stop the underlying cluster from continuing to accrue real charges.
• C. Raising `min_workers` forces the autoscaler to keep more workers running at all times, which increases baseline cost rather than reducing it, and does nothing to address a cluster that never terminates.
• D. `system.billing.list_prices` is a reference table of historical SKU rates published by Databricks; it cannot be written to in order to negotiate a lower price, and utilization data has no mechanism to trigger a repricing through this table.

Correct answer: A — Run `SELECT * FROM event_log('<pipeline_id>')` in a notebook attached to a cluster or SQL warehouse, reading the pipeline's hidden Delta event log table directly by ID.

• A. The `event_log()` table-valued function reads the pipeline's default hidden event log table by pipeline ID with no advance setup, which matches the no-configuration-change requirement.
• B. Publishing the event log to a visible catalog table is an optional convenience for governed access, not a prerequisite for querying it, so this adds an unnecessary configuration step.
• C. `system.lakeflow.pipelines` holds pipeline-level metadata for billing and auditing rather than per-flow progress or expectation metrics, so it cannot answer this event-level question.
• D. The Jobs API reports task and run status for jobs, not the flow-level `data_quality` metrics that only appear inside the pipeline event log's `flow_progress` events.

Correct answers: A, B, E — `system.lakeflow.job_run_timeline` aggregates run history across every workspace in the same region into one queryable table, which the `listruns` endpoint cannot do since it is scoped to a single workspace per call.; `system.lakeflow.job_run_timeline` can be joined directly with `system.billing.usage` in ordinary SQL, whereas correlating REST API run objects with billing data requires the caller to write custom stitching logic.; Repeatedly polling `listruns` for a 90-day window requires paging through and re-fetching runs already retrieved on a prior poll, since the endpoint has no native cursor for returning only rows changed since the last call.

• A. The system table is designed to aggregate data across workspaces sharing the same metastore region, giving one queryable surface for the whole region, while the REST endpoint only ever returns runs for the single workspace it is called against.
• B. Because both are SQL tables in the same catalog, they can be joined directly with a standard SQL join, whereas combining REST API JSON responses with billing usage rows requires the caller to extract, normalize, and stitch the data together outside of SQL.
• C. Polling the endpoint on demand reflects a run's state as soon as it changes, while rows for a given run in the system table are documented to typically appear within about an hour rather than immediately.
• D. The retention relationship is reversed: the system table is documented to retain roughly 365 days of history, while the REST API is a live, point-in-time view of runs rather than a long-term, retention-guaranteed archive.
• E. The endpoint has no changed-since cursor, so a scheduled poll covering a rolling window has to re-request and re-filter runs it has already seen on earlier polls to detect what changed.
• F. The system table is documented to lag behind real-time state changes by up to about an hour, so it is not lower latency than a REST poll for any sub-minute polling schedule; the two approaches trade latency for aggregation and joinability in opposite directions.

Correct answer: A — `system.lakeflow.job_task_run_timeline`, since it records per-task duration columns for both single-task and multi-task jobs.

• A. This table records per-task duration metrics for every job, and is the recommended source for multi-task jobs since it captures each task's own setup, queue, and execution duration.
• B. Its duration columns are documented as populated only for single-task jobs; for a multi-task job it does not give reliable per-task figures, so it does not satisfy the requirement.
• C. This table tracks task configuration such as dependencies and timeouts, not run-time duration metrics, so it cannot produce the requested average execution and queue times.
• D. This table holds job-level metadata like trigger type and schedule, not per-task or per-run duration figures, so it does not answer the reporting question.

Correct answer: A — Alerts now report status as one of OK, Triggered, or Error, and the previously used Unknown status has been removed from the evaluation model.

• A. The current alert editor evaluates each alert to OK, Triggered, or Error, and it explicitly no longer supports the Unknown status that legacy alerts used. This is the correct, up-to-date status model for monitoring governed metrics.
• B. Unknown was part of the legacy alert status model, not the current one. Carrying that assumption forward after a migration to the new editor leads teams to misinterpret alert history.
• C. Healthy and Unhealthy are the status labels used by Lakehouse Monitoring anomaly detection for table health badges, not the status vocabulary used by SQL alerts themselves.
• D. SQL alerts do not have a manual-acknowledgement Pending/Resolved workflow; their status is derived automatically from evaluating the query condition on each scheduled run.

Correct answer: A — The 40 MB write likely falls below the size threshold for clustering-on-write with two clustering columns on a Unity Catalog managed table, so the new files may not be clustered until a subsequent `OPTIMIZE` runs.

• A. Clustering-on-write only engages once accumulated new data crosses a size threshold that scales with the number of clustering columns; for two clustering columns on a Unity Catalog managed table that threshold is 256 MB, so a 40 MB transaction is likely to land unclustered until a later `OPTIMIZE` incrementally reorganizes it.
• B. Clustering on write is threshold-based rather than unconditional, so small writes below the applicable size threshold are not guaranteed to be clustered immediately; only writes at or above the threshold trigger clustering at write time.
• C. `OPTIMIZE FULL` is used to recluster all existing data the first time clustering keys are set or changed, but liquid clustering itself, including clustering-on-write behavior for sufficiently large transactions, is active from table creation and does not wait for a manual full optimize.
• D. Incremental clustering only rewrites the files necessary to accommodate new data relative to the current clustering keys; it does not force a rewrite of the entire historical table on every write, which is precisely what makes liquid clustering more efficient than repartitioning.

Correct answer: C — Recreate the table with `CLUSTER BY (customer_id)` so the file layout is maintained incrementally as the skewed data grows.

• A. Adding a second Z-ORDER column does not solve the underlying cost problem, since a Z-ORDER `OPTIMIZE` still rewrites the full set of touched files on every run regardless of how many columns are listed.
• B. Partitioning by a high-cardinality, skewed column like `customer_id` creates an excessive number of small partitions, which drives up file-listing overhead and small-file problems instead of fixing the rewrite cost.
• C. Liquid clustering with `customer_id` declared as a key incrementally maintains the layout as new data arrives, avoiding the full-table rewrite cost that a growing skewed table incurs under Z-ORDER.
• D. Given how heavily queries filter on `customer_id`, automatic clustering would likely select that same column as a key rather than avoid it, so this does not describe expected behavior.

Correct answers: A, B, D — Set `sequence_by` to the `_commit_version` column, or a business timestamp, so out-of-order change events apply in true logical order rather than arrival order.; Set `stored_as_scd_type` to `2` so the target table retains a full, queryable history of prior values for each key instead of overwriting the row in place on every update.; Set `apply_as_deletes` to the condition that identifies delete events from the feed, so that deleted source rows are tombstoned and excluded from the current view of the dimension.

• A. `sequence_by` tells AUTO CDC how to determine the true logical order of events, which is essential when events can arrive out of order. Using the commit version or a business timestamp ensures a late-arriving older change does not incorrectly overwrite a newer one.
• B. SCD Type 2 is the configuration that tells AUTO CDC to retain historical versions of each row rather than updating in place, which is exactly the historical tracking the dimension table requires. This is the correct setting for the stated requirement.
• C. AUTO CDC does not infer deletes automatically from any `_change_type` value, including `update_preimage`, which simply represents the pre-change state of an ordinary update. Deletes must be identified explicitly through the `apply_as_deletes` parameter or they will not be applied.
• D. Explicitly configuring `apply_as_deletes` with the condition that identifies delete events is the documented way to make AUTO CDC tombstone those rows in the target table. Without this configuration, delete events from the source would not be reflected downstream at all.
• E. SCD Type 1 is the in-place update mode that overwrites the existing row with no retained history, which is the opposite of what preserving full history requires. The dimension table in this scenario needs Type 2, not Type 1, to meet its stated history requirement.
• F. `keys` identifies the column or columns that uniquely match an incoming change event to an existing target row, not a partitioning hint. Using a non-unique column like `region` would cause unrelated customer records to be incorrectly matched and overwritten.

Correct answers: A, B, C — Databricks can automatically change the clustering keys as the observed query workload shifts, without requiring the table to be dropped and recreated.; Databricks can automatically change the clustering keys as the query workload shifts over time, without ever dropping and recreating the underlying table.; `OPTIMIZE` reclusters only the data that needs it incrementally, instead of requiring a full table rewrite every time new clickstream events are appended.

• A. This is accurate: `CLUSTER BY AUTO` lets Databricks pick and revise clustering keys based on observed query history as access patterns evolve, without a table rebuild.
• B. This is accurate: without fixed partition directories, concurrent writers are not funneled into contention over a small set of `event_type` folders the way rigid partitioning would force.
• C. This is accurate: standard `OPTIMIZE` on a liquid-clustered table only rewrites data that needs reclustering, rather than rewriting the whole table on every run like a full Z-Order pass would.
• D. This overstates the guarantee; liquid clustering improves data skipping through better file organization, but it does not guarantee single-file reads for every filtered query.
• E. This is backwards; `CLUSTER BY AUTO` relies on Databricks continuously analyzing query history to decide whether and how to adjust clustering keys over time.
• F. Z-Order statistics are only maintained within each partition, so the optimizer cannot use them to skip data across `event_type` partition boundaries, limiting global data skipping.

Correct answer: A — `MANAGE`, which controls the ability to change permissions, transfer ownership, or delete the schema, and is intentionally excluded from `ALL PRIVILEGES` grants.

• A. `ALL PRIVILEGES` grants every applicable privilege on the schema except a small set of administrative privileges, and `MANAGE` (along with `READ METADATA`, `EXTERNAL USE SCHEMA`, and `EXTERNAL USE LOCATION`) is deliberately excluded so that broad data grants do not automatically hand out administrative control.
• B. `SELECT` is a standard data-access privilege and is included when `ALL PRIVILEGES` is granted on a schema, so it does not need to be granted separately.
• C. `CREATE TABLE` is included when `ALL PRIVILEGES` is granted on a schema, since it is one of the ordinary creation privileges the grant is meant to bundle together.
• D. `USE SCHEMA` is included when `ALL PRIVILEGES` is granted, since usage on the schema itself is one of the baseline privileges the bundled grant covers.

Correct answers: A, B, C — A single ABAC policy attached at the catalog level automatically extends to new tables created later in that catalog, as long as those tables carry the tag the policy's `WHEN` clause matches.; Governed tags applied at the catalog level propagate down to schemas and tables beneath it, so a lower-level object inherits the tag unless a more specific tag overrides it closer to the object.; A tag applied to a table does not automatically apply to that table's columns, so column-level ABAC policies require the columns themselves to carry a matching tag.

• A. This statement is accurate: attaching a policy at the catalog level lets it apply automatically to any table that later acquires the matching tag, which is the core scaling benefit of ABAC over manually attaching filters table by table.
• B. This statement is accurate: tags follow the catalog-to-schema-to-table hierarchy by default, so an object inherits a tag from its parent unless a more specific tag is set closer to that object.
• C. This statement is accurate: tags do not flow from a table down to its columns, so a column-level policy condition only matches columns that have been tagged directly, even if the parent table carries a matching tag.
• D. This statement is inaccurate: ABAC GRANT policies only add privileges when their tag condition is met, and documentation is explicit that they cannot revoke access a principal already holds through a direct grant made outside the policy.
• E. This statement is inaccurate: DENY policies are currently limited in scope to the `MANAGE ACCESS CONTROL` privilege, so they do not universally override every GRANT regardless of which privilege is involved.
• F. This statement is inaccurate: row filter and column mask policies apply to table-level securables such as tables, materialized views, and streaming tables, not to volumes or registered models.

Correct answer: A — A row filter is a function evaluated per row that excludes the row from the result set when it returns `false`, while a column mask is a function that transforms the value of one column, leaving the row itself present.

• A. This matches how the two mechanisms are defined: a row filter is a function returning a boolean that hides whole rows failing the condition, while a column mask is a function that substitutes or transforms the value shown for one column, leaving the row present.
• B. This swaps the two mechanisms' actual behavior — row filters act on whole rows and column masks act on individual column values, not the other way around as this option describes.
• C. Row filters and column masks are not restricted to only streaming tables versus only batch tables; both mechanisms can be applied across the table types Unity Catalog supports for this feature, so this distinction does not hold.
• D. Both row filters and column masks are query-time controls evaluated when a table is read, not one-time write-time transformations or controls limited to Delta Sharing access paths.

Correct answer: B — Have the mask return `YEAR(date_of_birth)` cast back to the column's date type for everyone outside HR, generalizing the value to birth year only.

• A. Returning `NULL` suppresses the value entirely, which satisfies the privacy requirement but destroys the birth-year information the analytics team was explicitly granted access to. Suppression is too aggressive for this requirement.
• B. Reducing the date to its year component is generalization: it keeps exactly the granularity the analytics team is authorized to see for age-band studies while hiding the exact day and month, and HR still receives the untouched value through the mask's conditional logic.
• C. A cryptographic hash of the date produces an opaque fixed-length string that cannot be grouped into meaningful birth-year bands or cast back to a date, so it does not give the analytics team the age information they are supposed to have.
• D. Token-vault lookups are built for reversible pseudonymization of identifiers like account or card numbers, not for producing a coarser, still-analyzable version of a date; the analytics team would receive an opaque token instead of a usable birth-year signal.

Correct answers: A, B, C — Any user holding the `BROWSE` privilege on an object can view its comments, even without broader read access to the underlying data; Tag-based search in Unity Catalog requires an exact match on the tag key and value, rather than performing partial or fuzzy matching; Tags applied at the catalog level are queryable through `INFORMATION_SCHEMA` views such as `CATALOG_TAGS`, supporting programmatic discovery

• A. `BROWSE` is deliberately a lighter-weight privilege than full read access, and it is sufficient on its own to let a user view an object's comment, supporting discovery without granting data access.
• B. Tag search matches the key and value exactly rather than doing partial or fuzzy text matching, so a search term must correspond precisely to the stored tag.
• C. Catalog-level tags are exposed through `INFORMATION_SCHEMA` views like `CATALOG_TAGS`, which lets teams query tag assignments programmatically instead of browsing the UI object by object.
• D. Viewing a comment only requires `BROWSE`, a much lower bar than the `MODIFY` privilege, so read-only analysts with browse access can still see comments in search results.
• E. Tag matching in Unity Catalog is exact, not fuzzy or typo-tolerant, so a partial term like `financ` would not surface objects tagged `finance`.
• F. Tags are indexed and surfaced by Catalog Explorer's search, aiding discoverability directly, rather than existing solely as an access-control mechanism.

Correct answers: A, B, C — Open the Executors tab to check whether the executor running the slow task is under GC pauses or memory pressure that would compound the skew.; Open the associated SQL/DataFrame tab to inspect the physical plan and confirm which operator produced the oversized shuffle partition.; Enable adaptive query execution's skew join optimization, or increase `spark.sql.shuffle.partitions`, so the oversized partition splits across more tasks.

• A. Checking the executor running the outlier task for GC pauses or memory pressure is a standard Spark UI workflow: a struggling executor can turn ordinary skew into an extreme long tail, and this rules that factor in or out before changing the job.
• B. The physical plan in the SQL/DataFrame tab identifies exactly which shuffle-producing operator (such as a join or aggregation) created the oversized partition, which is necessary before deciding how to rewrite or reconfigure the query.
• C. Adaptive query execution's skew join handling, or a higher shuffle partition count, directly targets an oversized shuffle partition by splitting it into smaller pieces so no single task carries a disproportionate share of the data.
• D. Driver memory pressure affects planning and coordination, not the size of an individual executor task's shuffle partition, so a larger driver node would not address a single skewed reducer task.
• E. Structured Streaming micro-batches run as ordinary Spark jobs and expose the same Stages tab with per-task shuffle metrics as batch jobs, so this claim about batch-only visibility is incorrect.
• F. Speculative execution reruns slow tasks on other executors as a mitigation, but disabling it removes that safety net without doing anything to rebalance the skewed partition itself, so the underlying skew remains.

Correct answers: A, B, F — Values supplied in `job_parameters` for the repair request take precedence over the parameter values that were used in the original failed run.; Setting `rerun_all_failed_tasks` to true tells the service to re-execute every task that did not complete successfully in the prior attempt.; Submitting `rerun_tasks` with an explicit list of task keys lets the caller target specific tasks instead of relying on the failed-task detection.

• A. Correct: parameters passed in the repair request override the values from the original attempt for the tasks being re-executed, which is exactly how the Repair job run dialog's override behavior works when driven through the API.
• B. Correct: this boolean flag reruns every task that did not succeed in the prior attempt, which is the API equivalent of letting the service auto-detect failed and canceled tasks rather than listing them manually.
• C. Incorrect: `latest_repair_id` is only required as a safeguard when repairing a run that has already been repaired at least once, so it does not need to reference anything on a run's very first repair attempt.
• D. Incorrect: task parameters can be overridden on any repair attempt, and clearing an overridden field on a later repair returns that parameter to its original value rather than the setting being locked after one use.
• E. Incorrect: a repair request only changes the parameter values used for that specific repaired run; it does not mutate the job definition's stored default parameters used by future runs.
• F. Correct: `rerun_tasks` accepts specific task keys so the caller can target exactly which tasks to re-execute, as an alternative to the automatic failed-task or dependent-task detection flags.

Correct answer: A — Open the Executors tab, locate the row for that executor's ID, and click the link in its Thread Dump column to capture a snapshot of every thread's current state.

• A. The Executors tab exposes a Thread Dump link per executor that captures a live snapshot of every thread's stack trace and state on that JVM, which is exactly the mechanism designed for identifying where a specific executor is stuck.
• B. A task-level Logs link streams stdout/stderr application log lines for that task, but log output only shows what the code explicitly printed; it does not capture the live thread stack state needed to see exactly where execution is currently blocked.
• C. The SQL tab's Explain option renders the logical or physical query plan for an operator; it describes what the query intends to compute, not the live runtime thread state of a particular executor process.
• D. The DAG visualization on the Jobs tab shows stage dependencies and progress, and hovering over a node does not surface per-executor CPU/memory gauges or thread stack traces for diagnosing a hang.

Correct answer: A — Generate an Azure DevOps personal access token, since Databricks Git folders do not accept Microsoft Entra ID tokens for this integration.

• A. Azure DevOps is a documented exception: Databricks Git folders require an Azure DevOps personal access token for this integration and do not accept Microsoft Entra ID tokens, unlike the OAuth flow available for providers such as GitHub.
• B. The cloud the workspace runs on does not determine which Git providers it can integrate with; Azure-hosted workspaces can link to GitHub, GitLab, Bitbucket, and other supported providers just as workspaces on other clouds can.
• C. Unity Catalog governs data and object access within the workspace and has no bearing on which token type a Git folder accepts when authenticating to an external Git provider.
• D. The Jobs API manages job definitions and runs; it is not the interface used to authenticate or synchronize a Git folder with a remote repository, so switching to it would not resolve an authentication failure.

Correct answer: A — Export an environment variable named `BUNDLE_VAR_warehouse_id` set to the desired ID before invoking `databricks bundle deploy`, since CLI variable resolution checks that environment prefix ahead of the declared default.

• A. The `BUNDLE_VAR_<name>` environment variable convention is read by the CLI ahead of a variable's declared default, so exporting it per CI run supplies a fresh warehouse ID each time without touching any committed file.
• B. A `lookup` block resolves an object's ID by looking it up by name in the workspace; it solves a different problem than supplying a caller-chosen literal value per run and would not let CI inject an arbitrary ID.
• C. The `--profile` flag selects a named Databricks CLI authentication profile; it does not accept key-value pairs for overriding bundle variables, so this would not affect `warehouse_id` at all.
• D. A committed overrides file is lower precedence than an environment variable in the CLI's resolution order, and it would also require a file edit and commit on every run, which the requirement explicitly rules out.

Correct answer: A — Create the materialized view with `TRIGGER ON UPDATE` so a refresh is automatically scheduled only when the underlying source tables actually change, avoiding unnecessary compute when `fact_sales` is idle.

• A. The `TRIGGER ON UPDATE` refresh mode watches the source tables and schedules a refresh only when they actually change, which delivers near-real-time freshness without running compute on a fixed cadence while the source is idle. This matches both the freshness and the cost-avoidance requirement.
• B. An ad-hoc materialized view only refreshes when someone explicitly runs the refresh command, so freshness depends entirely on an analyst remembering to trigger it. That does not reliably deliver updates within a few minutes of new data landing.
• C. A per-minute cron schedule does refresh quickly, but it runs on a fixed timer even when `fact_sales` has not changed, which is exactly the wasted-compute pattern the team wants to avoid. Trigger-based refresh reacts to actual changes instead.
• D. A materialized view always physically stores its results and only updates them on refresh; it does not recompute live at query time the way a standard view does. Querying it without ever refreshing would just return stale, previously materialized data.

Correct answer: A — Create or alter the tables with `CLUSTER BY AUTO` so Databricks Runtime 15.4 LTS or later analyzes each table's query history and updates clustering keys only when the savings outweigh the reclustering cost.

• A. This is exactly the automatic clustering-key selection feature: Databricks analyzes the workload against the table and only changes keys when doing so is expected to be cost-effective, requiring no manual key management.
• B. Auto compaction controls small-file bin-packing behavior on write, but it does not select or change clustering keys, so it does not meet the requirement to automate key selection.
• C. This describes a manually built and maintained job that inspects statistics and swaps keys by hand, which is the opposite of the hands-off, workload-aware automation the team wants.
• D. Predictive optimization schedules maintenance jobs like `OPTIMIZE` and `VACUUM`, and `ZORDER BY` is a separate, non-adaptive indexing technique used with partitioned tables, not an automatic clustering-key selector.