Data Governance, Privacy, and Compliance
Privacy architecture is a design constraint, not a cleanup task. Candidates must understand the data lifecycle: what is collected, why, where it is stored, how long it is retained, who can access it, and how it is deleted. Know the core mechanisms: consent management integrated with tagging (consent determines whether beacons fire and what is included), IP obfuscation, data retention settings, data governance labels and their use in Experience Platform, and Privacy Service for access and deletion requests across Adobe solutions.
Understand the regulatory framing at a conceptual level: purpose limitation, data minimization, lawful basis, and subject rights. The architect must be able to map a subject access or deletion request to the specific identifiers and datasets that hold the data, including downstream exports and classifications.
Also know hit-level deletion and data repair limitations, the difference between deleting a visitor's data and excluding them going forward, and the fact that exports and feeds create copies outside the primary retention policy.
Traps: assuming a deletion request covers data feeds already delivered to a warehouse; treating consent as a UI banner rather than a gate on collection; applying retention settings and assuming historical data vanishes immediately; and labeling data after ingestion when labeling at schema definition is required. Questions often describe a compliant-sounding process that misses a downstream copy.
Rule of thumb: minimize at collection, label at definition, and trace every identifier to every copy. If you cannot enumerate all stores holding a visitor identifier, you cannot honor a deletion request.
Worked example: a deletion request arrives for a customer ID. The architect must remove it from the report suite, the identity graph, the data feed landing zone, and any imported classification files, then document completion.