SnowPro Advanced: Security Engineer Question 427
Single answerUse Cortex Analyst to support secure data exploration:A healthcare company is piloting Cortex Analyst so business users can ask natural-language questions about claims and member activity. The security team must ensure the pilot does not expose PHI beyond each user's existing Snowflake permissions. Analysts will query curated semantic models built on top of secure views that already enforce row access and column masking policies. Which approach best supports secure data exploration with Cortex Analyst while preserving existing Snowflake access controls?
- A
Deploy Cortex Analyst against semantic models that reference the secured views, and ensure end users access Analyst with their own Snowflake roles so generated SQL is evaluated under each user's existing policies.
- B
Grant Cortex Analyst a powerful service role with broad access to the underlying tables so it can answer all questions consistently, regardless of the end user's permissions.
- C
Export approved claims data to a separate database dedicated to Cortex Analyst, because Analyst cannot use objects protected by masking or row access policies.
- D
Remove masking policies from sensitive columns in the semantic model and rely on prompt instructions telling users not to ask for PHI.
Show answer and explanation
Correct answer: A
Explanation
The key principle is that Cortex Analyst should be layered on top of already governed Snowflake data models, not used as a reason to weaken controls. In a secure deployment, semantic models reference curated tables or views, and the generated SQL is still subject to Snowflake authorization and policy enforcement. For sensitive data, best practice is to keep controls in the platform using RBAC, secure views, row access policies, and masking policies so natural-language access does not become a side channel around governance. This follows Snowflake's broader security guidance: enforce least privilege, avoid duplicating sensitive data unnecessarily, and rely on centralized data-layer protections instead of application-only guardrails.
- A. Correct.
Correct. The secure design is to expose Cortex Analyst through semantic models built on governed Snowflake objects, such as secure views, while relying on Snowflake's native authorization model. If the underlying views enforce row access and masking policies, and queries run in the requesting user's security context, the generated SQL remains subject to those controls. This aligns with Snowflake best practices: keep governance in the data layer rather than trying to recreate it in the application layer.
- B. Incorrect.
Incorrect. Using a broad service role would bypass least-privilege principles and could allow users to receive answers derived from data they are not personally authorized to access. Even if the application tries to filter results afterward, this is not the recommended security pattern. For secure exploration, access should be constrained by the same role-based and policy-based controls that govern direct SQL access.
- C. Incorrect.
Incorrect. This reflects a common misconception. Snowflake governance features such as masking policies and row access policies are designed to protect data in-place. Creating duplicate datasets for Cortex Analyst increases operational risk, creates synchronization challenges, and weakens governance. Cortex Analyst is intended to work with governed Snowflake data rather than requiring policy-free copies.
- D. Incorrect.
Incorrect. Prompt instructions are not a substitute for enforceable security controls. Removing masking policies would materially weaken protection of PHI. Security for Cortex Analyst should rely on Snowflake-native controls such as role-based access, secure views, masking policies, and row access policies, not on user compliance with instructions.