Exam Prep · DOP-C02 · Mock Exam · Set 5

Mock Exam · Set 5

This is the fifth and final practice paper for AWS's DevOps Engineer Professional exam (DOP-C02), and it's built to be the closest thing to the real sitting you can get without paying for it. Set 1 and Set 2 gave you balanced first exposure; Set 3 drilled confusable pairs until the near-misses stopped costing you points; Set 4 deliberately over-weighted the three heaviest domains so a short-on-time candidate could triage correctly. Set 5 folds all three question styles — recall, applied scenario, and confusable-pair discrimination — back into one paper, sized and timed to genuinely rehearse the real thing: 45 questions, 100 points, one unbroken 180-minute clock, split across the six domains in the exam's own proportional weights rather than a scaled-down or skewed approximation. If you've worked through the other four papers, this is the one score that should tell you whether to book the exam or spend one more week on a specific domain.

Where Set 5 fits among the five DOP-C02 papers

☺ Like you're 10: Four different kinds of practice, then one final rehearsal that asks for all four kinds at once, under the real clock.

Each of the first four papers deliberately narrowed its focus so you could drill one skill at a time without the other three getting in the way. Set 5 removes that scaffolding on purpose — which is exactly what makes it a genuine readiness signal instead of another practice rep.

If you haven't sat at least Set 1 and Set 3 first, sit those before this one — a low score here won't tell you whether the gap is recall, scenario-reading, or a specific lookalike pair, and untangling that after the fact from a single 45-question paper is much harder than diagnosing it from three focused ones. Set 5 is a capstone, not a substitute; see the study plan for exactly where it belongs in your remaining weeks.

Sit it exactly like the real thing

☺ Like you're 10: One three-hour clock, no notes, no tabs, an answer for all forty-five — even the ones you're guessing on.

A dress rehearsal only measures readiness if you actually rehearse under the real constraints. Loosen any one of these and the number you get back stops meaning what you think it means.

1. One 180-minute timer, started once. That's the real DOP-C02's own duration — not scaled down the way Set 3 (35 min) and Set 4 (75 min) deliberately were. You will finish with time to spare across 45 questions rather than the real exam's 75, and that's intentional: the slack is where your flag-and-review protocol lives, exactly like it will on the real day when you've triaged well.
2. Genuinely closed-book. No AWS docs, no blueprint pages open in another tab, no notes, no AI assistant. The real exam gives you nothing but the scenario and the options.
3. Answer every question. DOP-C02 carries no penalty for a wrong answer. A blank is a guaranteed zero; an elimination-based guess between two plausible options costs nothing and sometimes pays off.
4. Don't open the answer key until all 45 are answered. It's folded behind a single summary at the end for exactly this reason — open it mid-sitting and you've converted a readiness test into a reading exercise.
5. Read every scenario twice before touching an option. This paper deliberately mixes recall questions (fast, one read is enough) with dense scenario and confusable-pair questions (the qualifier word or the ruling-out detail is often on the second read) — treating all 45 at the same reading speed is the single most common way candidates lose points they actually knew.
6. Mark yourself only after the sitting ends, then read every explanation — including for questions you got right. A correct guess on a confusable pair teaches you nothing until you check why the letter you picked was actually the right one.

Pacing 45 questions across the full 180 minutes

☺ Like you're 10: The real test gives you about two and a half minutes per question. This paper gives you closer to four — on purpose, so you have real time left over to double-check instead of racing the clock.

The real exam averages roughly 2.4 minutes per question across 75 questions. This paper's 45 questions over the same 180 minutes work out to about 4 minutes each — deliberately more generous, for two reasons. First, a paper built entirely from scenario and confusable-pair questions (the two densest styles Sets 2 and 3 taught) reads slower per question than a proportional mix that includes plenty of quick recall items, the way the real 75-question paper does. Second, that extra slack is exactly where the discipline that actually matters on exam day lives: a genuine read-twice-then-decide habit, a flag-and-return protocol for anything that stalls, and a real final sweep — not a rushed one squeezed out of a clock with nothing left to give.

How the 45 questions are weighted

☺ Like you're 10: The paper hands out points the same way the real test does — the biggest domain gets the most questions and the most points, not an even sixth each.

Every question below counts for either 2 or 3 points, and each domain's questions sum to that domain's real exam weight exactly — SDLC Automation's ten questions total 22 points because SDLC Automation is 22% of the real exam, and so on down the list. Nothing here is proportional-ish; it's proportional to the point.

The three question styles, combined

☺ Like you're 10: Some questions here just ask "what is this," some hand you a whole situation to reason through, and some are two similar-sounding things daring you to mix them up — the real exam throws all three at you with no warning which is coming.

Nothing on this paper announces its own style — that's deliberate, and it's the real exam's own behavior. But it's worth naming the three shapes so you recognize each one the instant it shows up, the same way answer triage & elimination teaches you to read a stem before you read the options:

• Recall (Set 1's style) — a direct "what does this feature do, and what's the one fact that distinguishes it" question. Fast if you know it cold, and exactly what Know It Cold exists to make automatic.
• Scenario (Set 2's style) — a paragraph of constraints and a qualifier word ("MOST cost-effective," "with the LEAST operational overhead," "without a human intervening") that rules out options that technically work but fail the actual ask.
• Confusable-pair (Set 3's style) — two or three AWS constructs that get taught on the same page because they're easy to conflate, with the question forcing you to name the one specific detail that tells them apart.

Every question below is genuinely new — none of these forty-five repeat a Set 1–4 question verbatim — but each one is written in one of these three families, and several deliberately blend two of them, exactly the way a real DOP-C02 question sometimes hands you a scenario built entirely around a confusable pair.

The paper — 45 questions, six domains, in blueprint order

☺ Like you're 10: Work straight through, D1 to D6, picking one letter each time — don't check anything until every question has an answer.

Each domain section opens with a one-line reminder of what it covers and nothing else — no hints about which of the three styles is coming next. Choose an option, write it down, and move to the next question. Only the final answer key tells you whether you were right.

D1 — SDLC Automation · 22 pts · Q1–Q10

☺ Like you're 10: Pipelines, builds, artifacts, and the different ways CodeDeploy moves traffic from old code to new code.

Q1 · 2 pts. A CodePipeline stage contains three actions: Lint, UnitTest, and SecurityScan, added to the stage in that order with no runOrder specified on any of them. What actually happens when the stage runs?

1. The three actions run one after another, strictly in the order they were added, because that's how CodePipeline orders actions by default.
2. All three actions run in parallel, because actions within the same stage default to runOrder: 1 and actions sharing a runOrder value execute concurrently — sequencing only happens if you explicitly assign increasing runOrder values.
3. CodePipeline rejects the stage at creation time, because a stage must contain exactly one action unless runOrder is explicitly set on each one.
4. Only the first action, Lint, runs automatically; the other two require a manual trigger.

Q2 · 2 pts. A team is designing a brand-new CodePipeline source stage in 2026 and is deciding between AWS CodeCommit and a CodeStar Connections integration to an external Git host. Which statement is accurate?

1. CodeCommit has not been orderable by new AWS customers since mid-2024 — existing CodeCommit repositories and the pipelines that use them keep working, but a new source integration should use a CodeStar Connections-based provider such as GitHub, GitLab, or Bitbucket instead.
2. CodeCommit was fully shut down for all customers, existing and new, and every CodeCommit-sourced pipeline stopped working.
3. CodeStar Connections only supports GitHub, so any team using GitLab or Bitbucket must still provision a new CodeCommit repository.
4. There is no functional difference; CodeCommit remains the AWS-recommended default source provider for all new pipelines.

Q3 · 2 pts. A CodeBuild buildspec.yml's post_build phase needs to always upload test reports to S3, even when an earlier command in that same phase fails and would otherwise abort the phase. Which buildspec construct achieves this?

1. A finally block nested under the phase's commands, which CodeBuild always executes after the phase's primary commands, whether or not those primary commands succeeded.
2. Setting the phase's on-failure value to CONTINUE, which is only a project-level setting and cannot be scoped to one phase.
3. There is no way to guarantee a command runs after a failure within the same phase; a separate CodeBuild project is required.
4. Moving the upload command into the install phase instead, since that phase always runs regardless of later failures.

Q4 · 2 pts. A team wants automated feedback on a pull request's code quality — flagging potential bugs and security issues in the diff before merge — and, separately, wants to identify which functions in a running production application are consuming the most CPU time. Which two AWS services match those two jobs, respectively?

1. Amazon CodeGuru Reviewer for the pull-request code analysis; Amazon CodeGuru Profiler for the running-application CPU analysis.
2. Amazon CodeGuru Profiler for the pull-request analysis; Amazon CodeGuru Reviewer for the running-application analysis.
3. Amazon Inspector handles both jobs identically, since it covers both static code analysis and runtime profiling.
4. AWS X-Ray handles both jobs, since tracing a request also reveals per-function CPU consumption.

Q5 · 2 pts. A team published a bad package version to CodeArtifact. They want that specific version to stop being resolvable by version ranges (so ^2.3.0 silently skips it and takes the next good version) while still allowing someone who already has it pinned exactly to reinstall it for forensic purposes. What CodeArtifact package version status achieves this, as opposed to blocking the version outright?

1. Unlisted — the version is hidden from version-range resolution and listing calls, but a client that requests that exact version number can still fetch it directly.
2. Blocked — the version is rejected for every request, including an exact-version pin, which is the wrong choice here since forensic re-fetching needs to still work.
3. Deleting the package version entirely, which also breaks the forensic-reinstall requirement.
4. CodeArtifact has no per-version status; the only option is deleting the whole package.

Q6 · 2 pts. A team pushes a new image to an ECR repository using the tag prod every release, intending each push to simply move the prod tag to point at the newest image digest. A security review flags this as risky because it makes it impossible to prove which exact image digest was running in production at a given point in the past. Which ECR repository setting directly prevents this pattern going forward?

1. Enabling basic scan-on-push, which scans for CVEs but has no effect on whether a tag can be reused.
2. Setting the repository's tag mutability to IMMUTABLE, which makes ECR reject any push that reuses an existing tag — forcing every release to use a new, unique tag (commonly the Git commit SHA) instead of overwriting prod.
3. Enabling lifecycle policies, which only control automatic expiration of old images and don't prevent tag reuse.
4. Switching from ECR to CodeArtifact, since CodeArtifact is the only AWS registry that supports immutable tags.

Q7 · 3 pts. Which statement correctly contrasts the set of CodeDeploy AppSpec lifecycle hooks available for an EC2/on-premises deployment against the set available for a Lambda deployment?

1. They're identical — both platforms support the same seven-hook sequence from ApplicationStop through ValidateService.
2. An EC2/on-premises deployment supports the full in-place lifecycle (ApplicationStop, DownloadBundle, BeforeInstall, Install, AfterInstall, ApplicationStart, ValidateService), because there's an actual instance to stop, install onto, and start; a Lambda deployment has no instance to install anything onto, so it only supports the traffic-shifting hooks — BeforeAllowTraffic and AfterAllowTraffic.
3. Lambda deployments support more hooks than EC2, because Lambda deployments always use blue/green and EC2 deployments never do.
4. Neither platform supports any lifecycle hooks; hooks are exclusive to ECS blue/green deployments.

Q8 · 2 pts. A CodeDeploy blue/green deployment group for an EC2 Auto Scaling group is configured to keep the original (blue) instances running for two hours after traffic fully shifts to green, before terminating them automatically. What is this setting called, and what's the operational reason to extend it rather than terminate immediately?

1. The termination wait time (part of the deployment group's blue/green deployment configuration) — extending it keeps a known-good, fully provisioned fallback environment available for a fast rollback (a routing change, not a redeploy) if a problem surfaces after the cutover that wasn't caught during the bake period.
2. The ValidateService timeout, which controls how long CodeDeploy waits for the smoke-test hook to return before failing the deployment.
3. The minimumHealthyHosts setting, which controls how many instances must stay healthy during the deployment itself.
4. There's no such setting; CodeDeploy always terminates the blue fleet the instant the green fleet is confirmed healthy.

Q9 · 3 pts (Choose TWO). A CodePipeline running in Account A needs to deploy a CloudFormation stack into Account B via a cross-account CloudFormation deploy action. Which TWO configuration steps are actually required for this to work?

1. The pipeline's deploy action must specify a RoleArn pointing at a role in Account B, and that role's trust policy must allow Account A's pipeline role to assume it.
2. The KMS key encrypting the pipeline's cross-region/cross-account artifact bucket must be a customer-managed key whose key policy explicitly grants the necessary permissions to the relevant principal(s) in Account B — the default AWS-managed key can't be shared this way.
3. Account B must disable all IAM policies, since cross-account CloudFormation deploys bypass IAM entirely.
4. CodePipeline requires both accounts to be in the same AWS Organization with no exceptions, or the deploy action is rejected outright.
5. The pipeline must be recreated entirely inside Account B; a pipeline cannot deploy outside the account that owns it under any configuration.

Q10 · 2 pts. A CodeBuild project needs to build a Docker image and push it to ECR as part of the build. The build fails with an error indicating it cannot connect to the Docker daemon. What CodeBuild project setting is almost certainly missing?

1. Privileged mode must be enabled on the CodeBuild project/build environment — without it, the build container has no access to a Docker daemon and any docker build or docker push command fails immediately.
2. The CodeBuild service role is missing ecr:GetAuthorizationToken, which would produce an authentication error, not a daemon-connection error.
3. The buildspec is missing an install phase; Docker only becomes available if explicitly installed via apt-get first.
4. CodeBuild cannot build Docker images under any configuration; this workload requires CodePipeline's separate Docker-build action type.

D2 — Configuration Management & IaC · 17 pts · Q11–Q17

☺ Like you're 10: CloudFormation, StackSets, the CDK, Systems Manager fleet config, and the guardrails that keep many accounts consistent.

Q11 · 3 pts. A CloudFormation template attaches both a DeletionPolicy: Retain and an UpdateReplacePolicy: Retain to a production S3 bucket resource. A teammate asks why both are needed instead of just one. What's the accurate answer?

1. They're redundant; either attribute alone protects the bucket in every scenario, including both stack deletion and resource replacement during an update.
2. DeletionPolicy governs what happens to the resource when the stack itself is deleted (or the resource is removed from the template); UpdateReplacePolicy governs what happens to the old physical resource specifically when an update forces CloudFormation to replace it with a new one. A bucket needs both attributes to be protected in both situations, since one attribute doesn't cover the other's trigger.
3. UpdateReplacePolicy is deprecated and has no effect; only DeletionPolicy does anything in current CloudFormation.
4. Both attributes only apply to RDS and EFS resources; S3 buckets ignore them entirely and are always retained by default.

Q12 · 2 pts. A parent CloudFormation stack creates a VPC in a nested stack and needs the child's subnet IDs to configure a resource declared directly in the parent template. What's the standard way to get that value from the nested stack back to the parent?

1. The nested (child) stack declares the subnet IDs under its own Outputs section, and the parent template reads them via !GetAtt NestedStackLogicalId.Outputs.SubnetIds — no cross-stack Export/Fn::ImportValue is needed, since the parent and child are part of the same stack operation.
2. The parent must use Fn::ImportValue against an exported output, exactly as it would for two unrelated, independently deployed top-level stacks.
3. Nested stacks cannot pass values back to their parent under any mechanism; only Parameters can flow into a nested stack, never out.
4. The subnet IDs must be hardcoded in the parent template after checking the console once, since CloudFormation has no native mechanism for this.

Q13 · 3 pts. An organization sets up two kinds of Control Tower guardrails: one that makes it impossible to disable CloudTrail in any member account (the action is rejected outright, before it ever takes effect), and one that flags an account as non-compliant if S3 Block Public Access is off (the account isn't stopped from turning it off, but the finding shows up for remediation). What are these two guardrail types called, and what AWS mechanism implements each?

1. Both are "detective" guardrails; the only difference is how fast each one's finding appears.
2. The first is a preventive guardrail, implemented as a service control policy that denies the action at the API level before it can execute; the second is a detective guardrail, implemented as an AWS Config rule that evaluates compliance after the fact without blocking anything.
3. The first is detective (Config rule), the second is preventive (SCP) — the reverse of option B.
4. Both are implemented as IAM permission boundaries, since boundaries are Control Tower's only guardrail mechanism.

Q14 · 2 pts. A team runs cdk deploy directly from individual developer laptops today. They want to move to a model where a CI/CD pipeline is the only thing that ever applies infrastructure changes, with developers only able to preview and merge, never directly deploy. Which CDK-native approach fits, and what does it actually deploy through the pipeline?

1. The pipeline runs cdk synth to produce a plain CloudFormation template as a build artifact, then a standard CloudFormation deploy action (or CDK Pipelines, which wraps this same pattern) applies that synthesized template — developers merge CDK source code, never CloudFormation templates or deployments, directly.
2. There's no way to run CDK from a pipeline; cdk deploy can only be executed interactively from a local terminal with AWS credentials.
3. The pipeline should run cdk deploy from a developer's laptop remotely triggered by a webhook, since cdk synth cannot produce a deployable artifact on its own.
4. CDK requires a completely separate, non-CloudFormation deployment mechanism when used from a pipeline.

Q15 · 2 pts. A Systems Manager Parameter Store advanced parameter holding a rotating internal token needs to automatically notify an SNS topic 7 days before it's due to expire, and separately, needs to actually stop being usable 30 days after it was last changed if nobody updates it. Which Parameter Store feature covers both requirements?

1. Parameter policies — specifically an ExpirationNotification policy for the advance SNS warning, and an Expiration policy for the hard cutoff — both attachable to the same advanced parameter, each with its own configured timeframe.
2. Parameter Store has no expiration concept at all; only Secrets Manager supports timed expiration.
3. A single NoChangeNotification policy covers both the advance warning and the hard expiration in one setting.
4. This requires a custom EventBridge scheduled rule, since Parameter Store parameters have no policy mechanism of their own.

Q16 · 2 pts. A platform team wants to package a set of AWS Config rules and their associated automatic remediation actions as one reusable, versioned unit that can be deployed identically across many accounts via StackSets, rather than creating each Config rule by hand in every account. What AWS Config feature is purpose-built for this?

1. A conformance pack — a collection of Config rules and remediation actions defined once (as a YAML template) and deployed as a single unit across accounts and regions, commonly via a StackSet.
2. A single custom Config rule with multiple Scope blocks, which can hold many unrelated rules inside it.
3. AWS Config has no bundling mechanism; every rule must be created individually in every account with no reuse possible.
4. A CloudFormation nested stack is the only way to bundle Config rules; Config itself has no native grouping feature.

Q17 · 3 pts. A team is choosing between a self-managed and a service-managed CloudFormation StackSet for deploying a baseline stack across 50 accounts inside an AWS Organization. Which statement correctly describes the practical difference in setup effort?

1. A self-managed StackSet requires manually creating and trusting the correct IAM roles (an administration role in the management account, an execution role in each of the 50 target accounts) before any stack instance can be created; a service-managed StackSet, once Organizations integration is enabled, requires no manual per-account role setup at all — AWS handles it automatically as accounts are targeted.
2. The two modes are identical in setup effort; the only difference is a cosmetic label in the console.
3. A service-managed StackSet actually requires more manual role setup than a self-managed one, since Organizations integration must be configured per account individually.
4. Self-managed StackSets can only target a single account at a time and cannot be used for 50 accounts under any configuration.

D3 — Resilient Cloud Solutions · 15 pts · Q18–Q24

☺ Like you're 10: Multi-AZ, Auto Scaling, load balancer health, Route 53 failover, and trading cost for a faster recovery.

Q18 · 3 pts. An Auto Scaling group needs to hold average CPU utilization near 50% automatically, adding or removing capacity as load actually changes, with no one hand-tuning step sizes. A second, unrelated ASG needs to react only to a specific CloudWatch alarm by adding exactly 2 instances the first time it fires and exactly 4 more if the alarm is still in breach 5 minutes later. Which two Auto Scaling policy types match these two requirements, respectively?

1. Target tracking scaling for the first (you declare the target metric value and Auto Scaling manages the add/remove steps itself, like a thermostat); step scaling for the second (you define specific step adjustments tied to how far past the alarm threshold the metric is, escalating over time).
2. Simple scaling for the first, target tracking for the second — simple scaling is the metric-driven "thermostat" type.
3. Step scaling for both, since target tracking cannot be driven by CPU utilization.
4. Scheduled scaling for both, since neither requirement mentions a specific date or time.

Q19 · 2 pts. An ALB target group's health check is currently configured with a 30-second interval, a healthy threshold of 5, and an unhealthy threshold of 5 — meaning a genuinely failed instance takes up to 2.5 minutes to be marked unhealthy. The team wants materially faster failure detection without generating false positives from single transient blips. What's the right tuning move?

1. Lower the health check interval and the unhealthy threshold together (for example, a 10-second interval with an unhealthy threshold of 2, marking a target unhealthy after roughly 20 seconds of consecutive failures) — this detects real failures faster while still requiring more than one bad check before acting, avoiding a single blip triggering a false failure.
2. Set the unhealthy threshold to 1, so any single failed check immediately marks the target unhealthy — this is always the safest configuration regardless of workload.
3. Health check timing cannot be tuned on an ALB target group; only the health check path can be changed.
4. Raise the healthy threshold instead, which has no effect on how quickly a failure is detected.

Q20 · 2 pts. A workload's DR requirement: infrastructure for the secondary region should already be running at full production scale at all times, kept in sync closely enough that failover takes only a few minutes, and the team accepts the cost of running two full production environments simultaneously. Between pilot light, warm standby, and multi-site active-active, which one actually matches "already running at full scale, both regions live, minutes-not-hours failover"?

1. Pilot light — only a minimal core (like a database) runs continuously; everything else is scaled up on failover, which is slower than "already running at full scale."
2. Warm standby — a scaled-down but always-running full stack; still needs to scale up on failover, and isn't running at "full production scale" continuously the way the requirement demands.
3. Multi-site active-active — both regions run at full production capacity simultaneously at all times, which is the only one of the three that matches "already running at full scale" with the fastest possible failover, at roughly double the standing infrastructure cost.
4. Backup and restore — the cheapest and slowest of the four standard DR strategies, the opposite of what this requirement describes.

Q21 · 2 pts. A service runs active production traffic in two regions simultaneously and wants Amazon Route 53 to send each user to whichever of the two regions currently responds fastest for them, continuously adjusting as network conditions change — not a fixed 50/50 split, and not an active/passive failover. Which Route 53 routing policy fits?

1. Failover routing, since it's designed for multi-region setups.
2. Weighted routing set to 50/50, since that evenly distributes traffic across both regions.
3. Latency-based routing — it routes each request to whichever configured region gives that specific requester the lowest network latency, based on continuously measured AWS latency data, which is exactly the "fastest-responding region, continuously" behavior described.
4. Geolocation routing, since it routes strictly by the requester's geographic location rather than measured latency.

Q22 · 2 pts. A team needs synchronous, zero-data-loss automatic failover within a single AWS Region for an Aurora MySQL cluster, and separately, a secondary Aurora cluster in a different AWS Region kept in near-real-time sync (typically under a second of replication lag) for regional disaster recovery. Which two Aurora/RDS capabilities provide these, respectively, and why can't one alone do both jobs?

1. Multi-AZ (a synchronous standby within the same Region) for the in-Region failover; Aurora Global Database (asynchronous, typically sub-second cross-region replication, purpose-built for DR and read scaling across Regions) for the cross-region DR — Multi-AZ doesn't span Regions, and Global Database's cross-region leg is asynchronous, not zero-data-loss synchronous, so neither alone covers both jobs.
2. A single read replica handles both jobs identically, regardless of whether it's in the same Region or a different one.
3. Aurora Global Database provides synchronous, zero-data-loss replication across Regions, making a separate Multi-AZ standby unnecessary.
4. Multi-AZ automatically replicates across Regions once enabled; no separate cross-region capability is needed.

Q23 · 2 pts. An Application Load Balancer distributes traffic across three Availability Zones, but one AZ only has 2 registered targets while the other two have 8 each. Requests to the under-provisioned AZ's targets are landing with noticeably higher per-target load. What ALB setting addresses this directly?

1. Cross-zone load balancing — when enabled, each load balancer node distributes its traffic evenly across all registered targets in all enabled AZs, rather than only the targets in its own AZ, which is exactly what corrects an uneven per-target load caused by an uneven target count across AZs.
2. Increasing the health check interval, which has no effect on traffic distribution across AZs.
3. Enabling sticky sessions, which pins a given client to one target and would make the imbalance worse, not better.
4. ALBs cannot be configured this way; only Network Load Balancers support any cross-zone behavior.

Q24 · 2 pts. A Well-Architected review flags a service whose Auto Scaling group only holds a small baseline capacity day-to-day and relies on a scaling policy to add capacity during an AZ failure — a real-time API call that itself might be affected by the same disruption. The reviewer recommends the ASG instead keep enough capacity already running, spread across AZs, to absorb the loss of one AZ with no scaling action required at all. What Well-Architected Reliability concept is this recommendation an example of?

1. Static stability — designing a system so it survives a specific failure mode (here, losing an AZ) without needing to make any control-plane API call during the event itself, since that call could be exactly what's degraded during a real disruption.
2. Elasticity, since the goal is to scale capacity up and down with demand.
3. Idempotency, since the concern is about repeating the same scaling action safely.
4. The shared responsibility model, since AWS is responsible for AZ-level failures, not the customer.

D4 — Monitoring & Logging · 15 pts · Q25–Q31

☺ Like you're 10: CloudWatch metrics and alarms, logs and Logs Insights, X-Ray tracing, and CloudTrail's audit trail.

Q25 · 2 pts. A trading system needs to publish a custom CloudWatch metric with genuine 1-second granularity to catch sub-minute spikes that a standard metric would average away. Which PutMetricData configuration is required?

1. Setting the metric's StorageResolution to 1 (high-resolution), as opposed to the default of 60 (standard resolution) — high-resolution custom metrics can be published and retrieved at 1-second granularity, at a higher cost than standard-resolution metrics.
2. No special configuration is needed; every CloudWatch custom metric is stored at 1-second resolution by default.
3. High-resolution metrics require a completely separate service, CloudWatch Synthetics, and cannot be published via PutMetricData.
4. Setting a CloudWatch alarm's evaluation period to 1 second, which controls alarm evaluation frequency, not the metric's own storage resolution.

Q26 · 3 pts. A team wants two different things from the same CloudWatch Logs log group: (1) a CloudWatch metric that counts ERROR-level log lines per minute, so they can alarm on a rate spike, and (2) matching log lines streamed to a Lambda function in near real time for custom enrichment before they're stored elsewhere. Which CloudWatch Logs feature provides each, and how do the two differ?

1. Both jobs are the same feature under two names; a metric filter and a subscription filter are interchangeable.
2. A metric filter extracts a pattern from incoming log lines and turns matches into a CloudWatch metric data point (good for counting and alarming on a rate); a subscription filter instead streams matching log lines themselves, in near real time, to a destination such as Lambda, Kinesis, or Firehose (good for real-time processing of the actual log content) — one produces a number, the other forwards the events.
3. A subscription filter produces a metric; a metric filter streams raw log events to Lambda — the reverse of option B.
4. Neither feature exists; both jobs require exporting the log group to S3 first and querying with Athena.

Q27 · 2 pts. A platform team wants every application account's CloudWatch Logs to flow into one centralized security/logging account in near real time, without each application team manually exporting anything. Which architecture achieves this using CloudWatch Logs' own cross-account delivery mechanism?

1. A subscription filter on each application account's log group, targeting a destination (commonly a Kinesis Data Firehose delivery stream) owned by the central logging account, with a destination access policy in the logging account authorizing each source account to write to it.
2. CloudWatch Logs has no cross-account delivery mechanism; every application team must manually export and re-upload logs on a schedule.
3. A CloudTrail organization trail is the only way to centralize any kind of log data across accounts.
4. Each application account must be merged into the logging account's AWS Organization management account directly, since cross-account log delivery requires being the same account.

Q28 · 2 pts. A metric's normal daily pattern varies significantly by time of day (high during business hours, low overnight), which makes a single static alarm threshold either too sensitive overnight or too insensitive during the day. Which CloudWatch capability is built to alarm on deviation from a metric's own learned, time-of-day-aware expected range instead of one fixed number?

1. CloudWatch Anomaly Detection — it applies a statistical model to a metric's history to build an expected range ("band") that itself varies by time of day and day of week, and an anomaly-detection alarm fires when the actual value falls outside that band rather than outside one static number.
2. A composite alarm, which combines the states of other alarms with a Boolean rule but doesn't build any statistical model of its own.
3. CloudWatch Logs Insights, which queries log content and has no metric-threshold or anomaly concept.
4. Raising the standard alarm's threshold to the highest value seen in the metric's history, which would simply stop it from firing during business hours too.

Q29 · 2 pts. A service traced with AWS X-Ray receives extremely high request volume, and the team is concerned about both the cost and performance overhead of tracing every single request. What X-Ray mechanism reduces trace volume while still keeping a statistically useful, cost-controlled sample of traces?

1. Sampling rules — X-Ray lets you configure a sampling rate (for example, trace a fixed 1 request per second plus 5% of any additional requests) instead of tracing every request, trading complete coverage for controlled cost and overhead while still capturing a representative sample.
2. X-Ray always traces 100% of requests with no way to reduce volume; cost is only controlled by shortening trace retention.
3. Disabling X-Ray entirely is the only way to reduce trace volume; there's no partial-sampling option.
4. CloudWatch Logs Insights sampling settings control X-Ray's trace volume, since the two services share one sampling configuration.

Q30 · 2 pts. A team creates a new CloudWatch Logs log group and assumes, correctly or not, that old log data will "roll off" automatically after some default period the way many logging systems behave. What's actually true about a CloudWatch Logs log group's retention setting by default?

1. The default retention is Never Expire — logs accumulate indefinitely (and indefinitely incur storage cost) unless someone explicitly sets a retention period on the log group, which is a commonly missed step and a common source of surprise storage bills.
2. The default retention is exactly 30 days for every log group, with no way to change it.
3. CloudWatch Logs automatically deletes logs older than 90 days regardless of any setting.
4. Retention can only be set at the account level, never per log group.

Q31 · 2 pts. A team maintains one CloudWatch dashboard and asks whether it can show an alarm from us-east-1, a metric from eu-west-1, and a Logs Insights query result from ap-southeast-2 all on the same dashboard at once. Is this possible?

1. No — a CloudWatch dashboard is locked to the single AWS Region it was created in and can never display data from any other Region.
2. Yes — an individual CloudWatch dashboard can include widgets sourced from multiple Regions (and, with the right permissions, multiple accounts) simultaneously; each widget independently specifies which Region's data it pulls from.
3. Yes, but only for metrics — alarms and Logs Insights widgets are always restricted to the dashboard's home Region.
4. Only if all three Regions are in the same AWS Organization; otherwise cross-region widgets are rejected.

D5 — Incident & Event Response · 14 pts · Q32–Q37

☺ Like you're 10: Detecting trouble, remediating it automatically, escalating to a human, and learning from it afterward.

Q32 · 2 pts. A team wants CloudWatch alarm and EventBridge notifications to land in a Slack channel, and wants an on-call engineer to be able to type a scoped command in that same Slack channel (like re-running a specific SSM Automation runbook) without opening the AWS console. Which AWS service is purpose-built for this two-way ChatOps integration?

1. AWS Chatbot — it forwards CloudWatch alarms, EventBridge events, and SNS notifications into a configured Slack or Chime channel, and separately allows scoped, IAM-permission-bounded AWS CLI-style commands to be run from that same channel.
2. Amazon SNS alone, since a topic can be subscribed to by a Slack webhook with no additional service involved for two-way commands.
3. AWS Systems Manager Incident Manager, which creates incidents but has no chat-integration feature of its own.
4. Amazon EventBridge, which can route events but has no native Slack integration or command-execution capability.

Q33 · 3 pts. A critical alarm needs to do more than notify someone — it needs to automatically open a dedicated Slack incident channel, page a specific on-call rotation via a pre-defined escalation chain, and attach a runbook, all coordinated as one structured event. A different, lower-severity alarm just needs to email a distribution list. Which two mechanisms match these two needs, respectively?

1. A Systems Manager Incident Manager response plan for the first — it's specifically built to coordinate chat-channel creation, a defined escalation/engagement chain, and runbook attachment as one structured incident; a plain SNS topic for the second, which is well suited to simple fan-out notification but has no concept of escalation chains or coordinated incident structure on its own.
2. An SNS topic for the first, a response plan for the second — the reverse of option A.
3. Both needs are served identically by a plain SNS topic; response plans add no capability SNS doesn't already have.
4. Both needs require Incident Manager; SNS cannot be used for any alarm notification.

Q34 · 2 pts. An EventBridge rule matches CloudWatch alarm state-change events and targets an SNS topic that pages the on-call engineer's phone. The raw event delivered to SNS is a large, deeply nested JSON blob, and the on-call engineer wants the page to instead read as a short, readable sentence naming the alarm and its new state. What EventBridge feature reshapes the event payload before it reaches the target, without needing a Lambda function in between?

1. An input transformer on the rule's target — it lets you extract specific fields from the matched event (via input paths) and substitute them into a custom text or JSON template, so the target receives your reshaped message instead of the raw event.
2. An event pattern, which only controls which events match the rule, not how the matched event's payload is reshaped.
3. This isn't possible without a Lambda function inserted as an intermediate target to reformat the payload.
4. SNS message filtering, which filters which subscribers receive a message but doesn't rewrite the message content itself.

Q35 · 2 pts. An EventBridge rule needs to match only CloudWatch alarm state-change events where the new state is specifically ALARM (not OK or INSUFFICIENT_DATA), ignoring every other event in the bus. Which part of the rule definition expresses that condition?

1. The event pattern — a JSON structure matched against the incoming event's fields, here filtering on source: ["aws.cloudwatch"], detail-type: ["CloudWatch Alarm State Change"], and detail.state.value: ["ALARM"] to match only the specific state transition wanted.
2. The rule's target configuration, since targets — not patterns — determine which events are matched.
3. A resource-based policy on the event bus, which controls cross-account access, not per-event field filtering.
4. EventBridge cannot filter on a nested field like the alarm's new state value; only top-level fields like source can be matched.

Q36 · 2 pts. An organization's Incident Manager response plan pages the primary on-call contact, but wants that page to automatically escalate to a secondary contact if the primary doesn't acknowledge within 15 minutes, and further escalate to a manager if the secondary doesn't acknowledge within another 15 minutes. What Incident Manager feature configures this chained, timed escalation?

1. An escalation plan — a chain of contacts or contact channels, each with a defined response-timeout window, that Incident Manager progresses through automatically when the current stage doesn't acknowledge in time.
2. A single SNS topic subscribed by all three contacts simultaneously, which pages everyone at once with no timing or ordering.
3. Incident Manager has no escalation concept; all contacts must be manually re-notified by a human after each timeout.
4. An EventBridge scheduled rule that re-runs the same notification every 15 minutes indefinitely, regardless of acknowledgment.

Q37 · 3 pts. Following a resolved incident, the team wants every corrective action from the postmortem (a config check to add, a runbook to update, an alarm to tune) to be individually tracked, assigned an owner, and followed up on until closed — not just written in a document that nobody revisits. Which AWS mechanism supports this kind of tracked, owned follow-up item, tying naturally back into the same Systems Manager tooling used for the incident itself?

1. Systems Manager OpsCenter OpsItems — each corrective action from the postmortem can be created as its own OpsItem, with an assigned owner, a status, and related-resource context, giving the team a trackable, closeable work item instead of an unrevisited paragraph in a document.
2. A CloudWatch alarm, since alarms are the correct mechanism for tracking human follow-up tasks.
3. There's no AWS-native way to track postmortem action items; this must be done entirely outside AWS tooling.
4. An IAM policy document, since policies are the standard place to record follow-up commitments.

D6 — Security & Compliance · 17 pts · Q38–Q45

☺ Like you're 10: IAM, encryption, continuous compliance, threat detection, and locking down the pipeline itself.

Q38 · 2 pts. A principal in Account B has an IAM identity policy granting kms:Decrypt on a customer-managed KMS key owned by Account A. Nothing else has been configured. Can that principal actually decrypt data using that key?

1. Yes — an IAM identity policy alone is always sufficient to grant access to any KMS key, in any account.
2. No — a KMS key's own key policy is the primary access-control document and must also explicitly allow the action (directly, or by delegating to IAM in the key's own account); for a principal in a different account, the key policy must explicitly permit that external account/principal. Both the key policy and the calling principal's IAM policy must agree for the request to succeed — either alone is not enough.
3. No — cross-account KMS access is technically impossible under any configuration, regardless of policy.
4. Yes, but only if the key is an AWS-managed key rather than a customer-managed key.

Q39 · 2 pts. An EC2 Auto Scaling group's launch template needs to let each new instance transparently decrypt attached EBS volumes encrypted with a specific customer-managed KMS key, without granting the instance role a broad, standing key-policy statement. Which KMS mechanism is designed for exactly this kind of narrow, temporary, service-issued permission?

1. A KMS grant — a temporary, narrowly-scoped, programmatically created and revocable permission for a specific principal to perform specific KMS operations, commonly issued by an AWS service (like EC2/EBS) on your behalf, as opposed to a durable, hand-edited key policy statement.
2. A key policy statement is the only mechanism KMS supports; grants don't exist as a distinct concept.
3. A permissions boundary attached to the KMS key itself, since boundaries can be attached to resources as well as identities.
4. An SCP scoped to the specific EBS volume's ARN.

Q40 · 2 pts. A team needs Secrets Manager to automatically rotate a secret that holds credentials for a third-party SaaS API — not RDS, Redshift, or DocumentDB, none of which Secrets Manager ships a built-in rotation template for. What's required to make automatic rotation work here?

1. Automatic rotation is only available for the database engines Secrets Manager natively supports; a third-party API secret cannot be rotated automatically under any configuration.
2. The team must author their own rotation Lambda function implementing the standard four-step rotation strategy (createSecret, setSecret, testSecret, finishSecret) that calls the third-party API's own credential-rotation mechanism — Secrets Manager provides the rotation schedule and orchestration, but the actual "how do I get a new credential from this API" logic has to be custom for a non-built-in secret type.
3. The secret must first be migrated into Parameter Store, since only Parameter Store supports custom rotation logic.
4. Rotation requires no Lambda function at all for any secret type; Secrets Manager rotates every stored secret using one universal built-in mechanism.

Q41 · 2 pts. By default, GuardDuty analyzes VPC Flow Logs, DNS query logs, and CloudTrail events for signs of compromise. A team also wants GuardDuty to specifically evaluate S3 data-plane activity for anomalous access patterns and to scan EKS audit logs for suspicious Kubernetes API activity. What's required to get that additional coverage?

1. Enabling the relevant optional GuardDuty protection plans — S3 Protection and EKS Protection are separate, opt-in feature sets layered on top of GuardDuty's baseline foundational data sources, each analyzing a different additional signal (S3 data events, EKS audit logs) and each billed and enabled independently.
2. Nothing — GuardDuty's baseline configuration already covers S3 data-plane activity and EKS audit logs with no additional setup.
3. This requires switching entirely from GuardDuty to Security Hub, since GuardDuty cannot analyze S3 or EKS activity under any configuration.
4. Enabling AWS Config, since Config is a prerequisite for every GuardDuty feature, including its baseline detection.

Q42 · 2 pts. An AWS Config rule flags an S3 bucket the moment its Block Public Access setting is disabled, and the team wants that specific noncompliance automatically and immediately reversed by re-enabling the setting, with retry logic if the first remediation attempt fails. What's the most direct, purpose-built AWS Config mechanism for this, as opposed to hand-wiring an EventBridge rule and a separate SSM Automation execution yourself?

1. A Config rule's remediation configuration — it attaches an SSM Automation document directly to the rule, with its own retry attempts and wait time between attempts, so Config triggers the fix natively the moment a resource is evaluated as NON_COMPLIANT, with no separate EventBridge rule required for this specific case.
2. AWS Config has no native remediation mechanism at all; an EventBridge rule matching the compliance-change event is always required.
3. GuardDuty findings are the only trigger Config remediation can respond to.
4. Remediation configurations can only run a Lambda function, never an SSM Automation document.

Q43 · 2 pts. A security review of a CI/CD pipeline distinguishes between two different sets of permissions: the permissions the pipeline's own CodeBuild/CodePipeline service role holds to actually deploy resources, and the permissions individual developers hold to trigger, approve, or modify that pipeline. Why does the review treat these as two separate things to audit, rather than one?

1. Because they're functionally identical; auditing one automatically covers the other.
2. Because an over-permissioned pipeline execution role is a distinct risk from over-permissioned developer access — a developer with only "trigger this pipeline" access can still cause damage far beyond their own personal IAM permissions if the pipeline's own role is broader than the pipeline actually needs, since the pipeline's role — not the developer's — is what actually executes the deployment.
3. Developer permissions are irrelevant to pipeline security, since only the pipeline's own role ever touches production resources.
4. The pipeline's execution role is irrelevant to security, since only individual developer credentials can cause damage.

Q44 · 2 pts. A compliance team wants an automated, ongoing score against the CIS AWS Foundations Benchmark and, separately, against the AWS Foundational Security Best Practices standard, with individual control-level findings for each. Which service provides this, and what does enabling a standard within it actually do?

1. Security Hub — enabling a security standard (CIS AWS Foundations Benchmark, AWS Foundational Security Best Practices, PCI DSS, and others) turns on continuous, automated checks against that standard's individual controls, aggregating findings (including ones sourced from GuardDuty, Config, and Inspector) and computing an overall compliance score per standard.
2. GuardDuty, since it's the service responsible for compliance-standard scoring, not threat detection.
3. AWS Config alone, with no involvement from Security Hub, since Config natively understands named compliance standards like CIS.
4. Trusted Advisor, which only checks cost and performance recommendations, not named security compliance standards.

Q45 · 3 pts (Choose TWO). A CodePipeline in Account A (the "tooling" account) deploys into Account B (a production account) via a cross-account IAM role. The security team wants that role scoped as tightly as possible — assumable only by the specific pipeline, not by any other principal in Account A, even one with broad permissions. Which TWO measures directly enforce that scoping?

1. The role's trust policy in Account B names the specific pipeline's IAM role ARN in Account A as the trusted principal — not the whole Account A account ID — so no other principal in Account A can assume it even if IAM would otherwise allow it.
2. The role's permissions policy in Account B is scoped to only the specific resources and actions the pipeline's deployment actually needs, following least privilege, rather than a broad grant like *:*.
3. Deleting the role's permissions policy entirely, since a role with no permissions policy is automatically the most secure configuration.
4. Making the role assumable by every principal in Account A, since broader trust is easier to audit than a narrowly scoped one.
5. Attaching an SCP directly to the role itself, since SCPs can be attached to individual IAM roles rather than only to accounts or OUs.

Score yourself

☺ Like you're 10: Add up your points once you've answered all forty-five, then check the per-domain breakdown before you decide whether to book the exam.

Mark only after finishing all 45 and only using the answer key below. Full credit for the correct letter (or both correct letters on a Choose-TWO question — half credit is reasonable if you're grading yourself honestly and got exactly one of two); zero otherwise.

The real DOP-C02 pass mark is a scaled score, not a raw percentage — see the exam guide for why 750/1000 doesn't translate cleanly to "75% correct." As a study proxy, this course uses the same 64% reference the other four papers use. Below that here matters more than on any earlier paper, because Set 5 is the one sat under real proportional weighting and the real clock — treat a sub-64% score as a real signal to keep studying, not book yet.

Answer key & explanations

☺ Like you're 10: Read every explanation, even for the ones you got right — this paper mixes three question styles on purpose, and the reasoning behind a lucky guess is worth as much as the reasoning behind a miss.

Reveal only after you've scored yourself above.

Reveal Set 5 answers & explanations (45 questions)

1. Q1 — B. Actions in the same stage default to runOrder: 1 and run concurrently unless you explicitly assign increasing values to force sequencing.
2. Q2 — A. CodeCommit stopped being available to new customers in mid-2024; existing repos and pipelines keep working, but new source integrations should use CodeStar Connections to an external Git host.
3. Q3 — A. A finally block under a phase's commands always runs after the phase's primary commands, success or failure — the standard buildspec construct for guaranteed cleanup or upload steps.
4. Q4 — A. CodeGuru Reviewer analyzes code (commonly on a pull request) for bugs and security issues; CodeGuru Profiler analyzes a running application's runtime performance, including CPU-heavy functions. They solve different halves of the scenario.
5. Q5 — A. Unlisted hides a version from range-based resolution and listing while still letting an exact-version request fetch it — Blocked (B) would break the stated forensic-reinstall requirement.
6. Q6 — B. IMMUTABLE tag mutability makes ECR reject any push that reuses an existing tag, forcing a new unique tag (typically the commit SHA) per release — exactly what prevents "which digest was prod at time T" from becoming unanswerable.
7. Q7 — B. EC2/on-premises deployments have an actual host to stop, install onto, and start, so they get the full seven-hook in-place lifecycle; Lambda has no instance to install anything onto, so it only gets the traffic-shifting hooks, BeforeAllowTraffic and AfterAllowTraffic.
8. Q8 — A. The termination wait time keeps the original (blue) fleet alive as a fast-rollback fallback after cutover — a routing change back to it, not a fresh deployment, if a problem surfaces after the bake period that testing didn't catch.
9. Q9 — A, B. Cross-account CloudFormation deploys need an explicit cross-account trust relationship (A) so the pipeline's role can assume a role in the target account, and a customer-managed KMS key with a policy that explicitly names the target account's principal (B), since the default AWS-managed key can't be shared this way.
10. Q10 — A. Docker builds need an actual Docker daemon available inside the build container, which only privileged mode provides — without it, any docker command fails to connect to a daemon at all, regardless of IAM permissions or buildspec phase placement.
11. Q11 — B. DeletionPolicy governs the resource's fate when the stack (or the resource's presence in the template) is deleted; UpdateReplacePolicy governs the fate of the old physical resource specifically when an update forces a replacement. Different triggers, so both are needed for full protection.
12. Q12 — A. A nested stack's own Outputs, read via !GetAtt NestedStackLogicalId.Outputs.X from the parent, is the standard mechanism — no Export/Fn::ImportValue needed, since parent and child deploy together as one stack operation.
13. Q13 — B. "Rejected outright, before it takes effect" is the defining signature of a preventive guardrail (an SCP denying the action at the API level); "flagged as non-compliant, not blocked" is the defining signature of a detective guardrail (a Config rule evaluating after the fact).
14. Q14 — A. cdk synth produces a plain CloudFormation template as a build artifact that a standard (or CDK Pipelines-wrapped) CloudFormation deploy action then applies — developers merge CDK source, never trigger a deployment directly themselves.
15. Q15 — A. Parameter policies attach to an advanced Parameter Store parameter: ExpirationNotification for the advance SNS warning, Expiration for the hard cutoff — both configurable independently on the same parameter.
16. Q16 — A. A conformance pack bundles Config rules and their remediation actions into one versioned, reusable template, deployable as a unit across accounts/regions, commonly via a StackSet — exactly the "define once, deploy everywhere identically" requirement.
17. Q17 — A. Self-managed StackSets require manually creating and trusting the administration/execution IAM roles per target account; service-managed StackSets, once Organizations integration is enabled, handle that role setup automatically with no manual per-account step.
18. Q18 — A. Target tracking lets Auto Scaling manage the add/remove steps itself against a declared target value (the "thermostat" behavior for CPU at 50%); step scaling defines explicit, escalating step adjustments tied to alarm breach depth over time — exactly the "+2 then +4 more" behavior described.
19. Q19 — A. Lowering both the interval and the unhealthy threshold together shortens real-failure detection time while still requiring more than one consecutive bad check, which is what avoids a single transient blip causing a false failure.
20. Q20 — C. "Already running at full production scale, both regions live, minutes-not-hours failover" is multi-site active-active's exact definition — pilot light and warm standby both keep costs lower specifically by not running at full scale continuously, which is what the requirement explicitly rules out.
21. Q21 — C. Latency-based routing continuously routes each requester to whichever configured endpoint currently gives them the lowest measured network latency — the "fastest-responding region, continuously re-evaluated" behavior, distinct from a fixed weighted split or an active/passive failover policy.
22. Q22 — A. Multi-AZ is a same-Region synchronous standby for zero-data-loss local failover; Aurora Global Database is the purpose-built cross-region capability with typically sub-second asynchronous replication for DR — neither alone is both synchronous-zero-loss and cross-Region, so both are genuinely needed here.
23. Q23 — A. Cross-zone load balancing makes every load balancer node distribute traffic evenly across all registered targets in all enabled AZs, instead of only the targets local to that node's own AZ — directly correcting per-target imbalance caused by an uneven target count across AZs.
24. Q24 — A. Static stability means a system survives a specific failure mode without needing any control-plane API call during the event itself — pre-provisioning enough spread-out capacity to absorb an AZ loss with no real-time scaling action is the textbook example, since that scaling call could itself be affected by the very disruption it's reacting to.
25. Q25 — A. Setting StorageResolution to 1 on PutMetricData is what makes a custom metric high-resolution (1-second granularity) instead of the 60-second default — an explicit, per-metric setting, not automatic.
26. Q26 — B. A metric filter turns matching log lines into a CloudWatch metric data point (good for counting/alarming on a rate); a subscription filter instead streams the matching log events themselves, near-real-time, to a destination like Lambda — one produces a number, the other forwards events, and both are genuinely different CloudWatch Logs features despite the similar name.
27. Q27 — A. A subscription filter on each source account's log group, targeting a destination (commonly Kinesis Data Firehose) owned by the central account, with a destination access policy authorizing each source account, is CloudWatch Logs' own cross-account, near-real-time centralization mechanism — no manual export required.
28. Q28 — A. CloudWatch Anomaly Detection builds a statistical, time-of-day/day-of-week-aware expected band from a metric's own history, and an anomaly-detection alarm fires on deviation from that band rather than one fixed static threshold — directly solving the "normal varies by time of day" problem a static threshold can't.
29. Q29 — A. X-Ray sampling rules let you trace a configured rate (e.g., 1 request/second plus a percentage of the remainder) instead of every request, trading complete coverage for controlled cost and overhead while keeping a representative, statistically useful sample.
30. Q30 — A. A CloudWatch Logs log group's default retention is Never Expire — logs, and their storage cost, accumulate indefinitely until someone explicitly sets a retention period, a frequently missed step and a common source of surprise cost.
31. Q31 — B. A single CloudWatch dashboard can include widgets from multiple Regions (and, with the right permissions, multiple accounts) at once — each widget independently specifies its own source Region, so alarms, metrics, and Logs Insights results from different Regions can all sit on one dashboard.
32. Q32 — A. AWS Chatbot is the purpose-built two-way ChatOps integration: it forwards CloudWatch/EventBridge/SNS notifications into Slack or Chime, and separately lets scoped, IAM-bounded commands run from that same channel — neither SNS nor Incident Manager nor EventBridge alone provides that two-way command capability.
33. Q33 — A. An Incident Manager response plan is built specifically to coordinate chat-channel creation, a defined escalation/engagement chain, and runbook attachment as one structured incident; a plain SNS topic is well suited to simple fan-out notification but has no native escalation-chain or incident-structure concept.
34. Q34 — A. An input transformer on an EventBridge rule's target extracts specific fields from the matched event and substitutes them into a custom template, reshaping the payload before delivery — no intermediate Lambda function required just to reformat a message.
35. Q35 — A. The event pattern is the JSON structure matched against an incoming event's fields — here, filtering on the alarm source, detail-type, and specifically detail.state.value: ["ALARM"] to match only that one state transition and ignore every other event on the bus.
36. Q36 — A. An escalation plan defines a chain of contacts or channels, each with its own response-timeout window, that Incident Manager automatically progresses through when the current stage doesn't acknowledge in time — exactly the chained, timed behavior described.
37. Q37 — A. OpsCenter OpsItems give each postmortem corrective action a trackable, ownable, closeable work item with status and related-resource context — turning a postmortem document's action list into something the team actually revisits and closes out, rather than a paragraph nobody returns to.
38. Q38 — B. A KMS key's own key policy is the primary access-control gate and must explicitly allow the action — for a principal in a different account, it must name that external account/principal directly. The calling principal's IAM policy must also allow it; neither one alone is sufficient, which is the AND relationship the question is testing.
39. Q39 — A. A KMS grant is the narrow, temporary, programmatically issued and revocable permission mechanism — commonly issued by an AWS service like EC2/EBS on your behalf — distinct from a durable, hand-edited key policy statement, and exactly the tool for a scoped, service-issued permission rather than a broad standing grant.
40. Q40 — B. Outside the database engines Secrets Manager ships built-in rotation templates for, you author your own rotation Lambda implementing the four-step strategy (createSecret/setSecret/testSecret/finishSecret), calling the third-party API's own rotation mechanism inside it — Secrets Manager still provides the schedule and orchestration around your custom logic.
41. Q41 — A. S3 Protection and EKS Protection are separate, opt-in GuardDuty protection plans layered on top of the baseline VPC Flow Logs/DNS/CloudTrail analysis — each analyzing an additional data source (S3 data events, EKS audit logs respectively) and each enabled (and billed) independently of the baseline.
42. Q42 — A. A Config rule's remediation configuration attaches an SSM Automation document directly to the rule, with its own retry attempts and inter-attempt wait time, so Config triggers the fix natively on a NON_COMPLIANT evaluation — no separate hand-wired EventBridge rule needed for this specific rule-to-remediation case.
43. Q43 — B. A pipeline execution role broader than necessary is a distinct risk from developer access, because a developer with only "trigger this pipeline" permission can still cause damage far beyond their own IAM grant if the pipeline's own role can do more than the pipeline actually needs — the role, not the developer, is what executes the deployment.
44. Q44 — A. Security Hub is the aggregation and compliance-scoring layer — enabling a standard (CIS, FSBP, PCI DSS, etc.) turns on continuous automated checks against that standard's individual controls and computes a compliance score, pulling in findings from GuardDuty, Config, Inspector and other sources along the way.
45. Q45 — A, B. Naming the specific pipeline role's ARN (not the whole Account A account ID) as the trusted principal in the trust policy (A) stops any other Account A principal from assuming the role, and scoping the permissions policy to only what the deployment actually needs (B) limits the blast radius if it ever is misused — both are genuine least-privilege measures; deleting the permissions policy or trusting the whole account would each make the role either useless or far too broad.

After Set 5: what your score actually tells you

☺ Like you're 10: A strong score here means go book it. A weak score means go back to the one or two domains that dragged you down — not everything.

Because Set 5 is proportionally weighted and combines all three question styles, it's the one paper on this site whose result generalizes most directly to the real exam. Score comfortably above your target and your remaining prep should be logistics, not content: re-read No Docs Map — Closed Book so the closed-book constraint doesn't surprise you, confirm your registration details on the exam guide, and stop drilling new material inside the final 48 hours. Score below it, and the domain breakdown table above is your actual plan — re-read the specific blueprint pages you dropped points in, re-drill the matching sections of Set 1 through Set 4 for that domain specifically, and sit a fresh cold copy of this reasoning (not this exact paper — you've now seen it) against the service reference before you book anything.

Check your answers

1. Set 5 combines all three question styles (recall, scenario, confusable-pair) at the exam's real proportional domain weighting under the real 180-minute clock — none of Sets 1–4 do all three simultaneously, which is exactly why a Set 5 result maps more directly onto real-exam readiness than any single earlier paper's narrower score does.
2. Because this paper is built entirely from the denser scenario and confusable-pair styles rather than a mix that also includes fast recall questions the way the real 75-question exam does — so per-question reading naturally runs slower. The spare time belongs to a genuine read-twice habit, a flag-and-return protocol for stalled questions, and an actual final verification sweep, not to finishing early.
3. A key policy statement is a durable, hand-edited, standing access-control entry directly on the key; a KMS grant is a temporary, narrowly-scoped, programmatically issued and revocable permission, commonly created by an AWS service on your behalf for one specific, limited purpose.
4. Elasticity is about adding or removing capacity in response to changing demand — a normal, ongoing, healthy behavior. Static stability is specifically about having already provisioned enough spread-out capacity that surviving one failure mode (losing an AZ) requires zero real-time API calls at all, precisely because those calls might themselves be degraded during the very disruption they'd be reacting to.
5. Because the trigger — a specific Config rule evaluating a resource as NON_COMPLIANT — and the fix are both already inside AWS Config's own remediation-configuration feature, complete with built-in retry attempts and wait time between them. Hand-wiring an EventBridge rule to route the compliance-change event to a separate SSM Automation execution reproduces the same outcome with more moving parts to maintain, when the native mechanism already does the job for exactly this rule-to-remediation shape.

That's the full five-paper set. If today's score cleared your target, the next page you read shouldn't be another practice paper — it should be the exam guide's registration checklist. If it didn't, the domain table above already told you where to go next. Either way, the glossary, the flashcards, and the exam simulator stay useful right up to the day you sit the real thing.