SnowPro Advanced: Security Engineer Question 145
Single answerApply the principles of secure multi-party computationTwo healthcare organizations want to jointly analyze patient overlap and treatment outcomes in Snowflake without exposing their underlying patient-level datasets to each other. A security engineer is asked to design a solution that minimizes direct data sharing, prevents either party from seeing the other party's raw records, and still allows approved aggregate analysis. Which approach best aligns with secure multi-party computation principles in Snowflake?
- A
Create a clean room-style collaboration in which each party contributes controlled datasets, apply strict join and query policies to prevent exposure of raw rows, and allow only approved aggregate outputs.
- B
Replicate both organizations' patient tables into a shared database owned by one party, then use standard RBAC to deny SELECT on sensitive columns while analysts run joins on the raw tables.
- C
Have each party export hashed patient identifiers to object storage, then let analysts load the files into a common schema and run unrestricted SQL because hashing fully anonymizes the data.
- D
Use Secure Data Sharing to give both organizations direct access to each other's underlying patient tables, and rely on secure views alone to ensure no sensitive information can be inferred.
Show answer and explanation
Correct answer: A
Explanation
The best answer is the clean room-style collaboration approach because it most closely reflects secure multi-party computation principles as applied in Snowflake: enable joint analysis while reducing disclosure of each participant's underlying data. In practice, this means structuring collaboration so raw records are not broadly exposed, restricting query behavior, and limiting outputs to approved aggregates or privacy-preserving results. Snowflake security best practices relevant here include applying least privilege with RBAC, using secure objects where appropriate, and enforcing governance controls such as row access policies, masking policies, and controlled analytical interfaces. By contrast, simply sharing raw tables, relying only on RBAC, or assuming hashing alone provides anonymity are common misconceptions. Snowflake documentation and best practices on data collaboration, secure sharing, governance policies, and privacy-conscious analytics support designing collaborations that minimize unnecessary data exposure.
- A. Correct.
Correct. This approach is the closest practical implementation of secure multi-party computation principles in Snowflake. A clean room-style design focuses on privacy-preserving collaboration, where each party contributes governed data and analysis is constrained so participants can derive approved results without exposing raw underlying records. Controls such as policy-based restrictions, limited output patterns, and aggregation-only access are consistent with minimizing disclosure and supporting collaborative analytics safely.
- B. Incorrect.
Incorrect. Although RBAC is important, centralizing both raw datasets in a database owned by one party violates the core goal of minimizing trust and limiting direct exposure between participants. Denying access to some columns does not adequately protect sensitive row-level data when raw joins are still being performed in a shared environment. This design creates unnecessary custody and insider-risk concerns.
- C. Incorrect.
Incorrect. Hashing identifiers alone does not constitute secure multi-party computation and does not guarantee anonymity. Deterministic hashes can often still support linkage and may be vulnerable to re-identification, especially for low-entropy identifiers or when auxiliary information exists. In addition, unrestricted SQL on jointly loaded data undermines privacy-preserving analysis controls.
- D. Incorrect.
Incorrect. Secure Data Sharing is useful for sharing live data without copying, and secure views help limit exposure, but directly exposing underlying patient tables to both organizations is not aligned with the stated requirement. Secure views alone are not sufficient for a multi-party privacy-preserving collaboration if users can still infer sensitive details from granular shared data or flexible query patterns.