Prompt and scope
The company operates a web application, mobile clients, analytics, and advertising integrations. It must honor a browser-level Global Privacy Control signal, explicit user choices, and changing jurisdiction rules. Design the control plane and request-time enforcement path, including anonymous visitors, signed-in users, multiple devices, partners, and policy updates.
The core skill is distributed policy enforcement and privacy-state modeling, so this belongs to system-design.
What interviewers assess
First, can you separate a signal from a legal decision? The Sec-GPC header or browser property is an input; applicability and permitted processing come from policy and context.
Second, can you define precedence and scope? A global opt-out may apply to a browser, account, household, or jurisdiction under different rules. The system must avoid silently merging scopes.
Third, can you enforce before data leaves the boundary? Analytics, ad-tech, exports, and partner APIs need a shared decision point, not only a banner.
Fourth, can you make decisions explainable and revocable? Store policy version, source, timestamp, and expiry, while minimizing personal data and supporting later withdrawal.
Fifth, can you fail safely? A policy-store outage, stale cache, or unknown jurisdiction should default to the least permissive sharing mode and emit an observable reason.
Questions to clarify first
- Which jurisdictions and purposes are in scope, and which rules are authoritative?
- Does a GPC signal apply to an account after login or only to the browser context?
- Which purposes are blocked: sale, sharing, targeted advertising, measurement, or all optional processing?
- How quickly must revocation reach caches, queues, warehouses, and partners?
- What evidence must be retained, and what data must be deleted or anonymized?
- Can every outbound integration call the same policy decision service?
30-second answer framework
“I would normalize browser signals and explicit choices into versioned privacy intents, then evaluate them with jurisdiction and purpose policy at every data-egress boundary. The decision includes scope, policy version, expiry, and reason, and is cached briefly with fail-closed behavior for optional sharing. Events propagate revocation to queues and partners, while an append-only audit trail stores minimal evidence. I would test anonymous-to-login transitions, conflicting scopes, policy changes, cache staleness, and partner failures.”
Step-by-step answer
Step 1: Normalize inputs without over-identifying
At the edge, capture the GPC signal, origin, user agent context, account state, and declared region. Keep an anonymous browser identifier separate from an account identifier until policy permits linking. Normalize explicit choices into purposes such as sale, sharing, measurement, and personalization.
Step 2: Evaluate a versioned policy
The policy service receives subject scope, purpose, jurisdiction, source signal, and time. It returns allow, deny, or unknown, plus policy version, expiry, and a reason code. A GPC signal is not itself proof that every purpose is prohibited everywhere; the evaluator applies the relevant rule set.
Step 3: Enforce at every egress
Require the decision token before sending events to analytics, ad-tech, exports, or partner APIs. SDKs may reduce accidental collection, but the server must enforce because clients can be modified. Queues and batch jobs re-check the decision before delivery, not only at enqueue time.
Step 4: Propagate changes and revocation
Publish a privacy-intent event keyed by a scoped subject reference. Consumers invalidate caches, stop future exports, and mark retained data for the applicable deletion or suppression workflow. Partners receive a minimal contract with purpose, scope, effective time, and verification data; do not broadcast raw identity when a token is sufficient.
Step 5: Audit decisions, not payloads
Record request class, subject scope hash, purpose, policy version, signal source, decision, and timestamp. Encrypt access, limit retention, and separate operational logs from user-visible explanations. The audit record should answer why a transfer was allowed or denied without copying sensitive event contents.
Step 6: Fail closed and observe
If policy lookup or revocation propagation fails, block optional sharing and queue work for retry. Metrics should show unknown decisions, stale policy versions, denied transfers, partner acknowledgements, and time-to-revocation. Alerts must distinguish a policy outage from a legitimate increase in opt-outs.
Step 7: Test boundaries and adversarial cases
Test anonymous browsing followed by login, multiple tabs, conflicting account and browser scopes, clock skew, regional movement, replayed signals, cache expiry, queue redelivery, partner timeout, and policy rollback. Verify that a denied decision cannot be bypassed through an alternate export path.
Model answer
“I would build a versioned privacy decision service and require its short-lived decision token at every optional data-egress boundary. The edge normalizes GPC and explicit choices while keeping browser and account scopes distinct. Policy evaluation combines purpose, jurisdiction, source, and effective time; it returns a reason and policy version. Queues and partners re-check before delivery, and revocation events invalidate caches and trigger suppression workflows.
The service fails closed for optional sharing, records minimal decision evidence, and exposes metrics for unknown decisions, stale caches, acknowledgements, and time-to-revocation. Tests cover login transitions, conflicting scopes, replay, regional changes, retries, and alternate export paths. A banner alone is not enforcement.”
Common mistakes
- Treating GPC as a universal boolean → scope and jurisdiction are lost → evaluate signal, purpose, and policy together.
- Enforcing only in the browser → modified clients bypass controls → enforce at server egress.
- Linking anonymous and account identity immediately → unnecessary profiling → keep scopes separate until justified.
- Checking consent only at enqueue time → revocation races with delivery → re-check before send.
- Failing open on policy outage → optional data leaks → fail closed and retry.
- Auditing full payloads → logs become a privacy risk → store minimal decision evidence.
- Ignoring partner acknowledgements → propagation is unverified → track receipts and deadlines.
Follow-up questions
Follow-up 1: Does GPC replace a consent banner?
No. It is a browser-level signal whose meaning depends on applicable policy. A user interface may collect additional choices, but enforcement must honor the evaluated decision.
Follow-up 2: What happens after login?
Keep browser and account scopes distinct, then apply the documented linking rule. Do not silently convert an anonymous signal into a broader account preference without policy support.
Follow-up 3: How long may a decision be cached?
Only as long as the risk and policy permit. Use a short TTL, versioned invalidation, and fail-closed behavior when freshness cannot be proven.
Follow-up 4: How do you handle a partner that is offline?
Stop optional delivery after the acknowledgement deadline, retain a minimal retry record, and reconcile once the partner returns.
Follow-up 5: What should the audit record contain?
Scope reference, purpose, signal source, policy version, decision, reason, and time are usually sufficient; avoid copying event payloads.
Follow-up 6: How do you prove no bypass exists?
Inventory every egress path, require a decision token in shared middleware, and run denial tests against SDKs, batch jobs, exports, and partner retries.