Data Security and Governance
Privacy, Sovereignty, and Data Governance
CoreShare data without uncontrolled copies, discover PII, constrain Region placement, reconstruct configuration change, enforce sovereignty, govern project access, and operate a complete data-governance framework.
Aligned to AWS Certified Data Engineer - Associate (DEA-C01) Version 1.1, verified August 25, 2026.
Why this matters
Governance is a system of ownership, classification, access, lineage, quality, sharing, retention, and audit. No single catalog, tag, encryption setting, or Region choice provides all of these controls.
Must Know
- Redshift data sharing can grant governed access to live producer data without requiring an uncontrolled export copy; producer and consumer permissions still matter.
- Amazon Macie discovers and classifies sensitive data in S3. A finding informs handling and access controls but does not automatically revoke access.
- Restrict backup and replication destinations to approved Regions and accounts, align KMS keys and policies, and monitor configuration drift.
- Use AWS Config for resource configuration history and timelines; correlate with CloudTrail when the auditor also needs the actor and API call.
- Data residency concerns location; data sovereignty also includes applicable legal authority, account and operator control, access, encryption, retention, and operational governance.
- SageMaker Catalog project access uses membership, subscriptions, approvals, and least-privilege access to governed assets; project membership does not grant every catalog asset.
- A governance framework assigns owners and stewards, classifications, data contracts, catalog and lineage, quality expectations, access workflows, retention, sharing patterns, and auditability.
- Data sharing and governed subscription differ from copying datasets and credentials into consumer-owned stores.
Compare and Distinguish
- Data sharing versus copying: permissioned access differs from creating another lifecycle and control surface.
- PII discovery versus enforcement: classification findings differ from authorization and remediation.
- Residency versus sovereignty: physical placement differs from broader legal and operational control.
- AWS Config versus CloudTrail: configuration state history differs from API actor evidence.
- Project access versus governance framework: one enforcement surface differs from the overall operating model.
Scenario examples
- A consumer account queries a Redshift datashare under explicit permission rather than receiving an UNLOAD copy.
- Macie findings identify likely PII, after which Lake Formation and IAM controls restrict access and a governed remediation process handles the objects.
- A regulated dataset stays within approved Regions and accounts while AWS Config detects changes and CloudTrail identifies the modifying principal.
Exam traps
- Assuming Macie findings automatically enforce access.
- Using encryption as the only data-residency control.
- Treating an AWS Region tag as a sovereignty framework.
- Granting one project membership unrestricted access to every domain asset.
Key takeaways
- Govern data through coordinated ownership, policy, metadata, quality, lineage, access, and audit.
- Prevent uncontrolled copies and verify location controls.
- Use the correct evidence source for state change and actor identity.
How it works
- Owners publish classified assets with contracts and access workflows, while stewards monitor quality, lineage, retention, and sharing.
- Preventive controls limit copies and destinations; AWS Config and CloudTrail provide complementary evidence of state and actor changes.
When to use it
- Use Redshift data sharing or governed subscriptions when consumers need approved access without unmanaged exports.
- Use Macie to discover sensitive S3 data, AWS Config for configuration history, and CloudTrail for the modifying API actor.
Security and governance implications
- Restrict replication, backup, keys, and project access to approved accounts and Regions and monitor drift from those controls.
- Grant project or domain access through memberships and subscriptions at the asset scope rather than assuming membership grants everything.
Common failure modes and diagnosis
- For a disallowed copy, trace export, replication, backup, restore, sharing, and derived-data paths across accounts and Regions.
- For a governance exception, compare asset owner approval, classification, project membership, access policy, configuration history, and API activity.
More detail
- 4.5.1: Grant permissions for data sharing (for example, data sharing for Amazon Redshift).
- 4.5.2: Implement PII identification (for example, Amazon Macie with Lake Formation).
- 4.5.3: Implement data privacy strategies to prevent backups or replications of data to disallowed AWS Regions.
- 4.5.4: Viewing configuration changes that have occurred in an account (for example, AWS Config).
- 4.5.5: Maintain data sovereignty.
- 4.5.6: Manage data access through Amazon SageMaker Catalog projects.
- 4.5.7: Describe governance data framework and data sharing patterns.
Ready for the quiz?
- Can the consumer receive governed access without creating another uncontrolled copy and lifecycle?
- Which owners, Regions, accounts, keys, replicas, projects, and retention controls define the sovereignty boundary?
Related objectives
- D4.5 — Task 4.5: Understand data privacy and governance
- 4.5.1 — Grant permissions for data sharing (for example, data sharing for Amazon Redshift).
- 4.5.2 — Implement PII identification (for example, Amazon Macie with Lake Formation).
- 4.5.3 — Implement data privacy strategies to prevent backups or replications of data to disallowed AWS Regions.
- 4.5.4 — Viewing configuration changes that have occurred in an account (for example, AWS Config).
- 4.5.5 — Maintain data sovereignty.
- 4.5.6 — Manage data access through Amazon SageMaker Catalog projects.
- 4.5.7 — Describe governance data framework and data sharing patterns.