GDPR Architecture & System Design 2 — Questions and Answers
Question 1: When designing a microservices architecture that processes personal data, which pattern best ensures GDPR compliance by minimizing data exposure across services?
- Shared database pattern where all services access one central DB
- Data ownership pattern where each service owns its own data store (Correct answer)
- Saga pattern where all services share a common event bus with full payloads
- CQRS pattern without any data isolation between read and write models
Correct answer: Data ownership pattern where each service owns its own data store
The data ownership pattern ensures each microservice controls its own data store, limiting personal data exposure to only the services that legitimately need it.
Question 2: A system architect is designing an API gateway for a GDPR-regulated platform. Which feature is MOST critical for compliance from an accountability perspective?
- Rate limiting to prevent DDoS attacks
- Comprehensive request and response logging with PII redaction (Correct answer)
- SSL termination at the gateway layer
- Load balancing across backend services
Correct answer: Comprehensive request and response logging with PII redaction
Comprehensive logging with PII redaction enables demonstrable accountability while preventing the gateway itself from becoming a source of unauthorized personal data exposure.
Question 3: Under GDPR, when a system uses a data lake architecture, what is the PRIMARY architectural risk that must be mitigated?
- High storage costs making the system economically unviable
- Loss of data context making purpose limitation and erasure difficult to enforce (Correct answer)
- Inability to run analytics queries at scale
- Lack of support for structured data formats
Correct answer: Loss of data context making purpose limitation and erasure difficult to enforce
Data lakes aggregate raw data from multiple sources, making it difficult to track the original purpose of collection and enforce deletion rights without robust metadata management.
Question 4: A Privacy Enhancing Technology (PET) that allows computations on encrypted data without decrypting it first is called:
- Differential privacy
- Homomorphic encryption (Correct answer)
- Tokenization
- Data masking
Correct answer: Homomorphic encryption
Homomorphic encryption enables processing of encrypted data, meaning personal data can be analyzed without ever being exposed in plaintext.
Question 5: Which architectural approach to consent management best supports GDPR's requirement that consent be as easy to withdraw as to give?
- Storing consent in application code as hardcoded flags
- A centralized consent management platform with real-time propagation to all downstream systems (Correct answer)
- Recording consent in a single database table checked manually by developers
- Embedding consent logic within each individual service independently
Correct answer: A centralized consent management platform with real-time propagation to all downstream systems
A centralized consent management platform with real-time propagation ensures withdrawal of consent is immediately reflected across all systems processing data under that consent.
Question 6: When architecting a system to support GDPR's right to erasure, which database design decision creates the MOST difficulty?
- Using primary keys for record identification
- Using immutable append-only event sourcing without a deletion strategy (Correct answer)
- Indexing columns that contain personal data
- Storing data in third normal form
Correct answer: Using immutable append-only event sourcing without a deletion strategy
Immutable event logs make erasure inherently complex because overwriting or deleting historical events breaks the integrity of the event stream.
Question 7: A GDPR-compliant system design requires 'data minimization' at the collection layer. Which architectural control BEST enforces this at the API level?
- Accepting all fields and filtering excess data in the database layer
- Using strict input schemas that reject any fields not required for the stated purpose (Correct answer)
- Logging all received fields and discarding unused ones post-processing
- Compressing incoming payloads to reduce storage consumption
Correct answer: Using strict input schemas that reject any fields not required for the stated purpose
Strict input schema validation at the API layer prevents collection of unnecessary personal data before it enters the system.
GDPR Architecture & System Design 2
When designing a microservices architecture that processes personal data, which pattern best ensures GDPR compliance by minimizing data exposure across services?