Security and Privacy Program Governance and Strategy Questions
Designing and running enterprise security and privacy programs: setting vision and a multi-year roadmap, structuring governance bodies, defining security-officer, DPO, and privacy-officer responsibilities and board oversight, and aligning objectives with organizational risk appetite. Covers how a program is resourced, prioritized, matured, and evolved, and how governance authority and accountability are established across both security and privacy. Program-level strategy and maturity modeling rather than individual control implementation.
MediumTechnical
32 practiced
A prospective third-party analytics vendor provides a client SDK that collects device IDs and location. As a data engineer, create a checklist of technical assessments and mitigations you would require before integrating the SDK into production. Include what to look for in the SDK, telemetry, legal assurances, and runtime controls.
Sample Answer
Overview: Before integrating a third‑party analytics SDK that collects device IDs and location, require a technical, privacy, security, and operational checklist plus concrete mitigations so ingestion pipelines and downstream teams aren’t exposed to PII, legal risk, or instability.SDK/Code-level assessment- Request SDK binary/source, SBOM and build artifacts; verify signed releases and pin a fixed version.- Perform static code scan and dependency vulnerability check (SCA); run dynamic analysis on a sandbox device/emulator.- Inspect telemetry collection code paths: what fields are captured, where hashing/pseudonymization occurs, and whether raw device IDs/location are ever persisted or logged.- Verify network endpoints (hosts, IPs), TLS enforcement, certificate pinning, and support for proxy/allowlist.- Confirm runtime config options (disable/enable location, sampling rate, event filters, verbose logging off).Privacy & legal assurances- Require Data Processing Agreement (DPA) and tech addendum stating: no secondary use, no re-identification, retention limits, and data deletion on request.- Ask for certifications & audits: SOC2 Type II, ISO27001, PCI if relevant; provide recent penetration test and vulnerability remediation timeline.- Require DPIA or privacy impact statement and description of international transfers (SCCs/adequacy).- Contract clauses: indemnity for privacy breaches, breach notification timelines (e.g., 72 hours), audit rights, and minimum security standards.Telemetry & observability requirements- Schema/contract: explicit list of event types, fields, data types, and allowed values. Enforce schema validation at ingestion.- Instrument and monitor: - Volume/throughput changes by event type (anomaly alerts) - Presence of PII in payloads (PII detectors/regex rules; alert and quarantine) - Error/exception rates and SDK version distribution - Latency and retry patterns to vendor endpoints- Produce sample payloads and run synthetic workloads in staging to validate telemetry.Runtime controls & mitigations- Feature flags / remote config to toggle SDK on/off per environment, user cohort, or region; immediate kill switch accessible to SREs.- Client-side opt-in gating: integrate with our consent manager (only initialize SDK after consent).- Configure SDK to disable location/device ID collection by default; use hashed+salted identifiers only when necessary.- Enforce sampling & rate limiting upstream (gateway) to prevent flood of events.- Egress controls: network allowlist for vendor hosts, route through proxy that logs and inspects outbound payloads.- On ingestion: transform pipeline step to pseudonymize (HMAC with per-tenant key), strip or tokenise location to coarse granularity before storage.- Retention & partitioning policies: store raw PII only if absolutely necessary, in isolated encrypted storage with strict access controls and short TTL.Testing & rollout- Staging integration with synthetic and consented test users; schema validation and PII-detection tests.- Performance and load testing to measure added CPU/network on clients and ingestion systems.- Canary rollout (small % of users), monitor telemetry and business metrics, then progressively increase.- Backout plan: automated disable + search-and-delete scripts for recent PII if misconfigured.Operational & governance- Define SLAs with vendor for data availability, accuracy, and incident response.- Schedule periodic re-review: quarterly security/usage review and immediate re-eval on major SDK updates.- Maintain audit trail: changes to SDK config, consent state transitions, and deletion/processing requests.- Inform downstream teams and data catalog: mark datasets that originate from this SDK, document transformation/pseudonymization rules.Example mitigations (concrete)- If SDK sends raw device IDs: block at proxy; replace with HMAC(device_id, internal_key) before persisting.- If SDK sends precise lat/long: transform to city-level or grid TileID before storage.- If vendor changes schema unexpectedly: reject new events at ingestion and alert data engineering + product.This checklist ensures privacy-by-design, protects pipelines, preserves legal compliance, and gives operational controls to rapidly respond to problems.
MediumTechnical
27 practiced
Design observability and alerting for privacy in data pipelines. What telemetry, metrics, and logs would you collect to detect unauthorized PII access or exfiltration (for example unexpected spikes in PII counts or anomalous exports)? Describe detection rules, where to centralize alerts (SIEM), and response playbooks.
Sample Answer
High-level approach: treat PII observability like security + data-quality monitoring. Collect rich telemetry at ingestion, processing, storage, and export points; compute privacy-specific metrics; centralize in SIEM/observability platform; create deterministic and anomaly-based detection rules; and have clear, tested playbooks for investigation and containment.Telemetry & logs to collect- Ingestion logs: source ID, dataset/table, schema version, record counts, PII field counts per batch, producer credentials, source IP- Processing logs: job id, user/service account, code commit id, transformation that touches PII, row-level counts of PII before/after step- Access logs: read/write operations on data stores (S3/GCS, DB), query logs (BigQuery/Athena/Presto), user/service principal, client IP, SQL text, row/byte counts returned- Export/audit logs: ETL exports, downstream consumers, external transfers, export destinations, signed URLs, SFTP/HTTP events- Metadata lineage: dataset lineage events mapping PII fields through pipeline- Network telemetry: egress volumes, destination IPs, unusual protocols- Integrity events: schema drift, masking/de-identification failures, job errorsMetrics to compute (time-series)- PII_count_by_dataset, PII_rate (PII rows/min), PII_fields_per_record, unique_export_destinations, privileged_access_rate, failed_masking_rate, row_export_volume_by_destination- Baselines: rolling 7/14/30-day medians and variance for PII_count_by_dataset and export volumes- Ratio metrics: PII_reads / total_reads, PII_exports / total_exportsDetection rules- Thresholds: static (e.g., single export > X PII rows) and dynamic (z-score > 4 over rolling baseline)- Spike detection: sudden >200% increase in PII_count_by_dataset or PII_rate- Anomalous destinations: export to new external domain/IP not in allowlist- Privilege anomalies: service account or user accessing PII outside usual schedule or from rare geo/IP- Aggregation anomalies: many small exports that sum to a large PII count within short window (exfiltration by chunking)- Masking failures: downstream contains raw PII when a masked copy expected- Lateral movement: same principal accessing many datasets with PII within short time- Correlation rules: combine network egress spikes + new destination + increased PII_count → high severityCentralization & tooling- Ship all logs/metrics/alerts to SIEM (e.g., Splunk, Elastic SIEM, Sumo Logic, Sentinel) and APM/metrics store (Prometheus/Grafana) with enrichment (user/asset/context, data sensitivity tag)- Use a metadata/catalog (e.g., Data Catalog, Amundsen) to map dataset sensitivity and owner; enrich SIEM events with sensitivity level- Implement an alert routing layer: low/medium alerts to on-call data eng, high/critical to security SOC + data-privacy owner- Retain raw logs and lineage for forensic replay (WORM or ≥90 days depending on policy)Response playbook (tiered)1) Triage (Automated)- Auto-enrich alert (dataset owner, recent runs, last deploy)- Run quick queries: last 24h exports, top consumers, IPs- If rule matches known false-positive (e.g., scheduled export), auto-close or annotate2) Contain (Manual + automated)- Revoke or rotate credentials for implicated service account- Block destination IPs or suspend external transfer jobs- Pause affected pipelines / revoke dataset access (apply IAM deny) — automated runbook via infra-as-code3) Investigate- Use lineage and retained logs to reconstruct timeline: who/what/where/how- Export forensic snapshot (immutable) for security team- Interview stakeholders and check recent deploys/privilege grants4) Remediate- Revoke unintended exports, request deletion at external receiver if possible- Fix masking/deid bugs, roll forward a patch, and rerun pipelines with corrected masking- Rotate keys, enforce least-privilege, and add missing allowlists5) Post-incident- Root-cause analysis, update detection rules (reduce false positives), add automated tests for masking, update runbooks- Notify compliance/legal per privacy policy; log metrics for auditOperational best practices- Define severity and SLA matrix (minutes for critical exfiltration)- Run regular attack-simulation drills and tabletop exercises- Instrument pipelines to emit structured JSON logs and standardized PII metrics- Use differential privacy or synthetic data in dev/test to reduce exposure riskThis design balances deterministic checks (thresholds/allowlists) with anomaly detection (baselines, z-scores, correlation) and ensures alerts are actionable through SIEM enrichment and clear containment/investigation playbooks.
HardTechnical
28 practiced
Implement or describe the core logic of a Spark Structured Streaming application (PySpark) that filters events based on a real-time consent store. Requirements: low latency (<1s read from consent store), exactly-once semantics for downstream sinks (Kafka or parquet), and resilience to schema evolution. Include code snippets or pseudocode and discuss where consistency and backpressure issues arise.
Sample Answer
Approach (summary)- Keep a low-latency, strongly-consistent consent store (e.g., Redis/Elasticache, CockroachDB, DynamoDB with DAX) and maintain an in-memory broadcast/cache of consent keys in the Spark executors refreshed frequently (<1s TTL) to avoid per-row RPCs.- Use Structured Streaming with checkpointing + exactly-once sinks: for Kafka use Spark’s built-in Kafka sink (which integrates with offsets and checkpointing) or use foreachBatch with a transactional Kafka producer. For files/parquet prefer Delta Lake (ACID, schema evolution) or atomic write-then-rename pattern.- Handle schema evolution via a schema-aware sink: Delta Lake/Parquet + schema merge or Avro with explicit schema registry.Core code (PySpark pseudocode demonstrating broadcast refresh + foreachBatch to ensure exactly-once writes to Kafka and Delta):Key concepts and reasoning- Broadcast consent map refreshed frequently keeps per-event latency <1s; avoids per-row blocking RPCs and reduces backpressure risk.- Checkpointing + Kafka sink gives end-to-end exactly-once semantics: Spark tracks source offsets and sink commits are tied to checkpoint. Using Delta Lake provides ACID guarantees for files and supports schema evolution (mergeSchema or Delta schema evolution).- foreachBatch gives a deterministic microbatch boundary to perform atomic writes to multiple sinks; ensure operations inside foreachBatch are idempotent or transactional.Consistency and backpressure issues- External consent store consistency: if using eventual-consistent stores, you may accept stale consent for short windows. To guarantee strong consistency, use a CP store or leader-read path.- Broadcast refresh window trades freshness vs throughput; very small refresh intervals increase load on consent store; large intervals increase staleness.- Backpressure arises if consent refresh or enrichment is slow; avoid doing per-partition remote calls — use batched fetches or local caches. If streaming input rate > processing capacity, Spark will accumulate microbatches (increasing latency) — monitor and autoscale executors, throttle sources, or apply sampling/drop policies with business agreement.- Exactly-once pitfalls: custom sinks must be transactional/idempotent. If using a custom Kafka producer in foreachBatch, use Kafka transactions (init/commit per batch) and persist producer state keyed by batchId; ensure checkpointing replicates the batchId state.Edge cases & best practices- If consent set is large but sparse, use bloom filters in broadcast for quick membership checks to shrink memory footprint.- For schema evolution of events, prefer Delta Lake with mergeSchema or use Avro + schema registry; validate schema in pre-processing and fail-fast for incompatible changes.- Monitor lag, executor memory, and consent store performance; implement alerting and circuit-breaker if consent store becomes unavailable (e.g., fallback to deny-by-default).- Test failure scenarios: driver failure, executor loss, and verify exactly-once by end-to-end integration tests.This design balances sub-second consent checks, end-to-end exactly-once, and resilience to schema changes by combining in-memory broadcast caching, Spark checkpointing, and ACID file formats (Delta) or transactional Kafka writes.
python
from pyspark.sql import SparkSession
from pyspark.sql.functions import col
import redis, json, time
spark = SparkSession.builder.appName("consent-filter").getOrCreate()
# Read streaming source
raw = spark.readStream.format("kafka") \
.option("kafka.bootstrap.servers","kafka:9092") \
.option("subscribe","events") \
.load()
events = raw.selectExpr("CAST(key AS STRING)", "CAST(value AS STRING) as json") \
.selectExpr("key", "from_json(json, 'user_id STRING, payload MAP<STRING,STRING>, ts TIMESTAMP') as data") \
.select("key", "data.*")
# Helper: refresh consent broadcast (runs on driver thread)
def load_consent():
r = redis.Redis(host='redis', port=6379, db=0)
# store consent as JSON map user_id -> boolean
keys = r.hgetall("consent_map")
return {k.decode(): v.decode()=="1" for k,v in keys.items()}
consent_map = spark.sparkContext.broadcast(load_consent())
LAST_REFRESH = time.time()
def enrich_and_filter(df, batch_id):
global consent_map, LAST_REFRESH
# refresh broadcast if older than 0.8s
if time.time() - LAST_REFRESH > 0.8:
consent_map.unpersist()
consent_map = spark.sparkContext.broadcast(load_consent())
LAST_REFRESH = time.time()
# convert broadcast to DF for join (small)
consent_df = spark.createDataFrame([(k, v) for k,v in consent_map.value.items()], ["user_id","consent"])
joined = df.join(consent_df, df.user_id==consent_df.user_id, "left").filter(col("consent") == True)
# write to Delta for storage (ACID, schema evolution) and to Kafka exactly-once using foreachBatch transactional producer
joined.write.format("delta").mode("append").option("mergeSchema","true").save("/mnt/delta/events")
# Write to Kafka using Spark's kafka sink to leverage exactly-once with checkpointing
out = joined.selectExpr("CAST(user_id AS STRING) AS key", "to_json(struct(*)) AS value")
out.write.format("kafka") \
.option("kafka.bootstrap.servers","kafka:9092") \
.option("topic","filtered-events") \
.save()
query = events.writeStream.foreachBatch(enrich_and_filter) \
.option("checkpointLocation","/mnt/checkpoints/consent-filter") \
.start()
query.awaitTermination()EasyTechnical
28 practiced
Assume our company primarily serves users in the EU and California but also has customers in Brazil and Canada. Which privacy laws and regulations should a data engineer be most aware of (list at least four) and for each give one engineering-level compliance action (e.g., data residency, DPIA, consent storage, opt-out propagation).
Sample Answer
Relevant privacy laws a data engineer should know and a concrete engineering-level compliance action for each:- GDPR (EU): Implement data subject rights and DPIA support — build pipelines that tag personal data with purpose/consent metadata, maintain per-record provenance, and provide APIs to quickly locate, export, or delete an individual’s data (supporting right to access/erasure) and enable automated Data Protection Impact Assessments by logging processing flows.- CCPA / CPRA (California): Support opt-out and sale-processing controls — add flags in datasets indicating “do not sell/share” and ensure downstream ETL and third-party export jobs respect that flag (block transfers, anonymize, or exclude records before export).- LGPD (Brazil): Consent and lawful basis tracking — store immutable consent artifacts (who, when, what was consented to) in a consent service and join that to ingestion pipelines so data is only processed under a valid legal basis; enforce retention schedules accordingly.- PIPEDA (Canada): Data minimization and cross-border safeguards — implement schema and ingestion filters to collect only necessary attributes, and enforce data residency or encryption-at-rest/in-transit for records sent to non-Canadian regions; log transfers and apply access controls.Bonus: For cross-jurisdiction compliance, implement a central metadata/catalog service that records geo-tagging, residency requirements, retention, and consent per dataset to drive pipeline behavior (routing, masking, deletion).
EasyTechnical
36 practiced
You've researched our company's public privacy commitments (privacy policy, transparency reports, DPO/contact page, and any blog posts about privacy). Summarize the three most important public commitments you found that are directly relevant to data engineering, and for each commitment explain one concrete engineering requirement it creates for pipelines, storage, or tooling (for example: retention limits, encryption-at-rest, consent enforcement, or audit logging). Be specific about where the commitment maps to an operational control.
Sample Answer
1) Commitment: Data minimization and retention limits — policy states we only keep personal data as long as necessary and publish retention schedules.Engineering requirement: Enforce automated retention at storage and pipeline layers. Implement TTL lifecycle policies (e.g., partition-level expiry) for raw and curated tables: for example, set Hive/Spark table partitions with date-based expiration and configure S3/GCS lifecycle rules to transition then permanently delete objects after X days. Operational control mapping: retention policy = automated lifecycle jobs + periodic attestation reports; include a scheduled job that scans tables/partitions, deletes expired partitions, and emits retention-compliance metrics to monitoring.2) Commitment: Protect data in transit and at rest (encryption & key management) — privacy statements promise strong encryption and key control.Engineering requirement: Enforce encryption-at-rest and envelope encryption in storage and tooling. Ensure all object stores and databases have server-side encryption with customer-managed KMS keys; implement application-layer encryption for sensitive fields before landing to raw buckets. Operational control mapping: enforce via Infrastructure-as-Code (Terraform) that denies creation of unencrypted buckets/instances, and pipeline CI jobs that fail if keys/policies not present; audit KMS usage logs for access controls.3) Commitment: User control (consent, access, deletion/erasure) and auditability — users can withdraw consent and request deletion; company maintains transparency/audit logs.Engineering requirement: Build a consent-aware ingestion and deletion pipeline. Tag records at ingestion with consent_status and provenance metadata; implement a deletion workflow that queries tag/index to identify records to erase across systems, runs deterministic deletion or anonymization jobs, and writes immutable audit entries (who/when/what) into a tamper-evident log (append-only storage with retention). Operational control mapping: consent enforcement = runtime gate in ingestion and ETL (reject/transform data if no consent), plus a deletion orchestration service integrated with audit logging and regular reconciliation reports for privacy team.
Unlock Full Question Bank
Get access to hundreds of Security and Privacy Program Governance and Strategy interview questions and detailed answers.
Sign in to ContinueJoin thousands of developers preparing for their dream job.