Privacy by Design and Principles Questions

Comprehensive coverage of foundational privacy principles and the practice of embedding privacy into systems, products, and processes from inception. Candidates should understand core concepts including data minimization, purpose limitation, lawfulness and fairness of processing, accuracy, integrity and confidentiality, transparency, user control, privacy by default, retention limits, accountability, and security controls. The topic includes operationalization for product and engineering workflows: mapping data flows and inventories, conducting privacy impact assessments, threat modeling for privacy risks, defining retention and deletion policies, consent and user rights handling, choosing anonymization or pseudonymization strategies, and applying privacy enhancing technologies. It also covers integrating privacy requirements into the software development lifecycle with traceable requirements and design reviews, stakeholder collaboration with product managers engineers legal teams and compliance functions, measurement and monitoring of privacy controls in production, documentation and governance, and balancing privacy trade offs with business objectives and regulatory obligations such as the General Data Protection Regulation.

MediumSystem Design

29 practiced

Design a retention and deletion policy for user event logs used in analytics and model training. Include retention windows for raw vs aggregated data, deletion mechanisms, and safeguards for backups and replicas. Explain how you would implement and verify deletion across systems.

Sample Answer

Requirements & constraints:- GDPR right-to-be-forgotten, auditability, minimal disruption to analytics/model training, low latency for query workloads, cost-efficiency.- Retain raw event logs short-term for troubleshooting and model re-training; keep aggregated/derived summaries longer.

Policy overview:- Raw event logs: retain 90 days (configurable). Keep in cheap object store (e.g., S3) partitioned by date and hashed user-id.- Processed/feature store & intermediate tables: retain 180 days.- Aggregated analytics (daily/weekly/monthly rollups, cohort metrics): retain 3+ years.- Models & trained artifacts: store only features and metadata; ensure training data lineage but remove PII within retention windows.

Deletion mechanisms:- Soft-delete flag in metadata/catalog for immediate logical deletion; triggers downstream jobs.- Automated lifecycle jobs: - Time-based TTL jobs to purge partitions (batch jobs that delete S3 prefixes / drop Hive/BigQuery partitions). - Event-driven removal for user-initiated GDPR requests: mark user-id deleted, enqueue jobs to scrub raw events, replace identifiers with tombstones in feature store, and re-compute affected aggregates if necessary.- Use immutable audit log recording deletion requests, job runs, operator, and checksums.

Backups & replicas safeguards:- Ensure backups and cross-region replicas respect TTL: maintain backup catalogs with retention-aware restore points; on deletion requests, either: - Use encryption keys per-user (or per-bucket) and rotate/revoke keys to render backups unreadable; or - Track backup snapshots and apply targeted deletion where supported (e.g., object delete markers in S3 with versioning and lifecycle rules).- For databases without point-delete in backups, limit backup retention to window shorter than legal requirement or provide documented technical constraints to legal.

Implementation & verification:- Central metadata/catalog (Data Catalog) tracks data locations, retention, deletion status, and lineage.- Orchestrate deletions via workflow engine (Airflow) that: - Finds partitions/objects for user or date range - Deletes objects, drops partitions, updates catalogs - Calls downstream jobs to update aggregated tables and feature stores - Triggers re-keying for encrypted backups if used- Verification: after deletion run, run automated validators: - Catalog vs storage reconciliation: list objects/partitions and assert none reference the deleted user or date. - Hash/checksum tests and sample queries (e.g., select count(*) filter by user-id → zero). - Generate signed deletion report with timestamps and job IDs; store in WORM audit store.- Periodic end-to-end audits and chaos tests (simulate GDPR request and validate all layers including replicas/backups are cleaned or rendered inaccessible).

Trade-offs & safeguards:- Immediate physical deletion vs. soft-delete: soft-delete allows rollback but increases exposure window.- Key-revocation for backups is fast but relies on sound key management.- Communicate to stakeholders (model owners) when deletions may affect model inputs; maintain monitoring to detect data drift after mass deletions.

This design balances compliance, traceability, and analytical needs while providing automated, verifiable deletion across systems.

HardTechnical

32 practiced

Implement in Python a differentially private histogram aggregator: write a function that takes a list of categorical values and epsilon and returns a noisy count per category using the Laplace mechanism. Explain how to compute the global sensitivity and implications of epsilon selection for utility.

Sample Answer

To release a differentially private histogram with the Laplace mechanism, compute true counts per category, then add Laplace noise calibrated to the global sensitivity divided by epsilon. For typical histograms where each individual contributes to exactly one category, global sensitivity = 1. Smaller epsilon ⇒ more privacy but higher noise (lower utility).

python

import collections
import math
import random
from typing import List, Dict, Any

def laplace_noise(scale: float) -> float:
    # Draw from Laplace(0, scale)
    u = random.random() - 0.5
    return -scale * math.copysign(1.0, u) * math.log(1 - 2 * abs(u))

def dp_histogram(values: List[Any], epsilon: float) -> Dict[Any, float]:
    """
    Differentially private histogram using Laplace mechanism.
    - values: list of categorical observations (one category per individual)
    - epsilon: privacy budget (must be > 0)
    Returns: dict mapping category -> noisy count (float)
    """
    if epsilon <= 0:
        raise ValueError("epsilon must be > 0")
    # True counts
    counts = collections.Counter(values)
    # Global sensitivity for histograms (bounded, one record per person) = 1
    sensitivity = 1.0
    scale = sensitivity / epsilon
    noisy = {}
    for cat, cnt in counts.items():
        noisy_cnt = cnt + laplace_noise(scale)
        # Optionally clamp negative noisy counts to 0 for interpretability
        noisy[cat] = max(0.0, noisy_cnt)
    return noisy

Key points:- Global sensitivity = 1 because adding/removing one individual changes at most one category count by 1.- Noise scale = sensitivity / epsilon = 1/epsilon. E.g., epsilon=0.1 → scale=10 (large noise), epsilon=1 → scale=1.- Time complexity: O(n + k) where n = number of records, k = distinct categories. Space: O(k).- Edge cases: empty input returns {}; negative epsilon invalid; noisy counts can be negative — clamp to 0 if needed (this biases counts slightly).- Alternatives/improvements: use integer-valued Geometric mechanism, add post-processing like consistency (ensure total equals original n if releasing totals is permitted), or use hierarchical/bucketed approaches to reduce error for many categories. Consider composition: multiple queries consume epsilon; use advanced composition or privacy accounting (moments accountant) for repeated releases.

MediumTechnical

24 practiced

Federated learning can reduce central PII exposure but introduces other privacy challenges. Describe three data science-specific risks introduced by federated learning (e.g., model updates leaking info) and propose detection or mitigation techniques a data scientist could apply.

Sample Answer

1) Gradient / update leakage (reconstruction & membership inference)- Risk: Per-round gradients or model updates can be inverted to reconstruct training examples or confirm an individual’s participation.- Detection: Simulate known gradient-inversion and membership-inference attacks on a held-out replica of your training pipeline to estimate leakage risk.- Mitigation: Apply DP-SGD (per-example clipping + noise) at the client or server, use secure aggregation so the server sees only aggregated updates, and enforce gradient clipping and noise budgets. Report epsilon and track cumulative privacy loss.

2) Poisoning and backdoor attacks (malicious clients corrupt model)- Risk: Malicious participants can send crafted updates to bias the global model or implant backdoors.- Detection: Monitor update statistics (norms, cosine similarity to global direction), use anomaly detection on update distribution, and run targeted tests (trigger inputs) to detect backdoor behavior.- Mitigation: Use robust aggregation (median, trimmed-mean, Krum), client reputation scoring, small learning rates, and periodic validation on clean holdout datasets. If suspicious, quarantine or reweight client contributions.

3) Distributional leakage & unintended generalization (selection/hyperpopulation bias)- Risk: Training only on client-local distributions can leak cohort-specific correlations; model outputs may reveal sensitive group attributes.- Detection: Evaluate model performance and calibration across client cohorts; run attribute inference probes to see if sensitive attributes are predictable from model outputs.- Mitigation: Use fairness-aware training, cohort-level differential privacy, and restrict exposed model outputs (e.g., top-k labels only). Where possible, aggregate features at cohort level before training or derive and share only aggregated statistics.

Practical notes for a data scientist:- Always measure privacy-utility trade-offs (plot accuracy vs epsilon).- Automate logging: per-round update stats, privacy budget consumption, validation on canonical test sets.- Combine defenses: secure aggregation + DP + robust aggregation gives stronger practical protection than any single control.

HardTechnical

29 practiced

Model explainability vs privacy trade-offs: propose a policy for sharing model explanations with end users without compromising other users' privacy or revealing training set members. Include what to show, what to hide, and logging/monitoring for abuse of explanation interfaces.

Sample Answer

Summary: Share explanations that are useful to end users (actionable, interpretable) while preventing leakage of individual training records by exposing only aggregated, obfuscated, or provably-private information; instrument and monitor the explanation API to detect probing/abuse.

What to show (safe, useful):- Global model behavior: feature importance aggregated across meaningful cohorts, class-level partial dependence plots, and high-level decision rules derived from clusters.- Local, user-specific explanations: sparse, human-readable reasons (top 3 contributing features) with confidence and uncertainty bands — derived from smoothed/regularized local methods (e.g., LIME/SHAP with aggregation).- Counterfactual suggestions: feasible actionables (“If you increase X by Y, outcome likely changes”), provided as ranges not exact training-instance transformations.- Examples: synthetic or prototypical examples generated by sampling from model-agnostic prototypes, or fully synthetic data matching distributional properties.

What to hide / modify (privacy-preserving):- Do not return raw training records, nearest neighbors, or exact feature vectors from the training set.- Avoid showing per-instance influence scores (Cook’s distance, exact Shapley at training-point granularity) without strong DP guarantees.- Apply differential privacy (DP) or k-anonymity when releasing aggregate statistics; add calibrated noise to feature importance, PDPs, and counterfactual thresholds.- Clip contributions and bound sensitivity before computing explanations; limit granularity (bins, ranges) for numeric attributes.

Access controls and API design:- Role-based access: richer diagnostic explanations available only to internal/authorized users under NDA.- Rate limiting and per-user quotas on explanation queries.- Require contextual metadata with each explanation request (user id, intent) for auditing.

Logging, monitoring, and abuse detection:- Log: requester identity, timestamp, query payload, explanation returned, response metadata (DP epsilon, noise seed id), and analytics metrics.- Detect probing patterns: high-frequency queries, systematic feature-perturbation sequences, repeated near-neighbor-like requests. Flag and throttle suspicious clients.- Periodic audit: sample explanation logs to detect potential training-data leakage; run membership-inference/red-team tests on explanations to quantify leakage risk.- Alerting and escalation: automated alerts for suspicious behavior; manual review and temporary suspension of API keys.- Privacy budget accounting: track cumulative DP epsilon per user/app; deny or degrade explanations once budget exceeded.

Governance and user communication:- Document explanation limits and privacy protections in user-facing policy.- Provide transparency reports (aggregate stats about explanation requests, audits, DP parameters).- Re-train and tune privacy/explainability balance periodically based on audit results and changes in threat model.

Rationale: Prefer aggregation, synthetic/prototypical outputs, and DP/noise to reduce per-instance leakage while keeping explanations actionable. Logging + proactive detection closes the loop to identify and mitigate adversarial probing.

MediumTechnical

32 practiced

Data leakage via feature stores: outline controls to prevent sensitive attributes from being accidentally used as features in downstream models. Include naming conventions, automated guards, CI checks, and runtime enforcement strategies.

Sample Answer

Start with policy + catalog hygiene, then layer automated checks and runtime enforcement.

1) Naming & metadata conventions- Prefix sensitive features and sources (e.g., pii_, secret_, ssn_, ip_). Use standardized tags in the feature-store catalog: sensitive: true, pii_type: "SSN", allowed_use: ["fraud_detection_system"].- Require owner, purpose, retention, and approved-use YAML in feature metadata.

2) Automated guards (ingest / registration)- Validation at registration: reject any feature with pii tag unless flagged for explicit approval.- Lint rule example (pseudo-python) to run on feature spec:

python

def validate_feature(spec):
    if any(tok in spec.name for tok in ["ssn","pii","dob"]) and not spec.approved:
        raise ValueError("Sensitive feature requires explicit approval")

3) CI checks (pre-merge / pipeline)- Enforce catalog linting, unit tests, and policy compliance in CI. Fail PRs that reference sensitive features in model training code unless an exemption exists.- Example CI jobs: `feature-lint`, `pii-usage-scan` (static analysis of SQL/feature references), `access-review`.

4) Runtime enforcement- Feature-serving layer should filter sensitive features unless the request context has explicit authorization. Implement attribute-based access control (ABAC) using service tokens that carry purpose.- Row/column-level masking: Serve NULL/hashed values for unauthorized requests; log and audit every access.

5) Governance + monitoring- Periodic scans comparing model training artifacts with catalog to detect drift/hidden leakage.- Alerting on sudden inclusion of newly-tagged sensitive features in model inputs.- Maintain an approval workflow and require threat-model review for any exemption.

Why this works: combines low-friction developer experience (naming + metadata) with deterministic blocking (registration/CI) and last-line defense (runtime ABAC/masking + auditing).

Unlock Full Question Bank

Get access to hundreds of Privacy by Design and Principles interview questions and detailed answers.

Join thousands of developers preparing for their dream job.