Data Privacy and Governance: Macie, Redshift Sharing, Config, and Sovereignty

Amazon Macie is the AWS service that discovers sensitive data in Amazon S3 — it does not protect or mask anything itself; it tells you where the risk is. Macie uses machine learning and pattern matching through managed data identifiers covering categories like names, addresses, credit card numbers, national ID numbers, and credentials, and you can add custom data identifiers (regular expressions with keywords and proximity rules) for organization-specific values such as internal customer IDs or contract numbers.

Macie works two ways. Sensitive data discovery jobs scan the buckets and prefixes you target, on a one-time or scheduled basis, producing sensitive data findings that say which objects contain which categories of data. Automated sensitive data discovery instead samples objects continuously across your buckets, building a running sensitivity profile of your whole S3 estate for a fraction of the cost of full scans — the right default for broad, ongoing visibility, with targeted jobs reserved for full-coverage audits of high-risk buckets. Macie also evaluates the buckets themselves, raising policy findings when a bucket is publicly accessible, unencrypted, or shared outside your organization.

Macie is organization-aware: a delegated administrator account can enable and manage it across all member accounts, which is how a central governance team gets one view of PII exposure. Findings flow to AWS Security Hub and to Amazon EventBridge, and EventBridge is the automation hook — a finding can trigger a Lambda function that tags the object, moves it to a quarantine bucket, or opens a ticket. On the exam, any stem about discovering, classifying, or inventorying PII in S3 resolves to Macie; stems about masking or restricting access to the PII you found resolve to Lake Formation or masking features, never Macie itself.

Discovery only pays off when it changes who can read the data, and the exam guide names the pairing explicitly: Amazon Macie identifies the PII, and AWS Lake Formation enforces access to it. The pattern is a pipeline. Macie finds that certain objects or columns in the data lake contain sensitive categories; an EventBridge-triggered function translates those findings into governance metadata — typically Lake Formation LF-tags such as a classification tag with values like public, internal, or pii applied to the affected databases, tables, or columns; and Lake Formation tag-based access control (LF-TBAC) then grants query access by tag rather than by naming individual tables.

Tag-based access control is what makes this scale. Instead of maintaining grants on thousands of tables, you write a policy once — for example, the analyst role may SELECT on anything tagged internal but nothing tagged pii, while the compliance role may read pii-tagged columns. When Macie finds new sensitive data and the automation applies the pii tag, the restriction takes effect everywhere that tag lands, with no per-table policy work. Lake Formation data filters add the finer instruments: column-level exclusions, row-level filters, and cell-level security applied at query time through Athena, Redshift Spectrum, and EMR.

A concrete scenario ties it together: a healthcare data platform lands raw files in S3 daily. Automated discovery flags a new prefix containing patient identifiers; EventBridge fires a Lambda that applies the pii LF-tag to the corresponding Glue Data Catalog table; from that moment the general analytics role's Athena queries no longer return those columns, while the governed clinical-research role retains access — no data was copied, moved, or manually re-permissioned. That closed loop — detect, tag, enforce — is the answer shape the exam rewards.

Amazon Redshift data sharing grants other Redshift warehouses live, read-only access to your data without copying or moving it — consumers always query the current data, and no ETL pipeline exists to break or lag. A producer creates a datashare, adds objects to it (schemas, tables, views, and user-defined functions), and grants it to a consumer; the consumer creates a database from the datashare and queries the shared objects with ordinary SQL, using its own compute. Because consumers bring their own compute, a heavy analytics team cannot degrade the producer's workload — the isolation argument that distinguishes datashares from simply granting logins on the producer cluster.

Scope determines the workflow. Within one account, a producer grants the datashare directly to another namespace. Across accounts, governance gets an explicit two-step approval: the producer grants the datashare to the consumer account and a producer administrator authorizes it, then a consumer administrator associates it with specific warehouses — mirroring the two-sided pattern you saw with cross-account KMS. Datashares also work across Regions (with data transfer costs), and AWS Data Exchange datashares extend the mechanism to licensing data to third parties, with AWS Data Exchange managing entitlements. Data sharing requires RA3 node types or Redshift Serverless, a favorite exam qualifier — clusters on older node types cannot participate.

Choose datashares whenever a scenario says another team, account, or Region needs to query warehouse data "without copying it," "without ETL," or "with up-to-date data." The classic wrong answers are unloading to S3 on a schedule (stale, duplicated, extra pipeline) or sharing cluster credentials (no isolation, no governance). If consumers are not Redshift at all, that is your cue to reconsider — Redshift data sharing is warehouse-to-warehouse.

Preventing data from reaching disallowed AWS Regions is a preventive-control problem, and the strongest tool is a service control policy (SCP) applied through AWS Organizations. An SCP that denies all actions when the aws:RequestedRegion condition key is not in your approved list stops every principal in every member account — including account administrators — from creating resources or writing data in forbidden Regions. Exempt the global services that authenticate through a single Region (such as IAM and other non-regional endpoints) so you do not break identity management. AWS Control Tower packages this same guardrail as its Region deny control if you want it managed rather than hand-written.

Then close the service-specific side doors — features that copy data across Regions even when no user ever calls an API in the disallowed Region. S3 Cross-Region Replication is configured by s3:PutReplicationConfiguration, so deny that action (or scope it with conditions) to stop replication rules pointing at forbidden Regions. DynamoDB global tables replicate to whatever replica Regions are added — govern the table-update actions that add replicas. Redshift can copy snapshots cross-Region; AWS Backup copy jobs can target other Regions; AMIs and EBS snapshots can be copied too. Each is legitimate for disaster recovery and each is a sovereignty leak if ungoverned — deny the copy and replication actions for non-approved destinations in the SCP.

Detection backs up prevention: AWS Config rules and aggregators (next section) reveal any resource that nonetheless exists in an unexpected Region, and Macie policy findings flag buckets replicating outside the organization. On the exam, distinguish the layers — an SCP is the preventive guardrail; Config is the detective control; and S3 Block Public Access solves a different problem entirely (public exposure, not Region placement), though it belongs in the same governance baseline for any regulated data platform.

AWS Config answers "what changed, when, and was it compliant" — it continuously records the configuration of supported resources as configuration items and keeps a timeline per resource, so you can open any S3 bucket, security group, or Redshift cluster and see exactly how its settings looked at any point in time and which change altered them. Pair it with CloudTrail mentally: CloudTrail tells you who made the API call; Config tells you what the resource's configuration became as a result. Auditors typically need both halves.

Config rules evaluate resources against policy continuously or on change. Managed rules cover the common cases — buckets must block public access, volumes and snapshots must be encrypted, resources must carry required tags — and custom rules (Lambda-backed or written declaratively with Guard) express organization-specific policy. A noncompliant evaluation can trigger automatic remediation through Systems Manager Automation documents: the classic example re-enables encryption settings or removes a public bucket ACL minutes after someone changes it. Conformance packs bundle rules and remediation into a deployable compliance baseline you can push organization-wide, and an aggregator collects configuration and compliance data from every account and Region into one governance-account dashboard — including surfacing resources sitting in Regions where nothing should exist.

For a data platform, Config is how you prove the security posture you claim: that every data bucket has always had encryption and public access blocks on, that no Redshift cluster was ever publicly accessible, that a security group opened to the world last Tuesday was remediated within minutes. When an exam stem asks how to view configuration changes over time, evaluate resources against rules, or auto-remediate drift, the answer is AWS Config — not CloudTrail, which records calls rather than resulting state, and not Trusted Advisor, which checks best practices rather than your own policies.

Data sovereignty means data remains subject to the laws of the jurisdiction where it is stored — and often, per regulation or contract, must physically stay in that jurisdiction. The foundational AWS property is that customer data in a Region does not leave that Region unless you move it: S3, Redshift, DynamoDB (without global tables), and EBS all store data regionally. Sovereignty engineering is therefore mostly the discipline of not moving it — the Region-deny SCPs and replication controls above are the enforcement half of a sovereignty story.

Encryption supplies the second half: control of the keys. KMS keys are themselves regional — key material for a single-Region key never leaves its Region — so encrypting data with a customer managed key in the approved Region, holding the key policy tightly, and logging every use through CloudTrail demonstrates that even AWS-side operations on your data were mediated by keys under your jurisdiction's control. Be deliberate with multi-Region keys: they exist precisely to make ciphertext portable across Regions, which is the opposite of what a sovereignty mandate usually wants. For residency-plus-latency contradictions — users worldwide, data confined to one Region — architectures serve queries remotely (for example, cross-Region access to a single authoritative store) rather than replicating the data outward.

Compose the full posture for a scenario like "EU customer data must never leave EU Regions": provision infrastructure only in approved EU Regions; apply an SCP denying all other Regions plus the cross-Region copy actions; encrypt with single-Region customer managed keys in those Regions; monitor with Config aggregators for out-of-Region resources; and document the evidence trail with CloudTrail and Config history. The exam rewards answers that stack a preventive control (SCP), a data-layer control (regional KMS keys), and a detective control (Config) rather than any single mechanism.

Amazon SageMaker Catalog is the business data catalog inside Amazon SageMaker Unified Studio, and it manages data access through a publish-and-subscribe model built on projects. Producers publish data assets — Glue Data Catalog tables, Redshift tables — into the catalog with business metadata and glossary terms so consumers can actually find and understand them. Consumers work inside projects: governed workspaces that bundle team members, tools, and the data the project has been granted. When a project needs a published asset, a member raises a subscription request; the data owner approves or rejects it; and on approval the underlying grants (Lake Formation permissions for lake tables, Redshift access for warehouse tables) are fulfilled automatically to the project.

The governance value is the workflow itself: access is requested against a curated catalog, approved by the owner who is accountable for the data, scoped to a project rather than an individual, and recorded — an auditable paper trail replacing ad hoc IAM tickets. Domains and domain units mirror the organization's structure, so ownership and approval authority sit with the business units that steward each data area rather than with a central bottleneck team.

On the exam, differentiate the catalogs: the AWS Glue Data Catalog is the technical metastore (schemas, partitions, locations) that query engines depend on; SageMaker Catalog is the business layer on top — discovery, semantics, ownership, and the subscription workflow. A stem about crawlers, partitions, or Hive-compatible metadata means Glue; a stem about publishing assets, approval workflows, projects, or letting teams find and request data in self-service means SageMaker Catalog.

A data governance framework is the organizational system that keeps data trustworthy and compliant: policies defining classification levels and handling rules; named roles — data owners accountable for each domain and data stewards maintaining quality and metadata day to day; cataloging so data is findable with its meaning and sensitivity attached; lineage so any dataset can be traced to its sources and transformations; quality controls; and auditability across the lot. The AWS services in this lesson are the mechanical enforcement of that framework — Macie implements classification, SageMaker Catalog implements cataloging and stewardship workflows, Lake Formation implements access policy, Config and CloudTrail implement auditability.

Data sharing patterns describe how data moves between producers and consumers, and each has a canonical AWS implementation.

The exam signal words: "single team governs all data" points at the centralized lake; "domain teams own their data as products" is the mesh; "zero-copy, always current, cross-account warehouse access" is a datashare; "monetize or license datasets to external organizations" is AWS Data Exchange. Zero-copy patterns beat copy-based ones whenever the question weighs freshness, duplication cost, or pipeline maintenance — copies win only when consumers sit outside the producing technology or need point-in-time snapshots.