Mock Exam 2 Distractor Analysis & Weak Domain Review
Recap
Mock Exam 2 was the same instrument as Mock Exam 1 — 75 questions, 180 minutes, no pausing — but it was not the same test, because the Day 59 and Day 60 deep reviews sat between them. That is the whole point of the score delta: if the targeted review of Domain 1 governance and Domain 2 resilience actually closed the gaps Day 58 flagged, the second score should move, and if it does not move, the review method itself is the suspect rather than the content. The trap here is treating a higher score as proof of understanding. A score can rise because the second exam happened to lean on topics you had just re-read, which is pattern familiarity rather than durable recall, and it can rise because you got faster at eliminating obviously wrong options without ever being able to justify the right one.
So the analysis below is deliberately not organized by score. It is organized by the wrong answers that keep surviving elimination, because those are the ones that will reappear on the real exam in a slightly different costume. Where Mock Exam 1's distractors clustered around governance ceilings and DR pattern selection, Mock Exam 2's cluster around service substitution — the option that names a real service doing roughly the right thing, but not the one the constraint actually demands.
Foundations You'll Need Today
Today's analysis is about why wrong answers are wrong, and most of the wrong answers in this file are wrong because they confuse two things that sound similar. Before the patterns make sense, four background ideas need to be solid: what a guardrail policy actually does, why one particular account in an AWS organization is treated as radioactive, how network routing works when you connect networks together, and what the two different kinds of database redundancy are for.
Guardrail Policies Can Only Take Away, Never Give
In AWS, permission to do something comes from an identity policy — a document attached to a user, group, or role that says "this identity may call these API actions on these resources." A Service Control Policy, or SCP, is a different kind of document. It is attached to an organizational unit or an account rather than to a person, and it does not grant anything. Its only job is to define a ceiling: the maximum set of actions that anything inside that account is allowed to do, no matter what its own identity policies say.
The practical consequence is that an SCP can never make an action succeed that the identity policy does not already allow. If a developer's identity policy does not include s3:DeleteBucket, adding an SCP that mentions s3:DeleteBucket changes nothing — the call still fails. What an SCP can do is block an action the identity policy does allow, by explicitly denying it. So when you see a scenario where something is being denied and the proposed fix is "attach an SCP that allows it," that fix is incoherent, because SCPs do not allow. This is the single most common wrong answer in the governance domain, and it is the subject of Pattern 1 below.
The Management Account Is Special, and That Makes It Dangerous
When a company adopts AWS Organizations, one account is designated the management account (older documentation calls it the payer account or the master account). It sits at the root of the organization tree, it owns the billing relationship for every other account, and it is the only account that can invite new accounts in or remove existing ones. Crucially, SCPs do not apply to it. The guardrails you place on every other account in the organization simply do not bind the management account.
That exemption is what makes it a bad home for anything. If a workload or a tool runs in the management account and an attacker compromises it, there is no organizational ceiling to stop them — they can reach into any account in the organization, and they can remove accounts from the organization entirely. This is why the correct answer to "where should the log archive live" is a dedicated account in a Security OU, not the management account, even though the management account can already see everything. Visibility is not the same as a safe place to run code.
Connecting Networks: Route Tables and Why Peering Is Different
Every network in AWS — a VPC — has a route table, which is a list of rules saying "traffic destined for this range of IP addresses should go out through this connection." When you connect two VPCs together, whether directly or through a central hub like a Transit Gateway, the connection only works if both sides have a route table entry pointing at it. A Transit Gateway is essentially a router in the middle: VPCs attach to it, and it has its own route tables that decide how traffic arriving from one attachment is forwarded to another.
Most attachment types on a Transit Gateway can propagate their routes automatically — you attach a VPC and the Transit Gateway learns that VPC's address range without you typing anything. Peering attachments between two Transit Gateways are the exception: they do not propagate, so you must manually add static routes on both sides. That single asymmetry is why "the attachment shows Available but traffic does not flow" is a recognizable symptom, and it is what Pattern 3 is testing.
Two Kinds of Database Redundancy That Do Different Jobs
A Multi-AZ database deployment keeps a second, continuously synchronized copy of your data in a different data center, and that copy exists for one purpose: to be promoted and take over if the primary fails. It is not addressable, it has no connection endpoint of its own, and your application cannot send queries to it. It buys you durability and a fast, lossless failover. It does not buy you any additional capacity to serve traffic.
A read replica is the opposite trade. It is a separate, addressable copy of the data that your application can connect to and query, which is how you take read load off the primary. But replication to it is asynchronous, meaning it can lag behind the primary by some amount, so promoting it during a failure can lose the most recent writes. Neither mechanism substitutes for the other, and a scenario that asks for both read scaling and zero data loss on failover is asking you to configure both. Pattern 5 is built entirely on this confusion.
With that grounding, here is why the fourteen patterns below are organized the way they are: each one is a case where a real AWS service was offered for a job it genuinely does not do, and the way to catch it is to know what the service actually is rather than what its name suggests.
Distractor Patterns From Mock Exam 2
Pattern 1: The SCP That Grants Access
The most persistent wrong answer across both mocks is the one that treats a Service Control Policy as a source of permission. It shows up as an option like "attach an SCP granting s3:GetObject to the workload OU" or "create an SCP that allows the developer role to assume the cross-account role." It is tempting because SCPs are attached to OUs and accounts, they look like policies, and in a scenario where an account is being denied something, attaching a policy to the account feels like the direct fix. The tell that separates it from the correct answer is the word grant. An SCP can only ever subtract from what an identity policy already allows; it is a ceiling, not a floor, and no SCP in existence will make an action succeed that the identity's own IAM policy does not permit.
On Mock Exam 2 this appeared in a question about a developer whose s3:DeleteBucket call was failing despite an identity policy containing s3:*. The correct answer was that the OU-level SCP's explicit Deny wins, and the tempting distractor was to remove the SCP and rely on the identity policy. Removing the SCP would indeed make the call succeed, which is why the option is seductive — it is a real fix for the symptom. It is wrong because the scenario's stated requirement was that no one in that OU be able to delete buckets, so the SCP is the control being tested, not the obstacle. When a question describes a guardrail as a requirement, the answer that removes the guardrail is always wrong regardless of whether it resolves the immediate error.
Pattern 2: The Management Account as a Workload Home
Questions about where a new account or a new workload should live reliably offer the management account as an option, phrased innocuously — "create the account under the root," "deploy the aggregation Lambda in the management account," "run the audit tooling from the payer account." It is tempting because the management account genuinely does have visibility into every account in the organization, it holds the consolidated billing relationship, and it is the one account that can never be locked out by an SCP. That combination reads as convenient, and convenience is what the distractor is selling.
The tell is whether the workload touches production data or runs code that could be compromised. The management account is immune to SCPs, which means a compromised principal there has no organizational ceiling at all, and it is the account that holds the organization's root credentials and the ability to leave the organization entirely. Any option that places a workload, a log aggregation pipeline, or a security tool in the management account is wrong on blast-radius grounds even when it is technically feasible. The correct answers in this family put log archives in a dedicated Security OU account and audit tooling in the audit account, both of which Control Tower provisions for exactly this reason.
Pattern 3: Route Propagation Across TGW Peering
Transit Gateway peering questions almost always include an option that says routes will propagate automatically once the peering attachment is created. It is tempting because every other Transit Gateway attachment type does propagate — VPC attachments, VPN attachments, and Direct Connect gateway attachments all feed routes into the TGW route table without manual intervention, so the mental model "attach it and routing works" is correct everywhere except peering. The tell is the word peering in the attachment type, combined with a symptom of "the attachment is available but traffic does not flow."
Mock Exam 2 presented this as a cross-region scenario where spoke VPCs in two regions could not reach each other after a TGW peering attachment was created and verified as available. The tempting distractor was to check security groups, which is the reflexive first move for any connectivity failure and is almost never the answer in a TGW question. The correct answer was that peering attachments require static routes in each TGW route table, because propagation is not supported for that attachment type. If you find yourself reaching for security groups on a question that mentions Transit Gateway route tables, stop — the question is testing route table design, not packet filtering.
Pattern 4: PrivateLink as a General-Purpose Network Bridge
PrivateLink is the answer to a narrow question and the distractor to a broad one. The narrow question is "expose one specific service to many consumers without merging networks," and the broad question is "connect these VPCs so everything can talk to everything." Mock Exam 2 offered PrivateLink as an option in a scenario requiring bidirectional reachability between a shared-services VPC and three application VPCs, and it is tempting because PrivateLink is the cleanest-sounding option in the list — no CIDR planning, no route tables, no peering mesh. The tell is the scope of the requirement: if the scenario needs more than a specific service endpoint, or needs the consumer to initiate connections to arbitrary ports on arbitrary hosts, PrivateLink cannot express that.
The mirror-image distractor is Transit Gateway offered for a scenario that explicitly states overlapping CIDR ranges. TGW, like VPC peering, requires non-overlapping address space because it routes at the IP layer; PrivateLink sidesteps the problem entirely because the consumer only ever talks to an ENI in its own VPC. When a question volunteers that two networks both use 10.0.0.0/16, that detail is not flavor — it is the constraint that eliminates every IP-routing option and leaves exactly one answer.
Pattern 5: Multi-AZ as a Read-Scaling Answer
RDS Multi-AZ is the most reliably misused option in the database domain. It appears as the answer to any question containing the words "high availability," which is correct, and as the answer to any question containing the words "read traffic," which is not. It is tempting because Multi-AZ does create a second copy of the data in a second Availability Zone, and a second copy sounds like it should be able to serve reads. The tell is whether the scenario describes a standby or a replica: Multi-AZ's standby is not addressable, has no endpoint of its own, and exists solely to be promoted during a failure.
On Mock Exam 2 the scenario described a reporting workload saturating a primary database with read queries during business hours. The tempting distractor was to enable Multi-AZ, which would improve durability and failover time while doing nothing for the read contention. The correct answer was read replicas, with the caveat that promotion of a replica is asynchronous and therefore carries a data-loss window that Multi-AZ failover does not. Questions that ask for both read scaling and zero data loss on failover are testing whether you know that no single RDS configuration delivers both — you need replicas for reads and Multi-AZ for the synchronous standby, and the two are complementary rather than alternatives.
Pattern 6: Aurora Global Database for Multi-Region Writes
Aurora Global Database and DynamoDB Global Tables get swapped constantly, and the swap is always in the same direction: Aurora offered for a scenario that requires writes in more than one region simultaneously. It is tempting because Aurora Global Database is genuinely multi-region, genuinely fast to promote, and genuinely the right answer to a large family of disaster-recovery questions. The tell is the word write applied to more than one region at the same time. Aurora Global Database has a single writer region; secondary regions serve reads and can be promoted, but they do not accept writes while the primary is healthy.
Mock Exam 2's version of this described a global application where users in three regions needed low-latency writes to the same logical dataset. The tempting distractor was Aurora Global Database with a note about "multi-writer" — a phrase that exists in Aurora's documentation for a limited single-region multi-writer configuration and does not describe cross-region write capability. The correct answer was DynamoDB Global Tables, which is multi-active by design and resolves conflicts with last-writer-wins. If a scenario needs writes in two regions at once and the data is not relational in a way that forbids key-value modeling, the answer is almost never Aurora.
Pattern 7: Reserved Instances When Flexibility Is the Requirement
Cost questions in Mock Exam 2 leaned heavily on commitment instruments, and the recurring distractor was a Standard Reserved Instance offered for a workload whose defining characteristic was that its shape would change. It is tempting because RIs carry the largest headline discount and because the scenario usually mentions a steady, predictable baseline — which is exactly the condition under which a commitment is appropriate. The tell is any sentence describing planned change: a migration to Graviton, a move to a different region, a shift from EC2 to Fargate, or an expectation that the instance family will be re-evaluated after right-sizing.
Compute Savings Plans apply across instance families, regions, operating systems, and even to Lambda and Fargate usage, which makes them the correct answer whenever the scenario's constraint is flexibility rather than maximum discount. EC2 Instance Savings Plans sit between the two: cheaper than Compute Savings Plans but locked to a family and region. The exam pattern is to describe a workload that is steady today and explicitly expected to change, then offer all three plus Spot. Spot is eliminated by any mention of fault intolerance or stateful long-running work, and the RI is eliminated by the change language, leaving the Savings Plan tier that matches how much change was described.
Pattern 8: Compute Optimizer and Trusted Advisor as Interchangeable
Both services produce recommendations, and Mock Exam 2 offered them as substitutes for each other. It is tempting because Trusted Advisor does have a cost category and does flag idle resources, so "use Trusted Advisor to find oversized instances" sounds defensible. The tell is the specificity of the ask. Trusted Advisor's cost checks are coarse heuristics — idle load balancers, unassociated Elastic IPs, low-utilization instances against a fixed threshold. Compute Optimizer analyzes historical utilization per resource and returns a specific recommended instance type with a projected savings figure.
When a question asks which instances are oversized relative to their actual CPU and memory utilization, that is Compute Optimizer. When a question asks for a broad sweep of best-practice findings across cost, security, performance, and fault tolerance, that is Trusted Advisor. The distractor usually inverts these, offering Trusted Advisor for a right-sizing question or Compute Optimizer for a security-posture question, and the second inversion is the easier one to catch because Compute Optimizer has no security findings at all.
Pattern 9: Backup and Restore for a Fifteen-Minute RTO
The DR spectrum question is a fixture, and the distractor is always the cheapest pattern offered for a requirement that is too tight for it. Mock Exam 2 described a workload with a fifteen-minute RTO and a five-minute RPO, then offered Backup and Restore, Pilot Light, Warm Standby, and Multi-Site Active-Active. Backup and Restore is tempting because the scenario also mentioned cost sensitivity, and Backup and Restore is unambiguously the cheapest. The tell is the RTO number itself: restoring from backup means provisioning infrastructure, restoring data, and validating the application, which is measured in hours even when the backups are current.
Pilot Light is the correct answer at that RTO because core data is continuously replicated and a minimal footprint is already running, so failover is a scale-up rather than a build-out. The distinction between Pilot Light and Warm Standby is the one that trips people: Pilot Light runs a skeleton that must be scaled, Warm Standby runs a scaled-down but fully functional copy of the application that can absorb production traffic immediately. If the scenario says the standby can serve traffic without any scaling step, it is Warm Standby; if it says the standby needs to be scaled up first, it is Pilot Light.
Pattern 10: Route 53 Failover Without a Readiness Check
Route 53 health-check failover is a real mechanism and a frequent distractor when the scenario's requirement is stronger than DNS can deliver. It is tempting because it is simple, cheap, and genuinely automatic — a health check goes unhealthy, the failover record starts answering, and traffic moves. The tell is any requirement about the failover mechanism itself surviving a regional failure, or any requirement to prove the standby region is actually capable of serving traffic before you depend on it.
Route 53 Application Recovery Controller exists precisely because a health check tells you an endpoint is reachable, not that the region behind it has the capacity, configuration, and data currency to take production load. Mock Exam 2's version described a financial system where the failover control plane had to remain operable during a full regional outage, and the tempting distractor was Route 53 failover routing with health checks. The correct answer was ARC's routing control cluster, which is deliberately distributed so the failover mechanism does not share a failure domain with the thing it is failing over from, paired with readiness checks that continuously validate standby capacity.
Pattern 11: MGN for a Database Migration
Migration questions in Mock Exam 2 mixed server and database tooling freely, and the recurring distractor was Application Migration Service offered for a database workload. It is tempting because MGN does replicate continuously at the block level, which sounds like it should keep a database current, and because a database is technically running on a server. The tell is whether the scenario cares about the database as a database — schema, engine version, transactional consistency, or a change of engine. MGN replicates a machine; it has no concept of a transaction boundary, so a block-level copy of a running database's volumes is not a consistent database.
The correct tool depends on what is changing. Same engine, minimal downtime, keep the server: DMS with full load plus change data capture. Different engine, schema and stored procedures must be rewritten: Schema Conversion Tool for the schema and code, then DMS for the data. Files rather than database contents: DataSync. A whole server including its operating system and installed software: MGN. The exam rarely states the tool name; it states the constraint, and the constraint maps to exactly one of these four.
Pattern 12: Snowball for a Small Ongoing Delta
Offline transfer questions have a characteristic distractor: the physical device offered for a dataset that is small, or that changes continuously. It is tempting because the scenario usually opens with a large historical volume, which legitimately justifies a Snowball, and then the option that says "use Snowball for the migration" sounds like it is honoring that. The tell is the second half of the scenario — the ongoing daily delta, the requirement for near-real-time currency, or a dataset measured in gigabytes rather than terabytes.
The pattern the exam rewards is the hybrid one: Snowball Edge for the bulk historical dataset, then a network-based mechanism for the delta. Mock Exam 2 described 300TB of history plus roughly 50GB of daily change over a constrained link, and the tempting distractor was to transfer everything over the link, which would take months at that bandwidth. The correct answer paired Snowball for the history with DMS change data capture for the delta. Note the arithmetic the question is inviting you to do: a link measured in hundreds of megabits per second against a dataset measured in hundreds of terabytes is a mismatch you are expected to notice without being told the answer.
Pattern 13: Composite Alarms as a Sensitivity Fix
Observability questions in Mock Exam 2 included a family where the symptom was alarm fatigue and the tempting distractor was to raise the threshold or lengthen the evaluation period. It is tempting because it does reduce pages, and reducing pages is what the scenario asked for. The tell is whether the scenario also requires that genuine incidents still be caught. Raising a latency threshold suppresses the false positives and the true positives together, because a single metric cannot distinguish a self-resolving spike from the leading edge of an outage.
Composite alarms are the correct answer because they let you require correlated signals — high latency and elevated error rate — before paging, which is a different operation from making the individual alarm less sensitive. The distractor that catches people is deleting the noisy alarm outright, which is offered as "remove the alarm that is generating false positives." That is never correct in a scenario that describes a production system, because it trades noise for blindness. The general rule: when a question asks you to reduce alert volume without losing incident detection, the answer adds a correlation layer rather than moving a threshold.
Pattern 14: Synthetics as a Replacement for Internal Metrics
The last recurring pattern is a substitution in the opposite direction from the others: synthetic canaries offered as a replacement for server-side metrics rather than a complement to them. It is tempting because canaries are the more impressive-sounding tool and because the scenario usually describes a user-visible failure that internal metrics missed. The tell is whether the question asks you to diagnose why something is slow or merely to detect that it is broken.
Canaries probe from outside the infrastructure and will catch a broken login page, a DNS failure, or a CDN misconfiguration that every internal metric reports as healthy — that is their unique value and the reason they are the answer to "customers report a problem but our dashboards are green." They will not tell you which of twelve microservices is contributing the latency, because they see only the end-to-end response. That question belongs to X-Ray's service map. Mock Exam 2 offered canaries for a p99 latency attribution question and X-Ray for an outside-in availability question, and both were wrong for the same reason: the tool was matched to the symptom rather than to the question being asked.
Hands-on Lab / Practical Action (45 min)
Rebuild your Mock Exam 2 error log as a distractor ledger rather than a list of missed questions. The distinction matters because a missed-question list tells you what you got wrong once, while a distractor ledger tells you which wrong answers you are systematically drawn to, and the second is what predicts your real exam score. Open a spreadsheet with five columns: question number, the option you selected, the option that was correct, the specific word or phrase in the question that should have eliminated your selection, and the pattern number from the list above that the miss belongs to.
Work through every question you answered incorrectly, then go back and work through every question you answered correctly but flagged for review or arrived at by elimination rather than by knowing the answer. Those near-misses are the highest-value entries in the ledger, because a correct guess and a correct answer look identical in a score report and completely different on the next exam. For each near-miss, write the one sentence you would have needed to know to answer it directly. If you cannot write that sentence, the topic is not learned yet regardless of what the score says.
Once the ledger is populated, sort it by pattern number rather than by question order. A cluster of four misses under Pattern 5 is a different remediation than four misses spread across four patterns: the first is a single conceptual gap about what Multi-AZ does and does not do, and the second is a general reading-comprehension problem where you are not extracting the constraint from the scenario before evaluating options. Both are fixable, but only if you can tell them apart.
Then compare the pattern distribution against the one you built on Day 58 from Mock Exam 1. The comparison is the actual deliverable of this exercise. Patterns that appeared in both ledgers are the ones the Day 59 and Day 60 deep reviews failed to close, which means re-reading the same material a third time is unlikely to help — those need a different treatment, such as writing your own scenario questions that hinge on the same distinction. Patterns that appear only in the Mock Exam 2 ledger are new gaps, and they are the ones Day 63 and Day 64 should target.
Finish by re-tagging each ledger entry with its SAP-C02 domain and writing a one-line summary of your current weak spot per domain. Keep this to a single page. It becomes the input to the next two deep-review days and eventually folds into the personal cheat sheet you will build on Day 68, so write it in a form you will still be able to read in a week without the surrounding context.
Scenario Question Drills (20 min)
Q1. A developer in the Workloads/Prod OU has an identity policy granting s3:* but receives AccessDenied when calling DeleteBucket. The OU has an SCP that denies s3:DeleteBucket. A colleague suggests removing the SCP so the call succeeds. Why is that the wrong fix?
Q2. A security team wants a single account that aggregates CloudTrail logs from every account in the organization and cannot be modified by workload teams. Which placement is correct?
Q3. Two VPCs in different regions are attached to Transit Gateways that are peered with each other. The peering attachment shows Available, but the spoke VPCs cannot reach each other. What is the most likely cause?
Q4. A shared-services VPC must be reachable from three application VPCs, and each application VPC must also be able to initiate connections to arbitrary ports on hosts in the shared-services VPC. Two of the VPCs use overlapping CIDR ranges. Which connectivity option fits?
Q5. A reporting workload is saturating a production RDS instance with read queries during business hours. The business also requires that a database failure cause no data loss. What should be configured?
Q6. A global application needs users in three regions to write to the same logical dataset with low latency, and the data model is a simple key-value access pattern. Which database configuration fits?
Q7. A company runs a steady-state production fleet today but expects to migrate to Graviton instances and consolidate regions within the next year. They want the largest discount that does not lock them out of those changes. What should they purchase?
Q8. A company suspects many EC2 instances are oversized relative to their actual CPU and memory utilization but does not know which ones. Which service returns specific right-sizing recommendations with projected savings?
Q9. A workload requires an RTO of 15 minutes and an RPO of 5 minutes, and the business wants to minimize standing infrastructure cost. Which DR pattern fits?
Q10. A critical financial system needs a failover mechanism that remains operable during a full regional outage, plus continuous proof that the standby region has the capacity to take production traffic. What should be configured?
Q11. A company must migrate a self-managed Oracle database to Aurora PostgreSQL with minimal downtime. The schema includes stored procedures and functions. Which tool combination is required?
Q12. A migration must move 300TB of historical data plus roughly 50GB of daily change, over a link capped at 500 Mbps. What approach is appropriate?
Q13. On-call engineers are paged repeatedly by isolated latency spikes that self-resolve, but the team still needs to catch genuine incidents. What should be configured?
Q14. Customers report that the login page is broken, but every internal CloudWatch metric reports healthy servers. Which monitoring capability would have caught this?
Q15. A microservices application has rising p99 latency, but it is unclear which of twelve services is responsible. Which tool isolates the bottleneck?
Preview
Everything above is organized by distractor pattern, which is useful for recognizing a wrong answer but says nothing about whether the underlying topic is actually understood. The ledger you built in the lab tells you which patterns you keep falling for; it does not tell you whether the migration tooling behind Pattern 11 and Pattern 12 is solid or whether those two misses were reading errors on questions you could otherwise answer. That distinction is the open question heading into the next review day, and it is not answerable from a score report.
Day 63 targets Domain 3 directly — the 7 Rs, Application Migration Service, DMS and Schema Conversion Tool, DataSync, the Snow Family, and the bandwidth planning that connects them. The test there is not whether you can name the tools but whether you can derive the tool from a stated constraint: what is changing, how much data is moving, how much downtime is tolerable, and whether the source is a server, a database, or a file share. If the Pattern 11 and Pattern 12 misses were conceptual, that derivation will still fail under a fresh scenario. If they were reading errors, it will not.