Exam Prep · DOP-C02 · Mock Exams · Set 3

Mock Exam · Set 3

Sets 1 and 2 tried to feel like the whole exam. Set 3 does something narrower and, if you keep missing the same three shapes of question, more useful: every single question on this paper is a confusable pair — two (or three) AWS constructs that sound alike, get taught in the same paragraph, and are specifically what the DOP-C02 exam likes to swap into each other's answer slot. Eighteen questions, 100 points, weighted to the real blueprint, split across three named traps — deployment-strategy lookalikes (in-place vs. rolling vs. blue/green), IAM policy constructs that sound interchangeable but aren't, and CloudWatch vs. X-Ray vs. CloudTrail scope confusion — plus a fourth section proving the other three domains are just as full of lookalikes. Sit it timed, mark it honestly, then read every explanation in the answer key even for questions you got right — on a paper built entirely from near-misses, the reasoning matters more than the score.

What makes Set 3 different: the confusable-pairs paper

☺ Like you're 10: Most wrong answers on a professional-level exam aren't from not knowing anything — they're from knowing two similar things and grabbing the wrong one under a clock.

This is the third of five full papers in this exam-prep track — see Set 1, Set 2, Set 4, and Set 5 for the others. Where those papers spread evenly across everything the blueprint covers, Set 3 is built around one specific observation from real DOP-C02 sittings: the professional-level AWS exams rarely ask "do you know this service exists." They ask "given two (or three) services that all plausibly fit this sentence, which one actually does the thing described." That's a different skill than recall, and it's the one this paper drills. Every question below was written by starting from a pair or trio of AWS constructs that already share a page in this course's exam blueprint — because they're taught together because they're confusable — and then writing the scenario that forces you to pick correctly between them.

Three lookalike families carry most of the paper, matching this set's brief exactly: Section A is deployment-strategy lookalikes — CodeDeploy's own "in-place" vocabulary versus ECS's native "rolling" update versus blue/green, plus the ASG-native mechanism that isn't CodeDeploy at all. Section B is IAM policy constructs that sound like synonyms and aren't — trust policy vs. permissions policy, identity-based vs. resource-based, permissions boundary vs. service control policy. Section C is CloudWatch vs. X-Ray vs. CloudTrail — three services that all watch your account, answering three completely different questions. Section D proves the other three domains play the same game with nested stacks vs. StackSets, Parameter Store vs. Secrets Manager, ASG health-check types, RDS Multi-AZ vs. read replicas, and CloudWatch Alarms vs. EventBridge rules.

How to sit this paper: timing, scoring, and domain weights

☺ Like you're 10: Same rules as a real test — one sitting, no looking anything up, and the points aren't spread evenly because the real exam doesn't spread its questions evenly either.

Give yourself 35 minutes for these 18 questions — a little under two minutes each, which is roughly the real exam's own pace once you subtract time for the longer scenario-based questions it also contains. Read every scenario twice before touching an answer; every single question on this paper has a detail that only shows up on the second read, which is exactly the point. Don't open any of this course's blueprint pages mid-sitting — that defeats the diagnostic — and mark yourself only after you've finished all 18, using the answer key below.

Points are weighted to the DOP-C02 blueprint's own domain split, the same one this course's exam blueprint uses throughout, so a domain worth more of the real exam is worth more of this paper too:

Section A — Deployment-strategy lookalikes: in-place vs. rolling vs. blue/green

☺ Like you're 10: "In-place," "rolling," and "blue/green" all mean roughly "swap old for new somehow" in plain English — but on this exam they're three specific, non-interchangeable AWS behaviors with three different rollback stories.

Deployment strategies already taught the vendor-neutral shapes; SDLC Automation taught CodeDeploy's specific vocabulary for them. This section is where the two get tangled: CodeDeploy calls its single-environment strategy "in-place," not "rolling" — even though a conservative in-place config (OneAtATime) behaves a lot like a rolling deployment in the generic sense. Meanwhile ECS has its own native rolling update that has nothing to do with CodeDeploy at all, and sits alongside a completely separate CodeDeploy-managed blue/green option on the exact same service. Get the vocabulary precise before you touch the five questions below.

Q1 · 6 pts. A team runs a service on Amazon ECS. They create it with "deploymentController": {"type": "CODE_DEPLOY"}, two target groups, and a CodeDeploy deployment group using CodeDeployDefault.ECSLinear10PercentEvery1Minutes. Which statement correctly describes what happens on the next deployment?

1. ECS updates tasks in place, one at a time, honoring minimumHealthyPercent and maximumPercent on the existing task set.
2. CodeDeploy stands up a second, fully separate task set behind the second (test/green) target group, shifts the production listener's traffic to it in 10% increments once per minute while watching any attached CloudWatch alarms, then terminates the original task set after the configured wait time.
3. ECS terminates every existing task immediately and launches the new task definition revision as one atomic operation with no traffic shifting at all.
4. The deployment fails immediately, because ECS services cannot use a CodeDeploy-managed deployment controller.

Q2 · 6 pts. A payments team wants the fastest possible rollback for an EC2 fleet: if the new release misbehaves in the first five minutes, they want to be serving 100% of traffic from unmodified, still-running original instances via a single routing action — not a redeploy. Which CodeDeploy deployment type and configuration choice actually delivers that, and why?

1. In-place deployment with CodeDeployDefault.OneAtATime — the most fault-tolerant in-place setting, replacing a single instance at a time.
2. In-place deployment with CodeDeployDefault.AllAtOnce, since finishing fastest means less time is spent exposed to a bad release.
3. Blue/green deployment, since the original fleet is left running (or terminated only after a delay you configure), so rollback is a routing change back to it rather than a new deployment.
4. Blue/green deployment configured to terminate the original instances immediately after traffic shifts, which frees up capacity the fastest.

Q3 · 5 pts (Choose TWO). A team wants CodeDeploy to shift Lambda traffic from function version v12 to v13 gradually, with automatic rollback if a CloudWatch alarm trips. Which TWO statements about Lambda deployments through CodeDeploy are correct?

1. Traffic is shifted between two Lambda function versions behind a single weighted alias — never between raw version ARNs, and never against $LATEST.
2. CodeDeployDefault.LambdaCanary10Percent5Minutes shifts 10% of traffic, holds for 5 minutes while an attached CloudWatch alarm is watched, then shifts the remaining 90% if the alarm hasn't tripped.
3. CodeDeployDefault.LambdaLinear10PercentEvery1Minute jumps once to 10%, then holds there indefinitely until a human manually promotes the rest.
4. Lambda deployments through CodeDeploy always require a second, fully separate Lambda function to be created for the "green" side, mirroring the EC2 blue/green pattern exactly.
5. Automatic rollback fires the moment any CloudWatch alarm anywhere in the account enters ALARM, whether or not it's attached to this deployment.

Q4 · 5 pts. An Auto Scaling group runs EC2 instances built from an older AMI. The team updates the launch template to a new AMI version and wants the ASG itself — no CodeDeploy, no CodePipeline — to replace instances gradually while respecting a minimum healthy percentage, with nobody hand-terminating anything. Which native ASG capability does exactly this?

1. A CodeDeploy in-place deployment targeting the Auto Scaling group.
2. Instance refresh — it replaces instances in the group in batches according to a minimum healthy percentage and an optional warm-up time, using the launch template's latest version.
3. A scheduled scaling action that sets a new desired capacity at a specific date and time.
4. Setting the Auto Scaling group's health check type to ELB.

Q5 · 5 pts. A CodeDeploy deployment to EC2 behind an Application Load Balancer needs to run a smoke test against the new instances immediately after they start receiving real, live traffic — to catch anything that only surfaces under actual request load. Which appspec.yml lifecycle hook is correct, and why is it the only one of the four options that both fires after live traffic starts and only exists when a load balancer is part of the deployment?

1. BeforeInstall — runs before the application is even installed.
2. ValidateService — runs at the very end of the lifecycle, but exists on every deployment whether or not a load balancer is attached.
3. BeforeAllowTraffic — runs after the new instances are healthy, but strictly before the load balancer starts sending them any traffic at all.
4. AfterAllowTraffic — runs the moment the load balancer starts routing live traffic to the new instances, and only exists when a load balancer is part of the deployment.

Section B — IAM policy constructs that sound alike

☺ Like you're 10: "Trust policy," "permissions policy," "permissions boundary," and "resource-based policy" all have the word "policy" in the name and all live inside IAM — that's exactly why the exam loves swapping them into each other's answer slot.

Security & Compliance already laid out all four IAM policy types this section tests. What that page can't do for you is force the split-second recognition the real exam demands: given a one-paragraph symptom, which construct is actually broken. The cleanest diagnostic rule on the whole exam: "can't even get credentials to assume this role at all" is a trust-policy symptom; "assumed the role fine, but got AccessDenied calling a specific API" is a permissions-policy symptom. Get that rule automatic before Q6–Q8.

Q6 · 6 pts. A platform team wants application teams to self-service their own IAM roles, but no role a team creates should ever be able to exceed a pre-approved permission ceiling — even if that team writes AdministratorAccess directly into the role's own identity policy. What is the AWS-recommended mechanism for this specific, per-role ceiling?

1. A service control policy attached to the application teams' OU, since SCPs are evaluated instead of any per-role configuration.
2. A permissions boundary attached to each role the application team creates, capping that identity's effective permissions regardless of what its own identity policy grants — typically enforced by requiring the boundary's ARN via the iam:PermissionsBoundary condition key on the CreateRole permission the team is delegated.
3. A resource-based policy on each service the role is meant to access, since resource-based policies always take precedence over identity-based policies.
4. An inline policy on the role instead of a managed policy, since inline policies are automatically capped at a lower maximum permission set than managed policies.

Q7 · 6 pts. An IAM role is meant to be assumed by an EC2 instance profile. Its identity (permissions) policy correctly grants s3:GetObject on the needed bucket. When the application on the instance calls the AWS SDK, it gets "unable to locate credentials" — the instance never obtains temporary credentials for the role at all; STS never even issues them. Which policy on the role is the most likely place the misconfiguration lives?

1. The trust policy (assume-role policy document) — it must name ec2.amazonaws.com as a trusted principal for an EC2 instance profile to assume the role at all; if it doesn't, EC2 can never obtain credentials for it, regardless of what the identity policy allows.
2. The identity (permissions) policy — it must separately list sts:AssumeRole as an allowed action for the role to become assumable.
3. A permissions boundary, since a role can never be assumed unless a permissions boundary is explicitly attached to it.
4. A resource-based policy on S3, since S3 controls which roles are permitted to assume identities.

Q8 · 5 pts. Account A owns an S3 bucket. A role in Account B needs to read objects from that bucket directly, without any principal in Account B ever calling sts:AssumeRole into Account A. Which IAM policy type makes this possible unassisted, and why is it the only one of the four that can?

1. An identity-based policy attached to the role in Account B, since identity-based policies can name principals in other accounts directly.
2. A permissions boundary attached to the bucket, since boundaries can grant cross-account access once attached to a resource.
3. A resource-based policy (an S3 bucket policy) attached to the bucket in Account A, naming the Account B role as an allowed principal — the only IAM policy type that can grant access to a principal in a different account without that principal assuming any role in the granting account.
4. A service control policy on Account A's OU, since SCPs can grant cross-account resource access directly.

Section C — CloudWatch vs. X-Ray vs. CloudTrail: same signal, different scope

☺ Like you're 10: All three watch your AWS account for a living, which is exactly why it's so easy to reach for the wrong one — but only one of them knows who did something, only one knows where one specific request's time went, and only one knows whether a number is bad.

Monitoring & Logging covers all three in depth; this section is the speed-round version. The fastest triage question to ask on any scenario naming one of these three: is it asking "who did it" (CloudTrail), "where did one request's time go" (X-Ray), or "is this number bad, and why" (CloudWatch)? Almost every trap question in this domain is solvable the instant you correctly categorize which of those three questions the scenario is actually asking.

Q9 · 5 pts. A production security group was found open to 0.0.0.0/0 on port 22. The team needs to know exactly who made that change, from which source IP, and at what time — including if it happened more than 90 days ago. Which service answers this, and what's the one prerequisite that must already have been in place for the answer to reach back further than 90 days?

1. CloudWatch Logs Insights, querying the VPC Flow Logs log group — no prerequisite needed, since Flow Logs capture this by default.
2. CloudTrail, and specifically a Trail (not just the account's default Event history) must already have been configured to deliver events to S3, since Event history alone only retains 90 days.
3. AWS X-Ray, tracing the console session as a segment — no prerequisite, since X-Ray traces every management API call by default.
4. GuardDuty, since any security-relevant configuration change generates a GuardDuty finding automatically.

Q10 · 5 pts. A checkout API's p99 latency has spiked. The service calls three downstream dependencies per request — an internal pricing service, a payments processor, and a database — and the team needs to see, for individual slow requests, exactly which one of the three downstream calls is adding the latency. Which service is purpose-built for this, and why can't the other two candidates below answer it the same way?

1. CloudWatch Logs Insights can answer it directly, since a stats query can aggregate duration by downstream call name from structured logs alone.
2. AWS X-Ray, which stitches each request into a trace made of segments and subsegments per downstream call, showing exactly where time went on that one request — CloudWatch can show that latency rose in aggregate and CloudTrail can show an API was called, but neither shows per-request, per-downstream-call timing the way a trace does.
3. CloudTrail, since it records the latency of every API call made by the service's IAM role.
4. CloudWatch Contributor Insights, since it's purpose-built to break down latency by downstream dependency.

Q11 · 5 pts. A team enables CloudTrail with a Trail delivering to S3 and says: "we're fully covered now — every read of a customer record in our S3 bucket is logged automatically." Is that true?

1. True — once a Trail exists, it captures every API call against every resource, including S3 object-level GetObject calls, with no further configuration.
2. False — a Trail captures management events by default, but S3 object-level activity like GetObject/PutObject is a data event, which is not captured unless explicitly enabled (per bucket, or account-wide), specifically because of the cost and volume of logging every object read.
3. False — CloudTrail never captures any S3 activity under any configuration; S3 server access logging must be used instead.
4. True, but only for buckets created after the Trail was configured — pre-existing buckets are permanently excluded.

Section D — the rest of the blueprint, still full of lookalikes

☺ Like you're 10: The three named traps above aren't special cases — they're just the loudest examples of something true across all six domains: almost every AWS pro-level question is secretly asking you to tell two lookalikes apart.

These seven questions round the paper out to the real blueprint's weight while proving the point one more way: Configuration Management & IaC, Resilient Cloud Solutions, and Incident & Event Response each carry their own famous confusable pair, and each shows up here.

Q12 · 6 pts. A platform team needs to deploy an identical baseline VPC and logging configuration into 40 AWS accounts across two Regions, with a new account joining the target OU receiving that baseline automatically, with zero manual steps. Which CloudFormation feature is designed for this, and how does it differ from decomposing one large template into smaller pieces?

1. Nested stacks, since AWS::CloudFormation::Stack lets one template reference smaller child templates for reuse across accounts.
2. A StackSet with service-managed permissions targeting the OU, with automatic deployment enabled — a StackSet deploys one template as many independent stacks across accounts/regions, a different problem from nested stacks, which only organize one stack's complexity within a single account and region.
3. A single stack with 40 separate Parameters blocks, one per target account, deployed once from the management account.
4. AWS Config conformance packs, since applying one configuration across every account in an OU is a conformance pack's job.

Q13 · 6 pts. Three weeks after a CloudFormation stack was last updated through the pipeline, an engineer manually disables versioning on the stack's S3 bucket directly in the console. No new deployment has run since. Which CloudFormation capability surfaces this, and why won't a change set catch it?

1. A change set, because running one against the current template shows the bucket's versioning setting as a pending change.
2. Drift detection, because it compares each resource's actual current configuration against what the last-applied template declares — a change set only previews the effect of a future template update and has nothing to compare against here, since the template itself never changed.
3. StackSets, since operation preferences automatically detect and revert any out-of-band change within the target accounts.
4. AWS Config, since CloudFormation delegates all configuration-history checks to Config automatically with no setup required.

Q14 · 5 pts. An RDS database's master credentials need to rotate automatically every 30 days with zero custom Lambda code to write. The same team is also storing about a dozen low-sensitivity, non-rotating application config values and doesn't want per-secret pricing for those. What should hold each, respectively?

1. Both should go in Secrets Manager, since it's the more secure option regardless of rotation needs.
2. Both should go in Parameter Store SecureString, since it's free at the standard tier and encryption is what matters, not rotation.
3. The RDS credentials belong in Secrets Manager, which ships a built-in rotation Lambda template for RDS; the low-sensitivity config values belong in Parameter Store SecureString, which has no native rotation but is free at the standard tier — which is fine, since nothing there needs to rotate.
4. The RDS credentials belong in Parameter Store with a parameter policy set to disable rotation, and the config values belong in Secrets Manager for durability.

Q15 · 5 pts. An Application Load Balancer correctly marks a target unhealthy — the app inside has hung and is failing /health — but the Auto Scaling group never replaces the instance; EC2 status checks for that instance report fine the entire time. What is misconfigured, and what's the fix?

1. The ALB's deregistration delay is set too high; lowering it forces faster termination.
2. The ASG's health check type is left at its default of EC2, which only reacts to EC2-level impairment and ignores the load balancer's judgment entirely; setting it to ELB makes the ASG trust and act on the ALB's own health check instead.
3. The target group's health check interval is too long; shortening it makes the ASG replace the instance sooner.
4. Auto Scaling groups can only ever react to CloudWatch alarms, never to load balancer health checks, so this always requires a custom EventBridge rule.

Q16 · 5 pts. A team wants to both (a) scale out read traffic for a relational database and (b) keep a synchronously-replicated standby ready for instant automatic failover. They configure one RDS Multi-AZ deployment and start pointing some read traffic at the standby to "get both for the price of one." What's wrong with this plan?

1. Nothing — RDS Multi-AZ standbys serve reads by default once Multi-AZ is enabled.
2. An RDS Multi-AZ standby exists purely for synchronous failover and cannot serve read traffic directly; read scaling requires a separate read replica instead. The team needs both — a Multi-AZ standby for failover, and at least one read replica for reads — because one resource can't do both jobs.
3. RDS Multi-AZ standbys do serve reads, but only from a different Region than the primary.
4. A read replica automatically becomes the Multi-AZ standby the moment it's created, so no additional configuration is needed.

Q17 · 7 pts (Choose TWO). A CloudWatch alarm on checkout-error-rate needs to, the instant it enters ALARM state, both (1) invoke a specific custom Lambda function that posts a formatted summary to an internal ChatOps tool, and (2) start a Systems Manager Incident Manager incident. Which TWO statements correctly describe how to wire this?

1. The alarm's own native action list includes "start an Incident Manager incident" directly, so that half of the requirement needs no EventBridge rule at all.
2. The alarm's native action list does not include "invoke an arbitrary Lambda function" — only EC2 actions, Auto Scaling actions, SNS notifications, OpsItem creation, and starting an Incident Manager incident are native actions — so the ChatOps Lambda has to be reached by routing the alarm's state-change event through an EventBridge rule instead.
3. Neither behavior needs any configuration beyond the alarm itself, since every CloudWatch alarm silently forwards its state changes to every Lambda function in the account.
4. Both behaviors require going through EventBridge, since CloudWatch alarms have no native actions of any kind.
5. The Lambda function must be triggered through SNS, not EventBridge, because EventBridge rules cannot target Lambda functions directly.

Q18 · 7 pts. A team wants automated remediation for a known failure signature — an unhealthy EC2 instance — that (1) reboots the instance, (2) waits three minutes, (3) checks instance status, and (4) proceeds to a more disruptive replacement step only if the reboot didn't clear the problem, gated by a manual approval before that disruptive step runs. Which Systems Manager capability is designed for exactly this, and why is the obvious-sounding alternative wrong?

1. Systems Manager Run Command, since it can execute the reboot command on the instance immediately.
2. Systems Manager Automation, which supports multi-step, ordered workflows (aws:executeAwsApi, aws:sleep, aws:branch) including approval gates (aws:approve) for a higher-risk step — Run Command only executes one ad hoc command or script on a fleet right now, with no orchestration, branching, or approval-gate concept at all, which rules it out for a multi-step conditional workflow.
3. AWS Config, since remediation actions are a native Config feature that supports approval gates.
4. Systems Manager Patch Manager, since patch baselines support conditional multi-step logic.

Score yourself

☺ Like you're 10: Add up your points, then look specifically at whether your misses cluster in one lookalike family — that clustering is worth more than the total score.

Mark only after finishing all 18. Full credit for the correct letter (or both correct letters on a Choose-TWO question — partial credit for getting exactly one of the two is reasonable if you're grading yourself honestly); zero for anything else. Then total each domain separately, because a 78 built from six even domains and a 78 built from five strong domains plus a near-zero on Security & Compliance are very different results walking into the real exam.

The pass mark on the real DOP-C02 is a scaled score, not a raw percentage, but as a study proxy this course uses the same 64% reference other papers in this series use — see Set 1 for the scaled-score caveat in full. Below that on this specific paper, don't re-read this page's explanations in isolation; go build the real muscle in the source domain pages, since a confusable-pairs paper you re-read without re-drilling the underlying page just teaches you these 18 exact answers, not the distinction behind them.

Answer key & explanations

☺ Like you're 10: Read every explanation, not just the ones for what you got wrong — a lucky guess on a confusable pair teaches you nothing unless you check why the letter you picked was right.

Reveal only after you've scored yourself above. Each explanation names the exact word or clause in the scenario that was doing the ruling-out.

Reveal Set 3 answers & explanations (18 questions)

1. Q1 — B. deploymentController: CODE_DEPLOY hands the deployment entirely to CodeDeploy's blue/green mechanics — a second task set behind the second target group, linear traffic shifting, then termination of the original. Option A describes ECS's own native rolling controller, a different deploymentController type entirely; the scenario's explicit CODE_DEPLOY controller is the word doing the ruling-out.
2. Q2 — C. "100% of traffic from unmodified, still-running original instances via a single routing action" is a description of blue/green's defining property — the original fleet survives. Both in-place options (A, B) replace the fleet in place, so there's no unmodified original fleet left to route back to; rollback there means a fresh, reverse deployment, not a routing action. Option D contradicts the requirement by tearing down blue immediately.
3. Q3 — A, B. CodeDeploy's Lambda traffic shifting always works through a single weighted alias pointing at two versions (A) — there's no separate "green" function (ruling out D) and no shifting against raw ARNs or $LATEST. LambdaCanary10Percent5Minutes is exactly the one-jump-then-hold-then-rest behavior described in B. C is wrong because that "jump once, hold forever" description is what a canary preset does at its jump step, not what linear does — linear keeps adding a fixed percentage every fixed interval until 100%, with no permanent hold. E is wrong because rollback only fires from an alarm explicitly attached to that specific deployment.
4. Q4 — B. "No CodeDeploy, no CodePipeline" is the phrase ruling out A. Instance refresh is the ASG-native mechanism for exactly this: replace instances in batches, from the launch template's latest version, respecting a minimum healthy percentage — with zero external orchestration tooling involved. C and D solve different problems (timing and health-check source, not AMI rollout).
5. Q5 — D. The scenario needs a hook that fires after live traffic starts, ruling out BeforeAllowTraffic (C, which fires before any traffic flows) and BeforeInstall (A, far too early). Between ValidateService (B) and AfterAllowTraffic (D), only AfterAllowTraffic is conditioned on a load balancer being present at all — ValidateService runs on every deployment regardless — so D is the hook that's specifically "only available for a load-balanced deployment," exactly as the question asks.
6. Q6 — B. A permissions boundary is the per-identity ceiling tool, and it's the standard way to make delegated self-service safe: the platform team's own IAM policy grants application teams CreateRole/PutRolePolicy only when the request includes the approved boundary ARN in the iam:PermissionsBoundary condition, so a team can create a role with AdministratorAccess as its identity policy, but that role's effective permissions are still capped by the boundary. An SCP (A) caps the whole OU, not a specific role's ceiling the way the scenario describes; C and D are simply false claims about how those constructs behave.
7. Q7 — A. "Unable to locate credentials" / never obtaining any temporary credentials at all is the textbook trust-policy symptom — STS refuses to hand out credentials for a principal the trust policy doesn't name. If the identity policy were the problem, EC2 would still obtain credentials fine and only fail on the specific s3:GetObject call with AccessDenied — a different symptom than the one described. B, C, and D each misstate how those constructs work.
8. Q8 — C. Identity-based policies (A) only ever grant permissions to the identity they're attached to — they can't reach out and grant access to a principal in another account. Permissions boundaries (B) and SCPs (D) never grant anything at all, only cap. A resource-based policy — here, an S3 bucket policy — is the only IAM policy type built to both grant permissions and name an external account's principal directly, which is exactly the "without assuming any role" requirement in the scenario.
9. Q9 — B. "More than 90 days ago" is the phrase ruling out relying on the account's free, always-on Event history, which only retains 90 days and isn't durable. Only a configured Trail delivering to S3 satisfies a longer retention requirement, which is the prerequisite the question is fishing for. A, C, and D each name a service that answers a different question than "who changed this and when."
10. Q10 — B. "For individual slow requests, which one of the three downstream calls" is a per-request, per-dependency latency question — exactly what an X-Ray trace's segments and subsegments are built to show. CloudWatch (A, D) can show aggregate latency trends but not a single request's path through three dependencies, and CloudTrail (C) doesn't record application-level call latency at all — it audits management/data-plane API activity against AWS services, not a service's own downstream calls.
11. Q11 — B. A Trail's management events (creating/modifying resources) are on by default; S3 object-level activity like GetObject is a data event, off by default and enabled explicitly. The claim in the scenario ("every read... automatically") is false specifically because of that management-vs-data-event split, not because CloudTrail can't ever see S3 activity (ruling out C) and not because of any bucket-creation-date rule (ruling out D).
12. Q12 — B. "40 accounts... two Regions... a new account joining the OU receives it automatically" is precisely a StackSet with service-managed permissions and automatic deployment turned on. Nested stacks (A) solve a different problem — organizing one stack's own complexity within one account/region — and don't fan a template out across many accounts at all.
13. Q13 — B. "Manually... directly in the console... no new deployment has run" describes an out-of-band change with no template update involved — that's what drift detection is built to surface, by comparing live configuration against the last-applied template. A change set (A) only previews a future template update; since the template never changed here, there's nothing for a change set to show.
14. Q14 — C. "Rotate automatically every 30 days, zero custom Lambda" is Secrets Manager's exact value proposition for RDS — a built-in rotation template. "Low-sensitivity, non-rotating, cost-conscious" is Parameter Store SecureString's sweet spot. Splitting them (C) is correct; putting both in one service (A, B) either overpays for rotation nobody needs or under-delivers rotation that's required, and D inverts which service does which job.
15. Q15 — B. "ALB marks it unhealthy... ASG never replaces it... EC2 status checks report fine" is the textbook signature of the ASG's health check type being left at its default of EC2, which only reacts to EC2-level impairment and never consults the load balancer's own judgment. Setting the health check type to ELB closes exactly this gap.
16. Q16 — B. An RDS Multi-AZ standby is a synchronous failover target only — it is not readable directly, so it cannot also serve as a read-scaling resource. The two jobs (failover readiness and read scaling) require two separate resources: the Multi-AZ standby for the former, a read replica for the latter.
17. Q17 — A, B. "Start an Incident Manager incident" is on the alarm's short, fixed native action list, so A is correct and needs no EventBridge rule. Invoking an arbitrary Lambda function is not on that native list, so reaching the ChatOps Lambda requires routing the alarm's state-change event through an EventBridge rule matching source: aws.cloudwatch, detail-type: CloudWatch Alarm State Change — making B correct too. C, D, and E each misstate either the native action list or EventBridge's target capabilities.
18. Q18 — B. "Multiple ordered steps... a wait... a conditional replacement step... gated by manual approval" names, feature for feature, what Systems Manager Automation is built for: aws:sleep, aws:branch, and aws:approve in one runbook. Run Command (A) has no concept of ordering, branching, or approval gates at all — it just runs one command on a fleet right now — which rules it out the moment the scenario asks for a multi-step, conditional, approval-gated workflow.

Check your answers

1. Because the original environment is never torn down until after a soak period you control, so "roll back" is just pointing the router at it again — a single routing action. That only holds as long as the original fleet is still running and hasn't already been terminated; a blue/green deployment configured to terminate the old fleet immediately loses this advantage entirely.
2. If credentials for the role could never be obtained at all, suspect the trust policy (who's allowed to assume it). If credentials were obtained fine and a specific API call then failed with AccessDenied, suspect the identity (permissions) policy (what the role can actually do).
3. Ask what the scenario is really asking: "who did this" → CloudTrail. "Where did one specific request's time go" → X-Ray. "Is this number bad, and by how much" → CloudWatch. Almost every trap question in this domain resolves the moment you correctly name which of the three questions is being asked.
4. Because neither one is a grant — both are ceilings. A permissions boundary caps what one identity's own policies can ever reach; an SCP caps what every identity in an account or OU can ever reach. Any answer choice that describes either one "granting" or "allowing" something is wrong by definition, regardless of how the rest of the scenario reads.
5. Check the alarm's short, fixed native action list: EC2 action, Auto Scaling action, SNS notification, create an OpsItem, or start an Incident Manager incident. If the requirement is any of those five, the alarm can do it alone. If it's anything else — a specific Lambda, a Step Functions workflow, an SSM Automation runbook — the alarm's state change has to be routed through an EventBridge rule instead.

That's Set 3. If most of your misses landed in one of the three named families, go re-read that single blueprint page rather than all six — a confusable-pairs paper diagnoses narrowly on purpose. For the mechanics of eliminating a wrong-sounding answer under a clock rather than just recognizing the right one, see answer triage & elimination; for the exact commands and service names behind every question above, see the AWS service & command reference; and for the small set of facts worth memorizing outright rather than reasoning through each time, see know it cold.