Day 5 - Week 9 Review: Security and Governance

📌 Key Takeaways

• A single data request passes in order through the checkpoints of transport (TLS) → IAM → Lake Formation → KMS → filters and masking → audit records. If it is denied, first work out which checkpoint denied it.
• IAM and Lake Formation are in an AND relationship. Both must pass to reach the data, and for encrypted data the KMS key policy must also be right.
• Encryption is distinguished by who holds the key (SSE-S3 / SSE-KMS / SSE-C / client-side). Encryption in transit is enforced separately.
• Macie only detects. What reduces exposure is masking, tokenization, and data filters, and you must decide where to mask (ETL, catalog, or query).
• For sharing, separate Data Exchange (hands over) from Clean Rooms (originals not exposed), and object-level auditing is recorded only if you turn on CloudTrail data events.

The Checkpoints One Request Passes Through

This week we looked at access control, encryption, sensitive data protection, and governance, one per day. The four topics are not separate features; they are the checkpoints that a single analyst query passes through, in order, before it reaches the data.

An analyst's Athena query
   │
   ▼ ① Transport: is it TLS?            (aws:SecureTransport, require_ssl)          Day 2
   ▼ ② IAM: can it call this API?        (athena, glue, lakeformation:GetDataAccess) Day 1
   ▼ ③ Lake Formation: can it see this table?  (SELECT, LF-Tags)                    Day 1
   ▼ ④ KMS: can it decrypt?              (key policy, kms:Decrypt)                   Day 2
   ▼ ⑤ What is returned?                 (data filters, masking, tokens)             Day 1, 3
   ▼ ⑥ Record: who read what?            (CloudTrail data events)                    Day 4
 Result

• ① through ④ decide whether it passes, ⑤ decides the visible scope, and ⑥ decides after-the-fact proof. Looking at which of the three the question's requirement belongs to narrows the answer choices.
• The checkpoints cannot substitute for one another. Encryption (④) does not stop an authorized user from seeing PII, and permissions (③) do not record who viewed it.

"Where Was It Blocked" Lookup Table

• Cross-account problems have three layers: the trust policy (who can assume the role) + the permission policy (what that role can do) + the KMS key policy. If the question says two of them are in place, the remaining one is the answer.

Telling Look-Alikes Apart

Four means of "keeping sensitive data from being seen"

• Macie is different in nature in this table. The other three are controls, and Macie is discovery. If you pick Macie for a requirement to "make it invisible," it is wrong.

S3 encryption: who holds the key

Sharing: what the other party gets their hands on

Audit logs

Where to Configure: One Page per Service

• Even if the source is encrypted with SSE-KMS, Athena query results and Glue job temporary and log data follow their own settings. This is where sensitive data leaks through the result bucket or the logs.

Week 9 Numbers and Defaults on One Page

• Three values changed recently: the rotation period of AWS managed keys (3 years → 1 year), the default blocking of SSE-C, and the default encryption of Redshift. Exam material may still show the old values.

Integrated Scenario: A Regulated Customer Data Platform

Requirements: Load payment data into a data lake, detect and protect PII, show analysts only masked data, collaborate with partners without exposing originals, audit all access, and respond to GDPR deletion.

[Payment source] --Glue ETL (KMS encryption, tokenization)--> s3://lake-clean/payments/ (Iceberg)
   --Macie scan--> [PII finding] --EventBridge--> [Lambda: restrict access/notify]
   --Lake Formation (data filters, LF-Tags)--> [Analysts: view without PII]
   --Clean Rooms--> [Partners: agreed aggregates only]
   All activity --> CloudTrail (data events) --> audit account bucket

-- GDPR deletion (Iceberg on Athena): logical delete, then clean up snapshots too
DELETE FROM lake_clean.payments WHERE customer_id = 'GDPR-REQ-2026-042';
VACUUM lake_clean.payments;

{
  "Name": "analyst_payments_filter",
  "ColumnNames": ["txn_id", "region", "amount_token", "dt"],
  "RowFilter": { "FilterExpression": "region = 'ap-northeast-2'" }
}

• For Macie to read this bucket, the customer managed key's key policy must allow Macie. The encryption decision (Day 2) becomes a precondition of the detection decision (Day 3).
• The reason to keep Macie even though you tokenized is the paths the design missed. Controls block "where it should be," and detection finds "where it should not be."

Three Requests You Actually Get in Operations

💡 Related theory: Security and governance are not a single control but defense in depth. Encryption (confidentiality) + access control (authorization) + detection (visibility) + auditing (accountability) must work together to meet regulatory and trust requirements. Because one is strong, you cannot omit another.

Frequently Missed Traps

• Turning on Lake Formation does not mean control is applied. If IAMAllowedPrincipals remains, data is readable through IAM alone.
• Lake Formation does not block direct S3 access. Even with a filter, if the user has s3:GetObject, the raw file opens.
• KMS permissions do not end with the IAM policy. The key policy must allow IAM delegation or allow directly.
• Rotating a key does not re-encrypt existing data. Even if you change default encryption, existing objects stay as they are.
• A Bucket Key is not giving up key control. It is only that KMS events show the bucket ARN rather than the object.
• Macie neither masks nor deletes. It also does not look outside S3 (Redshift tables).
• DELETE is not a physical deletion. Until you expire the snapshots, the data can be read through time travel.
• datashare and Data Exchange are not "originals not exposed." They just do not copy; the other party reads the rows.
• Even with audit logging on, query statements may not be recorded. In Redshift, enable_user_activity_logging is separate.

Question Clue → Correct Answer Table

Next week is the last week. We start with an integrated review of Domains 1 and 2 (ingestion and transformation, and store management).

📖 Glossary

• Defense in depth: A design that protects in multiple layers so that if one control is breached, the next one blocks.
• Control point: A point where a request is judged as to whether it passes. Transport, IAM, Lake Formation, and KMS are one each.
• In-place access: A sharing method in which you read the provider's store directly instead of receiving a copy of the data.
• Analysis without exposing originals: A collaboration method in which you get only agreed aggregate results without seeing the other party's row data.
• Logical deletion / physical deletion: Merely marking as deleted versus actually removing from storage. An Iceberg DELETE is the former.
• Audit account: An account, separated from operations accounts, where logs are gathered. It keeps operators from altering their own records.
• Accountability: The property of being able to prove after the fact who did a given action.
• Right to be forgotten: The right of an individual to demand deletion of their own data. A GDPR deletion request is the representative example.