Tuning Spark's core parameters and measuring what changed
Spark performance tuning on Databricks centers on a handful of configuration parameters that control shuffle behavior, memory allocation, and join strategy. Learners should know default values, when to adjust them, and how to validate improvements by re-running and comparing query metrics (e.g., via the Spark UI or query execution time) after each change.
Must-know
- spark.sql.shuffle.partitions controls the number of partitions used when shuffling data for joins or aggregations; it defaults to 200 and often needs to be lowered for small datasets or raised for large clusters to avoid too many small tasks or too few large ones.
- spark.default.parallelism sets the default number of partitions for RDD operations (not DataFrame/SQL operations, which use spark.sql.shuffle.partitions instead), so it has limited effect in typical DataFrame-based Databricks workloads.
- spark.executor.memory and spark.driver.memory set the JVM heap size for executors and the driver respectively; increasing them can prevent out-of-memory errors and spill-to-disk during large shuffles or aggregations, but over-allocating can reduce the number of executors that fit on a cluster.
- spark.sql.autoBroadcastJoinThreshold determines the max size (default 10MB) of a table that Spark will automatically broadcast to all executors for a broadcast hash join, avoiding an expensive shuffle join; setting it to -1 disables auto-broadcasting entirely.
- Tuning is iterative: change one parameter at a time, re-run the workload, and compare metrics (execution time, shuffle read/write, spill) in the Spark UI to confirm the change actually helped rather than assuming improvement.
- These are session- or cluster-level configs typically set via spark.conf.set() or cluster configuration, and changes only apply to queries/jobs run after the setting is applied, not retroactively.
A data engineer joins a 500 GB fact table with a 40 MB dimension table. The join runs as a full shuffle (sort-merge join) instead of a broadcast join, causing excessive shuffle time. spark.sql.autoBroadcastJoinThreshold is currently set to 10MB. What should the engineer do to make Spark broadcast the smaller table?
What you have tried across Databricks DEA's objectives, not a readiness score.
Databricks Intelligence Platform
Data Ingestion and Loading
- Batch, streaming, and incremental loading patterns, and where the data comes from
- Loading files from cloud storage into governed tables with COPY INTO
- Landing data with Auto Loader, and handling schema enforcement and evolution
- Setting up Lakeflow Connect to ingest from enterprise sources reliably
- Pulling data through JDBC, ODBC, or REST clients and scheduling the job
- Choosing the right ingestion method for a given volume, frequency, and governance need
- Bringing semi-structured and unstructured data into governed Delta tables
Data Transformation and Modeling
- Cleaning bronze data into silver tables with PySpark and SQL
- Joining and combining DataFrames with the different join and union types
- Reshaping columns, rows, and arrays in a table
- Deduplicating and aggregating DataFrames
- Tuning Spark's core parameters and measuring what changed
- Building Gold-layer views and tables for BI and analytics
- Validating Silver and Gold datasets for quality
Working with Lakeflow Jobs
Implementing CI/CD
- Branching, committing, and opening pull requests from inside the Databricks workspace
- Promoting one codebase across dev, test, and prod with bundle variables and overrides
- Packaging and deploying jobs and pipelines with Automation Bundles
- Validating and managing bundle deployments from the Databricks CLI
Troubleshooting, Monitoring, and Optimization
- Spotting performance trends in a job's run history
- Reading job status, task graphs, and failure rates to monitor pipeline health
- Diagnosing skew, shuffle, and spill from Spark UI stage metrics
- What Liquid Clustering and predictive optimization actually do
- Diagnosing cluster startup failures, library conflicts, and out-of-memory errors
Governance and Security
Coverage checked against the published exam guide on Jul 26, 2026.
These are independent practice questions, written against this certification's published exam guide. They are not the certification vendor's own questions, and not the real exam.