Module 5: Data Security and Network Isolation

🧠 Free Recall ❓ Quiz 🔍 Cues 🔮 Simulation 🥷 ShadowBox 📐 Encode Cards

Module 5 — Data Security and Network Isolation
Tier: Standard. Covers Skill 3.2.1 (protected AI environments — VPC endpoints for network isolation, IAM policies for secure data access patterns, AWS Lake Formation for granular data access, CloudWatch for monitoring data access).
5.0 Why this module exists
Modules 2 through 4 controlled what the model says. This module controls what it can reach.
The distinction matters because these are non-substitutable. A guardrail cannot prevent a retrieval system from returning another tenant's documents. A grounding check cannot stop an ingestion pipeline from indexing a restricted spreadsheet. No output control fixes an access problem, and this is the specific confusion Module 1 warned about — safety controls being proposed where security controls are required.
The module's organizing artifact is a map. For any GenAI system, draw where data sits, where it moves, who can read it at each hop, and where it crosses a boundary. Most security questions in this domain are answered by drawing that map honestly, and most security failures are places the map was never drawn.
5.1 The data flow map
5.1.1 The hops
  SOURCE SYSTEMS          who can read them today?
    |                     what permissions apply?
    v
  INGESTION PIPELINE      <- runs under WHAT identity?
    |                        does it inherit source permissions,
    |                        or does it read as a service?
    v
  STAGING / RAW STORE     <- encrypted with what?
    |                        who can read the bucket?
    v
  EXTRACTION + CHUNKING   <- intermediate artifacts persisted?
    |
    v
  EMBEDDING               <- content leaves your account here
    |                        (or does not, if self-hosted)
    v
  VECTOR INDEX            <- contains EVERYTHING, flattened
    |                        who can query it directly?
    v
  RETRIEVAL               <- filtered by WHOSE permissions?
    |
    v
  PROMPT ASSEMBLY         <- now in a context window
    |
    v
  MODEL INVOCATION        <- crosses to a managed service
    |                        in which region?
    v
  RESPONSE                <- to whom?
    |
    +--> INVOCATION LOGS  <- contain prompts AND responses
    +--> TRACES           <- may contain content
    +--> EVALUATION SETS  <- built from production data
5.1.2 The three hops teams get wrong
The ingestion identity. An ingestion pipeline typically runs as a service, reading everything in scope. Whatever permission model existed at the source is discarded at this hop. A Confluence space restricted to twelve people, indexed by a pipeline with broad read access, is now in an index that anyone with retrieval access can query. §5.4 and §5.5 address this; the point here is that it happens silently at ingestion, not at query time.
The index contains everything. Whatever filtering you apply at retrieval, the index itself holds all indexed content. Direct index access is therefore equivalent to reading the entire corpus — and index access is frequently granted more loosely than source access, because it does not look like the sensitive thing.
The observability tail. Invocation logs contain prompts and responses. Traces may contain content. Evaluation datasets are built from production data. These are copies of your data in systems with their own access models and their own regions, and they are the most commonly missed leg of the map — Domain 2 Module 7 made the same point about residency.
5.2 Network isolation
5.2.1 The requirement and the mechanism
"Traffic must not traverse the public internet" is among the most common compliance constraints in this domain, and the answer is consistently VPC endpoints (PrivateLink).
  WITHOUT an endpoint
    Lambda in VPC -> NAT Gateway -> Internet Gateway
                  -> public internet -> Bedrock

WITH an interface endpoint
    Lambda in VPC -> ENI with a private IP in your subnet
                  -> AWS network -> Bedrock
    Never traverses the public internet.
Two endpoint types, and the distinction is examinable:

Interface endpointGateway endpointMechanismAn ENI with a private IP in your subnetA route table entryServicesMost, including Bedrock runtimeS3 and DynamoDB onlyCostHourly plus data processingNo additional chargeCross-region / on-premisesReachable via Direct Connect and VPNNot reachable from on-premisesSecurity groupsApplicableNot applicable
5.2.2 The full endpoint set
A GenAI workload touches more services than teams anticipate. Missing one produces a hang or timeout that is tedious to diagnose.
  bedrock-runtime         interface   model invocation
  bedrock-agent-runtime   interface   Knowledge Bases retrieval
  s3                      gateway     documents, logs
  dynamodb                gateway     state, metadata
  secretsmanager          interface   credentials
  kms                     interface   encryption operations
  logs                    interface   CloudWatch Logs
  monitoring              interface   CloudWatch metrics
  sts                     interface   AssumeRole
  states                  interface   Step Functions
Enable private DNS on interface endpoints so the standard service hostname resolves to the endpoint. Without it, the SDK resolves the public endpoint and your traffic leaves regardless of the endpoint existing.

5.2.3 Endpoint policies as a second enforcement layer
An endpoint policy restricts what can be done through that endpoint, independently of the caller's IAM.
Why this is more than redundancy: an IAM policy governs a principal. An endpoint policy governs a network path. A policy on the Bedrock endpoint restricting invocation to approved model ARNs applies to every principal using that endpoint, including ones created later by teams who did not read the standard.
The layered position: IAM answers "may this principal do this?" The endpoint policy answers "may this be done through this path at all?" Both, and the endpoint policy is frequently the more durable control because it does not depend on every future role being written correctly.

5.2.4 The VPC-attached Lambda trap
A Lambda attached to a VPC has no default internet access. This surprises teams reliably, and it is the cause of most "it worked in dev, it hangs in production" incidents in this space.
Three fixes, and the compliance requirement selects among them:

FixWhat changesSatisfies "no public internet"?Interface VPC endpoint with private DNSTraffic stays on the AWS networkYesNAT gateway with a routeTraffic goes out to the internet and backNoRemove the Lambda from the VPCUses the Lambda service's own networkingNo — and it loses VPC resource access5.3 IAM for foundation model access
5.3.1 Scoping model invocation
  WEAK
    "Action": "bedrock:*",
    "Resource": "*"

BETTER
    "Action": ["bedrock:InvokeModel",
               "bedrock:InvokeModelWithResponseStream"],
    "Resource": [
      "arn:aws:bedrock:*::foundation-model/<approved-model-1>",
      "arn:aws:bedrock:*::foundation-model/<approved-model-2>"
    ]
The streaming action is separate. A role granted only bedrock:InvokeModel fails on a streaming call, which is a confusing error the first time.

5.3.2 Conditions that carry weight
Requiring a guardrail. A condition on the invocation requiring a specific guardrail identifier converts "teams should attach a guardrail" into "an invocation without one is denied." Module 2 §2.7.4 argued this is the right enforcement mechanism; here is where it lives.
Restricting regions. A condition on aws:RequestedRegion enforces residency at the IAM layer.
Requiring a VPC endpoint. A condition on aws:SourceVpce denies invocation that does not arrive through your endpoint — closing the gap where a principal with valid IAM calls from outside the intended path.
Tag-based scoping (ABAC). Conditions matching principal tags to resource tags, which scales where per-principal policies do not.

5.3.3 The organizational layer
From Domain 2 Module 7 §7.5.3, because it is the answer whenever a restriction must hold regardless of team configuration:
  SCP                  organization-wide ceiling.
                       No local IAM can grant past it.
                       -> the answer for "no team may use
                          unapproved models or regions"
  Permission boundary  caps what any role a team creates
                       can be granted
  VPC endpoint policy  governs a network path
  IAM policy           governs a principal
  Application check    one bug from being bypassed
5.4 Fine-grained data access
Skill 3.2.1 names Lake Formation, and the reason it appears in a GenAI security module is worth stating precisely.

5.4.1 Why IAM cannot do this
The clearest statement of the problem:

A Parquet file either grants s3:GetObject or it does not. There is no s3:GetObject that returns every column except ssn.
IAM authorizes objects and API actions. Column-level, row-level, and cell-level control over tabular data is a different authorization problem, and IAM cannot express it. That is the gap Lake Formation fills.
For GenAI specifically: if your ingestion pipeline reads a table containing a mix of general and restricted columns, IAM gives you all-or-nothing. Lake Formation lets the pipeline read the columns it should and not the ones it should not.

5.4.2 The four levels
LevelControlsTableAccess to entire tables within a databaseColumnWhich columns a principal may see — include or exclude listsRowWhich rows, via a row filter expression such as region='EU'CellColumn and row filtering combined
Data filters are the mechanism for row and cell level: a named filter specifying column-level access (all columns, an include list, or an exclude list) plus a row filter expression, granted to principals like any other permission.

5.4.3 LF-Tags and tag-based access control
Named-resource permissions work and do not scale. Tag-based access control (LF-TBAC) attaches custom labels — LF-Tags — to databases, tables, and columns, and grants permissions against tags rather than against individual resources.
Guidance worth following: use LF-TBAC from day one for a new data lake. Retrofitting a tag ontology onto an established named-resource permission model is significantly harder than starting with one.
Establish a sensitivity classification early. Four levels — public, internal, confidential, restricted — cover most cases, and give you a vocabulary that GenAI ingestion can filter on directly.

5.4.4 The critical bypass
Revoke the IAMAllowedPrincipals default. If you do not, Lake Formation permissions can be bypassed entirely through IAM.
This is the single most consequential configuration detail in the section. IAMAllowedPrincipals is a backwards-compatibility grant that allows IAM permissions alone to govern access — which means every fine-grained Lake Formation grant you carefully constructed is optional. A principal with s3:GetObject and Glue catalog access reads the whole table.
It also breaks cross-account sharing. Data permissions associated with IAMAllowedPrincipals cause cross-account sharing via AWS RAM to fail.
Verify it explicitly. A Lake Formation deployment that appears to be working, with grants in place and queries returning filtered results for the roles you tested, can still be entirely bypassable by a role you did not test.

5.4.5 The limitation that matters most for GenAI
Lake Formation vends scoped credentials and a permitted column and row set to integrated query engines — Athena, Redshift Spectrum, Glue ETL, and EMR for Spark.
It does not govern a consumer that reads S3 directly.
  ENFORCED
    ingestion -> Athena / Glue ETL / EMR -> Lake Formation
                 applies column, row, cell filters
                 -> the pipeline receives only permitted data

NOT ENFORCED
    ingestion -> s3:GetObject on the underlying Parquet files
                 -> the pipeline receives EVERYTHING
                 -> Lake Formation is not in the path at all
This is precisely the shape of a GenAI ingestion pipeline that goes wrong. A team configures careful column-level exclusions on PII, then writes an ingestion Lambda that reads the S3 objects directly for speed — and indexes the excluded columns.
The honest framing to carry into a design review: direct-S3 paths, non-enforcing engines, third-party engines requiring full-table access, and schema-bearing table properties are all ways data moves outside the control. Treat Lake Formation as one layer of a defense-in-depth design and verify each path, rather than assuming a passing grant means the data is contained.

5.4.6 Other constraints worth knowing
Cell-level security is not supported on nested columns, views, or resource links.
Glue 5.0 and higher supports fine-grained access control via Lake Formation only for Apache Hive and Apache Iceberg tables.
Hybrid access mode allows selectively enabling Lake Formation permissions for specific databases and tables — an incremental adoption path that does not disrupt existing IAM-based access for other users.
5.4.7 Verification
Two habits that catch most misconfigurations:

list-permissions to verify grants exist as intended
Actually run queries as the target role. Verifying a grant is not the same as verifying behavior, and the IAMAllowedPrincipals bypass in §5.4.4 is invisible from the grant list.
5.5 The tenant and permission isolation problem
5.5.1 Why embeddings flatten permissions
From the Domain 1 book, Module 4 §4.4.5, and it belongs here because it is a security problem rather than a retrieval one:
Once a document is chunked and embedded, the vector index does not inherit the source system's access model. The source may have had rich folder, row, or document-level permissions. The index has vectors and metadata.
  SOURCE                          INDEX
  document A -- 12 people         chunk A1  [vector] [metadata]
  document B -- everyone          chunk A2  [vector] [metadata]
  document C -- 3 people          chunk B1  [vector] [metadata]
                                  chunk C1  [vector] [metadata]

The permission structure is GONE unless you carried it
  into metadata at ingestion -- and even then, it is a
  snapshot that goes stale.
5.5.2 The three approaches
ApproachMechanismWhere it failsPermission metadata + pre-filterStore ACLs or group identifiers as filterable metadata; filter per user at query timePermissions change independently of content, so the index goes stale. Requires re-sync on permission-only changes, which most connectors do not handle.Index per permission setPhysically separate indexesExplodes combinatorially with fine-grained permissionsPost-retrieval authorization checkRetrieve broadly, then verify each result against the live sourceCorrect and current, but slow, and recall degrades because you discard results
5.5.3 The working pattern
  1. COARSE PRE-FILTER on stable, low-cardinality attributes
     department, classification level, region, engagement ID
     -> removes the bulk cheaply

2. OVER-FETCH to compensate for what step 3 will discard

3. POST-RETRIEVAL AUTHORIZATION CHECK against the live
     authority, for anything sensitive
     -> THIS is the security boundary

4. Return what survives
Step 3 is the boundary, and the reason is that it consults the live authority rather than an index snapshot. Steps 1 and 2 make retrieval efficient; step 3 makes it correct.
The failure direction is deliberate and worth stating in a design review: if metadata is stale, step 1 filters incorrectly and the user gets under-retrieval — missing documents they are entitled to. They do not get over-exposure, because step 3 is authoritative. Designing so the failure points toward under-retrieval rather than over-exposure is the property you want.

5.5.4 Tenant isolation
For multi-tenant systems, stronger measures than permission filtering:

StrategyIsolationCostShared index, metadata filterWeakest — depends on every query applying the filterLowestShared index, namespacesModerateLowIndex per tenantStrongest — physically separatePer-index overhead multiplies; check the minimum billable unitAccount per tenantStrongest, plus fault and quota isolationHighest operational overhead
The rule that recurs in every domain of this material:

The tenant identifier must be derived from the authenticated session, before the model or user input can influence it. Never a parameter. Never populated by the model.
And never rely on post-filtering as a tenant boundary. Post-filtering retrieves the other tenant's data and then discards it — the isolation depends entirely on the discard step being correct, and a bug in it is a breach rather than a defect.
Defense in depth for high-sensitivity tenancy layers so no single failure suffices:

Physical index separation
IAM scoping so the credential cannot reach another tenant's index at all
Application-level filtering
Monitoring that alarms on any result set containing a foreign tenant ID
Layer 2 is the one most often missing, and it is what converts isolation from a code-correctness property into an infrastructure guarantee.
5.6 Encryption and key control
5.6.1 What a customer-managed key actually buys
Not a different algorithm. Revocability and an audit trail.

AWS-ownedAWS-managedCustomer-managedYou see it in your accountNoYesYesKey policy you controlNoNoYesRevoke access by disablingNoNoYesCloudTrail on key usageNoLimitedYesRotation controlNoAutomaticConfigurableCostNoneLowPer key + per request
The compliance argument for a CMK is usually revocability: the ability to render data unreadable by disabling a key, without deleting the data. And the audit trail: every decrypt operation appears in CloudTrail with the calling principal.
A CMK is not a substitute for access control. Data encrypted with a CMK, readable by a principal with both key and data access, is exactly as exposed as unencrypted data to that principal.

5.6.2 Where CMKs apply in a GenAI stack
  S3 buckets              source documents, staging,
                          invocation logs
  Vector store            OpenSearch, Aurora, S3 Vectors
  Knowledge Bases         encryption configuration
  Custom model artifacts  fine-tuned weights
  SageMaker endpoints     volume and inter-node encryption
  DynamoDB                metadata and state
  CloudWatch Logs         log group encryption
  Secrets Manager         credentials
Key policies are required, not optional. IAM alone does not grant key access — a principal needs permission in both the IAM policy and the key policy. This is a frequent source of AccessDenied on operations that look correctly permitted.
Encryption context allows key policy conditions on how a key may be used, which is a useful additional constraint for keys shared across purposes.
5.7 Monitoring data access
Skill 3.2.1 names CloudWatch for monitoring data access. What to actually monitor.

5.7.1 The signals
  ACCESS PATTERNS
    CloudTrail management events -- who configured what
    CloudTrail DATA events on S3 -- who read which objects
      (not enabled by default; enable for sensitive buckets)
    Lake Formation audit -- who queried what data, when
    Vector store query logs -- who retrieved what

ANOMALIES
    volume: a principal reading far more than baseline
    pattern: enumeration, sequential access, off-hours
    scope: access to classifications a principal usually
           does not touch
    CROSS-TENANT: any result set containing a foreign
           tenant identifier  <- the highest-value alarm

CONFIGURATION DRIFT
    AWS Config rules: resources without a CMK, buckets
      without the intended policy, roles with over-broad
      model access, endpoints missing
5.7.2 CloudTrail data events specifically
Data events are not enabled by default and cost more than management events. For a GenAI system this is the difference between knowing that someone configured a bucket and knowing that someone read every document in it.
The practical position: enable data events on the buckets holding source documents, invocation logs, and evaluation datasets. Those are the three stores whose contents are the data itself, and they are the ones an auditor will ask about.

5.7.3 The alarm that matters most
Of everything in this section, one alarm justifies itself immediately:
Any retrieval result set containing content from a tenant other than the requesting tenant.
It is cheap to compute — compare the tenant identifier on each result against the session's tenant — and it detects the failure mode with the highest consequence in a multi-tenant GenAI system. A system that cannot detect cross-tenant leakage will discover it from a customer.
5.8 Consolidated decision reference
  +-----------------------------------------------------------------+
  |  "TRAFFIC MUST NOT TRAVERSE THE PUBLIC INTERNET"                 |
  |    -> VPC INTERFACE ENDPOINT with PRIVATE DNS ENABLED            |
  |       (S3 and DynamoDB use GATEWAY endpoints -- no charge)       |
  |    NAT gateway does NOT satisfy this.                            |
  |    Removing the Lambda from the VPC does NOT satisfy this.       |
  |    Add an ENDPOINT POLICY as a second layer -- it governs the    |
  |      PATH, not the principal, so it applies to roles created     |
  |      later by teams who did not read the standard.               |
  +-----------------------------------------------------------------+

+-----------------------------------------------------------------+
  |  ENFORCEMENT LAYER, BY STRENGTH                                  |
  |    SCP                  org ceiling; unbypassable by local IAM   |
  |    permission boundary  caps what a team-created role can get    |
  |    VPC endpoint policy  governs a network path                   |
  |    IAM policy           governs a principal                      |
  |    application check    one bug from being bypassed              |
  +-----------------------------------------------------------------+

+-----------------------------------------------------------------+
  |  COLUMN / ROW / CELL CONTROL                                     |
  |    IAM CANNOT DO THIS. There is no s3:GetObject that returns     |
  |    every column except ssn.                                      |
  |    -> LAKE FORMATION: table, column, row, cell levels            |
  |    -> LF-TAGS from day one; named resources do not scale         |
  |                                                                  |
  |    !! REVOKE IAMAllowedPrincipals, or Lake Formation is          |
  |       bypassable entirely through IAM (and cross-account         |
  |       sharing via RAM fails)                                     |
  |    !! Enforcement applies to INTEGRATED QUERY ENGINES.           |
  |       A pipeline reading S3 DIRECTLY bypasses it completely.     |
  |    !! Cell-level: not on nested columns, views, resource links   |
  |    !! Glue 5.0+ FGAC: Hive and Iceberg tables only               |
  +-----------------------------------------------------------------+

+-----------------------------------------------------------------+
  |  RETRIEVAL PERMISSIONS                                           |
  |    coarse PRE-FILTER on stable attributes (efficiency)           |
  |    + OVER-FETCH                                                  |
  |    + POST-RETRIEVAL CHECK against the live authority (security)  |
  |    -> stale metadata then causes UNDER-retrieval, not            |
  |       over-exposure. Design the failure to point that way.       |
  |                                                                  |
  |    TENANT ID from the authenticated session. Never a parameter.  |
  |    NEVER post-filter as a tenant boundary -- the data was        |
  |    retrieved and then discarded.                                 |
  +-----------------------------------------------------------------+

+-----------------------------------------------------------------+
  |  WHAT A CMK BUYS                                                 |
  |    Revocability and an audit trail. NOT a different algorithm,   |
  |    and NOT a substitute for access control.                      |
  |    Key policies are REQUIRED -- IAM alone does not grant key     |
  |    access.                                                       |
  +-----------------------------------------------------------------+
5.9 Checkpoint
1. Name the three hops in the data flow map that teams most often get wrong. (5.1.2)

The ingestion identity (source permissions are discarded when a pipeline reads as a service); the index itself (it contains everything, and direct access equals reading the whole corpus); and the observability tail (invocation logs, traces, and evaluation datasets are copies of your data with their own access models and regions).
2. Which endpoint type do S3 and DynamoDB use, and what is the practical difference? (5.2.1)

Gateway endpoints — a route table entry rather than an ENI, with no additional charge, no security groups, and no reachability from on-premises. Everything else, including Bedrock runtime, uses interface endpoints.
3. You created an interface endpoint and traffic still leaves your VPC. What is the likely cause? (5.2.2)

Private DNS is not enabled, so the SDK resolves the public service hostname and traffic exits regardless of the endpoint existing.
4. Why is an endpoint policy more than redundancy with IAM? (5.2.3)

An IAM policy governs a principal; an endpoint policy governs a network path. It applies to every principal using that endpoint, including roles created later by teams who did not read the standard — which frequently makes it the more durable control.
5. Give the three fixes for a VPC-attached Lambda that cannot reach Bedrock, and which satisfies "no public internet." (5.2.4)

An interface endpoint with private DNS (traffic stays on the AWS network — satisfies it); a NAT gateway with a route (traffic goes out and back — does not); or removing the Lambda from the VPC (uses Lambda's own networking, and loses VPC resource access — does not).
6. State why IAM cannot provide column-level access control. (5.4.1)

A Parquet file either grants s3:GetObject or it does not. There is no s3:GetObject that returns every column except ssn. IAM authorizes objects and API actions, not columns and rows.
7. What is IAMAllowedPrincipals and why must it be revoked? (5.4.4)

A backwards-compatibility grant allowing IAM permissions alone to govern access. If left in place, Lake Formation permissions can be bypassed entirely through IAM — every fine-grained grant becomes optional. It also causes cross-account sharing via RAM to fail.
8. Your ingestion pipeline reads S3 objects directly for speed. What happens to your Lake Formation column exclusions? (5.4.5)

They do not apply. Lake Formation vends scoped credentials to integrated query engines — Athena, Redshift Spectrum, Glue ETL, EMR for Spark. A direct-S3 read is not in that path, so the pipeline receives everything, including the excluded PII columns.
9. Why does the index flatten permissions, and what is the working mitigation? (5.5.1, 5.5.3)

Chunking and embedding discard the source system's access model; the index holds vectors and metadata only. The working pattern is coarse pre-filtering on stable attributes for efficiency, over-fetching, and a post-retrieval authorization check against the live authority — which is the actual security boundary.
10. Why should stale permission metadata cause under-retrieval rather than over-exposure? (5.5.3)

Because the live post-retrieval check is authoritative. If the index metadata is stale, the coarse pre-filter removes documents the user is in fact entitled to — they see less than they should, rather than more. Designing the failure to point that direction is a deliberate property.
11. Why is post-filtering unacceptable as a tenant boundary? (5.5.4)

The other tenant's data was retrieved and then discarded. The isolation depends entirely on the discard step being correct, so a bug in it is a breach rather than a defect. Partition the index and scope with IAM so the credential cannot reach foreign data at all.
12. What does a customer-managed key actually buy? (5.6.1)

Revocability — the ability to render data unreadable by disabling a key without deleting the data — and an audit trail, since every decrypt operation appears in CloudTrail with the calling principal. It is not a different algorithm and not a substitute for access control.
13. Which single alarm is highest value in a multi-tenant GenAI system? (5.7.3)

Any retrieval result set containing content from a tenant other than the requesting tenant. It is cheap to compute and detects the highest-consequence failure mode — a system that cannot detect cross-tenant leakage will learn about it from a customer.
14. Which CloudTrail events must be explicitly enabled, and why does it matter here? (5.7.2)

Data events. They are off by default. For a GenAI system this is the difference between knowing someone configured a bucket and knowing someone read every document in it — enable them on source document, invocation log, and evaluation dataset buckets.
5.10 Practice cases
Case 3.12 — The pipeline that read too much
Scenario. A financial services firm built a GenAI assistant over its customer data warehouse.
The data team had previously invested in Lake Formation: LF-Tags classifying data by sensitivity, column-level exclusions on PII fields (national ID, full account number, date of birth), and row-level filters restricting analysts to their own region.
The GenAI team built an ingestion pipeline that generates natural-language summaries of customer records and indexes them for retrieval. For performance, the pipeline reads the underlying Parquet files from S3 directly using a service role with s3:GetObject on the data lake bucket.
A compliance review discovers that the retrieval index contains national ID numbers and dates of birth, and that region restrictions are not reflected in retrieval at all.
Produce: a root cause analysis and a corrected architecture.
Discussion.
The root cause is a single architectural decision: the pipeline reads S3 directly, so Lake Formation is not in the path.
Lake Formation vends scoped credentials and a permitted column and row set to integrated query engines — Athena, Redshift Spectrum, Glue ETL, EMR for Spark. A direct s3:GetObject on the underlying Parquet files bypasses that layer entirely. The column exclusions and row filters are real, correctly configured, and simply not consulted.
This is not a Lake Formation failure. The data team's controls work for the consumers they were designed for. The GenAI team introduced a consumer outside the enforcement path, and nothing in the system announced that.
Two compounding problems worth surfacing:
The permission structure was flattened at ingestion (§5.5.1). Even if the pipeline had read the correct columns, the region-based row filters would not have survived into the index unless carried explicitly into chunk metadata. Retrieval has no inherent notion of who may see what.
Verify whether IAMAllowedPrincipals has been revoked (§5.4.4). If it has not, then even a corrected pipeline using an integrated engine could still be bypassable by any principal with IAM access. Check this regardless of the primary fix — it is invisible from the grant list and voids the whole model.
The corrected architecture:
  1. INGEST THROUGH AN INTEGRATED ENGINE
     Replace direct S3 reads with Athena or Glue ETL running
     under a role whose Lake Formation grants exclude PII
     columns.
     -> the pipeline CANNOT read national ID or DOB, because
        the engine does not return them

2. CARRY CLASSIFICATION AND REGION INTO CHUNK METADATA
     At ingestion, tag every chunk with:
       - sensitivity classification (from LF-Tags)
       - region
       - source table and record identifiers
     -> the permission structure now survives into the index

3. RETRIEVAL: coarse pre-filter + live authorization check
     pre-filter on region and classification for efficiency
     + over-fetch
     + post-retrieval check against the live authority for
       anything sensitive
     -> the live check is the security boundary (5.5.3)

4. REMEDIATE THE EXISTING INDEX
     It currently contains national IDs and DOBs. It must be
     rebuilt, not patched -- and the old index deleted,
     including any backups and snapshots.

5. NETWORK AND KEY CONTROLS
     VPC endpoints throughout; CMK on the index and staging
     store; CloudTrail data events on the data lake and
     index buckets.
Step 4 deserves emphasis and is the part teams under-scope. The index is a copy of restricted data. Removing the columns from future ingestion does not remove them from what is already indexed. A full rebuild is required, the old index and its snapshots must be destroyed, and — depending on jurisdiction and what was exposed — this may be a reportable incident rather than an internal remediation. That question should be asked, not assumed away.
The organizational finding, which matters more than the technical one: a team built a data consumer that bypassed the organization's data governance layer, and no control detected it. The specific fix is the architecture above; the systemic fix is:

An AWS Config rule or SCP restricting direct s3:GetObject on data lake buckets to approved roles, so a new pipeline cannot repeat this
A review gate requiring data governance sign-off for any new consumer of the lake
Verification from the consumer's perspective (§5.4.7) — running queries as the pipeline's role and confirming what it actually receives, rather than confirming that grants exist
What a strong answer includes: identifying direct-S3 reads as the exact bypass and naming the integrated-engine boundary; recognizing that permission flattening is a second, independent problem; checking IAMAllowedPrincipals regardless; requiring a full index rebuild and raising the reportability question; and treating "no control detected this" as the systemic finding.
The reasoning being tested: do you know where Lake Formation enforcement stops, and do you recognize that an index built from over-permissioned reads is itself a data exposure requiring remediation?
Case 3.13 — The isolation review
Scenario. A SaaS company runs a GenAI assistant for its customers. Each customer organization uploads its own documents; the assistant answers questions over them.
Current architecture:

One OpenSearch index for all customers
Each chunk carries a customer_id in metadata
The application adds a customer_id filter to every retrieval query
The customer_id is taken from the request payload sent by the customer's front-end application
One Lambda execution role has full read access to the index
Traffic between the Lambda and OpenSearch goes over the public internet
No CloudTrail data events; no alarms on retrieval content
A prospective enterprise customer's security team is reviewing the architecture before signing.
Produce: the findings you would expect them to raise, ranked, with remediations.
Discussion.
Finding 1 — critical. The tenant identifier comes from the request payload.
This is the most serious issue and it should lead. The customer_id is supplied by the caller, which means it is not a security boundary at all — it is a request parameter. A modified front-end, an intercepted request, or a compromised client can set it to any value.
This violates the rule that recurs across every domain of this material: the tenant identifier must be derived from the authenticated session, before anything the caller or the model can influence.
Remediation: resolve customer_id from the validated authentication token at the API boundary. It must never appear in the request body.
Finding 2 — critical. The filter is the only isolation mechanism, and one role can read everything.
Even with finding 1 fixed, a single bug — a query path that omits the filter, a new endpoint, a refactor — exposes all customers. The Lambda role has full index read access, so nothing below the application layer constrains it.
Remediation, layered:

Index per tenant for enterprise customers, with IAM scoping so the credential used for a request cannot reach another tenant's index at all. This converts isolation from a code property into an infrastructure guarantee.
If a shared index is retained for smaller tenants, pre-filter, never post-filter (§5.5.4), plus per-tenant credential scoping.
Verify the minimum billable capacity before committing to index-per-tenant — Domain 1 Module 4 flagged that per-index floors can dominate cost at small tenant sizes.
Finding 3 — high. Traffic traverses the public internet.
For an enterprise customer with any compliance posture, this alone may block the deal.
Remediation: VPC interface endpoints, private DNS enabled, endpoint policies restricting what can be done through the path (§5.2).
Finding 4 — high. No detection capability.
No CloudTrail data events, no alarms on retrieval content. The company could not detect cross-tenant leakage if it occurred, and could not answer an enterprise customer's question about who accessed their data.
Remediation:

The §5.7.3 alarm: any result set containing a customer_id other than the session's. Cheap, and it detects the highest-consequence failure directly.
CloudTrail data events on document and index storage.
Per-tenant access logging, which enterprise customers frequently require as a contractual deliverable.
Finding 5 — medium. Encryption and key control unstated.
An enterprise customer will ask whether their data is encrypted with a key they can revoke.
Remediation: CMKs on document storage and the index. For the largest customers, per-tenant keys — which gives genuine cryptographic separation and a revocation mechanism per customer, at the cost of key management overhead.
What a strong answer also raises:
The deletion path. An enterprise contract will include data deletion on termination. Can this architecture delete one customer's data completely — from the index, from document storage, from invocation logs, from traces, and from any evaluation datasets built on production data? In a shared index with no per-tenant partitioning, this is genuinely hard, and it should be established before the contract is signed rather than after.
The tiering recommendation. Not every customer needs index-per-tenant. A defensible model offers shared-index isolation for standard tiers and dedicated-index or dedicated-account isolation for enterprise tiers — priced accordingly. That is an honest architecture and a sellable one, and it is better than either over-engineering for all customers or discovering the requirement during a security review.
What a strong answer includes: ranking the request-payload tenant ID as the critical finding; recognizing that the filter alone is insufficient even once fixed; layering isolation so IAM enforces it below the application; naming the detection gap as its own finding; raising deletion as a contractual requirement the architecture may not support; and proposing tiered isolation rather than one posture for all customers.
The reasoning being tested: can you find the boundary that is not a boundary, and do you think about what an enterprise buyer will actually require beyond the technical controls?
Case 3.14 — The network isolation build
Scenario. A healthcare organization must deploy a GenAI documentation assistant under a requirement that no protected health information traverses the public internet at any point, and that all access is auditable.
The system: clinicians upload consultation notes; the assistant summarizes them and answers questions; retrieval runs over a corpus of clinical guidelines; results are written back to the EHR through an internal API.
Produce: the network and access architecture, and the evidence you would produce for an auditor.
Discussion.
Start by enumerating every hop where data moves (§5.1.1), because the requirement is absolute and a single unlisted hop defeats it.
  clinician upload        -> S3
  ingestion / extraction  -> Lambda or Fargate
  staging                 -> S3
  embedding               -> Bedrock
  index                   -> OpenSearch
  retrieval               -> Bedrock Knowledge Bases / OpenSearch
  model invocation        -> Bedrock
  write-back              -> internal EHR API
  logging                 -> CloudWatch Logs, S3
  traces                  -> X-Ray / CloudWatch
  secrets                 -> Secrets Manager
  encryption ops          -> KMS
Every one of those needs a private path. The architecture:
  VPC, private subnets only, NO internet gateway, NO NAT
    -> if there is no route to the internet, the requirement
       is satisfied STRUCTURALLY rather than by configuration
       -> this is the strongest form of the control

INTERFACE ENDPOINTS (private DNS enabled)
    bedrock-runtime, bedrock-agent-runtime, secretsmanager,
    kms, logs, monitoring, sts, states, and the OpenSearch
    endpoint

GATEWAY ENDPOINTS
    s3, dynamodb

ENDPOINT POLICIES
    Bedrock endpoint: approved model ARNs only, and require
      a guardrail
    S3 endpoint: your buckets only -- prevents exfiltration
      to an attacker-controlled bucket through your own
      endpoint

EHR API
    reached via PrivateLink if it is in another account, or
    Direct Connect / VPN if on-premises
The no-internet-route design is the key recommendation. Rather than adding endpoints alongside a NAT gateway, remove the internet path entirely. Then "PHI cannot traverse the public internet" is a property of the network topology, not of every service being configured correctly — and it is far easier to evidence.
The S3 endpoint policy point is worth calling out: restricting the S3 endpoint to your own buckets prevents data being written to an external bucket through your own private path, which is an exfiltration route that private networking alone does not close.
Access control:

PHI classification carried in metadata from ingestion onward
Clinician identity preserved end to end — the retrieval and write-back must operate under the clinician's authority, not a service account (Domain 2, Module 7, §7.4)
Lake Formation if structured clinical data is in scope, with column-level exclusions on identifiers — and verify no consumer reads S3 directly (§5.4.5)
CMKs throughout, with key policies restricting decrypt to the specific roles in the pipeline
Residency and service constraints to verify before committing:

Model regional availability in the required region
Guardrails Standard tier requires cross-region inference (Module 2, §2.5.2) — likely disqualifying here, so Classic tier
Automated Reasoning is region-limited (Module 4, §4.6.8) if formal verification is wanted
Invocation logs must stay in-region, since they contain PHI
The evidence package for the auditor — and per Module 1 §1.5, this is what the design is ultimately for:

ArtifactDemonstratesVPC configuration showing no IGW and no NATNo internet path exists — structural, not configuredEndpoint inventory and endpoint policiesEvery service reached privately, with path-level restrictionAWS Config rules and compliance historyContinuous conformance, not a point-in-time checkCloudTrail, including data events on PHI bucketsWho read which objects, whenKMS key policies and CloudTrail decrypt eventsWho decrypted whatIAM policies and SCPsWhat is structurally permittedGuardrail configuration and assessment logsSafety controls applied per requestModel invocation logs, in-regionWhat was sent and returned
The strongest single artifact is the absence of an internet route, because it is a topology fact rather than a claim about configuration correctness. An auditor can verify it in one place.
Two things to flag as ongoing rather than one-time:
Config rules for drift. Someone will eventually add a NAT gateway for a legitimate-seeming reason. A Config rule detecting an internet route in that VPC turns a silent regression into an alert.
The observability tail. Traces and evaluation datasets built from production data contain PHI. They must be in-region, encrypted, access-controlled, and included in retention and deletion policies — this is the leg of the map most often forgotten (§5.1.2).
What a strong answer includes: enumerating every hop before designing; proposing a no-internet-route topology so the requirement is structural; the S3 endpoint policy as an exfiltration control; preserving clinician identity rather than using a service account; checking the tier and region constraints that Modules 2 and 4 established; assembling an explicit evidence package; and treating the observability tail and configuration drift as ongoing obligations.
The reasoning being tested: do you make an absolute requirement structural rather than configured, and do you design toward the evidence an auditor will need rather than only toward the control?
5.11 Skill coverage audit
Skill statementWhere discharged3.2.1 — Develop protected AI environments to ensure comprehensive security for FM deployments (VPC endpoints to isolate networks, IAM policies to enforce secure data access patterns, AWS Lake Formation to provide granular data access, CloudWatch to monitor data access)The data flow map and the three hops teams get wrong — ingestion identity, the index containing everything, and the observability tail: §5.1. Network isolation — interface vs. gateway endpoints, the full endpoint set for a GenAI workload, private DNS, endpoint policies as path-level rather than principal-level control, and the VPC-attached Lambda trap with the three fixes: §5.2. IAM scoping for model invocation, the conditions that carry weight including guardrail enforcement and endpoint requirement, and the organizational enforcement layers: §5.3. Lake Formation — why IAM structurally cannot do column-level control, the four levels, LF-Tags and tag-based access control, the IAMAllowedPrincipals bypass, the integrated-engine enforcement boundary, and the other constraints: §5.4. The permission-flattening problem, the three approaches, the working coarse-filter-plus-live-check pattern, and tenant isolation strategies: §5.5. What a CMK actually buys, and where CMKs apply: §5.6. Monitoring — access signals, CloudTrail data events, and the cross-tenant alarm: §5.7. Applied in Cases 3.12, 3.13, and 3.14.5.12 Module summary
The map:

Draw where data sits, where it moves, who can read it at each hop, and where it crosses a boundary. Most failures are places the map was never drawn.
Three hops are routinely missed: ingestion identity (source permissions are discarded when a pipeline reads as a service), the index (it holds everything, so direct access equals the whole corpus), and the observability tail — invocation logs, traces, and evaluation datasets are copies of your data with their own access models and regions.
Network isolation:

"Must not traverse the public internet" means interface endpoints with private DNS enabled. S3 and DynamoDB use gateway endpoints at no charge.
A NAT gateway does not satisfy the requirement; nor does removing the Lambda from the VPC.
Endpoint policies govern a path, not a principal, so they apply to roles created later by teams who never read the standard — frequently the more durable control.
The strongest form is no internet route at all, which makes the requirement a topology fact rather than a configuration claim.
IAM:

Scope to specific model ARNs; the streaming action is separate. Conditions requiring a guardrail, restricting regions, and requiring a VPC endpoint each close a distinct gap.
Enforcement strength: SCP > permission boundary > endpoint policy > IAM policy > application check.
Fine-grained data access:

IAM cannot do column-level control. There is no s3:GetObject that returns every column except ssn. Lake Formation supplies table, column, row, and cell levels.
LF-Tags from day one. Named-resource permissions work and do not scale.
Revoke IAMAllowedPrincipals, or Lake Formation is bypassable entirely through IAM — and cross-account sharing via RAM fails.
Enforcement applies to integrated query engines. A pipeline reading S3 directly bypasses it completely, which is exactly the shape of a GenAI ingestion pipeline built for speed.
Cell-level security does not work on nested columns, views, or resource links; Glue 5.0+ FGAC covers Hive and Iceberg tables only.
Verify from the consumer's perspective — run queries as the target role, because a bypass is invisible from the grant list.
Permissions and tenancy:

Embeddings flatten permissions. The index does not inherit the source access model.
The working pattern is coarse pre-filter for efficiency, over-fetch, live post-retrieval check for security — and it makes stale metadata cause under-retrieval rather than over-exposure.
Tenant identity is derived from the authenticated session. Never a parameter.
Never post-filter as a tenant boundary — the data was retrieved and then discarded, so a bug is a breach.
Layer isolation so IAM enforces it below the application, not only the application layer.
Encryption:

A CMK buys revocability and an audit trail, not a different algorithm, and it is not a substitute for access control.
Key policies are required; IAM alone does not grant key access.
Monitoring:

CloudTrail data events are off by default — enable them on source document, invocation log, and evaluation dataset buckets.
The highest-value alarm is any result set containing a foreign tenant identifier. Cheap to compute, and it detects the failure mode with the worst consequence. A system that cannot detect cross-tenant leakage will hear about it from a customer.
Carry into Module 6: this module controlled who can reach data. Module 6 addresses the data itself — PII across the eight-stage GenAI lifecycle, the precise distinctions between redaction, masking, tokenization, and anonymization, and the erasure problem that fine-tuning makes unsolvable.
End of Module 5. Module 6 — Privacy and PII Handling — follows.

Unstarred

Dunk (exclude from study)

Module 5: Data Security and Network Isolation

Review Questions

Todos

Sensemaker