Account Security and Data Protection: free practice questions

SYSTEM$GET_TAG is the correct function to retrieve the value of a specific tag on a specific object in real time. It accepts the fully qualified tag name, the fully qualified object name, and the object type ('table', 'column', etc.), returning the tag value or NULL if not set. Option A references ACCOUNT_USAGE.TAG_REFERENCES, which is a valid view but has up to a 2-hour data latency (as with all ACCOUNT_USAGE views) and is better suited for bulk auditing rather than immediate verification. Option C is incorrect: INFORMATION_SCHEMA.TAGS is the view for listing tag definitions (metadata about the tags themselves), not for querying which tags are applied to which objects. Option D is incorrect: SNOWFLAKE.ACCOUNT_USAGE.OBJECT_TAGS is not a standard Snowflake view name; the correct view for tag assignments is TAG_REFERENCES.

ACCESS_HISTORY (available on Business Critical and higher) records the base objects accessed by each query, including the specific columns that were read (projected), not just the table. It captures direct object access and lineage down to the column level, making it the correct view for this use case. QUERY_HISTORY records query text and metadata (execution time, bytes scanned, etc.) but does not enumerate which specific columns were accessed. LOGIN_HISTORY tracks authentication events, not data access. OBJECT_DEPENDENCIES tracks compile-time dependencies between objects (e.g., views referencing tables), not runtime column-level access.

GCP Private Service Connect (PSC) provides a private network path between a customer's VPC and Snowflake's GCP endpoint, ensuring traffic never traverses the public internet—exactly what the policy requires. A network policy IP allowlist restricts who can connect but still routes traffic over the public internet. AWS PrivateLink is an AWS-specific service and cannot be used for GCP-hosted Snowflake accounts. TLS encryption secures data in transit but does not change the routing path; traffic still crosses the public internet.

The APPLY privilege on a masking policy controls which roles can attach or detach the policy from columns. By granting APPLY only to the DATA_GOVERNANCE_ROLE and revoking it from SYSADMIN (using ALTER ACCOUNT to prevent SYSADMIN from managing policies), you ensure that only approved governance principals can remove or change the policy assignment. Option B is incorrect: FORCE is not a valid parameter for CREATE MASKING POLICY in Snowflake; there is no such immutability flag. Option C is incorrect: RESTRICT = TRUE is not a valid clause for attaching masking policies; it does not exist in Snowflake DDL for this purpose. Option D is partially correct in that tag-based masking ties the policy to the tag, but the tag assignment itself can still be modified by anyone with APPLY TAG privilege, so it does not fully enforce the governance approval requirement without also controlling that privilege.

In Snowflake, a network policy assigned at the account level applies to all users, including ACCOUNTADMIN. However, a user-level network policy overrides the account-level policy for that specific user. By assigning a separate, unrestricted (or broader) network policy directly to ACCOUNTADMIN users, those users bypass the account-level restriction. Option A is wrong because ACCOUNTADMIN is NOT automatically exempt from network policies. Option C is wrong because SYSADMIN has no special bypass capability for network policies. Option D could work logically but is operationally impractical and still leaves no account-level guardrail, meaning any user without an assigned policy would have no restriction.