Data Governance practice questions

Grant SELECT on the table, create a row filter using SQL user-defined functions, and assign it via the catalog explorer UI.

Why it fails: Row filters restrict entire rows based on predicate logic rather than modifying specific column values for dynamic masking. Applying a row filter would drop entire records instead of obfuscating the email string data requested by the engineering requirements.

Create a cloned copy of the table using shallow clone, apply static data masking via Python notebooks, and grant read access exclusively to the clone.

Why it fails: Static data cloning creates an independent copy of the storage location, which duplicates storage costs and introduces data drift synchronization challenges. Unity Catalog dynamic masking avoids duplication by handling transformations directly at query execution time.

Configure access control lists at the storage container level using cloud provider IAM policies to block the principal from viewing column paths.

Why it fails: Cloud provider IAM policies operate at the file or container storage level and cannot isolate individual table columns stored within Delta parquet files. Unity Catalog manages fine-grained governance logically above cloud storage layers for column enforcement.

The REVOKE statement invalidates the entire chain of permissions for the schema.

Why it fails: Revoking access from a specific object does not propagate to the parent schema or catalog. Unity Catalog evaluates permissions based on the most specific object level available. The REVOKE statement is simply ineffective here because the user never possessed the SELECT permission on that specific table to begin with.

Unity Catalog requires an explicit GRANT to the individual table regardless of schema-level access.

Why it fails: While object-level permissions override schema-level permissions, a user with SELECT on the schema would inherit access to all tables within it unless restricted. The issue here is that the sensitivity of the data implies a need for explicit authorization, and the current policy configuration fails to provide that access.

The analyst lacks the required SELECT privilege on the specific table.

Why it fails: Unity Catalog operates on a principle of least privilege. Since there is no GRANT statement for the sensitive table, the analyst does not have the necessary permission. Even if they have schema access, explicit table-level security effectively overrides general permissions, ensuring that sensitive data is protected by default unless access is granted.

Tables must be converted to the Delta format.

Why it fails: While Delta Lake is highly recommended for performance and ACID compliance, Unity Catalog does technically support non-Delta formats through external tables. However, the requirement for Unity Catalog management is the hierarchical namespace registration, not the specific underlying data format, although Delta is best practice for modern analytical workloads.

Tables must be registered using the three-level namespace (catalog.schema.table).

Why it fails: The three-level namespace is the fundamental architecture of Unity Catalog. Without this structure, Unity Catalog cannot enforce fine-grained access control or track lineage. Migrating existing Hive Metastore tables involves creating these objects within a catalog and schema, ensuring that the governance framework is correctly applied to every data asset.

All tables must be granted the OWNER privilege to the account admin.

Why it fails: Ownership in Unity Catalog can be assigned to users, groups, or service principals. Assigning everything to the account admin violates the principle of least privilege. Ownership should be delegated to the teams responsible for the data to ensure operational agility and proper accountability within the governance framework of the organization.

The policy is missing s3:DeleteObject, which is required for dropping managed tables.

Why it fails: While s3:DeleteObject is necessary for certain operations, it is not required for 'managed' tables, as those are handled by the Unity Catalog service itself. This exhibit concerns an 'external' table, which relies on the storage credential policy, but the primary issue is the scope of the permission provided for lifecycle management.

The resource ARN format is incorrect for an S3 bucket integration.

Why it fails: The ARN format for S3 is standard. The bucket and the contents (with the wildcard) are correctly specified. The limitation is not in the resource path definition but in the specific actions permitted by the IAM policy which restricts the necessary administrative operations required by the Unity Catalog service.

The policy contains unnecessary permissions, violating security best practices.

Why it fails: The permissions listed (GetObject, PutObject, ListBucket) are standard requirements for read/write access. The issue is not the presence of these actions, but the absence of the delete action. Following the principle of least privilege means providing exactly what is needed, and this policy currently lacks the specific capability for full lifecycle management.

The Schema.

Why it fails: Schemas are containers within a catalog, designed to organize tables and views. While they can have their own permissions, they are not the top-level entity for managing security and organizational structure across the entire platform. Using catalogs as the primary management unit provides a more robust governance strategy.

The Table.

Why it fails: The table is the lowest level of data object in the namespace. While it is the granularity point for security, it is far too granular to serve as the primary container for organizational governance. Managing permissions at the table level for every single object would quickly become unmanageable and prone to errors.

The Metastore.

Why it fails: The metastore is the deployment-level container that holds all catalogs. While it is the foundation for the entire Unity Catalog setup, it is not used for day-to-day data governance or organizing data assets into manageable units. The Catalog is the appropriate level for managing functional data boundaries and access.

The user can access the table because of the CATALOG-level SELECT grant.

Why it fails: Granular object-level permissions in Unity Catalog take precedence over broader, container-level permissions. Even though the catalog grant is wide, the revocation on the specific table is a targeted restriction that effectively blocks access for any member of the group, which is the desired behavior for securing sensitive data assets.

The user is prompted for credentials to override the REVOKE.

Why it fails: There is no mechanism in Unity Catalog for users to manually override security policies or revoke their own restrictions. Access control is strictly managed by administrators, and the system evaluates permissions automatically based on the configured policy hierarchy without user intervention or the possibility of ad-hoc credential-based overrides.

The user can query the table, but the sensitive columns are masked.

Why it fails: The command in the exhibit is a full REVOKE on the table, not a column-level masking operation. A REVOKE command removes all access to the object entirely, preventing the user from even seeing the table metadata, let alone querying the data within it or seeing any masked columns.

Workspace Admin.

Why it fails: The Workspace Admin is limited to managing resources within a specific workspace. Unity Catalog is a metastore-level construct, which exists above the workspace level. Therefore, workspace-level permissions are insufficient for creating catalogs that span across multiple workspaces and projects, necessitating higher-level privileges within the Unity Catalog metastore configuration.

Account Admin.

Why it fails: While the Account Admin manages the overall cloud account, the creation of catalogs is specifically a metastore-level function. While an Account Admin might be a Metastore Admin, the role specifically required for catalog management within Unity Catalog is the Metastore Admin, not the generic cloud platform account administrator.

Owner of the current schema.

Why it fails: The owner of a schema only has permissions within that specific schema. They cannot create new catalogs as that involves defining a parent object in the Unity Catalog hierarchy. Allowing schema owners to create catalogs would lead to a chaotic and ungoverned data environment, violating core security principles.

Grant the UNMASK privilege on the table to 'hr_group'.

Why it fails: The UNMASK privilege is not a standard Unity Catalog privilege for column masks. While some systems have similar concepts, in Unity Catalog the mask function itself must implement the conditional logic. Granting UNMASK is not a valid step and would not achieve the requirement.

Create a row filter that allows 'hr_group' to see all rows and apply it to the table.

Why it fails: A row filter controls which rows are visible, not which column values are masked. The requirement is column-level masking, so a row filter is the wrong tool. It would not affect the masking of the 'email' column for other users.

Grant EXECUTE on the mask function to 'hr_group' only.

Why it fails: Granting EXECUTE on the mask function to 'hr_group' does not control who sees unmasked data. The mask function is applied to all users who query the column; the function itself must implement the logic to return unmasked values for 'hr_group'. EXECUTE privilege is needed for the function to run, but it does not bypass the mask.

Configure the storage credential with the CMK key vault URI.

Why it fails: Storage credentials are used to authenticate to cloud storage, not to configure encryption keys. The CMK is configured at the metastore level or on the storage account itself, not within the storage credential. This action would not enable CMK encryption for the metastore.

Enable CMK on each external location's underlying storage.

Why it fails: External locations point to external storage that may be outside the metastore's control. While CMK can be enabled on those storage accounts, it is not required for encrypting the metastore's internal data. The question focuses on the metastore, so this action is not necessary.

Apply a cluster policy that enforces CMK encryption for all clusters.

Why it fails: Cluster policies control cluster configurations, such as instance types and libraries, but they do not manage encryption keys for data at rest. CMK encryption is configured at the storage and metastore level, not via cluster policies. This action would not achieve the encryption goal.

GRANT SELECT ON TABLE main.sales.sales TO analysts WHERE region = current_user();

Why it fails: GRANT statements in Unity Catalog do not support WHERE clauses. Permissions are granted on the entire object, not on a subset of rows. Row-level filtering must be implemented with row filter functions, not through GRANT syntax.

ALTER TABLE main.sales.sales ADD CONSTRAINT region_check CHECK (region = current_user());

Why it fails: CHECK constraints enforce data integrity at write time, not read-time access control. They cannot reference session functions like current_user(), and they would reject valid inserts from other users rather than filtering rows per user. Row-level security requires row filters, not constraints.

CREATE VIEW main.sales.sales_filtered AS SELECT * FROM main.sales.sales WHERE region = current_user();

Why it fails: This creates a view that compares the region column to the current user's name, not their assigned region attribute. It also does not enforce the policy on the base table; users could still query the base table directly if they have SELECT permission. Row filters are the correct mechanism for dynamic row-level security.

Enable versioning on the S3 bucket to support time travel.

Why it fails: S3 bucket versioning is not required for Unity Catalog external locations or Delta Lake time travel. Delta Lake time travel uses its own transaction log, not S3 versioning. Enabling versioning is unnecessary and does not contribute to the required setup.

Attach a bucket policy to the S3 bucket that allows the IAM role to access the bucket.

Why it fails: A bucket policy is not strictly required if the IAM role has the necessary permissions. The IAM role's identity-based policy can grant access. Bucket policies are an alternative or additional control, but not a mandatory step for configuring an external location in Unity Catalog.

Grant the IAM role kms:Decrypt on the KMS key if the S3 bucket is encrypted with SSE-KMS.

Why it fails: While kms:Decrypt is necessary for SSE-KMS encrypted buckets, the question does not specify that the bucket is encrypted with SSE-KMS. This action is conditionally required, not universally required for all external locations. Therefore, it is not one of the two required actions in this scenario.

Use row-level filters in Unity Catalog by defining a filter function that restricts rows based on group membership, applied directly to the table.

Why it fails: Row-level filters in Unity Catalog restrict which rows a user can see at query time, but they still return individual rows that pass the filter. The security team requires only aggregated statistics, not any individual rows. Even with a filter that excludes sensitive rows, analysts could still see non-sensitive individual records, which does not satisfy the aggregate-only requirement.

Grant SELECT on the table to analytics_group but revoke SELECT on all columns except non-sensitive ones, and instruct analysts to use aggregate functions in their queries.

Why it fails: Column-level grants can restrict access to specific columns, but analysts would still see individual rows for the allowed columns, not aggregated statistics. Moreover, relying on analysts to voluntarily use aggregate functions is not enforceable and could lead to exposure of row-level data. This approach does not guarantee aggregate-only access and is insecure for the scenario.

Apply a dynamic view on the table using CURRENT_USER() in the view definition and grant SELECT on the view to analytics_group.

Why it fails: A dynamic view can filter rows based on the current user, but it does not provide aggregated statistics; it only returns filtered rows. The requirement is to show only aggregated data, not individual rows. A view that filters by CURRENT_USER() would still expose row-level data to analytics_group, violating the need for aggregated-only access. Thus, a dynamic view alone fails to meet the scenario.

The external location path must be granted to the service principal using a storage credential, not directly via GRANT statements.

Why it fails: External locations are granted to principals using GRANT statements on the external location object; storage credentials are used to access cloud storage but are not granted directly to users for file access. The GRANT statement syntax is correct. The missing piece is likely a table-level privilege, not the method of granting the external location.

The service principal lacks the CREATE TABLE privilege on the schema containing the external table.

Why it fails: CREATE TABLE privilege is needed to create new tables, but the external table already exists. The issue is writing data to an existing table. While schema-level privileges are important, the error described is about writing to the table, not creating it. The missing privilege for write operations on the data files is more directly related to the external location or table-level grants.

The service principal must also be granted USAGE on the catalog and schema, but that alone is insufficient for write access.

Why it fails: USAGE on catalog and schema is required to access any object within them, but it does not grant write permissions. The service principal likely already has USAGE if it can read. The problem is specifically about writing, which requires MODIFY on the table. This option correctly notes insufficiency but does not identify the actual missing privilege.

Create a storage credential that has access to the entire S3 bucket, and grant it to the group `dept_finance`.

Why it fails: Storage credentials are used to authenticate to cloud storage and are referenced by external locations. They are not granted directly to groups. Granting a storage credential to a group does not provide file access; it only allows the group to create external locations if they have CREATE EXTERNAL LOCATION privilege. The group needs permissions on external locations, not the credential itself.

Create a storage credential that has read and write access to the entire bucket, and grant USAGE on it to `dept_finance`.

Why it fails: USAGE on a storage credential allows a principal to reference it when creating external locations, but it does not grant file access. The group would still need external locations and file-level privileges. Granting USAGE on the credential does not provide read or write permissions on the S3 paths. Therefore, this action alone does not achieve the goal.

Grant MODIFY on all tables in the `finance` schema to `dept_finance`.

Why it fails: MODIFY on tables grants the ability to modify table data via SQL, but the requirement is about direct file access to S3. The group needs file-level permissions on external locations to read and write files directly, not table-level privileges. Moreover, the scenario does not mention any tables; it focuses on files in the bucket. Thus, this action is irrelevant.

The table is a Unity Catalog managed table, and the engineer did not grant the recipient's metastore access to the storage credential.

Why it fails: Delta Sharing abstracts storage access; the recipient does not need direct access to the storage credential or the underlying cloud storage. The share provider's Unity Catalog manages storage access. The recipient accesses the data through the Delta Sharing protocol, not by directly reading files. Therefore, granting storage credential access is not required and not the cause.

The partner's Databricks workspace is not in the same cloud region as the share provider, causing network latency.

Why it fails: Delta Sharing is designed to work across cloud regions and even across clouds. Network latency might affect performance but would not prevent querying the table entirely. The partner can see the share, indicating connectivity is established. The issue is more likely related to permissions or configuration, not region. Therefore, this is not the most likely cause.

The partner has not been granted USAGE on the share, in addition to SELECT on the table.

Why it fails: In Delta Sharing, granting SELECT on the share (or on the table within the share) is typically sufficient for the recipient to query the table. There is no separate USAGE privilege on shares. The recipient must have the share assigned to them, which is done via the recipient definition. If they can see the share, they likely have the necessary privileges. Thus, missing USAGE is not the cause.

The storage credential must be defined with a path to the S3 bucket, and that path must be registered in the metastore.

Why it fails: A storage credential does not contain a path; it only contains the IAM role information. Paths are specified in external locations, which reference the storage credential. Registering paths in the metastore is not a requirement for the storage credential itself.

The storage credential must include the AWS secret access key and access key ID for an IAM user with permissions to the S3 bucket.

Why it fails: Unity Catalog storage credentials for AWS use IAM roles, not long-term IAM user credentials. Storing secret access keys is insecure and not supported for storage credentials. The correct approach is to use an IAM role with a trust relationship to the Databricks control plane.

The storage credential must be associated with a specific external location, and the external location must be created before the storage credential.

Why it fails: The storage credential is an independent object that can be referenced by multiple external locations. It does not need to be associated with a specific external location at creation. In fact, you typically create the storage credential first, then create external locations that reference it.

Apply a static mask using a custom UDF during data ingestion.

Why it fails: Static masking during ingestion permanently alters the data, which is detrimental for downstream users who may require the raw values for legitimate business analysis. This approach lacks the flexibility required for role-based access control and makes it impossible to revert the changes for authorized users without re-processing the entire dataset.

Grant the analyst group SELECT access on the table and instruct them to cast PII columns to null.

Why it fails: Relying on end-users to manually mask their own queries is fundamentally insecure and prone to human error or malicious intent. Data governance requires programmatic enforcement of policies that operate independently of user behavior to maintain regulatory compliance and prevent accidental data leakage across the organization's analytical workflows.

Create separate physical tables for analysts containing only non-sensitive columns.

Why it fails: Creating physical copies for different groups leads to significant data proliferation, increased storage costs, and difficult lineage tracking. Synchronizing these tables whenever the source data updates creates a maintenance nightmare and increases the risk of data inconsistency, making this an unsuitable solution for modern, enterprise-grade data governance strategies.

It forces all data to be stored in a single, centrally managed S3 bucket.

Why it fails: Unity Catalog is designed to manage data across multiple storage locations, including different cloud providers and regions. It acts as a logical governance layer rather than a physical data storage requirement. Forcing data into a single bucket would contradict the principles of cloud-native architecture and limit scalability and performance.

It automatically encrypts all data at rest using customer-managed keys.

Why it fails: While encryption is a critical component of data security, it is typically handled by the cloud provider's storage layer or Databricks platform settings, not by the lineage tracking feature of Unity Catalog. Lineage is focused on metadata and provenance, whereas encryption is a data protection mechanism independent of lineage.

It allows users to manually edit the lineage graph to include external data sources.

Why it fails: Lineage in Unity Catalog is system-generated based on query execution and cannot be manually edited by users. This preserves the integrity of the data provenance information. Allowing manual edits would undermine the auditability and accuracy of the lineage, making it unreliable for regulatory reporting and complex dependency analysis.

Grant the recipient access to the underlying S3 bucket directly.

Why it fails: Delta Sharing is designed to avoid granting external users direct access to the underlying storage buckets. By providing data via the Delta Sharing protocol, you maintain control and security, whereas direct bucket access would bypass all governance, auditing, and fine-grained access control features of the Databricks platform entirely.

Copy the data to a public-facing S3 bucket for easier access.

Why it fails: Copying data to public buckets defeats the purpose of Delta Sharing and creates significant security risks. Delta Sharing is specifically intended to eliminate data replication and keep the source of truth secure. Moving data to public storage makes it vulnerable to unauthorized access and creates an unmanaged data copy.

Workspace-level access control lists.

Why it fails: Access control lists manage permissions on who can perform specific actions in a workspace, but they do not relate to the physical encryption of data at rest. While important for governance, they are a separate concern from data-at-rest encryption provided by cloud-native storage security features and CMK configurations.

Unity Catalog lineage tracking.

Why it fails: Lineage tracking monitors the flow of data but has no impact on the encryption status of the storage layer. It is a metadata management feature that helps with auditing and transparency, rather than a security mechanism for data protection at rest, which is handled at the infrastructure and storage level.

Table access control (TAC).

Why it fails: Table access control regulates who can read or write to a table, but it does not influence how the data is encrypted on the disk. Encryption at rest is an infrastructure-level concern, whereas TAC is an application-level governance policy that operates once the data is already accessible to the engine.