Privacy by Design and Default Questions
Embedding privacy into architecture and the development lifecycle: the privacy-by-design principles, privacy-protective defaults, and on-device or edge processing to minimize data exposure. Covers integrating privacy controls into product and program design and into engineering workflows rather than bolting them on. Includes designing privacy-first solutions and reference architectures.
MediumTechnical
83 practiced
Implement (or provide clear pseudocode) for a Node.js logging helper that redacts PII from a JSON object before emitting logs. The helper should accept a list of redaction paths (e.g., ['user.email','payment.card.number']), support nested objects and arrays, preserve the original object structure, and avoid mutating the input. Show example input/output and discuss time/space complexity.
Sample Answer
Approach: Walk the input object recursively and build a shallow-deep copy while applying redaction when a path matches. Do not mutate the input — create new objects/arrays on the fly. Support dot-separated paths like "user.email" and handle arrays by descending into each element automatically (no special syntax required).Example:Input:{ user: { name:'Alice', email:'a@x.com' }, sessions: [{ id:1, user:{ email:'a@x.com' } }], payment: { card: { number: '4111', cvv: '123' } }}Redaction paths: ['user.email', 'payment.card.number']Output:{ user: { name:'Alice', email:'[REDACTED]' }, sessions: [{ id:1, user:{ email:'[REDACTED]' } }], payment: { card: { number:'[REDACTED]', cvv:'123' } }}Key points:- Preserves structure and types, doesn't mutate input.- Supports arrays by mapping into elements automatically.- Uses a path-trie for efficient matching across multiple paths.Complexity:- Time: O(N + M * L) roughly — N = number of nodes (object properties + array elements); M = number of redaction paths, L = average path length for building the trie. Matching cost per node is O(1) lookup into current trie level.- Space: O(N) for returned copy + O(M * L) for path-trie.Edge cases:- Non-existent paths are ignored.- Nulls and primitives handled safely.- If you need wildcard paths (e.g., redact any key named "email" anywhere), extend buildPathTree to support special token '*' and check it during traversal.
javascript
// Node.js / JavaScript implementation
const REDACTED = '[REDACTED]';
/**
* Redact PII from obj according to redactionPaths (e.g. ['user.email','payment.card.number'])
* Returns a new object, does not mutate input.
*/
function redactPII(obj, redactionPaths) {
const pathTrees = buildPathTree(redactionPaths);
return redactNode(obj, pathTrees);
}
function buildPathTree(paths) {
// Build a trie-like tree for fast matching
const root = {};
for (const p of paths) {
const parts = p.split('.');
let node = root;
for (const part of parts) {
node[part] = node[part] || {};
node = node[part];
}
node.__redact = true;
}
return root;
}
function redactNode(node, pathTree) {
// primitive or null -> return as-is
if (node === null || typeof node !== 'object') return node;
if (Array.isArray(node)) {
// map each element, applying same pathTree
return node.map(el => redactNode(el, pathTree));
}
// object: copy keys; for each key check pathTree
const out = {};
for (const [k, v] of Object.entries(node)) {
if (pathTree && pathTree[k]) {
if (pathTree[k].__redact) {
// redact the whole value at this path
out[k] = REDACTED;
} else {
// descend with the subtree for this key
out[k] = redactNode(v, pathTree[k]);
}
} else {
// key not in any redaction path: still need to deep-copy to avoid mutation
out[k] = redactNode(v, null);
}
}
return out;
}HardTechnical
94 practiced
Design a zero-downtime key rotation strategy for master encryption keys used to protect data-at-rest across multiple databases and services. Discuss KMS integration, key versioning, choices between eager and lazy re-encryption, migration algorithm, rollback plan, and how to test and validate that rotation succeeded without data loss.
Sample Answer
Requirements & constraints:- Zero downtime, no data loss, cross-database/service consistency, KMS-backed master keys, ability to rollback quickly, auditability.High-level approach:- Use KMS (cloud HSM) to generate and store root (master) keys and provide envelope encryption keys (DEKs). Version every master key and use key IDs/versions for deterministic lookup. Services never store raw master keys — only DEKs encrypted under KMS.Key versioning & metadata:- Maintain a Key Registry (DB/table) mapping key_id -> kms_key_arn/version, status (active, retiring, retired), rollout_timestamp. All encrypted blobs include metadata header: {kms_key_id, key_version, dek_encrypted, algorithm, iv}.Eager vs lazy re-encryption:- Prefer lazy re-encryption for zero-downtime: keep existing ciphertexts readable with old DEKs while newly written or updated objects use new key. Eager re-encryption useful if you must remove old keys quickly or for compliance — then schedule controlled background workers.Migration algorithm (lazy):1. Create new master key in KMS; add entry to Key Registry as active.2. Update service config to write new encrypted DEKs using new key_version; on read, if blob kms_key_id != active, decrypt using indicated key (KMS) then re-encrypt DEK under active key and write back asynchronously (idempotent).3. Background migrator workers scan objects, decrypt with indicated key, rewrap with new key, update metadata and set migration_flag. Use batching and rate-limit to avoid DB impact.4. Once coverage > 99.99% (or policy threshold) and no reads reference old key, mark old key retiring; keep for a retention window.Rollback plan:- Never delete old key material during rotation window. For rollback, switch service config to previous key_version as active; background workers can rewrap back if needed. KMS supports disabling/reenabling keys to prevent accidental use.KMS integration:- Use envelope encryption: generate per-object DEK (symmetric), encrypt data with DEK locally (AES-GCM), encrypt DEK with KMS master key via Encrypt API. Cache decrypted master-key-derived material cautiously using short TTLs and CPU-bound caches; rely on KMS for key operations to maintain audit logs.Consistency & concurrency:- Use compare-and-swap or optimistic locking when updating object metadata to avoid lost-writes. Make re-encryption idempotent: include migration generation/version and checksum to skip already-updated items.Testing & validation:- Test in staging with sampled real-size datasets. Automated tests: - Unit tests for envelope encrypt/decrypt and metadata handling. - Chaos tests: rotate keys under load; simulate KMS failures and latency. - Integration tests: read-old-write-new paths, concurrent reads/writes.Validation metrics:- Verify per-object header reflects expected key_version and that rewrapped_flag set.- End-to-end checksum over sample dataset before/after rotation.- Monitoring: migration progress, error rates, KMS API error spikes, latency.- Periodic audit: try decrypting random objects across DBs using recorded key ids; ensure no failures.- Final compliance: only after verification, schedule KMS key schedule to disable then schedule deletion after retention.Security & operational notes:- Least privilege IAM for services calling KMS; granular key policies for migration workers.- Audit logs enabled; alert on unexpected usage of retired keys.- Rate-limit and backoff on KMS calls; exponential retry for transient errors.This strategy yields zero-downtime rotation, safe rollback, and measurable validation while keeping key material protected by KMS.
HardTechnical
68 practiced
Design an implementation to detect potential PII in unstructured logs at scale. Describe a hybrid approach that combines high-precision regex rules and ML classifiers (e.g., NER), strategies for generating labeled data, confidence thresholds for quarantining logs, indexing for fast search, and a rollout plan to minimize false positives/negatives and performance impact.
Sample Answer
Approach summary:Combine deterministic, high-precision regex rules as the first-pass fast filter, then apply ML NER/classifiers for context-aware detection. Use a streaming pipeline to score each log and take actions by confidence thresholds (quarantine, redact, allow). Iteratively improve with human-in-the-loop labeling.Pipeline (high level):1. Ingest (Kafka)2. Regex filter (fast, CPU-light)3. Enrichment (tokenize, embeddings)4. NER/classifier (BERT-based or spaCy transformer)5. Scoring & policy engine (confidence thresholds)6. Index & store (Elasticsearch / OpenSearch with flags)7. Human review UI + retraining loopExample simplified implementation sketch (Python-like pseudocode):Label generation strategies:- Seed regex rules -> harvest positive examples (weak supervision).- Use heuristics and distant supervision from structured sources (user profiles, hashed emails).- Active learning: surface low-confidence/ambiguous examples to human reviewers; label and add to training set.- Synthetic data: generate realistic PII patterns mixed into benign logs to augment rare classes.Confidence & policy:- Two thresholds: REDACT (e.g., 0.6–0.8) and QUARANTINE (e.g., 0.9+). Use calibration (Platt scaling) on validation set to map model probabilities to true risk.- Regex hits bump score significantly; whitelist contexts (e.g., test data) subtract risk.- Circuit-breaker: rate-limit quarantining to avoid pipeline floods.Indexing & search:- Store original log + metadata and PII flags in OpenSearch. Index tokens, snippet locations, pii_type, score.- Use inverted indices and runtime fields to support fast queries like "all quarantined logs with email PII in service X".- Retain redacted view for analysts; secure access controls for quarantined raw logs.Rollout plan:1. Shadow mode (regex + ML runs, no action) for 2–4 weeks; collect metrics (precision/recall estimates via sampled human review).2. Gradual enforcement: start with REDACT only for low-risk; QUARANTINE in small percentage of traffic using canary.3. Active learning loop: prioritize labeling examples with mid-range scores to improve model.4. Monitor: false positive rate, false negative proxies (e.g., downstream incidents), latency, resource usage.5. Tune thresholds and regexes; add whitelists/blacklists per service.6. Finalize full enforcement when precision meets SLA (e.g., FP < 1% for quarantine).Performance considerations:- Regex filtering runs in-line; ML runs on GPU/CPU inference service with batching and async calls.- Use model distillation or smaller transformer (DistilBERT) for latency-sensitive paths.- Cache recent results for identical log templates.- Backpressure: if ML service overloaded, fall back to conservative redact-by-regex.Trade-offs:- Regex: high precision, low recall. ML: higher recall, risk of false positives. Hybrid balances both.- Prioritize safety for PII (favor false negatives reduction via review rather than mass quarantining).This design provides scalable, auditable, and iteratively improvable PII detection with controlled operational risk.
python
def process_log(record):
if regex_high_precision_match(record.text):
return action_quarantine(record, reason="regex")
features = featurize(record.text) # tokens, pos, embeddings
preds, probs = ner_model.predict_proba(features)
score = combine_scores(regex_score(record), probs)
if score >= QUARANTINE_THRESH:
return action_quarantine(record, reason="ml", score=score)
elif score >= REDACT_THRESH:
return action_redact(record, preds)
else:
return action_allow(record)EasyTechnical
80 practiced
A QA engineer discovers a staging dataset that contains production PII. As the on-call engineer, list immediate containment steps, stakeholders to notify, how to ensure copies are removed from all environments (logs, backups, caches), and preventative actions to avoid recurrence. Provide a short checklist with priorities.
Sample Answer
Situation: QA finds staging dataset containing production PII while I'm on-call.Immediate containment (minutes):- Quarantine dataset: revoke access to the staging environment (disable app/service account, remove IAM roles) and stop any automated jobs that write/read staging.- Snapshot and document: take an access-controlled snapshot for forensic audit (do not proliferate copies).- Rotate credentials if the leak could expose keys (API keys, DB creds).- Notify security/incident response and your manager immediately.Stakeholders to notify (in order):1. Security/IR team (primary)2. Engineering manager / on-call lead3. Data owner / product manager4. Legal & privacy officer / DPO5. QA lead and SRE/Platform6. Customer support if customer data affectedEnsure removal across environments (hours):- Identify all locations: databases, object stores (S3), caches (Redis), logs, CI artifacts, backups, snapshots.- Remove copies: run targeted deletes (e.g., DELETE in DB, rm s3://bucket/path) and purge caches.- Invalidate logs/backups: mark affected backups for secure deletion and follow backup retention/secure-erase procedures.- Reindex/search: remove from search indices.- Verify with checksums/queries that no rows/objects remain.- Produce an audit log of deletion steps and who executed them.Prevention (days-weeks):- Masking/anonymization in non-prod; enforce synthetic or scrubbed test data.- Automated policy: prevent production data in non-prod via data-loss prevention (DLP) or gating checks in pipelines.- IAM hardening: least privilege for staging; require MFA and scoped roles.- CI/CD controls: prevent production DB dumps from being used in staging; use approvals for data imports.- Monitor: alerts for PII patterns in non-prod, periodic scans, and regular backup audits.- Runbook & training: documented procedures and drill.Short prioritized checklist:P0 (now): Quarantine environment; notify Security/IR; stop jobs.P1 (within hours): Snapshot for forensics; delete copies from DB, S3, caches, logs; rotate credentials if exposed.P2 (same day): Notify Legal/PM; mark backups for deletion; verify deletions and produce audit.P3 (days): Implement masking/DLP, IAM fixes, CI controls, monitoring, and team training.This approach contains the incident, documents actions for compliance, and reduces likelihood of recurrence.
HardSystem Design
97 practiced
Architect a multi-region service processing PII for 100 million users distributed across EU, US, and APAC. Address data partitioning and replication policies, cross-border transfer controls, region-specific key management, consent synchronization, subject-access and deletion APIs that respect regional laws, audit trail design, and disaster recovery. For each area explain trade-offs and how you'd prove compliance to auditors.
Sample Answer
Requirements & constraints:- Process PII for 100M users across EU, US, APAC; comply with GDPR, CCPA, region data residency; low-latency local access; strong auditability and deletion/SARs; tolerate region failure.High-level architecture:- Regions = independent deployment units (EU, US, APAC) each with local API gateway, app tier, data stores, KMS; global control plane for metadata, consent sync, and orchestration.- Data partitioning & replication: - Primary partition by user residence (country) → user PII stored primarily in that region’s database (sharded by user_id). - Read replicas within same legal domain for HA/performance; cross-region replication only when lawful/explicit consent exists (e.g., global features), using asynchronous, auditable pipelines. - Trade-off: strong locality reduces cross-border risk and latency, but increases operational overhead and possible data duplication for global features.Cross-border transfer controls:- Explicit transfer policy service enforces lawful basis: consent, contract, SCCs, or adequacy. Transfers require tokenized approval and are routed through a transfer broker that logs purpose, legal basis, TTL, and allowed attributes.- Trade-off: Blocking transfers by default is safest but can limit global features; broker adds latency and complexity.Region-specific key management:- Each region has a region-local KMS (HSM) holding master keys; data encrypted with DEKs per user, wrapped by regional KMS.- For cross-region replication, DEKs may be re-encrypted only if policy allows; cross-region key export disabled unless explicit transfer and dual control approvals.- Proof to auditors: key rotation logs, HSM tamper reports, split-key access policies, KMS audit trails.Consent synchronization:- Canonical consent store in user's home region; publish consent delta events to a global, signed event bus. Other regions subscribe but must enforce local enforcement decisions (pull-to-verify).- Use event versioning and idempotent processors to ensure eventual consistency.- Trade-off: eventual consistency simplifies scale but requires careful SAR handling.Subject-Access & Deletion APIs:- Expose region-local endpoints; requests routed to home-region handler. For cross-region copies, orchestrator executes delete/SAR across regions where replicas exist.- Implement workflows that (a) verify identity, (b) enumerate locations of user's PII (metadata map), (c) execute deletions or data export, and (d) return proof-of-action (signed receipts).- Enforce retention and legal hold exceptions by policy flags; provide auditors redacted logs of actions.Audit trail design:- Immutable, append-only audit logs per region using write-ahead log stored in WORM storage (e.g., object store with immutability). Include: who, what, when, why (legal basis), request id, data hash, and cryptographic signature.- Central indexed indexer stores only metadata pointers (no PII). Logs replicated to multiple enclaves and retained per policy.- Provide auditor views: filtered, signed bundles with chain-of-custody, KMS key signatures, and proofs of deletion using hash-chains.Disaster recovery:- Region-level DR: automated failover to warm standby within same legal boundary; cross-region DR only if policy allows and with approvals.- Backups: encrypted, region-stored snapshots; automated restore procedures; periodic DR drills with auditor witnesses.- RTO/RPO targets defined per region and tested.Proving compliance to auditors:- Provide: - Data residency map showing primary storage per user. - Transfer broker logs with legal basis records. - KMS/HSM reports, key rotation and access logs. - Immutable audit log exports with signatures and hash-chains. - SAR/deletion workflow records and signed receipts. - Policy documents, SCCs, DPIAs, and runbooks for DR drills. - Automated evidence packs generated per audit request (time-bounded, redacted).- Trade-offs: generating comprehensive evidence increases storage and complexity but dramatically reduces audit friction.Operational controls & monitoring:- Automated policy enforcement tests, synthetic SARs, continuous compliance pipelines, anomaly detection on cross-region transfers.- Organizational: Data Protection Officer, periodic penetration and privacy impact assessments.Summary of trade-offs:- Locality vs global features: prefer locality, allow controlled transfers.- Consistency vs latency: eventual consistency for cross-region sync; strong consistency inside region.- Security vs operability: strict KMS separation increases operational steps; mitigated with automation and clear approval flows.This design balances legal isolation, operational availability, and auditable controls while providing concrete artifacts (logs, receipts, KMS proofs) to satisfy auditors.
Unlock Full Question Bank
Get access to hundreds of Privacy by Design and Default interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.