Enforce GDPR's Right to be Forgotten Across a Complex Architecture
This tests your design of a verifiable, async deletion workflow. A strong answer proposes a central index metastore, an orchestrated workflow (e.g., Step Functions) for deletion, and an auditing layer.
What's really being asked
This question assesses your understanding of data governance and compliance in a distributed system. The interviewer is looking for more than a simple deletion script. They want to see if you can design a system that is robust, auditable, and handles the complexities of different storage paradigms like immutable object stores, transactional databases, and ephemeral caches. It tests your ability to think about asynchronous workflows, error handling, human-in-the-loop approvals, and verifiability.
The full answer
A strong answer outlines a multi-stage, orchestrated process. First, acknowledge the core challenge: you cannot efficiently scan all data. Propose creating and maintaining an index metastore (e.g., in DynamoDB or RDS) that maps a user ID to the specific locations of their data (e.g., S3 object key and row number, database primary key). Second, describe the deletion workflow itself, ideally using an orchestration engine like AWS Step Functions. This workflow would query the index, generate a deletion plan, handle optional human approval steps (via email links and API Gateway), execute the deletions across different systems, and update the index. Third, emphasize verifiability. The final step should be generating a permanent, auditable report confirming the deletion, which is stored in a secure location.
The mistakes people make
A major red flag is proposing a simple, synchronous "find and delete" script. This approach is naive and fails in a real-world system. It doesn't scale, as it requires scanning massive datasets. It ignores the immutability of data in lakes like S3, where you can't delete a single row within a file (you must rewrite the file). It also lacks robustness, error handling, and the critical audit trail required to prove compliance to regulators. Another mistake is forgetting about downstream systems like caches or search indexes, leading to incomplete data erasure.
What usually comes next
Expect questions about the details. How do you build the index for a pre-existing, massive data lake? (Answer: A large-scale batch job, e.g., using Spark or AWS Glue, to backfill the index). How do you handle deletion failures in the middle of the workflow? (Answer: The orchestrator, like Step Functions, should have built-in retry logic and state management; failed deletions are flagged for manual intervention). What is the performance and cost impact of maintaining the index? (Answer: Discuss the trade-off: write-time cost of updating the index vs. the unacceptable cost/time of a full scan during a deletion request).
A concrete example
Using AWS services, a deletion request could trigger a Step Functions state machine. The first Lambda function queries a DynamoDB index for all S3 objects and Snowflake rows associated with the user ID. The state machine then enters a wait state for human approval, sending an email via SES with "approve/reject" links that point to an API Gateway endpoint. Upon approval, another Lambda is triggered. For S3, it reads the original Parquet file, filters out the user's data, and writes a new file, then deletes the old one. For Snowflake, it issues a DELETE FROM ... WHERE user_id = X command. For Redis, it issues a DEL command. Once all tasks complete successfully, a final Lambda generates a PDF receipt of deletion and saves it to a WORM-compliant S3 bucket for auditing.
Interview question
When designing a GDPR 'right to be forgotten' workflow, what is the primary purpose of maintaining a central index that maps user IDs to their data locations?
- a.To generate a final, permanent audit report that proves the deletion was successfully completed for regulators.
- b.To avoid inefficient, full-system scans by providing direct pointers to a user's data across all services.Correct
- c.To manage the retry logic and error handling if a deletion fails in one of the connected data stores.
- d.To temporarily consolidate a user's data from all systems into one place before executing the deletion.
Why? this is the answer
The correct answer is C because the central index's main function is to make data discovery efficient, avoiding the impracticality of scanning entire databases or data lakes. Distractor A is incorrect because retry logic is the responsibility of the workflow orchestrator, not the index itself.
Just read this? Test yourself on what you have been reading.
Read the original → aws.amazon.com
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on data governance — each one lists the topics its interview covers.
See open roles