Deep Review — Domain 1 Weak Areas (Org/Governance/Networking)
Recap — Why Distractor Analysis Comes First
Day 58 established that distractor analysis is the real work: for every missed question — and every question answered correctly by luck or elimination — you articulate why the correct answer is right and why each distractor is wrong, then tag each miss by domain to find your weakest area. That exercise was a prerequisite for what happens here, because a domain tag is only useful if it converts into a specific, named misconception you can attack. "Domain 1 is weak" is not actionable. "I keep choosing VPC peering when the CIDR ranges overlap" is.
So today takes the Domain 1 tags from that analysis — multi-account governance and hybrid networking, Weeks 1 and 2 — and turns them into a catalogue of answer patterns. Each entry below names the tempting-but-wrong option, explains why it is tempting, and gives the specific tell that separates it from the correct answer. The goal is not to re-teach Organizations or Transit Gateway from scratch; it is to make the wrong answers recognizable on sight, which is a different and faster skill than recall.
Foundations You'll Need Today
Today's material is entirely about how a large company organizes its AWS estate and wires the pieces together. That vocabulary is second nature to someone who has built a VPC by hand, but it is not obvious from the outside, so here is the grounding the rest of this page assumes.
Accounts, Organizations, and OUs
An AWS account is the fundamental container for everything you do in AWS: it holds your resources, your users, and your bill. A small team might use one account for everything, but a large company does not, because a single account makes it impossible to give one team's engineers access to their own resources without also giving them access to everyone else's. The standard answer is many accounts — one per team, per environment, per business unit — so that access and billing boundaries line up with organizational boundaries.
AWS Organizations is the service that ties those accounts together into a hierarchy so they can be managed as a group rather than one at a time. The hierarchy is built from organizational units, or OUs — folders that group accounts by purpose, such as a Security OU for audit accounts or a Workloads OU containing Dev and Prod. The reason the hierarchy matters is that rules attached to an OU apply to every account inside it, including accounts added later. That is the whole point: you write a rule once at the folder level instead of chasing down forty accounts individually.
Policies: What They Are and What They Do
A policy in AWS is a JSON document that says who is allowed to do what. The one most people meet first is an IAM policy, which is attached to a user, group, or role and grants that identity permission to call specific AWS APIs — for example, allowing a developer to read from an S3 bucket. IAM policies are grants: without one, an identity can do nothing.
A service control policy, or SCP, is a different kind of policy that attaches to an OU or account in Organizations rather than to a person. An SCP does not grant anything. It sets a ceiling on what is possible inside the accounts it covers, and anything outside that ceiling is blocked no matter what the IAM policies say. The practical consequence, and the thing today's patterns keep testing, is that effective permission is the overlap between what IAM allows and what the SCP permits — and an explicit Deny in either one always wins. If that distinction feels slippery, hold onto this: IAM says "you may," SCPs say "you may not go beyond here."
VPCs, CIDR Ranges, and Route Tables
A virtual private cloud, or VPC, is your own private network inside AWS. It is the AWS equivalent of the network a company would build in its own data center: you decide how big it is, carve it into subnets, and control what can talk to what. Every resource that needs network connectivity — a server, a database, a load balancer — lives inside a VPC.
The size of a VPC is expressed as a CIDR range, which is shorthand for a block of IP addresses. You will see things like 10.0.0.0/16, which means a large block of addresses, and 10.0.1.0/24, which means a smaller block carved out of it. The reason CIDR ranges come up constantly in this domain is that two networks can only be joined directly if their address blocks do not overlap. If two companies both built their networks on 10.0.0.0/16, every address is ambiguous the moment you connect them, and the connection cannot work. That single constraint drives a surprising number of the design decisions and distractors below.
A route table is the set of rules that tells a network where to send traffic. When a packet leaves a resource, the route table is consulted to decide the next hop — stay inside the VPC, go out to the internet, or travel across a connection to another network. If there is no matching route, the traffic is simply dropped. This is why so many networking problems in AWS turn out to be routing problems: the connection exists, the firewalls are open, and nothing works because no route table knows how to get there.
Connecting Networks: Peering, Transit Gateway, and PrivateLink
Once a company has more than one VPC, those VPCs usually need to talk to each other, and AWS offers several ways to arrange that. VPC peering is a direct one-to-one link between two VPCs. It is simple and fast, but it does not scale: connecting ten VPCs to each other this way means managing dozens of individual links, and it still requires non-overlapping CIDR ranges.
AWS Transit Gateway, or TGW, solves the scaling problem by acting as a central hub. Instead of every VPC connecting to every other VPC, each VPC connects once to the TGW, and the TGW decides how traffic flows between them. That decision-making happens through TGW route tables, which work on the same principle as the VPC route tables above — they determine which networks can reach which. Because the hub controls the routing, you can use it to allow some connections and deliberately prevent others, which is exactly the isolation requirement today's patterns keep circling.
AWS PrivateLink takes a different approach entirely. Rather than joining two networks, it exposes one specific service in one VPC to consumers in another, without the two networks ever being connected. Because no networks are merged, PrivateLink works even when the CIDR ranges overlap — the constraint that breaks peering and TGW simply does not apply. The trade-off is scope: you get access to that one service, not to the whole network behind it.
With that grounding, here's why the Domain 1 distractor patterns below are worth memorizing: nearly every wrong answer in this domain is one of these mechanisms applied at the wrong granularity, or a policy type used as though it worked like the other one.
Domain 1 Distractor Patterns
Fourteen patterns, ordered roughly by how often they appear in Domain 1 scenario questions. Read each one against your own Day 58 miss list; if a pattern matches a question you got wrong, that is the one to drill hardest in the quiz below.
Pattern 1 — "Put the log-archive account under the root"
The tempting answer places the centralized logging account directly under the organization root, or inside the Workloads OU, on the reasoning that it needs to be reachable by everything and therefore should sit somewhere neutral. It is tempting because the account genuinely does need broad read access from every other account, and "under the root" sounds like the most permissive, most connected position available. The distractor is exploiting the intuition that centrality equals accessibility.
The tell is the word cannot be modified by workload teams, or any phrasing about blast radius and isolation. A log-archive or audit account belongs in a dedicated Security OU protected by SCPs that deny deletion or modification of logging resources, precisely so that a compromised workload account cannot reach up and tamper with the evidence. Centrality is not the requirement; isolation with a one-way write path is. If an option describes the account as sitting alongside Production "for proximity to the data it audits," that proximity framing is the giveaway — audit accounts are deliberately distant from what they audit.
Pattern 2 — "The management account can just run this one workload"
This distractor offers the management account as a convenient home for a small, low-risk workload — a billing report generator, a tagging enforcer, a single Lambda. It is tempting because the management account already exists, already has broad visibility, and provisioning a new account feels like overhead for something trivial. The option usually includes a softener like "since it only needs read access" or "to avoid cross-account complexity."
The tell is any question that asks why the management account should stay empty, or any scenario where the correct answer hinges on SCP coverage. SCPs cannot be applied to the management account, so anything running there operates outside the guardrail layer entirely. Best practice keeps it workload-free and limited to billing, Organizations, and org-wide services such as IAM Identity Center. When a distractor justifies management-account placement with convenience or existing permissions, that is the trap. The related wrong answer — "it has a lower service quota by default" — is a plausible-sounding but invented constraint; the real reason is SCP immunity, not quotas.
Pattern 3 — "SCPs grant access, so attach the SCP and you're done"
The tempting option treats an SCP as a permission grant: attach a policy allowing S3 to the OU and the accounts can now use S3. It is tempting because SCPs are written in the same JSON policy language as IAM policies, with the same Allow and Deny structure, so they look like they should behave the same way. The distractor is exploiting surface similarity between two policy types with fundamentally different semantics.
The tell is a question that pairs an SCP with an IAM identity and asks what the effective permission is. SCPs are a permission ceiling, not a grant: the effective permission is the intersection of what IAM allows and what the SCP permits, and an explicit Deny in either one always wins. A developer with s3:* in their IAM policy who is also covered by an SCP denying s3:DeleteBucket will be denied — the SCP does not need to allow anything for that to be true. Watch for the reverse framing too: an option claiming "IAM policies take precedence" over an SCP Deny is the same misconception wearing a different hat.
Pattern 4 — "Region-restriction SCPs are safe to apply as written"
This distractor presents a clean region-restriction SCP — deny everything outside two approved regions — and treats it as a finished artifact. It is tempting because the policy is short, obviously correct in intent, and matches the stated compliance requirement exactly. Nothing in the option looks wrong.
The tell is the absence of any mention of global services. IAM, Route 53, CloudFront, and Support are global and do not live in a region, so a naive region-deny breaks account operations in ways that are hard to diagnose — IAM calls start failing, and the failure looks unrelated to the networking change you just made. The correct answer always carves out those services, usually via a condition on aws:RequestedRegion combined with an exemption list. If a distractor's SCP has no global-services carve-out and the scenario mentions IAM or Route 53 anywhere, that is the answer to eliminate.
Pattern 5 — "Control Tower guardrails are all optional"
The tempting option describes Control Tower guardrails as a menu of best practices you enable as you see fit, which makes "turn off the guardrail that's blocking us" sound like a legitimate operational move. It is tempting because elective and strongly recommended guardrails genuinely are optional, so the framing is half true — which is exactly what makes it dangerous.
The tell is the word mandatory, or a scenario where a control cannot be disabled. Mandatory guardrails are always enforced and cannot be turned off; elective and strongly recommended guardrails can be enabled per OU based on governance needs. A distractor that offers "disable the mandatory guardrail for this OU" is offering something that does not exist. The related wrong answer — "mandatory guardrails cost extra" — is a fabricated pricing claim; the distinction is enforcement, not billing.
Pattern 6 — "One IAM user per engineer per account"
This distractor solves a federation question with per-account IAM users, sometimes dressed up with a group structure or a shared credential store. It is tempting because it is the most familiar pattern, it works in a single-account world, and it requires no IdP integration work. In a 40-account organization it is also unambiguously the wrong answer.
The tell is any scenario mentioning an existing corporate IdP (Entra ID, Okta), a large account count, or a requirement to avoid long-lived credentials. IAM Identity Center with SAML federation and permission sets is the answer: permission sets map to an IAM role auto-provisioned into each assigned account, and users authenticate once against the IdP. The distractor "share a single root-account access key" is the same error at maximum severity, and "use SCPs alone" is the error of reaching for a guardrail mechanism to solve an authentication problem.
Pattern 7 — "Permission boundaries are just another policy to attach"
The tempting answer treats a permission boundary as an additional grant — attach it to the role and the role gains those permissions. It is tempting because a boundary is a managed policy, and managed policies normally do grant things. The distractor is exploiting the fact that the boundary's JSON looks like an allow-list.
The tell is a delegated-admin scenario, especially one asking how to stop a role-creator from minting an AdministratorAccess role. A permission boundary caps the maximum permissions an entity can ever hold, even when its attached policies are broader. The correct pattern is a condition requiring iam:PermissionsBoundary on CreateRole, so every role the delegate creates is automatically capped. Distractors that propose attaching a Deny to each developer role individually, or removing iam:CreateRole entirely, miss the point: the first does not scale and the second breaks the delegation you were asked to build.
Pattern 8 — "Share the whole VPC with RAM"
This distractor offers AWS RAM as a way to hand an entire VPC to another account. It is tempting because RAM is genuinely the right service for the underlying requirement — central network ownership without per-account VPCs — and the option gets the service name right, which is often enough to feel correct under time pressure.
The tell is the granularity. RAM shares subnets, not VPCs. Application accounts launch resources into subnets owned by a central VPC, and the VPC itself stays owned by the network account. A distractor that says "share the VPC" is wrong on the resource type even though it is right on the service. The other common wrong answer in this family is "VPC peering between every pair of accounts," which solves reachability but not ownership, and scales quadratically — the exact problem RAM subnet sharing exists to avoid.
Pattern 9 — "A single flat Transit Gateway route table is fine"
The tempting answer attaches every VPC to one TGW route table with all routes propagated, on the grounds that everything needs to reach the shared-services VPC anyway. It is tempting because it is the simplest configuration, it works immediately, and the connectivity requirement as stated is satisfied — every spoke can reach shared services.
The tell is a negative requirement: "but never reach each other," "must not be able to," "isolated from." A flat route table gives you reachability and isolation is impossible to express in it. The correct design uses separate TGW route tables for Dev and Prod, each propagating only the shared-services routes, with no propagation between the two. Distractors that propose Security Groups or NACLs to enforce the isolation are answering a different question — those are stateful/stateless packet filters, not routing topology, and they do not prevent route-level reachability from existing.
Pattern 10 — "TGW peering propagates routes automatically"
This distractor assumes a TGW peering attachment behaves like a VPC attachment: create it, and routes flow. It is tempting because every other TGW attachment type does propagate, so the mental model is consistent — it is just wrong for this one attachment type.
The tell is a scenario where the peering attachment exists, both TGWs are healthy, and spoke VPCs still cannot reach each other. Peering attachments do not support route propagation; static routes must be added manually to each TGW route table. The distractor "the TGWs are in different Availability Zones" is a category error — TGWs are regional, not AZ-scoped — and "peering doesn't support cross-region traffic at all" is simply false. The related number worth holding onto: inter-region TGW peering caps MTU at 1500 bytes, which matters for any workload that assumes jumbo frames.
Pattern 11 — "One Direct Connect link is enough if it's 10 Gbps"
The tempting option answers a resiliency question with bandwidth: a single large connection, or two connections at the same location, on the reasoning that capacity is the constraint being described. It is tempting because the scenario usually does mention throughput, and a 10 Gbps link sounds like it removes the problem.
The tell is the word resiliency, or any mention of a mission-critical workload. DX resiliency is about diversity, not size: two connections at two different DX locations, terminating on separate devices, with BGP failover, plus a VPN backup for the case where both DX paths fail. Two connections at the same location share fate — a single facility outage takes both. The distractor "Public VIF only, since it's cheaper" confuses the VIF type with the resiliency model; a Public VIF is for reaching public AWS endpoints, not for private VPC connectivity at all.
Pattern 12 — "Inbound and outbound Resolver endpoints are interchangeable"
This distractor picks the wrong Resolver endpoint direction, usually by choosing outbound when the scenario needs inbound. It is tempting because both endpoints are part of the same hybrid DNS story and the names are easy to swap under time pressure — the option reads as correct if you are pattern-matching on "Route 53 Resolver" rather than on who is asking whom.
The tell is the direction of the query. Inbound endpoints let on-prem resolvers query AWS private hosted zones; outbound endpoints plus forwarding rules let AWS resources resolve on-prem names. The mnemonic that survives exam pressure is to ask who initiates: if the query originates on-prem and the answer lives in AWS, you need inbound. If the query originates in AWS and the answer lives on-prem, you need outbound. A distractor offering "a public hosted zone instead" is a different error — it changes the visibility model rather than the direction.
Pattern 13 — "PrivateLink and peering are interchangeable for cross-account access"
The tempting answer reaches for VPC peering or TGW peering to expose one service to another account, because those are the connectivity tools you have been using all week. It is tempting because peering does provide reachability, and reachability is what the scenario appears to ask for.
The tell is overlapping CIDR ranges, or a requirement to expose exactly one service to many consumers. PrivateLink works with fully overlapping IP ranges because it never merges route tables or CIDRs — it is ENI-level connectivity in the consumer VPC to an endpoint service in the provider VPC. Peering and TGW both require non-overlapping ranges and give you network-level reachability, which is more than the scenario asked for and impossible when the ranges collide. The decision rule: PrivateLink for service-level exposure to many consumers, TGW for broad network-level connectivity across VPCs and on-prem.
Pattern 14 — "Network Firewall belongs in every VPC"
This distractor deploys AWS Network Firewall independently in each spoke VPC, which is defensible on the grounds that each VPC then owns its own inspection policy. It is tempting because it is the most direct reading of "every VPC needs inspection," and it avoids any cross-VPC routing complexity.
The tell is cost, consistency, or a requirement to inspect traffic between VPCs. The standard pattern is a centralized inspection VPC attached to the Transit Gateway, with spoke route tables directing 0.0.0.0/0 to the TGW so all egress passes through one firewall. That gives one policy to maintain, one place to add rules, and one bill. The distractor "Network Firewall cannot inspect cross-VPC traffic" is false — it inspects whatever is routed through it, which is precisely why the centralized pattern works. Per-VPC deployment is not wrong in the sense of failing to inspect; it is wrong in the sense of multiplying cost and policy drift by the number of VPCs.
Hands-on Lab / Practical Action (45 min)
Re-do every missed Week 1-2 practice question from Days 1 through 14, then add ten new scenario questions aimed at whichever sub-topic your Day 58 tag list put at the bottom. The point of the re-do is not to get the questions right the second time — you have seen them, so that proves nothing. The point is to write, for each one, the one-sentence reason the correct answer is correct and the one-sentence reason each distractor is wrong, in the same format Day 58 established. If you cannot produce the distractor sentence, you have not actually closed the gap; you have memorized the letter.
For the ten new questions, source them from a different question bank than the one used for Mock Exam 1 if you have access to one. Fresh distractors are the only way to test whether the pattern recognition generalizes or whether you have simply learned the specific wrong answers in the first bank. Tag each new miss by domain as you go, and if a new pattern emerges that is not in the fourteen above, write it down — that is a genuine finding, and it belongs in your cheat sheet.
Budget the time roughly as twenty-five minutes for the re-do and twenty for the new questions, and stop at forty-five minutes even if you are mid-question. The value here is calibration, not volume, and the quiz below is designed to test the same patterns under time pressure.
Scenario Question Drills (20 min)
Fifteen questions, each built around one of the patterns above. Every question includes the tempting wrong answer as a live option — read all four before revealing.
Q1. A company wants a dedicated account that only aggregates CloudTrail logs from every other account and cannot be modified by workload teams. Where should this account live?
Q2. Why should the AWS Organizations management account never run workloads?
Q3. A developer has an IAM policy granting s3:*, but an SCP on their OU denies s3:DeleteBucket. What happens if they call DeleteBucket?
Q4. A compliance team requires that no resource be created outside two approved regions. What must the region-restriction SCP account for?
Q5. What is the key difference between a mandatory and an elective Control Tower guardrail?
Q6. An enterprise wants engineers to log in once via their corporate Okta and assume the correct role in any of 40 AWS accounts without individual IAM users. What is the best-practice solution?
Q7. A delegated admin role can create IAM roles for developers. How do you prevent them from creating a role with AdministratorAccess?
iam:PermissionsBoundary is the standard escalation-prevention pattern. Option A does not scale; option C breaks the delegation you were asked to build.Q8. A company wants every application account to use a common, centrally managed VPC without each account owning its own VPC. What is the mechanism?
Q9. You need Dev and Prod VPCs to both reach a Shared-Services VPC, but never reach each other. How do you design TGW route tables?
Q10. After creating a TGW peering attachment between two regions, spoke VPCs still cannot reach each other. What is most likely missing?
Q11. A company needs the highest-resiliency Direct Connect design for a mission-critical workload. What should they provision?
Q12. On-prem servers need to resolve names in a private Route 53 hosted zone. What do you configure?
Q13. Two companies with overlapping CIDR ranges (both 10.0.0.0/16) need one to consume a specific API hosted in the other's VPC. What connectivity option works despite the overlap?
Q14. What is the standard pattern for forcing all internet-bound traffic from multiple VPCs through a single AWS Network Firewall?
Q15. When should you choose PrivateLink over Transit Gateway for cross-account connectivity?
Preview — Domain 2
Everything above assumed the failure was a governance or routing decision made at design time — a policy attached to the wrong OU, a route table that propagated too much, a VPC that should have been a PrivateLink endpoint. Domain 2 asks a harder question: what happens when the design is correct and the system still fails? The open question is whether your recovery mechanisms have ever actually been exercised, or whether they are assumptions dressed up as architecture.
Day 60 turns to the Domain 2 tags from the same Day 58 analysis — compute, databases, and the SRE and DR cluster. Expect the distractors to look different there. Domain 1 wrong answers tend to be the right service applied at the wrong granularity; Domain 2 wrong answers tend to be the right pattern applied at the wrong RTO, or a recovery mechanism that was never tested. Bring the same discipline: name the tempting option, name the tell, and write the sentence that explains why it is wrong.