CCNA Account Mgmt Data Governance Questions

SYSADMIN is the predefined role that provides privileges to create and manage warehouses, databases, and other objects. It does not include user or role management, which is handled by SECURITYADMIN and USERADMIN. By granting SYSADMIN to DATA_ENGINEER, the administrator ensures the role can perform its intended tasks without over-privileging it.

SHOW GRANTS TO USER returns the roles granted to a named user, including those inherited through role hierarchies, which is exactly what a compliance audit needs. SHOW GRANTS ON targets object privileges, SHOW ROLES lists role definitions, and SHOW USERS lists user accounts. Only SHOW GRANTS TO USER maps a user to their effective roles.

The SECURITYADMIN role is specifically designed for managing security objects such as roles, grants, and users. This role has the power to grant and revoke privileges to other roles. Keeping this role separate from SYSADMIN (which manages warehouses and databases) is a key governance practice known as Segregation of Duties, ensuring that no single person has unchecked control over both security and data.

Tag-based masking and tag reference auditing together form a scalable governance pattern. Associating masking policies with tags means protection follows the tag wherever it is applied, and TAG_REFERENCES provides the visibility needed to confirm coverage and identify gaps. Manual per-column policies and broad role grants do not scale, and encryption features address a different control objective.

Tri-Secret Secure is the Snowflake feature that allows customers to manage their own encryption keys, providing an extra layer of security beyond Snowflake's standard managed keys. This is critical for highly regulated industries like finance or healthcare that require strict control over data encryption. By using their own keys, customers ensure that even if Snowflake infrastructure were compromised, the data remains inaccessible without the customer-held key materials.

The LOGIN_HISTORY table function in the ACCOUNT_USAGE schema provides a detailed audit trail of all connection attempts to the account. By filtering for the IS_SUCCESS column set to 'NO' and specifying the timeframe, the administrator can effectively monitor for potential brute-force attempts or configuration errors. This is a critical component for maintaining a robust security posture and ensuring compliance with organizational access monitoring policies.

The correct answer is that the WHERE clause is evaluated against masked values. Masking policies transform data at query time, so any filtering or joining on the masked column uses the masked representation. This is a critical concept: masking does not prevent the column from being used in predicates, but it changes the data used for those predicates, which can lead to unexpected results if the user expects to filter on original values.

Dynamic Data Masking is the correct feature because it applies masking policies to columns, dynamically masking data based on the user's role at query time without altering stored data. It provides fine-grained control and is designed for this exact scenario of protecting sensitive columns from unauthorized users.

In Snowflake, the USAGE privilege on a database is insufficient to view objects within schemas; the user must also be granted USAGE on the schema and SELECT on the specific tables or views. This multi-layered privilege requirement is a core component of Snowflake's security model, preventing accidental data exposure by requiring explicit grants at every level of the object hierarchy, from the database down to the individual object.

The QUERY_HISTORY table function and the ACCOUNT_USAGE.QUERY_HISTORY view are the primary methods for auditing query activity. These objects record every query submitted, who submitted it, the warehouse used, and the execution time. This is critical for data governance because it provides a forensic trail for compliance, troubleshooting, and understanding how data is accessed and modified over time by different users.

When a masking policy is applied, Snowflake evaluates the condition at query runtime. If the condition evaluates to FALSE for the current user's role, Snowflake replaces the data with the masked value defined in the policy. This ensures that sensitive data is only revealed to authorized users, protecting the organization from unauthorized data exposure while allowing the schema and query logic to remain unchanged for all users.

Tri-Secret Secure is the Snowflake feature that enables customers to maintain control over their data encryption keys. By combining a customer-managed key with a Snowflake-managed key, the organization ensures that data is encrypted at the storage layer while allowing for key rotation and revocation. This is a vital component for high-compliance industries requiring total control over the data lifecycle and access to encrypted storage buckets.

Snowflake tags record classification metadata on objects such as tables and columns, supporting discovery and reporting. They also integrate with masking policies through tag-based masking, so any column carrying the tag is automatically protected. Tags do not encrypt data, do not grant privileges, and cannot filter rows in a query, making those options incorrect for this governance use case.

Network policies are the primary mechanism for restricting access to Snowflake based on IP addresses. By defining allowed and blocked IP ranges, administrators can protect the account from unauthorized access attempts originating from outside the corporate network. This is a foundational governance task that ensures only trusted traffic can reach the Snowflake service, effectively mitigating risks associated with stolen credentials or external malicious activity.

Row access policies are the Snowflake feature designed to filter rows at query time based on the execution context, such as the current user or role. Because the policy is evaluated dynamically and can join against a mapping table, it enforces per-department visibility transparently: existing SQL statements continue to work, and users see only the rows their department is authorized to view.

A row access policy is designed to filter rows based on a condition evaluated at query time, such as the user's role. By attaching a row access policy to the table, the security team can ensure that PII_ANALYST sees only rows where region equals 'US', while other roles may see different rows or all rows. This avoids data duplication and centralizes access control.

The ACCESS_HISTORY view, introduced to enhance Snowflake's governance capabilities, provides a comprehensive log of every object access event. It records which columns were queried and which tables were accessed by specific users. This tool is essential for compliance, allowing administrators to audit who accessed sensitive data and when, fulfilling regulatory requirements like GDPR or HIPAA that demand strict tracking of data usage.

To allow a role to view all queries executed in the account, the MONITOR USAGE privilege must be granted. This privilege provides access to the ACCOUNT_USAGE schema, including the QUERY_HISTORY view, which contains records of all queries. Other privileges like USAGE on a database or MANAGE GRANTS do not grant account-wide query visibility.

A robust RBAC model relies on hierarchical structures to simplify management and minimize errors. By granting privileges to roles rather than users, and nesting roles logically, you create a scalable security architecture. These best practices ensure that permissions are easy to audit, follow the principle of least privilege, and prevent 'privilege creep,' where users accumulate excess access rights that are never revoked over time as their roles change.

A masking policy rewrites every reference to the protected column for unauthorized users, including references in ORDER BY. The user therefore sees the masked value and sorting is based on that masked value. The policy is not bypassed by placing the column in a sort clause.

Tags in Snowflake are used to label and categorize data objects for governance, reporting, and cost allocation. By applying a tag to a table or column, an administrator can track sensitive data across the entire account. This allows for automated reporting on data lineage and compliance, enabling teams to quickly identify where PII or other critical information resides for regulatory auditing and risk management purposes.

The CREATE DATABASE privilege is an account-level privilege, so it must be granted with the ON ACCOUNT clause. The SYSADMIN role has the authority to grant this privilege. The correct command is GRANT CREATE DATABASE ON ACCOUNT TO ROLE DB_CREATOR;

Disabling a user with ALTER USER ... SET DISABLED = TRUE immediately blocks authentication while keeping the account, its grants, and its metadata available for audit. Dropping the user or altering credentials does not preserve the account in the desired state, and revoking a role only removes one privilege path rather than blocking sign-in.

Snowflake utilizes a hierarchical RBAC model where privileges are additive. When a role is granted to another role, the parent role inherits all privileges assigned to the child role. This design allows for the creation of functional roles that map to business units or job tasks, ensuring that permissions are managed efficiently and transparently throughout the entire organizational structure of the account.

Time Travel allows for the recovery of data that was accidentally deleted or modified, serving as a critical safety net for data governance. By enabling the retention of historical data, Snowflake empowers administrators to restore states after human error, minimizing data loss and operational downtime. This functionality is essential for maintaining data integrity and business continuity, ensuring that the organization can reliably recover from unintended data lifecycle events without needing to restore from full backups.

A masking policy in Snowflake allows column-level security by dynamically masking data based on the user's role or other conditions. By applying a masking policy to the email column that returns '****' for all roles except 'COMPLIANCE_OFFICER', the data steward ensures that only authorized users see the actual email addresses. This is the correct feature for column-level masking.

Dynamic Data Masking (DDM) provides a centralized way to protect sensitive data by applying masking policies to columns. By using the IS_ROLE_IN_SESSION function within the policy, the system evaluates the user's active role dynamically during query execution. This ensures that only members of the DATA_STEWARD role see unmasked data, while others see the masked output, maintaining governance consistency without needing to physically alter the underlying data storage or create multiple filtered views.

Secure views intentionally hide their definition from users who do not own the view. Even with SELECT privilege, non-owners cannot see the view's SQL definition. This is a key security feature of secure views.

The SECURITYADMIN role is dedicated to the management of users, roles, and grants. By separating administrative duties into distinct roles like SECURITYADMIN (for access) and SYSADMIN (for objects), Snowflake enables a clear separation of concerns. This is a critical governance practice that prevents a single individual from having both the ability to create objects and the ability to assign permissions to those objects, thereby reducing the risk of unauthorized access.

The ORGANIZATIONADMIN (ORGADMIN) role is responsible for managing tasks at the account-level across the entire organization. This includes creating and managing multiple accounts, monitoring organizational usage, and configuring global replication. This role is highly privileged and exists above the ACCOUNTADMIN level, allowing for centralized control over the enterprise's Snowflake footprint while maintaining segregation between different business units or environments within the same organization.

When a Row Access Policy is applied to an existing table, the policy immediately takes effect for all subsequent queries. Any user who runs a query against the table will only see the rows allowed by the policy logic. This is critical for governance because it provides an immediate, retroactive enforcement of security rules without needing to migrate or transform the existing data in the table, ensuring compliance from the moment the policy is activated.

Tag-based masking requires the masking policy to be attached to the tag. Creating both objects without linking them leaves tagged columns unmasked. The fix is to associate the policy with the tag so that every column carrying the tag is automatically protected.

Tag-based masking requires two conditions to be satisfied: the masking policy must be associated with the tag, and the tag must be applied to the target column. If the tag was only created or applied at the table level rather than the column level, Snowflake has no tagged column to protect, so queries return the original values. Verifying the column's tag assignment resolves the issue.

The SYSADMIN role is the standard role for creating and managing data objects such as databases, schemas, tables, and warehouses. It is distinct from the SECURITYADMIN role, which manages user identities and permissions. This separation of duties is a fundamental pillar of Snowflake's security architecture, ensuring that operational and administrative control over data objects is kept separate from the management of user access, thereby mitigating the risk of privilege escalation and internal misuse.

Snowflake provides several layers of defense-in-depth to secure sensitive information. Row Access Policies filter which rows a user can see, while Dynamic Data Masking transforms column data based on user privileges. Using these in combination allows architects to build a highly restrictive environment where users only interact with the exact data subsets and column values they are authorized to access, complying with strict regulatory data privacy standards.

Object change history in the ACCOUNT_USAGE schema records metadata changes such as column additions and drops, with timestamps and deleted markers. This is the correct source for auditing schema evolution. Time Travel and query or access history views serve different purposes and do not provide a structured column change log.

Dynamic Data Masking (DDM) allows centralized management of data access policies based on the user's role. By attaching a masking policy to a column, Snowflake automatically evaluates the user's role at query runtime. This approach is superior to static masking or manual view management because it centralizes governance, minimizes data duplication, and ensures that security policies remain consistent regardless of how the user accesses the underlying table.

Object tagging allows administrators to assign metadata to objects (like tables, columns, or warehouses) to facilitate discovery, tracking, and governance. Tags are useful for identifying sensitive data, tracking costs, or enforcing compliance. This is a crucial feature for large organizations that need to report on data usage, lifecycle, and sensitivity across thousands of objects, making it easier to manage and audit data at scale.

Network Policies are the mechanism to restrict access by IP address. By creating a policy and applying it to a specific user or the entire account, administrators can ensure that connections only succeed from authorized locations. This is a foundational governance practice to protect against unauthorized access from external or insecure network locations, effectively creating a perimeter around the data platform.

Delegating role administration requires the WITH GRANT OPTION clause on a GRANT ROLE statement directed at the user. This lets the grantee grant that specific role onward without needing SECURITYADMIN or USERADMIN. Simply granting the role or altering the default role does not confer grant authority.