Overview
Ensuring Data Security and Compliance has five objectives. The first applies least-privilege access control to Unity Catalog securables and to workspace resources such as jobs, clusters and notebooks. The second uses attribute-based access control: governed tags label sensitive columns or tables, and policies attached at catalog or schema level apply row filters and column masks to everything carrying those tags.
The third covers techniques for confidential data, namely hashing, tokenization, suppression and generalization, and the difference between anonymised and pseudonymised data. The fourth asks you to build a pipeline that detects PII and masks it in both batch and streaming paths using Unity Catalog. The fifth covers purging: deleting records for retention rules or erasure requests and making sure they are physically removed from Delta files, history and downstream copies, not just hidden from current queries.
How it's tested
Questions describe a compliance or access requirement and offer several technically possible controls. The best answer usually scales with the least ongoing effort and actually removes or hides data as required, for example a tag-based policy rather than a dozen views, or a delete followed by physical cleanup.
-
Grant the minimum
A user or service needs a narrow capability, and you choose the smallest set of privileges or workspace permissions.
-
Mask at scale
Many tables share a sensitive column type, and you pick governed tags with an ABAC policy over per-table controls.
-
Erase for real
A deletion request or retention rule applies, and you choose the steps that physically remove data from Delta files.
A user requests erasure under GDPR from a Delta table with deletion vectors enabled. Running DELETE hides the rows but files still hold them. VACUUM alone will not remove rows that deletion vectors only mark. Rewriting affected files with REORG TABLE ... APPLY (PURGE), then running VACUUM after the retention window, physically removes the data, so that sequence is correct.
Objectives 5
Official objectives from the Databricks outline, in outline order.
6.1 Apply least-privilege access control lists (ACLs) to secure Unity Catalog securable objects and workspace resourcesGranting only the access each principal needs.
- What it means
- Unity Catalog privileges such as USE CATALOG, USE SCHEMA, SELECT, MODIFY, CREATE TABLE and EXECUTE are granted on catalogs, schemas, tables, views, volumes and functions. Workspace objects such as jobs, clusters, notebooks and pipelines have separate permission levels, for example CAN VIEW, CAN RUN, CAN MANAGE RUN and CAN MANAGE.
- What to understand
- Grant to groups, not individuals, and use service principals as run-as identities for production jobs. Reading a table requires USE CATALOG and USE SCHEMA on its parents plus SELECT on the table. Ownership carries full control, so transfer it to a group. Workspace permissions decide who can trigger or edit a job, separately from the data it can read.
- How it shows up
- Expect a role description and a choice of the smallest set of grants or job permissions.
- Common confusion
- Granting ALL PRIVILEGES on a catalog when SELECT on one schema meets the need.
6.2 Apply attribute-based access control (ABAC) policies with governed tags to enforce row filters and column masks at scaleTag-driven policies instead of per-table rules.
- What it means
- ABAC in Unity Catalog uses governed tags, which are account-level tags with controlled values and assignment permissions. Policies defined on a catalog, schema or table use those tags to decide where a row filter or column mask function applies, so new tagged objects are protected automatically.
- What to understand
- Per-table row filters and column masks are set with ALTER TABLE and must be repeated for every table. ABAC policies reference a UDF and a tag condition, such as columns tagged pii with value email, and apply to every match below the policy's level. Policies can exempt groups. Restricting who may apply governed tags prevents users from removing protection.
- How it shows up
- A requirement covers many tables or future tables, and you choose ABAC over individual masks or views.
- Common confusion
- Creating a dynamic view per table when one tag-based policy covers them all.
6.3 Apply anonymization and pseudonymization methods, such as hashing, tokenization, suppression and generalization, on confidential dataReducing identifiability of sensitive values.
- What it means
- Pseudonymization replaces identifiers with values that can be linked back with extra information, such as a salted hash or a token mapped in a secure vault table. Anonymization removes the link entirely, for example by suppressing fields or generalising values into ranges.
- What to understand
- Hashing with a secret salt gives consistent join keys without exposing raw values, but it remains personal data under GDPR. Tokenization keeps a reversible mapping in a tightly controlled table. Suppression drops or nulls fields, and generalization reduces precision, such as age bands or truncated postal codes. Choose by whether the business must re-identify or join later.
- How it shows up
- Expect a requirement about joinability or re-identification and a choice of technique.
- Common confusion
- Treating unsalted hashes as anonymous; common values can be reversed by lookup.
6.4 Implement a compliant data pipeline that enforces PII detection and masking controls across batch and streaming using Unity CatalogBuilding privacy controls into the pipeline itself.
- What it means
- A compliant pipeline finds personal data as it lands and stops it from spreading unprotected. Detection can use Unity Catalog data classification to tag sensitive columns, or AI functions such as ai_mask on free text. Masking is applied with column masks, ABAC policies or transformation logic before data reaches broadly readable tables.
- What to understand
- Apply the same rules to batch and streaming paths, for example by sharing a masking function in Unity Catalog. Restrict bronze tables that hold raw PII to a small group, and expose masked silver tables to others. Tags applied by classification can trigger ABAC policies automatically. Logs and checkpoints may also contain sensitive values, so storage access matters.
- How it shows up
- A scenario describes PII arriving in a stream and asks where and how to detect and mask it.
- Common confusion
- Masking only in a reporting view while raw PII stays readable in silver.
6.5 Implement a data purging strategy that satisfies data retention and deletion policies, including GDPR erasure, using Delta Lake and Unity CatalogDeleting data so it is truly gone.
- What it means
- Purging means removing records required by retention policy or erasure requests from current data and from everything that could still return them. In Delta Lake that means DELETE, then physically removing old files with VACUUM after the retention period, and handling deletion vectors and downstream copies.
- What to understand
- DELETE writes a new version, but time travel can still read old versions until VACUUM removes unreferenced files older than the retention threshold, seven days by default. With deletion vectors, run REORG TABLE ... APPLY (PURGE) so rows are rewritten out of files before VACUUM. Change Data Feed files, clones and downstream tables also need purging. Predictive Optimization can run VACUUM on managed tables.
- How it shows up
- Expect an erasure request and a choice of steps or ordering that fully removes the data.
- Common confusion
- Believing DELETE alone satisfies erasure while time travel can still return the rows.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
USE CATALOG and USE SCHEMA
Prerequisite privileges for accessing objects inside a container.
- Remember
- Needed alongside SELECT.
- Tested as
- Least-privilege questions.
- Trap
- Granting SELECT alone and expecting access.
-
Workspace permission levels
CAN VIEW, CAN RUN, CAN MANAGE RUN and CAN MANAGE on jobs and compute.
- Remember
- Separate from data privileges.
- Tested as
- Job access questions.
- Trap
- Granting CAN MANAGE to someone who only triggers runs.
-
Governed tags
Account-level tags with controlled values and assignment rights.
- Remember
- Drive ABAC policies.
- Tested as
- Masking at scale.
- Trap
- Using free-form tags anyone can remove.
-
ABAC policy
Tag-based rule applying row filters or column masks below a catalog or schema.
- Remember
- Covers future tables automatically.
- Tested as
- Scale scenarios.
- Trap
- Repeating ALTER TABLE masks per table.
-
Column mask
Function that returns a masked value based on the caller.
- Remember
- Can be set per table or via ABAC.
- Tested as
- Masking questions.
- Trap
- Masking in a view while the table stays open.
-
Salted hashing
Hash with a secret salt for consistent pseudonyms.
- Remember
- Still personal data under GDPR.
- Tested as
- Pseudonymization questions.
- Trap
- Calling it anonymization.
-
Tokenization
Replace values with tokens mapped in a protected table.
- Remember
- Reversible by authorised users.
- Tested as
- Re-identification requirements.
- Trap
- Leaving the token table broadly readable.
-
Generalization and suppression
Reduce precision or remove fields.
- Remember
- Moves data toward anonymity.
- Tested as
- Analytics on de-identified data.
- Trap
- Keeping quasi-identifiers that allow re-identification.
-
Data classification
Unity Catalog feature that detects and tags sensitive columns.
- Remember
- Tags can trigger ABAC policies.
- Tested as
- PII detection questions.
- Trap
- Assuming tags apply masks without a policy.
-
VACUUM retention
Removes unreferenced files older than the threshold, seven days by default.
- Remember
- Required to make deletes physical.
- Tested as
- Erasure questions.
- Trap
- Thinking DELETE removes files.
-
REORG TABLE APPLY (PURGE)
Rewrites files to drop rows marked by deletion vectors.
- Remember
- Run before VACUUM for erasure.
- Tested as
- Deletion vector purging.
- Trap
- Running VACUUM alone on soft-deleted rows.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Per-table controls vs. ABAC
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Dynamic view | View with CASE or filter logic on group membership | Separate object to maintain | Base table left readable |
| Table row filter or column mask | Function attached to one table | Enforced on the table itself | Repeated for every table |
| ABAC policy with governed tags | Rule applied wherever tags match | Scales to many and future tables | Tags editable by anyone without control |
De-identification techniques
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Salted hashing | Consistent irreversible pseudonym | Joinable, still personal data | Using no salt |
| Tokenization | Token mapped in a vault table | Reversible for authorised users | Weak access to the vault |
| Suppression | Remove or null a field | Strongest, loses the data | Removing fields still needed |
| Generalization | Lower precision such as age bands | Keeps analytic value | Bands too narrow to protect |
Delete vs. purge in Delta
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| DELETE | New table version without the rows | Old versions still hold the data | Treated as complete erasure |
| REORG APPLY (PURGE) | Rewrites files marked by deletion vectors | Removes rows from live files | Skipped when deletion vectors are on |
| VACUUM | Deletes unreferenced files past retention | Ends time travel to those versions | Run before the retention period ends |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
DELETE is erasure
- What candidates pick
- Run DELETE and confirm the request.
- Why it looks right
- The rows disappear from queries.
- Why it's wrong
- Older versions and files still contain the data until purged and vacuumed.
Clue to watch for The requirement says data must be unrecoverable.
-
VACUUM with deletion vectors
- What candidates pick
- Run VACUUM straight after DELETE on a table using deletion vectors.
- Why it looks right
- VACUUM is the known cleanup step.
- Why it's wrong
- Rows marked by deletion vectors stay in data files until REORG APPLY (PURGE) rewrites them.
Clue to watch for The table has deletion vectors enabled.
-
View per table
- What candidates pick
- Build masked views over each sensitive table.
- Why it looks right
- Views are a long-standing pattern.
- Why it's wrong
- This does not scale and leaves base tables exposed; ABAC policies on tags protect tables directly.
Clue to watch for Hundreds of tables or future tables are mentioned.
-
Hash means anonymous
- What candidates pick
- Hash email addresses and treat the data as anonymous.
- Why it looks right
- Hashes look unreadable.
- Why it's wrong
- Consistent hashes remain linkable and can be reversed by lookup, so they are pseudonymous.
Clue to watch for The question asks about GDPR status or re-identification.
-
Manage for runners
- What candidates pick
- Give analysts CAN MANAGE on a job so they can trigger it.
- Why it looks right
- It guarantees they can run it.
- Why it's wrong
- CAN MANAGE RUN or CAN RUN suffices; CAN MANAGE also allows editing and permission changes.
Clue to watch for Users only need to start or cancel runs.
-
Mask only at the end
- What candidates pick
- Mask PII in the gold reporting layer only.
- Why it looks right
- Gold is what analysts query.
- Why it's wrong
- Raw PII in silver or bronze stays readable to anyone with access there; masking must start upstream.
Clue to watch for Several teams read silver tables.
Answer framework
Use these steps when a Section 6 scenario involves access or sensitive data.
- Identify the principal and the narrowest action it needs, then grant parent USE privileges plus the specific object privilege to a group.
- Separate data privileges from workspace permissions, and give jobs a service principal identity with only what they read and write.
- When many or future tables share a sensitive attribute, use governed tags with an ABAC policy rather than per-table filters or views.
- Decide whether data must be re-identifiable or joinable, then choose tokenization, salted hashing, generalization or suppression accordingly.
- For deletion, run DELETE, purge rewrites for deletion vectors, VACUUM after retention, and clean Change Data Feed, clones and downstream tables.
Practice question
Want more like this? The Databricks DE Pro practice test has questions for every domain.
Checklist
0 of 11
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with privileges, because they underpin everything else. Draw the Unity Catalog hierarchy and list what a reader, a writer and a pipeline service principal each need. Then do the same for job and compute permissions, since exam items often mix the two.
Next, practise the masking options in order of scale. Create one table with a column mask and a row filter, then build the same protection with a governed tag and an ABAC policy at schema level, and add a new table to watch the policy apply automatically.
For de-identification, write a short table of techniques with columns for reversible, joinable and still personal data. Practise salted hashing with sha2 and a secret, and build a small token vault table.
Finally, rehearse a GDPR erasure end to end on a test table with deletion vectors and Change Data Feed enabled: DELETE, REORG APPLY (PURGE), VACUUM, then confirm time travel no longer returns the row. Note what else might hold copies, such as clones and downstream tables.
FAQ
How much of the exam is Ensuring Data Security and Compliance?
Ensuring Data Security and Compliance is 8% of the scored content, about five of the 60 questions.
What is ABAC in Unity Catalog?
Attribute-based access control: policies that apply row filters or column masks to any object carrying matching governed tags, below the level where the policy is defined.
Is a salted hash anonymous under GDPR?
No. It is pseudonymous because the same input gives the same output and could be linked back. Anonymous data cannot be reasonably re-identified.
Why is DELETE not enough for erasure?
Delta keeps older versions for time travel. Files holding the deleted rows remain until VACUUM removes them after the retention period.
What does REORG TABLE APPLY (PURGE) do?
It rewrites data files so rows soft-deleted with deletion vectors are physically removed, which must happen before VACUUM can drop the old files.
Are workspace permissions part of this section?
Yes. The objective covers ACLs on workspace resources such as jobs and compute, alongside Unity Catalog securables.
Other Data & Analytics certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 6 knowledge
You have covered least privilege, ABAC, de-identification, PII pipelines and data purging. Check your choices on short compliance scenarios.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the Databricks DE Pro AI tutor Get any concept explained your way