SnowflakeProfessional levelPage 2 of 5

SnowPro Advanced: Security Engineer exam dumps: questions 101 to 200 of 431

Page 2 of the free SnowPro Advanced: Security Engineer question bank for the SnowPro® Advanced: Security Engineer exam. Questions 101 to 200 are listed below, the first 5 in full with answers and explanations. Back to page 1 for the exam overview and FAQ.

Question bank last updated April 2026

Start timed practice exam Questions 101 to 200

Free SnowPro Advanced: Security Engineer practice questions

Questions 101 to 105 of 431

Pick an answer before you open the explanation. Each question also has its own page with a permalink.

SnowPro Advanced: Security Engineer Question 101

Single answerConfigure external functions

A security engineer is implementing a Snowflake external function that sends customer identifiers to a tokenization service hosted behind a cloud API gateway. The company requires that Snowflake authenticate to the remote service without embedding static secrets in function definitions, and the security team wants outbound access tightly scoped to only the approved endpoint. Which configuration best meets these requirements?

A
Create an API integration that references the allowed API gateway prefix and a cloud provider token configuration, then create the external function using that API integration.
B
Create a network policy that allows Snowflake egress only to the tokenization endpoint, then attach the policy to the external function.
C
Store the tokenization service credentials in a Snowflake secret and reference the secret directly in the external function definition.
D
Use a secure UDF instead of an external function so Snowflake can call the remote HTTPS endpoint without additional integration objects.

Show answer and explanation

Correct answer: A

Explanation

For external functions, Snowflake requires an API integration that defines how Snowflake communicates with an external proxy service such as Amazon API Gateway, Azure API Management, or Google Cloud API Gateway/Cloud Run-based proxy patterns, depending on the cloud architecture. From a security perspective, the API integration is the correct place to restrict allowed outbound endpoint prefixes and configure authentication between Snowflake and the cloud provider service. This is preferable to embedding static credentials in SQL definitions and supports least-privilege outbound access. Network policies are for controlling inbound client access to Snowflake accounts, not outbound calls made by Snowflake. Likewise, secure UDFs do not replace the external function architecture. Best practice is to use API integrations with tightly scoped allowed URL prefixes and cloud-native authentication supported by Snowflake external functions.

A. Correct.
Correct. External functions are configured through an API integration, which is the Snowflake object used to define and secure communication with a proxy service such as a cloud API gateway. The API integration can restrict outbound calls to specific allowed URL prefixes and can be configured to use cloud-native authentication mechanisms rather than hardcoding credentials in the function definition. This aligns with least privilege and avoids embedding static secrets in SQL objects.
B. Incorrect.
Incorrect. Network policies in Snowflake control client access to Snowflake based on IP rules; they do not govern Snowflake's outbound connectivity for external functions. A common misconception is to treat network policies as general-purpose egress controls, but outbound access for external functions is controlled through the API integration's allowed prefixes and the cloud-side proxy configuration.
C. Incorrect.
Incorrect. Secrets are used with other Snowflake features such as external network access for procedures and functions in supported runtimes, not as the standard mechanism for authenticating external functions. External functions rely on an API integration and a supported proxy service. Referencing a secret directly in the external function definition is not how external function authentication is configured.
D. Incorrect.
Incorrect. Secure UDFs protect the function definition and can help with data governance, but they do not provide a way to invoke arbitrary remote HTTPS services. Calling remote services from Snowflake in this pattern requires an external function backed by an API integration and proxy service, not a standard or secure UDF alone.

SnowPro Advanced: Security Engineer Question 102

Single answerDomain 2.0: Data Protection, Data Privacy, and Data Governance (30%)

A healthcare company stores patient records in Snowflake. Analysts in the ANALYST role need to query a PATIENT_VISITS table for operational reporting, but they must not see full Social Security numbers or full dates of birth. A small compliance team in the COMPLIANCE role must retain access to the unmasked values for investigations. The security engineer wants a solution that is centrally managed in Snowflake, applies automatically at query time, and minimizes changes to analyst SQL. Which approach best meets these requirements?

A
Create a masking policy that conditionally reveals SSN and DOB only when CURRENT_ROLE() is COMPLIANCE, and apply the policy to the sensitive columns in PATIENT_VISITS.
B
Encrypt the SSN and DOB columns with client-side encryption before loading, then grant analysts access to the encrypted columns and let COMPLIANCE decrypt values outside Snowflake when needed.
C
Create a secure view over PATIENT_VISITS that excludes the SSN and DOB columns for analysts, and grant COMPLIANCE direct access to the base table.
D
Use row access policies to hide rows containing SSN and DOB from analysts while allowing COMPLIANCE to see all rows.

Show answer and explanation

Correct answer: A

Explanation

The best answer is to use a masking policy applied to the sensitive columns. In Snowflake, dynamic data masking is the appropriate control when different users or roles should see different representations of the same column values at query time. This is a strong fit for privacy-sensitive environments such as healthcare, where analysts often need operational access without exposure to direct identifiers, while authorized compliance personnel need full visibility.

Why this is the best fit:

It is centrally managed in Snowflake as a policy object.
It applies automatically at query time to protected columns.
It minimizes application and SQL changes because users continue querying the same table.
It supports role-aware logic, commonly implemented with context functions such as CURRENT_ROLE() or policy mappings.

Why the other choices are weaker:

Client-side encryption protects data differently and is not a substitute for role-based masking inside Snowflake.
Secure views can help with data sharing and governance, but they are not the most direct or scalable answer when the requirement is conditional masking of specific columns with minimal query changes.
Row access policies are for row-level visibility decisions, not for masking column values.

This aligns with Snowflake best practices for protecting sensitive data using dynamic data masking for column-level protection and row access policies for row-level restrictions. Secure views are valuable in some architectures, but the exam typically expects candidates to match the control to the requirement precisely: masking policy for conditional column obfuscation, row access policy for row filtering.

A. Correct.
Correct. Dynamic data masking in Snowflake is designed for exactly this use case: protecting sensitive column values at query time based on the querying context, such as role. A masking policy can return fully visible values for the COMPLIANCE role and masked or transformed values for the ANALYST role, with minimal or no changes to analyst queries because the policy is attached directly to the columns. This provides centralized governance and consistent enforcement wherever the protected columns are queried.
B. Incorrect.
Incorrect. Client-side encryption can protect data before it enters Snowflake, but it does not provide centralized, query-time role-based masking within Snowflake. Analysts would still see encrypted data rather than usable masked values, and COMPLIANCE would need external decryption workflows. This adds operational complexity and does not meet the requirement to minimize SQL changes while handling access natively in Snowflake.
C. Incorrect.
Incorrect. A secure view can be used to restrict exposed columns, but it is less flexible for this requirement because analysts need to query the table for reporting while still potentially using the columns in masked form. A secure view that excludes SSN and DOB removes the columns entirely rather than masking them. Also, maintaining parallel access paths between views and base tables is less centralized and can increase governance complexity compared to attaching masking policies directly to the sensitive columns.
D. Incorrect.
Incorrect. Row access policies determine which rows are visible, not how individual column values are transformed. In this scenario, analysts should still see the patient visit rows, just not the full SSN or DOB values. Using a row access policy would address row-level filtering, which is the wrong control for a column-level privacy requirement.

SnowPro Advanced: Security Engineer Question 103

Single answerDomain 2.0: Data Protection, Data Privacy, and Data Governance (30%)

A healthcare company stores patient records in Snowflake. A SECURITYADMIN needs to let an external research partner query a de-identified view of the data, while ensuring that users from the partner can only see rows for studies assigned to their organization and cannot view direct identifiers such as patient name, email, or SSN. The company wants the controls to be enforced centrally so that analysts do not need to rewrite filters in every query. Which combination of Snowflake features should be implemented to meet these requirements?

A
Create a secure view for the shared dataset, apply a row access policy to restrict rows by the partner organization, and apply a masking policy to direct identifier columns before exposing the data.
B
Use object tags on the patient table to mark sensitive columns and rely on tag inheritance to automatically hide identifiers and restrict rows for each partner organization.
C
Grant the partner role SELECT on the base patient table and require analysts to add WHERE clauses for their organization in each query, while using client-side encryption to protect identifiers.
D
Create a materialized view that excludes direct identifiers and grant the partner role access to it, because materialized views automatically enforce per-organization row filtering for downstream consumers.

Show answer and explanation

Correct answer: A

Explanation

The best answer is to combine a secure view, a row access policy, and a masking policy. In Snowflake, row access policies are designed for centralized row-level security, allowing access decisions to be evaluated at query time based on execution context. Masking policies are designed for centralized column-level protection of sensitive fields such as PII. Secure views are commonly used when sharing governed subsets of data because they help protect business logic and provide a cleaner abstraction layer over protected objects. Tags are valuable for data classification and can support governance programs, but they are not by themselves an enforcement mechanism for row-level security. Likewise, relying on analysts to manually filter rows is not a strong security design. This aligns with Snowflake best practices for layered data protection and privacy controls in regulated environments.

A. Correct.
Correct. This combines the right Snowflake governance controls for the scenario. A secure view is appropriate when exposing governed data to external consumers because it helps protect underlying logic and limits certain metadata exposure. A row access policy centrally enforces row-level filtering based on the querying context, such as the partner organization mapped to the current role or user. A masking policy de-identifies or redacts direct identifiers like patient name, email, and SSN. Together, these controls meet the requirement for centralized enforcement without depending on analysts to manually add filters.
B. Incorrect.
Incorrect. Tags are useful for classification, discovery, and governance workflows, and Snowflake supports tag-based masking in some governance designs. However, tags by themselves do not automatically hide data or enforce row-level restrictions. Tag inheritance does not implement dynamic row filtering. You still need explicit enforcement mechanisms such as masking policies and row access policies.
C. Incorrect.
Incorrect. Granting access to the base table and relying on analysts to write WHERE clauses does not provide centralized enforcement and is error-prone. It violates the requirement that controls should not depend on users remembering to filter correctly. Client-side encryption also does not solve the need for governed, query-time de-identification and row-level restriction within Snowflake.
D. Incorrect.
Incorrect. A materialized view can precompute results for performance, but it does not automatically enforce per-organization row-level security. If row-level restrictions are needed, they must be implemented through supported policy mechanisms such as row access policies. Excluding identifier columns from a materialized view helps reduce exposure, but it does not satisfy the requirement to centrally enforce access by organization.

SnowPro Advanced: Security Engineer Question 104

Single answer2.1 Implement data security features.

A healthcare company stores PHI in a Snowflake table named PATIENT_VISITS. Analysts in the ANALYST role should be able to query diagnosis trends by region, but they must not see direct identifiers such as patient name, SSN, or full date of birth. A small compliance team in the COMPLIANCE role must retain full access to all columns. The security engineer wants to enforce this inside Snowflake with minimal application changes and ensure protection remains in place regardless of which BI tool or worksheet is used. Which approach BEST meets these requirements?

A
Create a secure view that excludes sensitive columns and grant ANALYST access only to the view, while granting COMPLIANCE access to the base table.
B
Apply masking policies to the sensitive columns and configure the policy logic to reveal clear text only for the COMPLIANCE role and return masked or transformed values for other roles.
C
Encrypt the sensitive columns with client-side encryption before loading them into Snowflake so only COMPLIANCE can query the original values.
D
Use a row access policy on PATIENT_VISITS to hide columns such as patient name and SSN from the ANALYST role.

Show answer and explanation

Correct answer: B

Explanation

The best solution is to use Snowflake dynamic data masking through masking policies on sensitive columns. This directly addresses column-level protection for PHI/PII while allowing different roles to see different representations of the same data. In this scenario, COMPLIANCE can see clear text, while ANALYST can receive masked values or less identifying transformations. This approach is enforced within Snowflake and applies regardless of the client tool, which matches the requirement for centralized, consistent enforcement with minimal application changes.

Why not the others? Secure views can help by projecting only non-sensitive columns, and secure views are useful when you want to prevent exposure of underlying query details and control object access. However, they often require consumers to switch to a different object and are less flexible when the same table must serve multiple audiences with different column visibility rules. Row access policies are for filtering rows, not masking columns. Client-side encryption is not a practical replacement for Snowflake-native conditional access control because it shifts complexity to applications and removes Snowflake's ability to apply policy logic by role.

Relevant Snowflake guidance includes the use of masking policies for dynamic data masking and row access policies for row-level security. Secure views are also documented for controlled data sharing and limiting exposure, but for this scenario, masking policies are the most appropriate data security feature to implement.

A. Incorrect.
This can reduce exposure, but it is not the best answer for the stated requirement. A secure view can hide columns if analysts are restricted to the view and denied direct access to the base table. However, the requirement is to enforce protection inside Snowflake with minimal application changes and ensure consistent protection regardless of access path. Dynamic data masking is designed specifically for column-level protection and can be applied directly to sensitive columns on the base table, avoiding the need to refactor consumers to use a separate object. Secure views are valuable, but they are not the most direct fit for protecting specific columns while preserving base-table access patterns.
B. Correct.
This is correct. Masking policies in Snowflake provide dynamic data masking at the column level. The policy can inspect the current role or context and return full values for COMPLIANCE while masking, nulling, or partially transforming values for ANALYST and other roles. Because the policy is attached to the columns themselves, the protection is enforced consistently across supported query interfaces, tools, and SQL clients. This is a common best practice for protecting PII/PHI when different roles need different levels of visibility into the same table.
C. Incorrect.
This is incorrect. Client-side encryption before loading would make the original values unreadable inside Snowflake unless the application decrypts them externally. That adds operational complexity and does not align with the requirement for minimal application changes. It also prevents Snowflake-native policy-based conditional reveal by role. Snowflake already encrypts data at rest and in transit, but conditional column visibility for different users is typically implemented with masking policies rather than external client-side encryption schemes.
D. Incorrect.
This is incorrect. Row access policies control which rows are visible to a query based on context; they do not mask or hide specific columns. Someone might choose this option because row access policies are another Snowflake governance feature, but they solve a different problem: row-level filtering, not column-level redaction of identifiers like SSN or DOB.

SnowPro Advanced: Security Engineer Question 105

Single answer2.1 Implement data security features.

A healthcare company stores patient data in Snowflake. Analysts in the ANALYST role must be able to query de-identified patient records, while a small PRIVACY_ADMIN role must be able to view full values for columns such as SSN and EMAIL when needed for approved investigations. The security team wants a solution that minimizes application changes, enforces protection centrally in Snowflake, and continues to protect data even if analysts create new views on top of the table. Which Snowflake approach best meets these requirements?

A
Apply a masking policy to the sensitive columns and use CURRENT_ROLE() or IS_ROLE_IN_SESSION() logic so PRIVACY_ADMIN can see unmasked values while ANALYST sees masked values
B
Encrypt the sensitive columns with client-side encryption before loading them into Snowflake, and let PRIVACY_ADMIN decrypt them outside Snowflake when needed
C
Create a secure view that excludes sensitive columns for ANALYST, and grant direct access to the base table only to PRIVACY_ADMIN
D
Use row access policies on the patient table to hide SSN and EMAIL from ANALYST while allowing PRIVACY_ADMIN to see all column values

Show answer and explanation

Correct answer: A

Explanation

The best answer is to use Snowflake dynamic data masking via masking policies on the sensitive columns. This is the native Snowflake feature for column-level protection of sensitive data such as PII. It allows organizations to define a centralized policy once and apply it directly to columns, with logic based on role context or other conditions. This is especially appropriate when some users should see masked values while a privileged role can see full values. In Snowflake best practice, row access policies are for row-level filtering, while masking policies are for column-level obfuscation. Secure views can help with controlled exposure, but they are not a substitute for masking when the requirement is durable protection attached to the data element itself. Relevant Snowflake documentation areas include Dynamic Data Masking, Masking Policies, conditional policy expressions using role-context functions, and Row Access Policies for comparison.

A. Correct.
Correct. Dynamic data masking in Snowflake is designed to protect sensitive column values centrally at query time. A masking policy can be attached directly to columns such as SSN and EMAIL, and the policy body can evaluate the active role context using functions such as CURRENT_ROLE() or IS_ROLE_IN_SESSION() to determine whether to reveal or mask the data. Because the policy is attached to the column, the protection persists through downstream queries and views, helping ensure analysts do not bypass masking by creating new views.
B. Incorrect.
Incorrect. Client-side encryption can protect data before it reaches Snowflake, but it does not meet the requirement for centralized, role-based, in-platform selective disclosure with minimal application changes. It would require external decryption workflows and likely significant application or process changes. It also prevents Snowflake from natively applying policy-based, context-aware masking to the plaintext values.
C. Incorrect.
Incorrect. A secure view can help restrict exposed columns, but this approach does not provide the same centralized column-level protection as masking policies attached to the base table columns. If analysts later gain access to other derived objects or if governance expands, the protection is not as inherently persistent as a masking policy on the columns themselves. Secure views are useful, but they are not the best fit for the stated requirement that protection continue even when users create new views on top of the table.
D. Incorrect.
Incorrect. Row access policies control which rows are visible to a query based on a policy expression; they do not mask or selectively hide individual column values within visible rows. This option reflects a common misconception between row-level security and column-level protection. For SSN and EMAIL, a masking policy is the appropriate feature.

Timed practice exam

Take a SnowPro Advanced: Security Engineer practice test under exam conditions

65 questions in 115 minutes, drawn from this bank, with a score report and a per-question review when you finish.

Start timed exam

SnowPro Advanced: Security Engineer practice questions 101 to 200 of 431

Every question has a page with the answer and explanation. Numbers are stable, so you can bookmark or share them. The bank is split into 5 pages of up to 100 questions.