Design a Privacy-Compliant Analytics Architecture

WHAT THIS TESTS: This isn't just a data architecture question; it's a test of your seniority in handling non-functional requirements with legal and business-critical implications. The interviewer is assessing your ability to design a system that enables the business (analysts need data) while enforcing complex rules (GDPR). It tests your understanding of data governance, security engineering, and modern data warehousing concepts. You're being evaluated on your ability to translate legal requirements into specific, implementable technical controls.

A GOOD ANSWER COVERS: A strong answer outlines a "privacy gateway" or "governance layer" architecture that sits between analysts and the raw data warehouse (e.g., Snowflake, BigQuery). It should cover three key areas in order. First, dynamic data masking: explain how PII columns (e.g., email, name) are identified via tagging and dynamically replaced based on the user's permissions and query purpose. For example, a general analyst sees a hashed email, while a fraud investigator with a specific ticket number can see the raw email for 60 minutes. Second, purpose-based access control: describe how access is granted not just based on a user's role, but on the "purpose" of their query, often tied to a ticket (e.g., JIRA-1234). The policy engine checks this purpose before allowing the query. Third, auditable query logs: detail how every query, the user, their purpose, and the data accessed are logged to an immutable, append-only store (like a write-protected S3 bucket or a managed blockchain service) for compliance audits.

COMMON WRONG ANSWERS: A major red flag is suggesting static, irreversible anonymization (e.g., hashing all PII in the ETL pipeline). This destroys the "rich, user-level data" requirement and shows a misunderstanding of the trade-off. Another weak answer is being too vague, saying "we'll use role-based access" without explaining how to handle dynamic scenarios. Describing controls without naming any plausible technologies (e.g., Apache Ranger, Immuta, Satori, or a custom query proxy service) makes the answer seem academic. Finally, focusing only on one aspect, like logging, while ignoring the access control and masking components, shows a lack of depth.

LIKELY FOLLOW-UPS: Expect questions like: "How would you handle a 'right to be forgotten' request in this system?"; "How do you manage the performance overhead of this governance layer?"; "What's your strategy for classifying and tagging PII across thousands of tables?"; "How would you handle a case where an analyst needs to join two datasets, but only has purpose-based access to one of them?".

ONE CONCRETE EXAMPLE: An analyst needs to investigate a drop in user engagement. Their role grants them access to the user_events table. They submit a query with the purpose "JIRA-TICKET-789: Investigate Q3 Engagement Drop". The privacy gateway intercepts the query. The policy engine verifies that TICKET-789 is a valid, open task. The query is allowed, but the dynamic masking engine rewrites it on the fly. Instead of SELECT user_id, user_email, event_name..., the executed query becomes SELECT user_id, SHA256(user_email), event_name.... The analyst receives the data they need for cohort analysis without exposing raw PII. The original query, rewritten query, user, and purpose are all written to the immutable audit log.