DEA-C02 Data Governance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The row access policy is defined with a subquery that returns multiple rows for a given user, causing the policy to evaluate to false.

  Why it's wrong here

  Row access policies must return a boolean expression. If the subquery returns multiple rows, Snowflake would raise an error about subquery returning more than one row, rather than silently returning no rows. The policy expression must be scalar. Therefore, this would cause a query failure, not empty results. The issue described is more likely a logic mismatch that results in no matching rows for certain users.

• ✓

  The row access policy uses a mapping table that is not qualified with the database and schema, and the user's session does not have the correct current database and schema set.

  Why this is correct

  If the policy references the mapping table without fully qualifying it (e.g., using just TENANT_MAPPING instead of DB.SCHEMA.TENANT_MAPPING), the resolution depends on the session's current database and schema. Users with different session contexts might resolve the table incorrectly, leading to no matching rows. This is a common pitfall. Fully qualifying objects in policies ensures consistent behavior regardless of session settings, which is why this is the most likely cause.

• ✗

  The row access policy uses CURRENT_USER() to filter, but the mapping table maps roles to tenants, not users.

  Why it's wrong here

  If the mapping table maps roles to tenants and the policy uses CURRENT_USER(), the join would not match any rows because the mapping table does not contain user names. This would result in no rows for all users, not just some. The scenario states that some users should have access, implying that the mapping table is correctly populated for those users. If the policy used the wrong column, it would consistently fail for everyone, not selectively.

• ✗

  The row access policy is defined with a subquery that references the mapping table, but the policy owner does not have the necessary privileges to access the mapping table.

  Why it's wrong here

  While privileges are important, if the policy owner lacked access to the mapping table, the policy would likely return an error rather than no rows. Snowflake requires that the policy owner has access to any objects referenced in the policy. However, the symptom of returning no rows suggests a logic issue, not a privilege error. If privileges were missing, queries would fail with an error message, not silently return empty results.