Prompt and scope
Two companies want to compute overlap, conversion, or attribution metrics without copying email addresses, device identifiers, or event rows to each other. The interview tests whether “data stays in place” becomes an execution-layer control rather than a sharing contract, and whether you handle small cohorts, repeated queries, consent withdrawal, and multi-cloud deployment.
What the interviewer is testing
System design interviews typically reward clarifying scope before going deep on the hardest model, authorization, and failure paths. Data-engineering interview guidance also lists system design, governance, and privacy as distinct evaluation areas. AWS Clean Rooms documents least privilege, encryption, and CloudTrail; Salesforce’s architecture guidance puts zero-copy processing, identity alignment, minimum aggregation thresholds, and tamper-evident audit at the execution boundary. A strong answer names the component enforcing each rule and the attack it blocks.
Questions to clarify first
Confirm the number of parties, whether data stays in each cloud account, allowed analyses and output granularity; whether recipients may see exact counts; whether differential privacy is required; whether identity matching uses partner-provided tokens or a trusted mapping service; how quickly consent revocation must take effect; and the residency, key ownership, and audit-retention requirements. A one-off two-party aggregate can use a controlled batch; open SQL requires the query language and privacy budget in the threat model.
30-second answer framework
Open with: “I’ll split the clean room into a control plane, data connectors, policy compiler, isolated execution engine, and result publisher. Participants register metadata and permitted purposes while raw tables stay in their stores. The engine runs restricted queries at the data boundary and an isolated service performs identity matching. Before publishing, it enforces minimum cohort thresholds, a differential-privacy budget, and result scans. Queries, policy versions, and key operations go to an immutable audit trail. Revocation blocks new jobs and invalidates cached results; jobs are isolated by tenant, region, and key.”
Step-by-step deep dive
Step 1: Turn the collaboration agreement into policy
The control plane stores parties, datasets, purpose, allowed join keys, output columns, region, expiry, and consent version. Policies are versioned and signed, and a job locks the version at submission; a query cannot change rules mid-run. Tenant, human role, and service identity remain separate, and a requester sees only authorized metadata.
Step 2: Keep raw data inside the execution boundary
Connectors read local tables or zero-copy views and report only schemas, statistics, and locations to the control plane. The policy compiler reduces a request to approved joins, filters, and aggregates; arbitrary exports, user-level ordering, free-form functions, and raw columns in logs are rejected. In multi-cloud deployments, service roles and customer-managed keys are separate, TLS protects transport, and key permissions are scoped to the collaboration and intermediate tables.
Step 3: Match identities without exposing them
Do not store raw emails or device identifiers in the control plane. Partners normalize values under a shared specification and create tokens, or an isolated mapping service performs the match and returns only an irreversible join result. Record normalization version, provenance, and collision handling. A changed rule creates a new version instead of silently reusing a token under different semantics. Only the execution engine can consume match results.
Step 4: Enforce privacy at runtime
Before returning a result, the executor checks minimum cohort size, column allowlists, query count, and privacy budget. Differential privacy adds calibrated noise to aggregates and tracks budget consumed by each query; once the budget is exhausted, later queries are blocked. Even with differential privacy, restrict repeated segment, difference, and cross-query operations so an attacker cannot shrink a cohort by combining outputs.
Step 5: Publish results with audit evidence
The publisher emits only an approved aggregate schema, quality flags, and privacy status. It never returns intermediate tables, raw tokens, or failed rows. Each query records the requester, policy and dataset versions, query digest, budget consumption, recipient, and key operations in storage participants cannot delete. A result cache is bound to policy, consent, and data versions; revoking any one invalidates it.
Step 6: Handle revocation, failure, and regional recovery
Revocation first stops queued jobs, then makes the executor revalidate policy at checkpoints; published results are marked affected and no longer redistributed according to the contract. A failed task reruns only idempotent partitions and never reads temporary tables outside policy. Regional placement follows residency rules, with independent keys and logs per region. If the control plane is unavailable, pause new queries instead of running with an expired policy.
Model high-quality answer
“I would create a versioned collaboration policy that names purpose, datasets, join keys, output columns, region, and expiry. Raw tables remain in each participant’s store; connectors expose controlled views and schemas. A policy compiler restricts requests to approved joins, filters, and aggregates, and the execution engine runs inside the data boundary. An isolated matching service converts normalized identifiers into tokens that cannot be downloaded. Before publishing, enforce minimum cohort size, a differential-privacy budget, and combined-query checks; reject once the budget is exhausted. Record policy and data versions, requester, budget, key calls, and recipient in an immutable audit log. Revocation blocks new jobs, invalidates caches, and triggers checkpoint revalidation. Regional and key isolation keeps failover inside residency rules.”
Common mistakes and improvements
- Relying on a contract to prevent leakage: Make the executor and publisher reject raw columns, user-level results, and unauthorized functions.
- Treating a hash as automatic anonymization: Include normalization, salts, keys, and linkage attacks in the threat model; prefer an isolated token service.
- Setting a single minimum-group check: Also limit repeated, difference, and cross-query operations and track privacy budget.
- Changing only a console flag on revocation: Recheck policy and consent versions in queues, execution, cache, and distribution.
Follow-up questions and answers
How do you stop inference when the requester keeps changing filters?
Bind a privacy budget to each dataset and collaboration and charge every query. Limit segmentation dimensions, result frequency, and differences between adjacent queries. Reject when the budget or risk threshold is reached instead of returning ever-smaller groups.
What if the two parties normalize emails differently?
Fix a normalization version in policy and perform conversion inside the isolated matching service, recording that version. Fail and require remapping on a mismatch; silently accepting tokens would create false negatives or false matches.
Can a job move to another region when its key service is unavailable?
Only if residency and key policy explicitly allow it; otherwise pause while preserving the checkpoint. Cross-region replication should carry encrypted control metadata and audit records, never restricted raw data or decryptable intermediate tables.
How do you verify that the clean room does not leak raw data?
Run negative policy tests for raw-column selection, user-level sorting, below-threshold groups, repeated differences, and log injection. Inspect plans and result schemas, simulate revocation and key failure, and reconcile audit events with actual calls.