Study DEA-C01 Logging, Privacy, Sovereignty and Governance: key concepts, common traps, and exam decision cues.
This lesson closes DEA-C01 by tying together traceability, privacy, sovereignty, and governance. The strongest answers know that auditability depends on logs, but governance also includes retention, region restrictions, privacy detection, and policy review.
This domain is usually testing whether you can separate four ideas that often get blurred together:
If a stem says “we need governance,” you still need to ask whether it really means audit history, sensitive-data discovery, configuration compliance, or Region-boundary control.
| Need | Strongest first fit |
|---|---|
| API audit trail | CloudTrail |
| centralized audit-style log queries | CloudTrail Lake or analysis tooling |
| sensitive-data discovery | Amazon Macie pattern |
| configuration-change visibility | AWS Config |
| governance review and sovereignty controls | policy, logging, residency, and retention pattern |
When governance questions feel broad, use this order:
| If the stem emphasizes… | Think first | Why this fits |
|---|---|---|
| who did what and when | CloudTrail | This is the audit-event lane. |
| finding PII or sensitive data in S3 | Macie | This is privacy detection, not generic logging. |
| whether resource settings drift from required rules | AWS Config | This is compliance-state visibility. |
| keeping data in approved Regions or legal boundaries | Sovereignty and residency controls | This is a placement and replication-governance problem. |
| retention, policy review, and traceability across the estate | Governance pattern using logs, policy, tagging, and review controls | The answer is broader than one service. |
| Situation | Stronger first answer |
|---|---|
| prove which API action happened and who initiated it | CloudTrail |
| classify sensitive data in S3 | Macie |
| detect whether deployed resources drift from required config | AWS Config |
| stop data from leaving allowed Regions | sovereignty and residency controls |
| review logs and policy together across the platform | broader governance pattern |
flowchart LR
A["Governance requirement"] --> B{"What is the real concern?"}
B -->|Audit activity| C["CloudTrail"]
B -->|Sensitive data discovery| D["Macie"]
B -->|Config compliance and drift| E["AWS Config"]
B -->|Region or residency boundary| F["Sovereignty controls"]
C --> G["Retention and review"]
D --> G
E --> G
F --> G
| Trap | Better reading |
|---|---|
| “We need compliance, so CloudTrail alone solves it.” | CloudTrail is audit history, not the whole governance program. |
| “We need to know if PII exists in S3, so use Config rules.” | That is a sensitive-data discovery problem, which points to Macie. |
| “A sovereignty requirement is really just encryption.” | Encryption helps, but Region placement and replication boundaries are the actual center of gravity. |
| “Governance means one AWS service.” | DEA-C01 often expects a combination of logging, configuration review, privacy controls, and retention policy. |
On DEA-C01, “governance” is often the umbrella answer only after you have already identified the component parts:
That is why a broad requirement may still need more than one AWS service or control family in the final answer.
A regulated company must prove who accessed and changed data resources, detect PII in S3, and ensure certain datasets never replicate into disallowed Regions. The strongest answer usually combines lanes instead of naming one magic service: audit logging for actions, privacy discovery for sensitive content, and sovereignty controls for residency boundaries.