Snowflake Security Engineer

Data protection begins with how bytes are stored and who holds the keys. You study encryption in transit and at rest, the key hierarchy and rotation, customer-managed keys, and how retention features can protect and also expose data.

• Encryption at rest and in transit
• The key hierarchy and rotation
• Customer-managed keys and Tri-Secret Secure
• Time Travel and Fail-safe as protection and as exposure
• Protecting data in stages and unloads

You build A data protection design for a sensitive data set, covering keys, encryption and retention.

Privacy controls should follow the data wherever it goes. You find sensitive columns with classification, tag them, and apply masking, row access, aggregation and projection policies so protection holds for every query.

• Finding sensitive data with classification
• Tags and tag-based masking
• Masking policies in practice
• Row access policies
• Aggregation and projection policies
• Privacy-preserving sharing

You build A privacy setup that classifies, tags and masks a data set, tested role by role.

Most breaches begin with a stolen credential. You require multi-factor authentication, connect single sign-on and automatic provisioning, choose the right method for applications and services, and cut off access quickly when someone leaves.

• Multi-factor authentication and enforcement
• SAML single sign-on and SCIM
• OAuth and tokens for applications
• Key-pair authentication for services
• Authentication policies by user group
• Offboarding and disabling access fast

You build An identity design for people and services, with a tested offboarding procedure.

Over-privileged roles turn small mistakes into big incidents. You design role hierarchies, grant by least privilege, keep administrators’ duties separate, and write queries that reveal roles holding more than they need.

• Role hierarchy and inheritance
• Privileges on objects and future grants
• Managed access schemas
• Least privilege for services and tools
• Finding over-privileged roles
• Separation of duties for administrators

You build A least-privilege role design with a query that reports over-privileged roles.

Who can reach the account matters as much as who they are. You write network policies and rules, connect privately from your cloud, and control outbound paths so that data cannot leave through stages, unloads or external calls unnoticed.

• Network policies and network rules
• Private connectivity to Snowflake
• Outbound access and external functions
• Controlling egress through stages and unloads
• Network controls for partners and BI tools

You build A network control design that limits inbound and outbound paths for one account.

You cannot investigate what you did not record. You use account usage views to answer who signed in, who read which columns and what a query touched, and plan for the limits on how long that history is kept.

• ACCOUNT_USAGE views for security work
• Login history and failed sign-ins
• Access history: who read which columns
• Query history for forensic questions
• Retention limits of audit data
• Exporting audit data for long-term keeping

You build A set of audit queries that answer who accessed a sensitive table, and when.

Compliance asks for proof, not intentions. You use the Trust Center and alerts to detect weak configuration and risky events, collect evidence against a control set, and track each finding until it is closed.

• Trust Center scanners and findings
• Security baselines and configuration drift
• Alerts for risky events
• Collecting compliance evidence
• Reporting to auditors
• Tracking remediation to closure

You build An evidence pack showing an account meets a stated set of controls.

Controls cost effort, so effort should go where risk is highest. You identify realistic attack paths into a data platform, judge likelihood and impact, and record decisions in a risk register with owners.

• Risk assessment for data platforms
• Attack paths: stolen credentials, over-privilege, exfiltration
• Judging likelihood and impact
• Building a risk register
• Partner and third-party risk
• Reviewing configuration against a baseline

You build A risk register for one account with owners and treatments for each risk.

When an incident happens, the first hour decides its size. You write response phases into a playbook, contain a compromise by disabling users, revoking tokens and tightening policies, gather evidence from audit data and learn from it.

• Phases of incident response
• Detecting suspicious activity
• Containment: users, tokens and policies
• Collecting evidence from audit data
• Recovery and review afterward
• Running an incident exercise

You build An incident playbook for a credential compromise, rehearsed in a test account.

Audit data is too large to read by hand. You apply anomaly detection to sign-in and query activity, use language functions to summarize alerts, tune results to cut false positives, and understand where AI help is unsafe.

• Anomaly detection on login and query activity
• Scoring risky behavior with models
• Summarizing alerts and logs with language functions
• Tuning to reduce false positives
• Limits and risks of AI-assisted security

You build An anomaly detection job on sign-in activity that raises alerts for human review.

You review one account end to end: identity, access, network, data protection, auditing and response. You report findings with evidence and order fixes by risk, as a reviewer would for a client.

• Scoping a security review
• Testing identity, access and network controls
• Checking data protection and audit coverage
• Rating findings by risk
• Presenting the report and a fix plan

You build A written security review of a sample account with evidence and a prioritized fix plan.