Answer-first summary for fast verification
Answer: Implement a defense-in-depth model that includes: - Unity Catalog fine-grained privileges + dynamic row filters and column masks (preferably via centralized ABAC policies with governed tags), - Customer-managed keys (CMK) for Unity Catalog-managed storage and sensitive external locations, - Enforcement of TLS encryption for all cluster-to-storage and inter-cluster communication, - Audit logging enabled at the workspace and Unity Catalog level.
**A: Incorrect** While cloud-provider encryption at rest (e.g., SSE-KMS) and TLS for transit are baseline requirements and are enabled by default in Databricks, this option stops at coarse-grained (table-level) access control in Unity Catalog. It completely lacks dynamic row-level filtering and column-level masking/dynamic masking — features explicitly required for fine-grained protection of PII/PHI under GDPR/HIPAA/PCI-DSS. This would almost certainly fail compliance audits that demand need-to-know access at the record/field level. **B: Partially correct but insufficient** Using Unity Catalog's row filters and column masks (especially via ABAC in public preview or GA features) is excellent for dynamic, policy-driven protection without duplicating data. However, limiting CMK to only "the most sensitive catalogs" leaves gaps in other areas (e.g., workspace-level objects, notebooks, logs, or less-sensitive-but-still-regulated catalogs). Relying on default platform-managed keys and transit encryption is acceptable for many use cases but falls short of the "strict" multi-regulation scenario that often mandates customer control over key lifecycle (e.g., immediate revocation capability). **C: Correct** This is the most comprehensive defense-in-depth approach aligned with Databricks best practices and exam expectations at the Professional level: - **Unity Catalog** centralizes governance and enables fine-grained privileges, row filters, and column masks (preferably via ABAC for stronger, non-overridable enforcement). - **CMK** provides customer control over encryption key material for catalogs and sensitive locations, satisfying regulations requiring key ownership/revocation. - Explicit TLS enforcement covers data in transit end-to-end. - Audit logging supports compliance evidence and forensic needs. It achieves strong security, scalability (no heavy client-side crypto), centralized policy management, and reasonable cost (CMK has modest incremental cost but is often required). **D: Incorrect / anti-pattern** Client-side / application-level column encryption (via UDFs) before writing to Delta breaks many Delta Lake benefits: - No native predicate pushdown or optimization on encrypted columns - Query performance degradation (decryption in every read) - Complicates schema evolution, time travel, and Delta Sharing - Makes centralized governance harder (Unity Catalog cannot mask/understand encrypted blobs) While technically possible for extreme cases, it is **not** the recommended or scalable pattern in modern Databricks architectures.
Ultimate access to all questions.
No comments yet.
Author: LeetQuiz Editorial Team
In a Databricks Lakehouse architecture governed by Unity Catalog, your organization must comply with multiple overlapping regulations (including GDPR, HIPAA, and PCI-DSS) for a workload that processes highly sensitive PII and PHI across bronze, silver, and gold layers. All data resides in Delta Lake tables, with strict requirements for encryption of data at rest and in transit, fine-grained access controls (including dynamic row-level filtering and column-level masking), auditability, and minimal performance impact on large-scale analytical and ML workloads.
You are designing the security architecture and must select the most complete and production-ready approach that balances regulatory coverage, centralized governance, scalability, operational manageability, and cost.
Which of the following strategies BEST satisfies these requirements?
A
Rely primarily on the cloud provider's default server-side encryption for data at rest (SSE-S3 / SSE-KMS / ADE), enforce TLS 1.2+ for all network traffic, and implement table-level privileges in Unity Catalog without row/column-level controls.
B
Use Unity Catalog column-level dynamic data masking functions combined with row filters (via ABAC policies where possible), enable customer-managed keys (CMK) only for the most sensitive catalogs, and accept default platform-managed encryption for workspace objects and transit traffic.
C
Implement a defense-in-depth model that includes:
D
Apply column-level encryption directly in Delta tables using client-side encryption logic (e.g., AES via Python UDFs or third-party libraries) before writing data, combined with Unity Catalog table privileges, while relying on cloud-provider transit encryption only.