SnowPro Advanced: Security Engineer Question 194
Select 2Configure automatic, custom, and manual classificationsA financial services company stores customer data in Snowflake and wants to accelerate governance for a newly onboarded raw ingestion schema. The security engineer must identify sensitive columns quickly, add a business-specific label for internal employee IDs that Snowflake will not detect out of the box, and allow stewards to directly tag a few exceptional columns that were missed by automated processes. Which combination of approaches should the engineer use to meet these requirements with the LEAST operational overhead?
- A
Run Snowflake automatic sensitive data classification on the schema to detect supported sensitive data types, create a custom classification instance for the employee ID pattern, and use manual classification/tagging for exception columns.
- B
Create only masking policies on all raw tables, because masking policies automatically classify columns and assign system tags during query execution.
- C
Use manual classification for the entire schema, because automatic classification cannot be run at schema scope and custom classification replaces the need for any manual review.
- D
Use automatic classification to discover supported sensitive data, define a custom classification for the company-specific employee ID pattern, and manually assign tags to the small number of columns requiring steward override.
- E
Rely exclusively on custom classification, because custom classifiers can detect all built-in Snowflake sensitive categories and also apply steward-reviewed overrides without manual action.
Show answer and explanation
Correct answers: A, D
Explanation
The best practice in Snowflake is to combine classification methods based on the use case. Automatic sensitive data classification is intended to identify supported sensitive data types at scale with low operational effort. Custom classification is used when an organization needs to recognize proprietary or domain-specific patterns that are not covered by Snowflake's built-in classifiers, such as internal employee IDs. Manual classification or direct tag assignment remains important for exceptions, false negatives, or steward-directed overrides.
In practice, security engineers commonly run automatic classification across new schemas or databases, review results, add custom classification logic for business-specific identifiers, and then manually adjust tags on a limited set of columns. This approach minimizes manual work while preserving accuracy and governance control. Snowflake documentation on sensitive data classification and tag-based governance supports this layered approach: use built-in classification where possible, extend with custom classification where needed, and rely on manual stewardship for special cases.
- A. Correct.
Correct. This combines the three relevant approaches appropriately: automatic classification for built-in/supported detections, custom classification for organization-specific patterns such as employee IDs, and manual action for exceptional cases. This is aligned with how Snowflake supports data discovery and governance with the least overhead compared to fully manual review.
- B. Incorrect.
Incorrect. Masking policies protect data access after sensitive columns are identified, but they do not perform classification by themselves. A common misconception is to treat masking as a discovery mechanism. Classification and tagging are separate from applying masking policies, although detected tags can later be used to drive masking.
- C. Incorrect.
Incorrect. Automatic classification can be applied across broader object scopes such as schemas/tables, so saying it cannot be used at schema scope is false. Also, custom classification does not eliminate the need for manual review in edge cases; stewards often need to inspect or override results for missed or exceptional columns.
- D. Correct.
Correct. This option accurately describes the recommended practical workflow: use Snowflake automatic classification for supported sensitive categories, extend detection with custom classification for business-specific data patterns, and manually assign tags/classifications where human judgment or exceptions are needed.
- E. Incorrect.
Incorrect. Custom classification extends detection for patterns not covered by built-in capabilities, but it does not replace all built-in automatic classifications, nor does it remove the need for manual overrides. Another misconception here is that custom classification inherently performs steward-reviewed override logic automatically, which it does not.