Mock Exam · Set 2
This is the second of five full-length DOP-C02 practice papers on this course, and it changes exactly one thing about the format: the questions. Same seventy-five-question shape as Set 1 — 65 scored, 10 unscored, weighted to the same official domain percentages (22/17/15/15/14/17%), sat in one unbroken 180-minute block — but where Set 1 mostly asked "which service does this," every question below drops you into a small, multi-service AWS scenario and asks you to pick the best of several answers that all sound plausible on a first read. That's a harder, and more honest, rehearsal: the real DOP-C02 essentially never asks "what is CodeDeploy" in isolation. It describes a pipeline, a fleet, an incident, or an audit requirement spanning two or three services at once, and makes you decide which one actually solves the stated problem.
Set 1 was a vocabulary quiz — "what does this word mean." Set 2 is a word-problem quiz — "here's a whole little story about a train, a station, and a delayed passenger; now figure out which fact actually answers the question." The words you learned for the vocabulary quiz are all still in the story, but they're buried in details that don't matter, sitting next to one detail that changes the entire answer. Reading fast and confident got you through Set 1. Reading carefully is the only thing that gets you through Set 2 — which, uncomfortably, is also the only thing that gets you through the real exam.
How Set 2 differs from Set 1
☺ Like you're 10: Set 1 tested whether you know each tool by name. Set 2 hands you a situation with three tools already in the room and asks which one actually does the job — which is a different, harder skill.
Structurally, Set 1 and Set 2 are twins: the same six domains in the same 22/17/15/15/14/17% proportions, the same 65-scored-plus-10-unscored split, the same 180-minute clock, and the same 750/1000 scaled pass mark from the DOP-C02 exam guide. What changes is the shape of the question itself. A Set 1 stem asked a fact directly — "which CodeBuild phase installs dependencies." A Set 2 stem describes a working system with a stated symptom or requirement — a pipeline deploying across accounts, a database that needs to fail over in minutes not hours, an alarm that has to reach a chat channel and an incident response plan — and every one of the four answer choices names a real, existing AWS capability. Usually two or three of those four are things you'd genuinely use in some context; only one of them is the right tool for this context, given the specific numbers, verbs, and constraints buried in the scenario. That's deliberately closer to how AWS's own professional-level exams actually read than Set 1 was on purpose — see answer triage & elimination for the technique this paper is built to drill.
This is Set 2 of five — see Set 1, Set 3, and Set 4 for the others, and the DOP-C02 study plan for how to sequence all five against your remaining prep time. Sit this one only after Set 1 feels comfortable — if you're still missing a third of Set 1's direct recall questions, a scenario paper will bury that same gap one layer deeper rather than fixing it. If Set 1 went well, this is the paper that tells you whether that knowledge actually transfers under the exam's real conditions.
Sit it like the real thing
☺ Like you're 10: Same rules as Set 1 — no notes, no open tabs, one sitting, guess rather than leave a blank — but read every scenario twice before you touch an answer, because the sentence that matters is easy to skim past the first time.
The DOP-C02 exam is fully closed-book: no notes, no browser tab, no this course, no colleague, no AI assistant, once the clock starts. Sit this paper under that same restriction — see the closed-book map for exactly what that discipline means in practice. AWS scores an unanswered question as incorrect with no extra penalty for a wrong guess, so the strategy is unchanged from Set 1: never leave a question blank. Use answer triage & elimination to rule out the choices that fail for a structural reason, then commit to your best remaining option.
One habit matters more here than it did on Set 1: read the scenario twice before you look at the options. A scenario question almost always contains one clause doing all the work — a number ("within five minutes"), a constraint ("without any custom Lambda code"), or a negative ("without a human approval step") — and skimming past it on a first read is exactly how a plausible-sounding wrong answer wins. Reading twice costs you fifteen seconds; picking the wrong service because you missed one clause costs you the whole question.
The 75-question count, the 65/10 scored/unscored split, the 180-minute duration, the 750/1000 scaled passing score, and the six domain weights all reflect AWS's own DOP-C02 exam guide at a point in time, the same ones documented in full in the DOP-C02 exam guide. AWS revises exam formats and passing scores without much notice — this exam has already been revised once, from DOP-C01 to DOP-C02. Confirm the current specifics on AWS's own DOP-C02 exam page before you register for the real thing.
Your 180-minute budget
☺ Like you're 10: Same clock as Set 1, but budget a little more thinking time per question here — a two-sentence story takes longer to read carefully than a one-line fact does.
Seventy-five questions in 180 minutes still averages 2.4 minutes each, but scenario stems run longer than Set 1's direct-recall ones, so expect the first read-through of some questions to eat closer to 40–50 seconds before you've even looked at an option. The block structure is unchanged from Set 1 — five 33-minute blocks of fifteen questions, plus a 15-minute review sweep at the end — because the pacing discipline that structure teaches doesn't change just because the questions got harder to read.
If a question runs past about two and a half minutes without you being confident, apply the same flag-and-guess discipline as Set 1: eliminate what you can, commit to your best remaining option, and move on. Each question's explanation sits directly underneath it — don't open it before you've committed to an answer.
The paper — 75 questions in exam order
☺ Like you're 10: Seventy-five little stories, five blocks of fifteen, every domain mixed into every block — read the whole story once, read it again, then pick.
Each question is tagged with its domain in parentheses, exactly as in Set 1, so you can total your score by domain afterward — and, exactly as in Set 1, you won't get that label on the real exam. A handful of questions below are marked (Select TWO), matching the real exam's multiple-response format — full credit requires both correct letters, exactly as AWS scores it. Ten of these seventy-five are this paper's unscored, unidentified pretest stand-ins, scattered through the sitting exactly like the real exam's — you won't find out which until Score yourself, because on exam day you never find out at all.
Block 1 — Q1–15 (minutes 0–33)
Q1 (Domain 1 — SDLC Automation). A central tooling account runs a CodePipeline that builds an application and deploys it into three separate production AWS accounts. The pipeline's artifact bucket in the tooling account is encrypted with a customer-managed KMS key, and each production account assumes a cross-account IAM role to pull the build artifact during its deploy stage. Deployments to two of the three accounts succeed; the third fails with a KMS access-denied error during artifact decryption. What is the most likely cause?
- A. The failing account's Region doesn't support KMS
- B. The KMS key's key policy doesn't grant decrypt permissions to that account's specific deployment role, even though the pipeline's own IAM policy allows it
- C. CodePipeline artifacts can only ever be shared with exactly two accounts
- D. The S3 artifact bucket needs to be made public for the third account to reach it
Check the answer
B. A customer-managed KMS key's key policy is the actual source of truth for cross-account access — an IAM policy in the calling account granting kms:Decrypt isn't sufficient by itself if the key's own policy doesn't separately name that account's role as a permitted principal. Since two of three accounts work fine, the pipeline and bucket configuration are clearly not the problem, which rules out A, C, and D — the difference has to live in that one role's presence (or absence) in the key policy.
Q2 (Domain 2 — Configuration Management & IaC). A platform team uses a CloudFormation StackSet with service-managed permissions to deploy a baseline logging configuration to every account in an Organizations OU, with automatic deployment enabled for new accounts. During a recent rollout to 60 target accounts, 4 accounts failed and the operation stopped propagating to the remaining accounts, even though those remaining accounts had no relationship to the 4 failures. What StackSet setting controls this stop-on-failure behavior, and how should it be adjusted to tolerate a small number of expected failures without halting the whole rollout?
- A. Nothing can be adjusted; StackSets always halts entirely on any single account failure
- B. Increase
FailureToleranceCount(orFailureTolerancePercentage) so a bounded number of account failures is tolerated before the operation stops, and tuneMaxConcurrentCount/MaxConcurrentPercentageto control rollout speed independently - C. Switch to self-managed permissions, which removes all failure-tolerance behavior
- D. Delete and recreate the StackSet after every partial failure
Check the answer
B. Operation preferences on a StackSet include a failure tolerance (count or percentage) that governs how many target-account failures are acceptable before the whole operation stops propagating, independent of the concurrency settings that control how many accounts deploy in parallel. Tuning fault tolerance directly addresses "a small number of expected failures," which A and C wrongly claim is impossible to configure.
Q3 (Domain 6 — Security & Compliance). An application in a private subnet needs to read and write objects in Secrets Manager, but the VPC has no NAT Gateway and the security team's policy explicitly forbids adding one, citing cost and the desire to keep the subnet fully isolated from the public internet. Which approach lets the application reach Secrets Manager without violating that constraint?
- A. Create a VPC interface endpoint (AWS PrivateLink) for Secrets Manager, with an endpoint policy scoping which principals and actions are allowed, and route the application's calls through it
- B. Temporarily allow a NAT Gateway "just for this one service"
- C. Move the application to a public subnet with a public IP
- D. Hardcode the secret values as environment variables to avoid calling Secrets Manager at all
Check the answer
A. An interface VPC endpoint creates a private, PrivateLink-backed path from the VPC directly to the Secrets Manager API, with no internet egress or NAT Gateway required at all, and an endpoint policy can further restrict which principals and actions are permitted through it. B contradicts the stated policy outright, C removes the isolation the team explicitly wants, and D reintroduces exactly the hardcoded-secret risk Secrets Manager exists to eliminate.
Q4 (Domain 3 — Resilient Cloud Solutions). A globally distributed application's relational database must support cross-Region failover completing in under a minute, with writes always going to a single current primary and reads scalable across multiple Regions in normal operation. A standard Multi-AZ deployment with cross-Region read replicas is proposed. Which limitation makes that combination fail the stated failover-time requirement, and what should replace it?
- A. Nothing is wrong; Multi-AZ plus cross-Region read replicas already meets the requirement as described
- B. Promoting a standard cross-Region read replica to primary is a manual, asynchronous-replication-dependent operation that typically takes minutes, not seconds — Aurora Global Database's managed cross-Region failover, designed for typically under a minute, is the fit for this stated requirement
- C. DynamoDB Global Tables should replace the relational database entirely, since only DynamoDB supports cross-Region failover
- D. RDS Multi-AZ standbys are themselves already located in a different Region by default
Check the answer
B. A standard cross-Region read replica's promotion to primary is a manual action against an asynchronously-replicated copy, with no guaranteed sub-minute completion — it's built for read scaling and DR, not fast automated cross-Region failover. Aurora Global Database is purpose-built for that specific requirement, with a managed failover path designed to complete in about a minute. D is simply false — a Multi-AZ standby lives in a different AZ within the same Region, not a different Region.
Q5 (Domain 4 — Monitoring & Logging). A checkout service behind an Application Load Balancer occasionally has healthy-looking CPU and memory, but customers report timeouts. The on-call team wants a single CloudWatch alarm that only enters ALARM — and therefore only pages anyone — when both the ALB's TargetResponseTime p99 is elevated and the ALB's HTTPCode_Target_5XX_Count is simultaneously non-zero, since either signal alone is too noisy to page on by itself. Which CloudWatch construct is built for exactly this "both must be true" condition across two separate underlying alarms?
- A. A single alarm on a metric math expression that simply adds the two raw metrics together
- B. A composite alarm whose rule expression combines the two underlying alarms' ALARM states with AND logic
- C. Two separate alarms, each independently notifying the same SNS topic
- D. A CloudWatch dashboard widget showing both metrics on the same graph
Check the answer
B. A composite alarm evaluates a Boolean rule expression over the ALARM/OK states of other alarms, so an AND rule over the latency alarm and the 5xx-count alarm pages only when both conditions are simultaneously true — exactly the noise-reduction the team wants. C would still page on either signal alone, which is the noisy behavior the team is trying to eliminate, and A conflates two unrelated units (a time and a count) into one meaningless summed number.
Q6 (Domain 1 — SDLC Automation). A CodeBuild project builds a multi-stage Docker image and pushes it to ECR. Build times have crept from 3 minutes to 14 minutes as the dependency layer has grown, because every build re-downloads the same unchanged base-image layers and re-installs the same unchanged package list from scratch. The team wants the shortest path to meaningfully faster builds without restructuring their entire CI process. Which combination most directly addresses the repeated work?
- A. Increase the CodeBuild project's compute type to the largest available instance size
- B. Enable CodeBuild's Docker layer caching (local or registry-based) and order the Dockerfile so rarely-changing layers (base image, dependency install) come before frequently-changing layers (application code), so unchanged layers are reused instead of rebuilt
- C. Switch the source provider from CodeCommit to a different Git host
- D. Add a manual approval action before the build stage to slow down how often builds run
Check the answer
B. Docker layer caching persists previously built layers between builds, and a Dockerfile ordered so stable layers (base image, dependency installs) come before volatile ones (application code) means Docker only rebuilds the layers that actually changed — directly eliminating the redundant re-download and re-install work described. A larger compute type (A) speeds up computation generally but does nothing about redundant network and install work being repeated every single time; C and D don't touch the caching problem at all.
Q7 (Domain 5 — Incident & Event Response, Select TWO). A team wants a CloudWatch alarm on PaymentFailureRate to, the instant it enters ALARM state, both (1) start a formal Systems Manager Incident Manager incident using a predefined response plan with an on-call escalation chain, and (2) post a message into a specific ChatOps channel via a custom-formatted Lambda function that includes a link to the relevant runbook. Which TWO statements correctly describe how to wire this, given that a CloudWatch alarm's own native action list is short and fixed?
- A. Starting an Incident Manager incident is on the alarm's native, fixed action list, so that half of the requirement can be configured directly on the alarm with no EventBridge rule needed
- B. Invoking an arbitrary Lambda function is not on the alarm's native action list — reaching the custom ChatOps Lambda requires routing the alarm's state-change event through a separate EventBridge rule matching
source: aws.cloudwatch,detail-type: CloudWatch Alarm State Change - C. Both behaviors can be configured directly on the alarm with no EventBridge rule involved at all, since every alarm can invoke any Lambda function natively
- D. Neither behavior is possible without a custom Lambda function performing both actions from scratch
- E. EventBridge rules cannot target Lambda functions, so the ChatOps posting must go through SNS instead
Check the answer
A and B. A CloudWatch alarm's native action list includes EC2 actions, Auto Scaling actions, SNS notifications, creating an OpsItem, and starting an Incident Manager incident — so A is correct and needs no EventBridge rule. Invoking an arbitrary Lambda function isn't on that list, so the ChatOps posting has to be reached by routing the alarm's state-change event through an EventBridge rule instead, making B correct. C and D both misstate the alarm's native capabilities, and E is false — EventBridge rules can target Lambda functions directly.
Q8 (Domain 2 — Configuration Management & IaC). A platform team stores hundreds of configuration values under Systems Manager Parameter Store paths like /prod/billing/db-host, /prod/billing/feature-flags, and /prod/checkout/db-host, and wants each application team to be able to read and write only the parameters under their own service's path — the billing team should never be able to modify a checkout parameter, and vice versa — without creating a separate IAM policy by hand for every new parameter added. Which approach scales cleanly as new parameters are added under an existing path?
- A. One IAM policy per parameter, updated manually every time a new parameter is created
- B. A single IAM policy per team using a wildcarded resource ARN matching that team's path prefix (e.g.,
arn:aws:ssm:*:*:parameter/prod/billing/*), so any new parameter created under that prefix is automatically covered - C. One shared IAM role with access to the entire
/prod/*hierarchy, trusting each team to self-police - D. Store all configuration values in a single flat parameter with no hierarchy, encoded as one large JSON blob
Check the answer
B. IAM policies support wildcards in resource ARNs, so scoping a policy to a path prefix with a trailing * automatically extends to any parameter later created under that prefix — no policy edit needed per new parameter, while still keeping billing's and checkout's paths, and therefore their access, cleanly separated. A doesn't scale by design; C abandons least privilege entirely; D loses the path-based isolation the scenario explicitly wants.
Q9 (Domain 3 — Resilient Cloud Solutions, Select TWO). A team is evaluating DynamoDB Global Tables for an order-processing table that needs to accept writes in both a US Region and an EU Region simultaneously, with each Region's application unaware of the other's writes until replication catches up. Which TWO statements about DynamoDB Global Tables (version 2019.11.21 or later) are accurate?
- A. Every replica table is fully writable, and the service uses a last-writer-wins reconciliation approach (based on internal timestamps) to resolve conflicting concurrent writes to the same item across Regions
- B. DynamoDB Streams must be enabled on the table, since Global Tables uses the stream to propagate changes to other replicas
- C. Only one Region may accept writes at a time; all other replicas are strictly read-only until a manual failover is triggered
- D. Global Tables requires the application to manually resolve every conflicting write itself before it's accepted
- E. Replication between Regions is fully synchronous, so a write isn't acknowledged to the client until every replica Region has confirmed it
Check the answer
A and B. Global Tables is genuinely multi-Region active-active — every replica accepts writes, with last-writer-wins conflict resolution handling concurrent writes to the same item — and it relies on DynamoDB Streams under the hood to propagate those changes between replica tables. C describes a single-primary failover model, which is not how Global Tables works; D is false, since conflict resolution is automatic, not manual; E is false, since replication across Regions is asynchronous, not synchronous — a synchronous requirement would defeat the low-latency, multi-Region-write design entirely.
Q10 (Domain 6 — Security & Compliance, Select TWO). An application's EC2 instance role needs to decrypt objects using a customer-managed KMS key that a separate security team owns and administers. The security team wants to grant this access without directly editing the KMS key's policy document for every new consuming role that shows up over time. Which TWO statements about achieving this are correct?
- A. If the key policy includes the standard "Enable IAM User Permissions" statement delegating authorization to IAM, the security team can grant
kms:Decryptto the EC2 role via a normal IAM identity-based policy, with no key policy edit needed for that specific role - B. A KMS grant can be created programmatically to delegate a specific, often temporary, set of permissions (like
Decrypt) on the key to a principal, without modifying the key policy document itself - C. KMS key policies can never delegate any authorization to IAM under any circumstance
- D. Every single new consuming role always requires a direct edit to the key policy document, with no alternative mechanism available
- E. IAM policies are completely ignored for all KMS actions regardless of the key policy's contents
Check the answer
A and B. When a key's policy includes the default IAM-delegation statement, ordinary IAM policies attached to a role can grant that role KMS actions without ever touching the key policy — solving exactly the "new role shows up often" scaling problem. Grants (B) are the other mechanism for the same goal: temporary, revocable, programmatic delegation without editing the key policy document. C, D, and E each contradict how KMS authorization actually layers IAM and the key policy together.
Q11 (Domain 1 — SDLC Automation). An ECS service is deployed using "deploymentController": {"type": "CODE_DEPLOY"}, two target groups behind an ALB, and a CodeDeploy deployment group configured with CodeDeployDefault.ECSCanary10Percent5Minutes and a CloudWatch alarm monitoring the new task set's 5xx rate. Ten minutes into a deployment, the alarm enters ALARM. What happens by default, and why is this different from what would happen with a plain ECS native rolling update under the same conditions?
- A. Nothing happens automatically in either case; both require a human to notice and intervene manually
- B. CodeDeploy automatically stops the deployment and shifts traffic back to the original (still-running) task set — a routing-level rollback possible because CodeDeploy's blue/green mechanism never tore down the original task set. A native ECS rolling update has no CodeDeploy-style automatic-rollback-on-alarm concept and would need a separately configured mechanism to react the same way
- C. ECS automatically terminates the entire service in both cases
- D. The alarm has no effect on the deployment at all; alarms attached to a CodeDeploy deployment group are purely informational
Check the answer
B. With an alarm attached to the deployment group and automatic rollback enabled, CodeDeploy's ECS blue/green flow reacts to an ALARM state by routing traffic back to the original task set, which was deliberately kept running rather than torn down — a fast, routing-only rollback. A plain ECS native rolling update replaces tasks in place with no second task set to route back to, so it has no equivalent mechanism unless one is built separately (for example, via a CloudWatch alarm driving a manual or scripted redeploy).
Q12 (Domain 4 — Monitoring & Logging). A team has instrumented a high-traffic API with X-Ray and is now seeing their per-trace ingestion cost climb sharply as request volume grows, while still wanting to reliably capture every request that returns an error or an unusually high latency. Which X-Ray capability lets them reduce overall trace volume and cost while preserving visibility into the requests that actually matter?
- A. Disabling X-Ray entirely and relying only on CloudWatch metrics
- B. A custom X-Ray sampling rule that reduces the sampling rate for routine, healthy requests while still capturing a fixed rate (or all) of requests matching error or high-latency conditions
- C. Reducing the Lambda or ECS task's memory allocation, which automatically reduces X-Ray costs
- D. Switching every service to CloudTrail instead of X-Ray, since CloudTrail captures the same per-request timing data at lower cost
Check the answer
B. X-Ray sampling rules let you define reservoir and rate parameters per matched request pattern, so routine traffic can be sampled at a low rate to control cost while rules can be layered or application code can force-sample error/high-latency requests to ensure the traces that matter most are always captured. D is a common wrong-answer trap: CloudTrail records management/data-plane API activity, not per-request application latency — it cannot substitute for a trace at all.
Q13 (Domain 5 — Incident & Event Response). A team wants a production CloudWatch alarm's state change to post directly into a specific Slack channel as a nicely formatted message — including the alarm name, the current metric value, and a clickable link back to the CloudWatch console — without writing and maintaining a custom Lambda function to build and send that formatted message. Which AWS service is purpose-built for this integration?
- A. AWS Chatbot, configured for the target Slack workspace/channel and subscribed to the SNS topic the alarm action publishes to
- B. Amazon Pinpoint, sending an SMS to the on-call phone
- C. Amazon Connect, routing the event into a contact center queue
- D. AWS Systems Manager Session Manager, opening a shell session in the Slack channel
Check the answer
A. AWS Chatbot integrates natively with Slack and Chime, subscribing to an SNS topic; when the alarm's action publishes to that topic, Chatbot automatically formats and posts a structured notification — including the alarm name, state, and a console link — with no custom formatting code required. B, C, and D each name a real AWS service doing something unrelated to formatted chat notifications.
Q14 (Domain 2 — Configuration Management & IaC). An Elastic Beanstalk environment is deployed via .ebextensions configuration files bundled in the application source, which correctly configure the environment at deploy time. Three weeks after the last deployment, an engineer manually edits a configuration option directly in the Elastic Beanstalk console, and it silently drifts back to the old value a few days later with no one touching it again. What most likely explains the drift reverting on its own, and what should the team use instead to enforce an ongoing configuration state outside of deploy-time changes?
- A. Elastic Beanstalk deployments are the only mechanism that ever changes configuration, so this scenario is impossible
- B. Managed platform updates or environment health checks periodically reconcile configuration against the environment's saved configuration, which still reflects the original
.ebextensionsvalues — for continuous, out-of-band configuration enforcement independent of deploys, Systems Manager State Manager associations are the better fit - C. CloudFormation drift detection automatically reverts any manual console change within Elastic Beanstalk
- D. The AWS root account periodically resets all Beanstalk environments to their original state as a security measure
Check the answer
B. Elastic Beanstalk's own environment configuration (driven by its saved configuration, which .ebextensions feeds at deploy time) can reassert itself independent of a one-off manual console tweak — the config was never actually changed at the source. For genuinely continuous, out-of-band configuration enforcement decoupled from the deploy pipeline, Systems Manager State Manager associations that reapply a desired state on a schedule are the purpose-built tool, rather than relying on Beanstalk's own reconciliation behavior. C and D describe mechanisms that don't exist as stated.
Q15 (Domain 1 — SDLC Automation). A CodePipeline deploys to production only after a specific named engineer manually reviews and approves the change in the console, and the team wants that engineer notified the moment their approval is needed rather than having to poll the console. Which combination implements this cleanly within CodePipeline itself?
- A. A CodeBuild project that polls the pipeline's state every 30 seconds and emails the engineer
- B. A manual approval action configured with an SNS topic notification, so the engineer is notified the instant the pipeline reaches that action and pauses awaiting a decision
- C. A second, separate pipeline that watches the first pipeline's status
- D. A stage transition permanently disabled until someone remembers to re-enable it manually
Check the answer
B. A manual approval action natively pauses pipeline execution at that point and can publish to an SNS topic the moment it's reached, notifying subscribers that a decision is awaiting them — a first-class CodePipeline feature requiring no polling or custom glue.
Block 2 — Q16–30 (minutes 33–66)
Q16 (Domain 6 — Security & Compliance). A compliance team needs the same set of encryption and tagging rules enforced consistently across every account in a 200-account Organizations OU, with a single aggregated compliance score visible centrally, and wants new accounts joining the OU to inherit the rules automatically with no manual setup per account. Which AWS Config feature is purpose-built for this?
- A. A single Config rule deployed by hand into each of the 200 accounts individually
- B. A Config conformance pack deployed via an Organization-level StackSet, which aggregates a compliance score and can auto-deploy to new accounts as they join the OU
- C. AWS Trusted Advisor, since it automatically enforces custom organizational rules
- D. A shared spreadsheet tracking which rules are supposedly enabled in which account
Check the answer
B. An Organization conformance pack is deployed once and propagates to every account in the target OU, including automatically to new accounts that join later, with an aggregated compliance score visible from the management or delegated administrator account — precisely the "consistent, centrally-visible, auto-inherited" requirement described. A does not scale to 200 accounts by design, and Trusted Advisor doesn't support arbitrary custom compliance rules the way Config does.
Q17 (Domain 1 — SDLC Automation). An organization's CodeBuild projects across a dozen teams currently pull npm packages directly from the public registry, which has caused intermittent build failures during public registry outages and makes it hard to guarantee every team is using an approved, scanned version of a given package. Which AWS service addresses both problems — availability and governance — with one piece of infrastructure?
- A. Amazon S3 with versioning enabled, storing a manual copy of each package
- B. AWS CodeArtifact, configured with an upstream connection to the public npm registry so packages are cached locally on first use, giving every team a consistent, governed source that keeps working even if the public registry is briefly unreachable
- C. Amazon ECR, since it can also store npm packages
- D. AWS CodeCommit, storing package tarballs as committed files
Check the answer
B. CodeArtifact's upstream repository feature caches packages fetched from a configured upstream (like the public npm registry) the first time they're requested, so subsequent builds reuse the cached copy — improving availability during a registry outage — while giving the organization one governed, centrally-visible source of truth for exactly what package versions are in use. ECR (C) is built for container images and OCI artifacts, not general-purpose language package formats like npm.
Q18 (Domain 4 — Monitoring & Logging). A team's checkout service logs a structured JSON line per request, including a statusCode field. They need to compute, over the last hour, the percentage of requests that returned a 5xx status, without exporting the logs to a separate analytics system first. Which tool lets them run this as an ad hoc, interactive query directly against the existing log groups?
- A. CloudWatch Logs Insights, using a query with
filter,stats count(), and a computed percentage expression - B. AWS Config, using a custom rule evaluated against log data
- C. AWS X-Ray, using the service map's error-rate percentage
- D. VPC Flow Logs, since HTTP status codes are captured there by default
Check the answer
A. CloudWatch Logs Insights is purpose-built for exactly this: interactive queries directly against existing log groups with no separate export or ETL step, including stats aggregations that can compute a percentage from filtered counts. X-Ray's service map (C) does show aggregate error rates for traced services, but only for instrumented calls it traces, not an arbitrary field parsed from raw structured logs — and it wouldn't be the direct answer to "query the logs I already have."
Q19 (Domain 2 — Configuration Management & IaC). A CloudFormation template needs to provision a resource in a third-party SaaS product that has no native CloudFormation resource type — for example, registering a webhook in an external monitoring tool as part of stack creation, and deregistering it automatically on stack deletion. Which CloudFormation feature supports arbitrary logic like this as part of the stack lifecycle?
- A. A stack output exporting a value for other stacks to import
- B. A custom resource backed by a Lambda function, which CloudFormation invokes on Create, Update, and Delete and which can call any external API needed, including cleanup on stack deletion
- C. A CloudFormation mapping block
- D. A parameter with a default value
Check the answer
B. A custom resource is exactly the extension point CloudFormation provides for logic it has no native resource type for — the backing Lambda function receives Create/Update/Delete lifecycle events and can call any external API, including the cleanup call needed on stack deletion, which is the part of the scenario a simpler mechanism like an output or mapping has no way to express at all.
Q20 (Domain 5 — Incident & Event Response, Select TWO). GuardDuty raises a high-severity finding indicating an EC2 instance is communicating with a known command-and-control domain. The security team wants this to, within seconds and without human approval, (1) automatically isolate the instance's network access, and (2) create a corresponding finding visible in their centralized Security Hub dashboard for tracking. Which TWO statements correctly describe how this automated pipeline is typically built?
- A. GuardDuty findings are automatically forwarded to Security Hub once the GuardDuty–Security Hub integration is enabled, satisfying the tracking requirement with no additional custom logic needed
- B. An EventBridge rule matching GuardDuty finding events (filtered by finding type or severity) can target a Lambda function or SSM Automation document that modifies the instance's security group to isolate it — the standard fully-automated remediation pattern
- C. GuardDuty automatically isolates any instance mentioned in a finding with zero configuration required
- D. Security Hub can only display findings that were manually re-typed into it by a human analyst
- E. Network isolation requires deleting and recreating the entire VPC
Check the answer
A and B. Once the native GuardDuty–Security Hub integration is enabled, GuardDuty findings flow into Security Hub automatically, covering the tracking half of the requirement with no custom code. The automated isolation half needs an EventBridge rule watching for the relevant GuardDuty finding events, targeting a Lambda function or SSM Automation document that performs the actual security-group change — GuardDuty itself only detects and reports, it never takes remediation action on its own, which is exactly what C incorrectly claims.
Q21 (Domain 3 — Resilient Cloud Solutions). An application serves users from a primary Region under normal conditions, with a fully provisioned, ready-to-serve standby environment in a second Region. Route 53 needs to send 100% of traffic to the primary while it's healthy, and switch 100% of traffic to the secondary automatically, with no manual DNS change, the moment the primary's health check fails. Which Route 53 routing policy is designed for exactly this active-passive behavior?
- A. Weighted routing, split 90/10 between primary and secondary at all times
- B. Failover routing, with a health check associated to the primary record and the secondary record configured as the failover target
- C. Geolocation routing, based on the requester's location
- D. Multivalue answer routing, returning up to eight healthy records at random
Check the answer
B. Failover routing is purpose-built for active-passive: a health check tied to the primary record automatically shifts all traffic to the designated secondary the moment the primary is deemed unhealthy, with no ongoing traffic sent to the secondary while the primary is healthy. Weighted routing (A) always sends some traffic to both regardless of health, which contradicts the "100% to primary while healthy" requirement.
Q22 (Domain 1 — SDLC Automation). A CodePipeline's production deploy stage needs conditional logic more complex than a single manual approval — it must check the current time against a defined change-freeze window, verify a separate change-management ticket is in an approved state via an external API call, and only then proceed, retrying the ticket check with backoff if the external system is temporarily unavailable. Which approach lets the pipeline invoke this multi-step, stateful orchestration logic as one integrated stage?
- A. A single CodeBuild project running a shell script with no error handling
- B. A CodePipeline stage that invokes an AWS Step Functions state machine encoding the freeze-window check, the ticket-status check with retry/backoff, and the branching logic, reporting success or failure back to the pipeline
- C. A manual approval action alone, with a human performing all the checks by memory
- D. Splitting the logic across five separate CodeBuild projects with no coordination between them
Check the answer
B. Step Functions is designed for exactly this shape of problem — multi-step, stateful orchestration with built-in retry, backoff, and branching — and CodePipeline supports invoking a state machine as an action, with the pipeline continuing or failing based on the execution's outcome. A lacks the retry/backoff and branching Step Functions provides natively; C reintroduces the human-error risk the team is explicitly trying to remove by automating the checks.
Q23 (Domain 6 — Security & Compliance). A security team in a 50-account AWS Organization wants one consolidated view of Security Hub findings across every member account, without logging into each account individually, and wants new accounts joining the Organization to be automatically included in that consolidated view. Which setup achieves this?
- A. Manually forwarding a CSV export from each account's Security Hub console on a weekly schedule
- B. Enabling AWS Organizations integration for Security Hub with a delegated administrator account, which automatically aggregates findings from all member accounts (including new ones that join) into that administrator's consolidated view
- C. Creating 50 separate IAM users, one per account, and checking each dashboard by hand
- D. Security Hub findings cannot be aggregated across accounts under any configuration
Check the answer
B. Security Hub's Organizations integration lets a delegated administrator account automatically aggregate findings from every member account, including accounts that join the Organization later — a single console for the whole estate with no manual, per-account collection step.
Q24 (Domain 2 — Configuration Management & IaC). An operations team's Systems Manager Automation runbook for patching a fleet includes a step that installs OS patches, followed by a step that reboots the instance, followed by a step that runs a health check. They want to add a safety gate so that if the health check step fails, the runbook automatically attempts a rollback to the pre-patch state, but only after a specific on-call engineer explicitly approves that rollback step, rather than it firing unattended. Which SSM Automation capabilities together implement this?
- A.
aws:branchto route execution based on the health check's outcome, combined with anaws:approvestep gating the rollback branch specifically, so the rollback only proceeds after the named approver signs off - B. Systems Manager Run Command alone, since it supports conditional branching and approval gates natively
- C. A second, entirely separate runbook manually started by the engineer with no connection to the first
- D. AWS Config remediation actions, since they support multi-step conditional branching with approval gates
Check the answer
A. SSM Automation's aws:branch action step routes execution to different subsequent steps based on an input condition (here, the health check's result), and aws:approve pauses execution at that step until a named approver (or member of an approved group) signs off — chaining them delivers exactly the "branch to rollback, but gate it on approval" behavior described. Run Command (B) executes one ad hoc command or script with no orchestration, branching, or approval-gate concept at all, which rules it out immediately.
Q25 (Domain 4 — Monitoring & Logging). A security investigation needs to determine whether a specific internal IP address attempted to reach a known-malicious external IP over the past 72 hours, including the exact ports and byte counts involved, across an entire VPC with dozens of subnets. Flow Logs are already enabled and delivered to S3. Which approach lets the team query that historical data efficiently without manually scanning every log file?
- A. Downloading every Flow Logs file and grepping through them locally one at a time
- B. Using Amazon Athena with a table defined over the S3 location where Flow Logs are delivered, running a SQL query filtered by source/destination IP and time range
- C. AWS X-Ray, since it captures all network-level traffic automatically
- D. CloudTrail Insights, since it detects unusual network traffic patterns
Check the answer
B. Athena can query Flow Logs data delivered to S3 directly via SQL, filtering by IP address, port, and time range across the entire log volume without downloading or manually scanning files — the standard pattern for ad hoc historical network-forensics queries at scale. X-Ray (C) traces instrumented application requests, not raw IP-level network traffic, and wouldn't see this activity at all.
Q26 (Domain 1 — SDLC Automation). A team deploys a serverless application using a SAM template that includes a Lambda function and an API Gateway. They want production deployments to shift traffic gradually — 10% to the new version immediately, then the rest after 10 minutes if a specified CloudWatch alarm hasn't fired — and roll back automatically on failure, all defined declaratively in the SAM template itself rather than as a separate manually-configured CodeDeploy setup. Which SAM template feature provides this?
- A. A plain
AWS::Serverless::Functionresource with no additional configuration, since Lambda always shifts traffic gradually by default - B. The SAM
DeploymentPreferenceproperty on the function, referencing a CodeDeploy deployment configuration such asCanary10Percent10Minutesalong with anAlarmslist for automatic rollback - C. A separate, manually maintained CodeDeploy application and deployment group configured entirely outside the SAM template
- D. API Gateway's built-in canary release feature, which SAM cannot reference at all
Check the answer
B. SAM's DeploymentPreference property lets a function declare a CodeDeploy-managed traffic-shifting strategy (Canary, Linear, or AllAtOnce configurations) plus an alarm list for automatic rollback, entirely within the template — SAM provisions the underlying CodeDeploy application and deployment group for you at deploy time, which is exactly what makes this declarative rather than a separately hand-configured setup like C.
Q27 (Domain 5 — Incident & Event Response). In a multi-account organization, a centralized security account needs to run an SSM Automation document that remediates a misconfigured security group in a member account, triggered by an EventBridge rule in that member account forwarding events to the security account's event bus. Which additional piece is required for the security account's automation to actually perform the remediation action inside the member account?
- A. Nothing further; EventBridge cross-account event delivery alone is sufficient to execute actions in the target account
- B. A cross-account IAM role in the member account that trusts the security account and grants the specific permissions the Automation document needs, which the automation execution assumes to perform the remediation
- C. The member account's root credentials shared with the security account
- D. Disabling all IAM permission boundaries in the member account
Check the answer
B. EventBridge cross-account rules only deliver the event across the account boundary — actually performing an action (like modifying a security group) inside the member account still requires a properly scoped cross-account IAM role in that member account, trusting the security account's automation execution role, which the automation assumes at execution time. A conflates event delivery with the separate concern of cross-account authorization to act.
Q28 (Domain 3 — Resilient Cloud Solutions). A team runs ElastiCache for Redis as a session store for a latency-sensitive web application and needs automatic failover to a replica within seconds if the primary node fails, with no application-level reconnection logic to a hardcoded IP required. Which ElastiCache configuration provides this?
- A. A single-node cluster with no replicas, restored from the most recent snapshot after a failure
- B. A Multi-AZ Redis replication group with automatic failover enabled, where the application connects via the group's primary endpoint, which is automatically repointed to the newly promoted node on failover
- C. Manually launching a new Redis node and updating the application's connection string by hand after every failure
- D. Redis cluster mode disabled with no replica nodes configured at all
Check the answer
B. A Multi-AZ replication group with automatic failover promotes a replica to primary automatically on failure and updates the group's primary endpoint DNS to point at the new primary — the application keeps using the same endpoint and reconnects without any code change or manual IP update, meeting the "no hardcoded IP logic" requirement directly.
Q29 (Domain 2 — Configuration Management & IaC). A team maintains a large, mature library of Chef cookbooks used to configure a legacy EC2 fleet, and wants to continue running those existing cookbooks on AWS-managed infrastructure rather than rewriting the entire configuration logic in a different tool. Which AWS service historically provided managed Chef (and Puppet) configuration management for this exact use case?
- A. AWS OpsWorks, which provided managed Chef Automate and Puppet Enterprise environments for running existing cookbooks/manifests — note that AWS has been sunsetting parts of OpsWorks, so verify current availability before relying on it for a new deployment
- B. AWS CodeDeploy, which is designed to run Chef cookbooks natively
- C. AWS CloudFormation, which directly interprets Chef recipe syntax
- D. Amazon Inspector, which manages Chef-based configuration drift
Check the answer
A. OpsWorks was purpose-built to run existing Chef cookbooks and Puppet manifests against AWS-managed instances without a rewrite — this remains useful exam knowledge, though it's worth flagging that AWS has reduced OpsWorks over recent years, so its current-day availability is worth verifying rather than assumed for real production planning. B, C, and D each misdescribe what those services actually do.
Q30 (Domain 4 — Monitoring & Logging). A team's application logs occasionally emit a line containing the literal string "OutOfMemoryError", and the team wants a CloudWatch alarm to page the on-call engineer whenever this happens more than twice in a five-minute window — without changing the application code to emit a dedicated metric. Which combination achieves this from the existing log lines?
- A. A CloudWatch Logs metric filter matching the
"OutOfMemoryError"pattern, publishing a custom metric incremented on each match, with a standard CloudWatch alarm on that metric using a threshold of "greater than 2 in 5 minutes" - B. AWS X-Ray, tracing every log line for keyword matches automatically
- C. A CloudTrail data event selector configured to watch for the string in application logs
- D. VPC Flow Logs, which capture application-level log strings by default
Check the answer
A. A metric filter scans incoming log events for a defined pattern and increments a custom CloudWatch metric on each match, with zero application code changes required; a standard alarm on that metric then handles the "more than twice in five minutes" threshold and paging exactly as it would for any other metric. X-Ray and Flow Logs don't process arbitrary application log text at all, and CloudTrail data events record AWS API calls, not application log content.
Block 3 — Q31–45 (minutes 66–99)
Q31 (Domain 2 — Configuration Management & IaC). A CloudFormation stack update accidentally introduces a change that would replace a stateful RDS resource. The team wants the stack update to automatically stop and revert to the last known-good state if a specified CloudWatch alarm (measuring application error rate) enters ALARM state during the deployment monitoring period, without a human having to watch a dashboard and manually cancel the update. Which CloudFormation feature is designed for this?
- A. A stack policy denying updates to the RDS resource's logical ID
- B. Rollback triggers, which associate one or more CloudWatch alarms with a stack operation and automatically roll the stack back if any of them enters ALARM during the specified monitoring window
- C. Drift detection, run manually after the update completes
- D. A change set, previewed before the update is executed
Check the answer
B. Rollback triggers let a stack operation watch one or more CloudWatch alarms during a configured monitoring period and automatically roll back the entire update if any of them trips — exactly the automated, alarm-driven safety net described, with no human watching a dashboard required. A stack policy (A) would block the replacement outright rather than allow-then-auto-revert-on-signal, and a change set (D) only previews before execution, offering no protection once the update is actually running.
Q32 (Domain 6 — Security & Compliance). A data platform team suspects an S3 bucket used for ad hoc data science exports may contain customer PII that was never supposed to leave a more tightly controlled bucket, but doesn't know which of thousands of files might be affected. They want an automated scan that identifies files likely containing PII and reports findings into their existing centralized security dashboard. Which combination of services fits?
- A. Amazon Macie, configured to scan the bucket for sensitive data patterns, with its findings surfaced in Security Hub via the native integration
- B. AWS Config, since it can natively detect PII content inside S3 objects
- C. Manually opening and reading every file to check for PII by eye
- D. VPC Flow Logs, since PII detection is based on the traffic pattern used to upload each file
Check the answer
A. Macie uses machine learning and pattern matching to discover and classify sensitive data (including PII patterns) in S3 at scale, and its findings integrate natively with Security Hub for centralized visibility — the purpose-built tool for exactly this discovery-and-report workflow. Config (B) evaluates resource configuration against rules, not the content of files stored inside a bucket.
Q33 (Domain 1 — SDLC Automation). A CodeBuild project needs to reach an internal, self-hosted artifact repository that's only reachable from within a private VPC subnet with no public endpoint, in order to download a proprietary internal library during the build. By default, CodeBuild runs in an AWS-managed network outside the customer's VPC. Which configuration lets the build reach that private, internal-only resource?
- A. Making the internal artifact repository publicly accessible so CodeBuild's default network can reach it
- B. Configuring the CodeBuild project with a VPC configuration — specifying the VPC, subnets, and security group — so builds run with network access to resources inside that VPC, including the private repository
- C. CodeBuild cannot reach any resource inside a customer VPC under any configuration
- D. Copying the internal library into the CodeBuild service role's IAM policy as an inline artifact
Check the answer
B. CodeBuild supports an explicit VPC configuration that places build containers inside specified subnets of the customer's own VPC (with an associated security group), giving them the same private network reachability any other resource in those subnets would have — exactly what's needed to reach an internal-only artifact repository without exposing it publicly.
Q34 (Domain 3 — Resilient Cloud Solutions). A media company stores customer-uploaded assets in an S3 bucket in one Region and, as part of a new DR strategy, needs those objects continuously and asynchronously copied to a bucket in a second Region, with a documented commitment that replication of any given object usually completes within a bounded, predictable time window rather than "eventually." Which S3 feature combination meets the predictable-timing requirement specifically, beyond basic replication?
- A. S3 Transfer Acceleration alone, which is designed for cross-Region replication timing guarantees
- B. S3 Cross-Region Replication (CRR) with S3 Replication Time Control (RTC) enabled, which adds a service level agreement that 99.99% of new objects replicate within 15 minutes
- C. S3 Intelligent-Tiering, which automatically moves objects to a second Region based on access patterns
- D. Basic CRR with no additional configuration, since all replication is already bounded to under a minute by default
Check the answer
B. Plain CRR replicates asynchronously with no fixed time guarantee — Replication Time Control is the specific add-on that provides a documented SLA (99.99% of objects replicated within 15 minutes) plus metrics for monitoring replication that's falling behind, which is precisely the "bounded, predictable" requirement the scenario describes. Transfer Acceleration (A) speeds up client uploads over the internet via CloudFront edge locations — it has nothing to do with inter-Region replication timing.
Q35 (Domain 5 — Incident & Event Response, Select TWO). A team is setting up Systems Manager Incident Manager for their production services and wants (1) an incident automatically opened whenever a specific set of CloudWatch alarms fires, with (2) a predefined escalation plan that pages a primary on-call engineer immediately and escalates to a secondary engineer if there's no acknowledgment within 5 minutes. Which TWO statements correctly describe how Incident Manager supports this?
- A. A CloudWatch alarm can be configured to directly start an Incident Manager incident using a specified response plan, without requiring a separate EventBridge rule as glue
- B. A response plan can define an engagement/escalation plan with ordered stages and per-stage wait times, so an unacknowledged page automatically escalates to the next contact after the configured delay
- C. Incident Manager can only ever notify a single, fixed contact with no escalation logic of any kind
- D. Response plans cannot be linked to CloudWatch alarms under any circumstance and require fully custom Lambda glue
- E. Escalation timing in Incident Manager is fixed at exactly 15 minutes and cannot be configured
Check the answer
A and B. Starting an Incident Manager incident is one of the CloudWatch alarm's native action types, so A is correct with no EventBridge rule required as an intermediary. A response plan's engagement plan defines ordered escalation stages with configurable per-stage wait times before moving to the next contact, exactly matching the "escalate after 5 minutes if unacknowledged" requirement in B. C, D, and E each describe limitations that don't actually exist in the service.
Q36 (Domain 6 — Security & Compliance). A company is adopting a service mesh across dozens of internal microservices and needs every service-to-service call to use mutual TLS with certificates issued from a private certificate authority the company controls, rather than certificates from a public CA (which isn't appropriate for internal-only hostnames), with automated issuance and renewal as new services are added. Which AWS service is designed for operating that private CA?
- A. AWS Certificate Manager (ACM) issuing only public certificates from a public CA
- B. AWS Certificate Manager Private Certificate Authority (ACM Private CA), which operates a private CA hierarchy and integrates with ACM for automated issuance and renewal of private certificates for internal services
- C. Amazon Cognito, since it manages TLS certificates for service meshes
- D. AWS Secrets Manager, storing certificate files as plain secrets with manual renewal
Check the answer
B. ACM Private CA operates a private certificate authority hierarchy specifically for issuing certificates for internal, non-publicly-resolvable names, and integrates with regular ACM so certificates can be issued and renewed automatically as services scale — exactly the internal-mTLS-at-scale use case described. A public CA (A) can't validly issue certificates for internal-only hostnames at all.
Q37 (Domain 4 — Monitoring & Logging). A retail application's order volume naturally follows a strong daily and weekly pattern — high during business hours and weekends, low overnight — and the team wants an alarm that fires when order volume deviates meaningfully from what's expected for that specific time of day and day of week, rather than firing every single night when volume is naturally, harmlessly low against a fixed threshold. Which CloudWatch capability fits?
- A. A static threshold alarm set to the daily average
- B. CloudWatch anomaly detection, which builds an expected value band from the metric's own historical trend and seasonality, alarming only when the metric falls outside that adaptive band
- C. A metric math expression that always compares the current value to a fixed constant
- D. CloudWatch Logs Insights, run manually once a day
Check the answer
B. Anomaly detection specifically models a metric's own historical pattern — including daily/weekly seasonality — to build an expected band, and only alarms when actual values fall outside that adaptive band, avoiding exactly the false-alarm-every-night problem a fixed threshold produces for a naturally cyclical metric.
Q38 (Domain 1 — SDLC Automation). A team wants every pull request opened against their main branch to be automatically scanned for common code quality issues and security-relevant code patterns, with inline comments posted directly on the specific lines of concern, before a human reviewer even opens the PR. Which AWS service is purpose-built for automated, ML-powered code review of this kind?
- A. AWS CodeGuru Reviewer, which analyzes pull requests and posts automated recommendations, including security-relevant findings, as inline comments
- B. AWS CodeBuild, since any buildspec can be configured to leave PR comments by default
- C. AWS CodeArtifact, since it screens package quality before ingestion
- D. AWS X-Ray, since it reviews code paths at runtime
Check the answer
A. CodeGuru Reviewer is specifically built to analyze pull requests using machine learning models trained on code quality and security best practices, posting recommendations as inline PR comments automatically — the direct match for "before a human reviewer even opens it." The other three services solve entirely different problems.
Q39 (Domain 2 — Configuration Management & IaC). A team maintains a growing set of CloudFormation templates and is considering migrating to AWS CDK, defining the same infrastructure using a general-purpose programming language with higher-level constructs. After migrating one stack to CDK and synthesizing it, an engineer runs CloudFormation drift detection against the resulting stack. What should they expect regarding drift detection's behavior on CDK-synthesized stacks?
- A. Drift detection is unavailable for any CDK-managed stack, since CDK stacks aren't real CloudFormation stacks
- B. Drift detection works identically to any other CloudFormation stack, because CDK ultimately synthesizes standard CloudFormation templates and deploys them as ordinary stacks — CDK is a template-authoring layer, not a different deployment or drift-tracking mechanism
- C. CDK stacks automatically self-heal any drift within seconds with no configuration
- D. Drift detection only works on CDK L1 constructs and never on L2 or L3 constructs
Check the answer
B. CDK's cdk synth step produces a standard CloudFormation template, and cdk deploy deploys it as an ordinary CloudFormation stack — from CloudFormation's point of view there's no difference between a CDK-synthesized stack and a hand-written one, so drift detection behaves identically regardless of which CDK construct level (L1, L2, or L3) was used to author it.
Q40 (Domain 3 — Resilient Cloud Solutions). An Auto Scaling group backs a service with highly variable, hard-to-predict traffic, and the team wants the group to automatically add or remove instances to keep average CPU utilization near 50%, without hand-tuning specific scale-out and scale-in step adjustments or thresholds as traffic patterns shift over time. Which Auto Scaling policy type is designed for this "hold a target value" behavior?
- A. Simple scaling, with one fixed step adjustment
- B. Step scaling, with several manually defined thresholds
- C. Target tracking scaling, where the team specifies a target metric value and Auto Scaling automatically calculates and applies whatever adjustments are needed to hold it
- D. Scheduled scaling, based on a fixed calendar of dates and times
Check the answer
C. Target tracking scaling works like a thermostat: you specify a target value for a chosen metric (like average CPU at 50%), and Auto Scaling continuously calculates and applies the scale-out/scale-in adjustments needed to hold that target, adapting automatically as traffic patterns change — removing the hand-tuning burden step scaling (B) or simple scaling (A) would require.
Q41 (Domain 6 — Security & Compliance, Select TWO). An S3 bucket should be reachable only from within a specific VPC via its interface or gateway endpoint, never from the public internet or from any other VPC, even if a caller somehow obtains valid IAM credentials with S3 permissions from outside that VPC. Which TWO controls, used together, enforce that restriction at the bucket level?
- A. An S3 bucket policy with a condition using the
aws:sourceVpce(oraws:sourceVpc) condition key, denying access unless the request arrives through the specific approved VPC endpoint - B. A VPC endpoint policy on the S3 gateway/interface endpoint itself, scoping which principals and actions are allowed to use that endpoint
- C. An EC2 security group attached to the S3 bucket, since S3 buckets support security group attachments directly
- D. A CloudFront distribution in front of the bucket, since CloudFront is the only way to restrict S3 access by network path
- E. Relying solely on IAM policies with no bucket-level condition, since IAM alone can express a network-path restriction
Check the answer
A and B. The bucket policy's aws:sourceVpce/aws:sourceVpc condition denies any request that didn't arrive via the approved endpoint — enforcing the network-path restriction at the resource itself, regardless of how valid the caller's IAM credentials otherwise are — and the endpoint policy on the VPC endpoint adds a second, independent layer scoping exactly which principals and actions may use that specific endpoint. C is false — S3 buckets don't attach security groups, those apply to ENI-based resources like EC2 or interface endpoints. E is wrong because IAM policies alone have no concept of "which network path this request arrived on" — that's precisely what the bucket-policy condition key exists to add.
Q42 (Domain 5 — Incident & Event Response). A company wants to know proactively, before their own monitoring might notice, whenever AWS reports a service issue or scheduled maintenance event that could affect resources actually running in their account — rather than a generic status-page notice affecting all AWS customers broadly. Which service provides account-specific, personalized operational and health events that can also be routed through EventBridge for automated response?
- A. The public AWS Service Health Dashboard, which is identical and non-personalized for every AWS customer
- B. AWS Health (the AWS Health Dashboard's account-specific view), which surfaces events scoped to the resources actually present in that account and can emit EventBridge events for automated handling
- C. AWS Trusted Advisor, which only checks cost and security best practices, not live service health events
- D. Amazon CloudWatch, which has no visibility into AWS's own internal service health
Check the answer
B. AWS Health provides personalized visibility into events affecting the specific resources present in an account — not the generic, account-agnostic public Service Health Dashboard — and these account-specific health events can be routed through EventBridge to trigger automated response workflows, unlike the public dashboard in A, which carries no per-account targeting at all.
Q43 (Domain 1 — SDLC Automation). A team wants to ship a risky new checkout feature to production code-complete, but keep it dark for all users initially, then progressively enable it for 5%, then 25%, then 100% of users — independent of any CodeDeploy traffic-shifting deployment — and be able to instantly disable it for everyone with a single flip if a problem appears, without a new deployment. Which AWS service is designed for this kind of decoupled, in-application feature toggle?
- A. CodeDeploy's canary deployment configuration alone, since traffic shifting and feature enablement are the same mechanism
- B. AWS AppConfig feature flags, which let an application query a flag's current state at runtime and roll its rollout percentage forward or back instantly, entirely decoupled from any code deployment
- C. Route 53 weighted routing, applied at the DNS layer
- D. An environment variable baked into the deployment artifact, requiring a full redeploy to change
Check the answer
B. AppConfig feature flags are explicitly decoupled from code deployment — the flag's rollout percentage and enabled/disabled state can change instantly at runtime via a configuration update the application polls for, with no new build or CodeDeploy traffic shift involved at all. CodeDeploy's canary shifting (A) controls which deployed version receives traffic, a related but distinct mechanism from an in-application toggle that can flip a feature off within one already-deployed version.
Q44 (Domain 4 — Monitoring & Logging). A team wants to emit a custom, high-cardinality business metric — orders processed per customer ID — directly from their Lambda function's existing structured log output, without making a separate PutMetricData API call per order (which would add latency and cost at their volume). Which CloudWatch capability supports extracting custom metrics automatically from structured log entries at ingestion time?
- A. CloudWatch embedded metric format (EMF), where a specially structured JSON log entry is automatically parsed by CloudWatch to extract one or more custom metrics with no separate API call
- B. A CloudWatch Logs metric filter, which is the only option and requires one filter be manually created per unique customer ID
- C. AWS X-Ray annotations, which automatically become CloudWatch custom metrics
- D. CloudWatch Synthetics, since canaries can emit arbitrary custom metrics from any Lambda function
Check the answer
A. EMF lets application code write one structured JSON log entry containing both the log data and metric directives, which CloudWatch automatically parses to extract custom metrics at ingestion — avoiding a dedicated PutMetricData call per data point while still producing queryable, graphable metrics, including at high cardinality like per-customer-ID. A metric filter (B) can extract simple counts from pattern matches but doesn't scale cleanly to a distinct metric per unique ID the way EMF's dimension support does.
Q45 (Domain 2 — Configuration Management & IaC). A fleet of 500 EC2 instances across multiple accounts needs security patches applied only during an explicitly approved weekly maintenance window, with patch compliance reported centrally, and instances that fail to patch successfully flagged for follow-up — without an engineer manually SSH-ing into each instance. Which Systems Manager combination is designed for this at fleet scale?
- A. Systems Manager Session Manager, used to manually patch each instance one at a time over an interactive shell
- B. Systems Manager Patch Manager with defined patch baselines and a Maintenance Window scheduling patch operations to run only during the approved time, with centralized compliance reporting across the fleet
- C. A cron job installed manually on each instance
- D. AWS Config alone, since it can apply OS patches directly
Check the answer
B. Patch Manager defines patch baselines (which patches are approved, and any auto-approval delay) and integrates with Maintenance Windows to constrain exactly when patching runs across a targeted fleet, with built-in compliance reporting showing which instances are patched, missing patches, or failed — exactly the scale, scheduling, and reporting requirements described. Config (D) evaluates and reports on configuration compliance but doesn't install OS patches itself.
Block 4 — Q46–60 (minutes 99–132)
Q46 (Domain 4 — Monitoring & Logging). A company's public login page has occasionally been down for several minutes at a time with no customer-facing alert firing, because all existing monitoring is internal — CPU, memory, and application logs — and none of it can detect that the page itself is unreachable or broken from the outside world. They want a scripted check that loads the actual login page from outside their infrastructure every 5 minutes and alarms if it fails, before a customer has to report it. Which service is designed for this outside-in synthetic monitoring?
- A. AWS X-Ray, tracing requests that already reached the application
- B. Amazon CloudWatch Synthetics, running a scheduled canary script that simulates loading the page from outside the infrastructure and can alarm on failure
- C. VPC Flow Logs, which detect page load failures by traffic pattern
- D. AWS Config, evaluating the login page's HTML against a compliance rule
Check the answer
B. Synthetics canaries are scripted checks that run on a schedule from outside the application's own infrastructure, simulating a real user action (like loading a page) and raising a CloudWatch alarm on failure — proactive, outside-in monitoring that internal metrics like CPU or logs structurally cannot provide, because none of those signals exist if the request never reaches the application at all.
Q47 (Domain 1 — SDLC Automation). A team's existing build automation lives in a well-tuned, heavily customized Jenkins pipeline they aren't ready to fully replace, but they want to orchestrate source retrieval, the Jenkins build trigger, and the subsequent CodeDeploy deployment stage all from one CodePipeline, with the pipeline waiting for the Jenkins build to actually complete before proceeding. Which CodePipeline feature supports integrating an external tool like Jenkins as a stage within an otherwise-native pipeline?
- A. CodePipeline can only ever use AWS-native actions and cannot integrate any third-party build tool under any configuration
- B. A custom action, which lets a third-party tool like a self-hosted Jenkins server register as a valid action provider that CodePipeline polls for job completion before advancing the pipeline
- C. Manually pausing the pipeline and running Jenkins by hand between two separate pipeline executions
- D. Replacing Jenkins entirely with CodeBuild before any pipeline integration is possible
Check the answer
B. CodePipeline's custom action type lets a third-party system register itself as an action provider; a Jenkins plugin polls for jobs CodePipeline has queued, runs the build, and reports completion back — letting the pipeline treat an external Jenkins build as a first-class stage it waits on, without replacing the existing Jenkins investment.
Q48 (Domain 6 — Security & Compliance). A company with 30 AWS accounts wants engineers to sign in once through a central identity provider and be granted a consistent, centrally-managed set of permissions (like "Developer" or "ReadOnly") in whichever of the 30 accounts they need to work in that day, without creating and managing a separate IAM user in every account. Which AWS service is designed for this centralized, multi-account access model?
- A. Creating an identical IAM user manually in each of the 30 accounts, with a shared password
- B. AWS IAM Identity Center (successor to AWS SSO), which centrally defines permission sets and assigns them to users or groups across multiple accounts in an Organization, without per-account IAM users
- C. AWS Organizations alone, with no additional identity service
- D. A single IAM role in one account, shared by copying its credentials to every other account
Check the answer
B. IAM Identity Center centrally defines permission sets — reusable permission templates — and assigns them to users or groups against specific accounts across an Organization, letting a user sign in once and access whichever assigned accounts they need with consistent, centrally-managed permissions, entirely replacing the need for per-account IAM users.
Q49 (Domain 2 — Configuration Management & IaC). A platform team wants application teams to be able to self-service-request a new AWS account that automatically receives a baseline CloudFormation StackSet deployment the moment it joins the target Organizational Unit, with the platform team never having to manually run a deployment command for each new account. Which StackSet permission model and setting combination supports this "join and auto-receive" behavior?
- A. Self-managed permissions, since only self-managed StackSets support Organizations integration
- B. Service-managed permissions, with automatic deployment enabled and the StackSet targeting the OU directly — AWS Organizations automatically triggers the StackSet operation on the new account as it joins, with no manual per-account IAM role setup required
- C. A manually run CloudFormation stack creation command executed by a human for every new account
- D. Self-managed permissions, requiring the platform team to manually create an
AWSCloudFormationStackSetExecutionRolein each new account before it can be targeted
Check the answer
B. Service-managed permissions integrate directly with AWS Organizations, letting a StackSet target an OU with automatic deployment enabled so that accounts joining later are automatically included with no manual role setup — self-managed permissions (A, D) instead require manually creating the administration and execution IAM roles in each target account, which is exactly the manual step the scenario wants eliminated.
Q50 (Domain 3 — Resilient Cloud Solutions). A team deploying new EC2 instances behind an Application Load Balancer notices that in-flight requests are occasionally dropped mid-response during a deployment, right as an old instance is deregistered from the target group. They want existing in-flight connections to a deregistering target to complete gracefully before that target is fully removed, rather than being cut off immediately. Which ALB/target group setting controls this behavior?
- A. Cross-zone load balancing, which controls traffic distribution across Availability Zones, not deregistration behavior
- B. The target group's deregistration delay (connection draining), which keeps a deregistering target in a draining state — still completing in-flight requests, but receiving no new ones — for a configured number of seconds before final removal
- C. Sticky sessions, which control whether a client is pinned to the same target across requests
- D. The ALB's idle timeout, which controls how long an inactive connection stays open
Check the answer
B. Deregistration delay (connection draining) is the specific setting controlling how long a target stays in a "draining" state — no new requests routed to it, but existing in-flight requests allowed to finish — before it's fully removed from the target group, directly preventing the mid-response drop the team is describing. The other three settings each control a genuinely different aspect of ALB behavior with no bearing on graceful deregistration.
Q51 (Domain 4 — Monitoring & Logging). A team tracking an availability SLO wants a single CloudWatch metric representing their current error-budget burn rate, computed as (5xx error count ÷ total request count) over a rolling window, derived from two existing raw metrics they already publish, without writing and maintaining a separate Lambda function to do the division and publish a third metric on a schedule.
- A. A Lambda function scheduled every minute to fetch both metrics, compute the ratio, and publish a third custom metric via
PutMetricData - B. A CloudWatch metric math expression that divides the error-count metric by the request-count metric directly within an alarm or dashboard definition, computed on the fly with no separate publishing step or Lambda required
- C. AWS X-Ray, since burn rate is a native X-Ray metric
- D. CloudWatch Logs Insights, run manually once per day to eyeball the ratio
Check the answer
B. Metric math expressions combine existing metrics using arithmetic and statistical functions directly inside an alarm or dashboard definition — computed on the fly at query/evaluation time — so a derived ratio like error rate needs no separate scheduled Lambda function or additional published metric at all, which is precisely the maintenance burden the team wants to avoid.
Q52 (Domain 5 — Incident & Event Response). A team needs a recurring job that runs a Lambda-based report generator at 6 AM every weekday, with the ability to pass different input parameters to different scheduled invocations, retry a failed invocation with a configurable policy, and eventually migrate the schedule definitions into a dedicated, centrally manageable inventory rather than scattering cron expressions across many separate EventBridge rules. Which service is the more purpose-built fit for this evolving scheduling need, compared to a plain EventBridge scheduled rule?
- A. EventBridge Scheduler, a dedicated scheduling service supporting one-time and recurring schedules, per-invocation payload customization, configurable retry policies, and a schedule group model for centralized management at a larger scale than rule-based scheduling was originally designed for
- B. A plain EventBridge rule with a cron expression is strictly superior for every one of these requirements and requires no additional service
- C. AWS Step Functions Express Workflows, which replace the need for any scheduling service entirely
- D. Amazon SQS delay queues, which are the standard AWS mechanism for calendar-based recurring schedules
Check the answer
A. EventBridge Scheduler is a purpose-built scheduling service (distinct from an EventBridge rule with a schedule expression) designed for exactly this kind of growth — per-schedule payload customization, configurable retry policies, and schedule groups for managing large numbers of schedules centrally — capabilities a plain rule-based cron expression wasn't designed to scale to as cleanly. SQS delay queues (D) cap delay at 15 minutes and aren't a calendar-scheduling mechanism at all.
Q53 (Domain 6 — Security & Compliance). An application depends on credentials for a third-party, non-RDS SaaS API that supports credential rotation via its own API. The team wants those credentials to rotate automatically on a schedule with zero plaintext exposure, using AWS-native tooling, even though this isn't one of Secrets Manager's built-in RDS/Redshift/DocumentDB rotation templates. Which approach fits?
- A. Secrets Manager only supports automatic rotation for RDS, Redshift, and DocumentDB, so this requirement cannot be met with Secrets Manager at all
- B. Secrets Manager rotation with a custom rotation Lambda function implementing the four-step rotation lifecycle (createSecret, setSecret, testSecret, finishSecret) against the third-party API's own credential-rotation endpoints
- C. Store the credential in Parameter Store SecureString, which rotates automatically for any third-party API with no additional configuration
- D. Manually rotate the credential by hand every 90 days and update the value in a config file committed to source control
Check the answer
B. Secrets Manager's rotation framework isn't limited to its built-in database templates — it supports a fully custom rotation Lambda function implementing the same four-step lifecycle against any API a team can script against, including a third-party SaaS's own rotation endpoints, still achieving scheduled, zero-plaintext-exposure rotation. Parameter Store (C) has no native automatic rotation capability at all; that claim is simply false.
Q54 (Domain 1 — SDLC Automation). A team's source code lives in AWS CodeCommit, and they want a CodePipeline execution to start automatically and immediately whenever a commit lands on the main branch specifically — not on any other branch, and not on a fixed polling interval. Which trigger mechanism is both event-driven and branch-specific?
- A. A CodePipeline source stage polling CodeCommit every 5 minutes across all branches
- B. An EventBridge rule matching CodeCommit's "reference created/updated" event, filtered to the specific branch reference, targeting the pipeline's
StartPipelineExecutionaction — the standard event-driven, branch-scoped CodeCommit trigger - C. A CodeBuild webhook, since CodeCommit doesn't support any event-driven trigger mechanism
- D. Manually running
start-pipeline-executionafter every push to any branch
Check the answer
B. CodeCommit emits events (via EventBridge) on repository state changes including branch reference updates; a rule filtered to the specific branch reference and targeting the pipeline's start action triggers execution immediately on a matching push, with no polling interval and no other-branch noise — the standard modern CodeCommit-to-CodePipeline trigger pattern.
Q55 (Domain 3 — Resilient Cloud Solutions). A VPC spans three Availability Zones, each with a private subnet whose workloads need outbound internet access for patching and package downloads. The team initially deploys a single NAT Gateway in one AZ to save cost, then experiences a full outage in all three AZs' outbound connectivity when that one AZ has an issue. What's the correct multi-AZ resilient design, and what does it cost relative to the single-NAT setup?
- A. Nothing changes; a single NAT Gateway already provides equal resilience across all AZs by design
- B. Deploy one NAT Gateway per AZ, and route each AZ's private subnet traffic through the NAT Gateway in its own AZ, so a single AZ's NAT Gateway issue only affects that one AZ's outbound traffic rather than the entire VPC — at the cost of running (and paying for) multiple NAT Gateways instead of one
- C. Replace the NAT Gateway with a single internet-facing ALB, which provides equivalent outbound NAT functionality
- D. Disable outbound internet access entirely, which resolves the resilience concern by removing the dependency
Check the answer
B. A NAT Gateway is an AZ-scoped resource — a single NAT Gateway going down (or its AZ having an issue) takes out outbound connectivity for every subnet routed through it, regardless of which AZ those subnets are in. The standard resilient pattern is one NAT Gateway per AZ, with each AZ's route table pointing to its own local NAT Gateway, so a single AZ's NAT issue is contained to that AZ — accepting the added cost of running multiple NAT Gateways as the explicit tradeoff for that isolation.
Q56 (Domain 4 — Monitoring & Logging). A security team needs to investigate, across all 40 accounts in an Organization, every instance of a specific IAM action (iam:CreateAccessKey) called in the last 90 days, run as a single SQL-style query rather than checking each account's CloudTrail console individually. Which approach lets them query CloudTrail history across the whole Organization at once?
- A. Manually logging into each of the 40 accounts' CloudTrail Event history console and searching one at a time
- B. CloudTrail Lake, with an organization event data store aggregating events across all member accounts, queried with SQL directly for the specific action across the whole 90-day window in one query
- C. VPC Flow Logs, since IAM API calls are captured there
- D. AWS X-Ray, which traces IAM API calls automatically
Check the answer
B. CloudTrail Lake's organization event data store aggregates events from every member account into one queryable store, and its SQL-based query interface can filter for a specific event name across the full time range and every account in a single query — directly replacing the account-by-account manual search in A. Flow Logs (C) capture network metadata, not IAM API activity, and X-Ray (D) traces application requests, not management-plane API calls.
Q57 (Domain 2 — Configuration Management & IaC). An AWS Config rule flags any security group allowing inbound SSH (port 22) from 0.0.0.0/0 as non-compliant. The team wants any newly created non-compliant security group automatically remediated — the offending rule removed — within minutes, without a human running a script each time one is found. Which combination directly implements this?
- A. A remediation action attached to the Config rule, backed by an SSM Automation document that removes the offending ingress rule, configured to run automatically on a NON_COMPLIANT finding
- B. AWS Config alone, with no remediation action, since Config automatically fixes any resource it flags
- C. A weekly manual review meeting where an engineer reads the Config dashboard and fixes issues by hand
- D. Deleting AWS Config entirely and relying on a security group review during code review instead
Check the answer
A. Config supports attaching a remediation action — typically an SSM Automation document — directly to a rule, configurable to trigger automatically the moment a resource is evaluated as non-compliant, closing the loop from detection to fix with no manual intervention. B is false: Config only detects and reports non-compliance by itself; it never remediates anything without an explicitly attached remediation action.
Q58 (Domain 6 — Security & Compliance, Select TWO). A public-facing web application is experiencing both (1) a Layer 7 HTTP flood from a rotating pool of IP addresses making abnormally frequent requests, and (2) concern from the security team about broader, larger-scale volumetric and protocol-level DDoS attacks at the network layer. Which TWO AWS services or features together address both threat types, each doing the part it's actually built for?
- A. An AWS WAF rate-based rule on the CloudFront distribution or ALB, which automatically blocks (or challenges) source IPs exceeding a defined request-rate threshold in a rolling time window — addressing the Layer 7 HTTP flood
- B. AWS Shield Advanced, providing enhanced protection against larger-scale network- and transport-layer (Layer 3/4) DDoS attacks, plus cost protection and 24/7 DDoS Response Team access — addressing the broader volumetric concern
- C. AWS WAF alone fully replaces the need for Shield Advanced for network-layer volumetric attacks
- D. Shield Advanced alone fully replaces the need for a WAF rate-based rule for filtering an application-layer request flood
- E. VPC Flow Logs are the primary real-time DDoS mitigation mechanism for both attack types
Check the answer
A and B. A WAF rate-based rule operates at Layer 7, rate-limiting or blocking IPs exceeding a request threshold — the right tool for an application-layer HTTP flood. Shield Advanced adds protection specifically against larger network- and transport-layer (Layer 3/4) DDoS attacks, plus cost protection and DRT access — a different layer of the stack than WAF addresses. C and D each wrongly claim one service alone covers both layers, and Flow Logs (E) is a passive logging feature, not an active mitigation mechanism at all.
Q59 (Domain 5 — Incident & Event Response). A team wants an unhealthy EC2 instance to first attempt an automated, low-risk remediation (a service restart via SSM Run Command), and only if that remediation fails to clear the underlying CloudWatch alarm within a defined window, automatically escalate by starting a formal Incident Manager incident that pages a human — rather than paging immediately on every single alarm, most of which the automated restart already fixes. Which pattern implements this staged, escalate-only-on-failure design?
- A. Configure the CloudWatch alarm to start an Incident Manager incident directly as its only action, paging a human on every single occurrence regardless of whether automated remediation would have sufficed
- B. An EventBridge rule triggers an SSM Automation runbook on the alarm's state change; the runbook attempts the restart, then checks whether the alarm has cleared within the window, and only if it hasn't, the runbook's final step starts an Incident Manager incident — escalating to a human only when automation alone didn't resolve it
- C. Configure two entirely independent, uncoordinated systems — one restarting the instance, one paging a human on every alarm — with no relationship between them
- D. Disable the alarm entirely and rely on manual periodic checks instead
Check the answer
B. Chaining an SSM Automation runbook off the alarm's state-change event lets the runbook attempt the low-risk fix first, check the outcome, and conditionally escalate — via aws:branch logic ending in a step that starts an Incident Manager incident only on the failure path — exactly matching "escalate only if automated remediation didn't work." A pages on every occurrence with no attempt at automated resolution first, defeating the point of having automation at all.
Q60 (Domain 1 — SDLC Automation). A CodePipeline builds an artifact whose version needs to be visible and consistent across multiple later stages — for example, tagging the deployed CodeDeploy application revision with the exact CodeBuild build number that produced it, so a production incident can always be traced back to the specific build. Which CodePipeline mechanism passes that kind of value from an earlier stage/action to a later one within the same pipeline execution?
- A. Manually copying the build number into a separate, disconnected system and cross-referencing it by hand later
- B. Variables namespaced per action (action-level output variables, referenced as
#{NamespaceName.VariableName}in a later action's configuration), letting a value produced by an earlier action (like a CodeBuild build number) be consumed directly by a later action's configuration within the same execution - C. CodePipeline has no mechanism for passing values between stages; every stage is fully isolated with no shared state whatsoever
- D. Storing the value in a hardcoded environment variable that must be manually updated before every single pipeline execution
Check the answer
B. CodePipeline supports namespaced variables produced by an action (such as a CodeBuild action exporting its build ID as an output variable) that later actions in the same execution can reference directly in their configuration — exactly the mechanism needed to carry a build identifier forward into a later CodeDeploy action's tagging or configuration, with no external system or manual step required.
Block 5 — Q61–75 (minutes 132–165)
Q61 (Domain 6 — Security & Compliance). An organization wants a guardrail that prevents every account in a specific OU from ever disabling GuardDuty or leaving the Organization, even for an account's own root user or an administrator with a locally-attached AdministratorAccess policy — a restriction that must hold no matter what permissions are granted inside the account itself. Which mechanism is designed to enforce a ceiling above any single account's own IAM permissions?
- A. An IAM permissions boundary applied to every individual user in every account
- B. A Service Control Policy (SCP) attached to the OU, explicitly denying the GuardDuty-disabling and Organization-leaving actions — SCPs set the maximum available permissions for accounts in scope and are evaluated before any account-local IAM policy, so even a local
AdministratorAccessgrant can never override an SCP deny - C. A CloudWatch alarm that emails the security team if GuardDuty is ever disabled, after the fact
- D. An IAM policy attached to the root user of the Organization's management account only
Check the answer
B. SCPs are an Organizations-level guardrail that caps the maximum permissions available to accounts within their scope — they never grant anything themselves, only restrict — and a deny in an SCP cannot be overridden by any identity-based policy inside the account, including a locally-granted AdministratorAccess policy, which is precisely the "holds no matter what permissions are granted inside the account" requirement. C is reactive notification after the fact, not prevention.
Q62 (Domain 3 — Resilient Cloud Solutions). A company's disaster recovery requirements state an RPO of near-zero and an RTO of a few minutes for their primary transactional database, and a separate, less critical reporting service can tolerate an RPO of several hours and an RTO of most of a business day. Which pairing of DR approaches most directly matches the two different requirements, without over- or under-engineering either one?
- A. Both systems should use the identical, most expensive multi-Region active-active architecture regardless of their actual requirements
- B. The transactional database should use a near-real-time, fast-failover architecture like Aurora Global Database or Multi-AZ with cross-Region replication sized for minutes-scale RTO; the reporting service can use a cheaper backup-and-restore or pilot-light approach appropriate to its much looser RPO/RTO, avoiding the cost of over-engineering a system that doesn't need it
- C. Both systems should use only daily backups with no other DR mechanism, since backups alone satisfy any RPO/RTO combination
- D. RPO and RTO are the same metric and don't require different architectural choices
Check the answer
B. Matching the DR strategy's cost and complexity to the actual stated RPO/RTO for each system individually is the Well-Architected reliability principle at work here — a near-zero RPO and minutes-scale RTO genuinely requires a fast, near-real-time replication and failover architecture, while a system that can tolerate hours of data loss and most of a day of downtime doesn't need (and shouldn't pay for) that same level of engineering. Applying the same expensive architecture to both (A) wastes budget on the reporting service for no benefit; D confuses two genuinely distinct metrics — RPO measures acceptable data loss, RTO measures acceptable downtime.
Q63 (Domain 1 — SDLC Automation). A globally distributed application needs true active-active deployment across two Regions, where a single CodePipeline execution deploys the same validated artifact to both Regions' production environments only after it has separately passed validation in each Region, rather than deploying to Region B blindly based solely on Region A's success. Which pipeline structure supports this?
- A. Two entirely separate, uncoordinated pipelines, one per Region, with no shared artifact or validation gating between them
- B. A single CodePipeline with parallel deployment stages (or actions sharing the same
runOrder) targeting both Regions from the same built and validated artifact, each with its own region-specific validation step gating that Region's traffic shift independently - C. A pipeline that always deploys to Region B automatically the instant Region A's deployment starts, with no Region B-specific validation at all
- D. CodePipeline cannot deploy to more than one Region from a single pipeline execution under any configuration
Check the answer
B. A single pipeline can build one artifact once and fan it out to parallel, Region-specific deployment actions, each with its own validation and traffic-shift gating — so Region B's rollout depends on Region B's own validation passing, not merely on Region A having started, which is exactly the "separately validated in each Region" requirement the scenario states. A loses the shared-artifact guarantee (the two Regions could silently drift to different versions over time), and C explicitly violates the independent-validation requirement.
Q64 (Domain 5 — Incident & Event Response). During a database failover incident, the on-call engineer needs the exact sequence of diagnostic and remediation commands executed consistently every time — not improvised under pressure — and the team also wants a message automatically posted to their incident channel the moment the runbook starts and again when it completes, so the rest of the team has real-time visibility without asking the engineer for updates. Which combination best supports both the consistency requirement and the automatic status-visibility requirement?
- A. A written document in a wiki that the engineer reads from manually, with no automated status updates of any kind
- B. A Systems Manager Automation runbook codifying the exact failover steps, with early and late steps in the runbook publishing to an SNS topic that AWS Chatbot posts into the incident channel — giving both a consistent, repeatable procedure and automatic status visibility with no one having to type a manual update
- C. Relying entirely on the engineer's memory, since documenting failover steps in advance would make the response too slow
- D. A CloudFormation template, since infrastructure-as-code is the correct tool for documenting operational runbooks
Check the answer
B. An Automation runbook makes the procedure itself consistent and repeatable rather than improvised, and adding SNS-publishing steps at the start and end of that runbook — routed through Chatbot into the team's chat channel — delivers the automatic status visibility requirement with no manual typing required, satisfying both stated needs from one integrated mechanism. A wiki document (A) provides consistency at best but has no automated status-posting capability at all.
Q65 (Domain 4 — Monitoring & Logging, Select TWO). A team wants to identify, without writing any custom log-parsing code, which specific customer IDs are generating the most 5xx errors against their API in near real time, updating continuously as traffic patterns shift. They're evaluating CloudWatch Contributor Insights for this. Which TWO statements about Contributor Insights are accurate?
- A. Contributor Insights ships built-in rules for certain AWS services (like DynamoDB and Lambda) and also supports custom rules defined against CloudWatch Logs, extracting a top-N "contributors" report (e.g., top customer IDs by error count) without a custom parsing pipeline
- B. Contributor Insights reports update continuously as new matching log data arrives, rather than requiring a manual re-run of a query each time
- C. Contributor Insights fully replaces the need for CloudWatch alarms, since it can trigger alerts natively on its own
- D. Contributor Insights can only ever analyze VPC Flow Logs and no other log source
- E. Contributor Insights requires the underlying log data to already be pre-aggregated by the application before ingestion
Check the answer
A and B. Contributor Insights provides built-in rules for select AWS services plus custom rules against arbitrary CloudWatch Logs data, extracting top-N contributor reports (like the highest-error customer IDs) with no custom parsing code — and those reports update continuously as new log data streams in, rather than needing a manual re-query. It does not natively trigger alerts on its own (C is false — you'd still pair it with a graphed metric and a separate alarm), isn't limited to VPC Flow Logs (D is false), and works against raw, non-pre-aggregated log data (E is false).
Q66 (Domain 6 — Security & Compliance). A third-party SaaS monitoring vendor needs read-only access to specific CloudWatch metrics in a customer's AWS account. The customer wants to grant this without creating an IAM user or sharing any long-term credentials with the vendor, and wants the access revocable at any time from the customer's side alone. Which pattern is the AWS-recommended approach for this kind of third-party cross-account access?
- A. Create an IAM user with an access key and share the key with the vendor over email
- B. Create a cross-account IAM role in the customer's account with a trust policy naming the vendor's AWS account ID and requiring a shared, pre-agreed
sts:ExternalIdin the assume-role call — the vendor's own AWS account then assumes this role viasts:AssumeRole, and the customer can revoke access instantly by deleting or modifying the role, with no long-term credential ever shared - C. Share the AWS account's root credentials with the vendor for the duration of the engagement
- D. Make the relevant CloudWatch metrics publicly accessible so no authentication is required at all
Check the answer
B. A cross-account role with an external ID condition is the standard AWS-recommended pattern for granting a third party (like a SaaS vendor) scoped, revocable access without ever sharing a long-term credential — the external ID additionally protects against the "confused deputy" problem where the vendor might otherwise be tricked into using the wrong customer's role. Revocation is a one-sided action the customer controls entirely, unlike a shared access key (A), which the customer can only rotate, not instantly and unilaterally kill from the vendor's side.
Q67 (Domain 2 — Configuration Management & IaC). An organization's CloudFormation templates are maintained by a dozen different teams, and a platform team wants to enforce that every resource of certain types (like every S3 bucket and every EBS volume) automatically receives a standard set of cost-allocation tags, without relying on each individual team remembering to hand-write the same block of tags into every template they author. Which CloudFormation feature can transform every matching template at deployment time to inject this repeated pattern automatically?
- A. A CloudFormation macro, registered once and referenced via the template's
Transformsection, which can programmatically process and modify the template — including injecting a standard tag set onto matching resource types — before deployment - B. A stack policy, since stack policies can inject arbitrary content into resource definitions
- C. Manually reviewing every team's template by hand before every deployment to check for the tags
- D. AWS Config, since Config can retroactively add tags to already-deployed CloudFormation resources
Check the answer
A. A macro is a Lambda-backed template preprocessor invoked via a template's Transform section, capable of programmatically rewriting the template — including automatically injecting a standard tag block onto every matching resource type — before CloudFormation actually processes it, removing the need for every team to hand-author the same boilerplate. A stack policy (B) only controls which update actions are permitted on which resources; it has no template-rewriting capability at all.
Q68 (Domain 3 — Resilient Cloud Solutions). A company's RDS PostgreSQL database currently runs Multi-AZ within a single Region for high availability. A new requirement adds a second, geographically distant Region that must be able to serve reads locally (for latency) and be promotable to a fully independent, writable primary within a documented RTO if the entire primary Region becomes unavailable. Which addition, layered on top of the existing Multi-AZ setup, is required to meet this new cross-Region requirement?
- A. Nothing further is needed; the existing Multi-AZ standby already satisfies a cross-Region requirement
- B. A cross-Region read replica in the second Region, which can serve local reads immediately and can be manually promoted to a standalone, independently writable primary if the entire origin Region becomes unavailable
- C. A second, independent Multi-AZ deployment in the second Region with no replication link to the first, requiring the team to manually keep both databases in sync
- D. DynamoDB Global Tables, since RDS itself has no cross-Region capability of any kind
Check the answer
B. A Multi-AZ standby is confined to a second AZ within the same Region — it does nothing for a whole-Region outage. A cross-Region read replica is the RDS-native mechanism that both serves local reads from the second Region today and can be promoted to an independent, writable primary if the origin Region becomes unavailable, layering directly on top of the existing Multi-AZ setup rather than replacing it. C throws away built-in replication in favor of manual synchronization, which is strictly worse for this requirement.
Q69 (Domain 1 — SDLC Automation). A team deploying a new Lambda function version wants CodeDeploy to shift traffic gradually and automatically roll back if a specific CloudWatch alarm on the function's error rate fires — and separately wants the rollback to happen specifically because that named alarm tripped, not because of some unrelated alarm elsewhere in the account. Which piece of the CodeDeploy configuration ensures rollback triggers only from the alarm actually relevant to this deployment?
- A. CodeDeploy automatically rolls back on any alarm entering ALARM state anywhere in the AWS account, with no way to scope it to a specific alarm
- B. The deployment group's explicit alarm configuration, which lists the specific CloudWatch alarm(s) to monitor — only an alarm named in that list triggers CodeDeploy's automatic rollback for that deployment, unrelated account-wide alarms have no effect on it
- C. IAM policy conditions, which are the only mechanism controlling which alarm triggers a rollback
- D. Rollback triggers can only ever be configured at the CodePipeline level, never within CodeDeploy itself
Check the answer
B. A CodeDeploy deployment group's alarm configuration explicitly lists which CloudWatch alarm(s) it monitors for automatic-rollback-on-alarm behavior — only a state change on one of those named alarms affects that specific deployment, which is precisely the "the alarm relevant to this deployment, not some unrelated one" scoping the scenario asks for. A incorrectly claims account-wide, unscoped behavior that isn't how the feature works.
Q70 (Domain 4 — Monitoring & Logging). A team runs 40 Lambda functions across several accounts and wants every function's logs streamed in near real time into a single centralized S3-backed data lake for long-term retention and later batch analysis with Athena, rather than checking 40 separate CloudWatch Logs log groups individually. Which combination achieves centralized, near-real-time log aggregation at this scale?
- A. Manually exporting each log group to S3 once a month using the CloudWatch Logs console export feature
- B. A CloudWatch Logs subscription filter on each log group (or a cross-account, cross-Region destination) streaming matching events to Kinesis Data Firehose, which buffers and delivers them to the centralized S3 data lake, later queryable via Athena
- C. AWS Config, aggregating log content across accounts natively
- D. CloudTrail Lake, since it can ingest arbitrary Lambda function log lines
Check the answer
B. Subscription filters stream matching log events out of a log group in near real time to a destination like Kinesis Data Firehose, which can batch and deliver them into S3 — the standard centralized-logging pattern for aggregating many log groups (even across accounts, via a cross-account subscription destination) into one queryable data lake, without a manual monthly export process. Config (C) and CloudTrail Lake (D) are both built around AWS resource configuration and API activity, not arbitrary application log content.
Q71 (Domain 6 — Security & Compliance, Select TWO). A security team wants a single, centralized view of both (1) AWS resource configuration compliance and (2) aggregated security findings across all 60 accounts in their Organization, without logging into each account. They're evaluating an AWS Config aggregator alongside Security Hub's Organizations integration. Which TWO statements correctly distinguish what each of these two services actually aggregates?
- A. A Config aggregator collects AWS Config compliance data and resource configuration information across accounts (and optionally Regions) into one centralized, queryable view — it does not aggregate security findings from services like GuardDuty or Inspector
- B. Security Hub's Organizations integration aggregates security findings — including from GuardDuty, Inspector, Macie, and Config rule evaluations — into a delegated administrator account's consolidated dashboard, which is a different (though complementary) aggregation than a Config aggregator's resource-configuration view
- C. A Config aggregator and Security Hub aggregate exactly the same data, making one of them redundant to operate
- D. Security Hub cannot ingest findings that originated from an AWS Config rule evaluation under any circumstance
- E. A Config aggregator aggregates GuardDuty findings natively, with no need for Security Hub at all
Check the answer
A and B. A Config aggregator's scope is specifically AWS Config data — resource configuration and rule compliance — across accounts and Regions, while Security Hub's Organizations integration aggregates security findings from multiple sources including GuardDuty, Inspector, Macie, and yes, Config rule evaluations too, into a broader consolidated security posture view. They're complementary, not redundant (ruling out C), Security Hub does ingest Config-sourced findings (ruling out D), and a Config aggregator has no native GuardDuty-ingestion capability of its own (ruling out E) — that's specifically Security Hub's job.
Q72 (Domain 5 — Incident & Event Response). A team currently pages the on-call engineer via a direct SNS-to-SMS subscription with no structured escalation, no acknowledgment tracking, and no defined secondary contact if the primary doesn't respond. They want to formalize this into a proper on-call rotation with primary/secondary escalation stages, acknowledgment tracking, and a documented, reusable incident response plan triggered consistently from their existing CloudWatch alarms — using native AWS tooling rather than adopting a separate third-party paging product. Which AWS service is purpose-built for this?
- A. Continue using the direct SNS-to-SMS subscription, since AWS has no native purpose-built incident/on-call management service
- B. Systems Manager Incident Manager, which supports defined response plans, engagement/escalation plans with ordered contacts and stages, acknowledgment tracking, and can be triggered directly from a CloudWatch alarm's native action list
- C. Amazon Pinpoint, which is AWS's purpose-built on-call escalation and paging service
- D. AWS Chatbot alone, with no other service, since it natively tracks acknowledgment and escalation state
Check the answer
B. Incident Manager is specifically built for structured incident response — response plans, engagement plans with ordered escalation stages and contacts, and acknowledgment tracking — and integrates directly with CloudWatch alarms as a native alarm action, replacing the ad hoc SNS-to-SMS setup with the formalized on-call rotation the team wants, natively within AWS. Pinpoint (C) is a customer engagement/messaging service, not an incident-management or on-call escalation product.
Q73 (Domain 3 — Resilient Cloud Solutions). A team is deciding between a standard RDS cross-Region read replica and Aurora Global Database for their PostgreSQL-compatible workload's cross-Region DR story, specifically comparing typical failover promotion time and whether writes can be forwarded from a secondary Region without the application needing to redirect to the primary itself. Which statement accurately distinguishes the two?
- A. Both options provide identical sub-minute failover promotion time and identical write-forwarding capability, making the choice purely about cost
- B. A standard cross-Region read replica's promotion is a manual, asynchronous-replication-dependent operation typically taking minutes, with no native write-forwarding from the replica; Aurora Global Database offers managed failover typically under a minute and supports write forwarding from secondary-Region Aurora Replicas back to the primary, letting an application in the secondary Region issue writes without needing to redirect application logic to the primary Region's endpoint
- C. Aurora Global Database has no failover capability at all and is purely a read-scaling feature
- D. A standard cross-Region read replica supports write forwarding natively, while Aurora Global Database does not
Check the answer
B. This is the core distinction the exam tests between the two options: a standard cross-Region read replica requires a manual promotion with no write-forwarding capability at all, while Aurora Global Database provides both a faster, managed failover path (typically under a minute) and write forwarding, which lets secondary-Region application code issue writes that Aurora transparently routes to the primary — meaningfully reducing application-side complexity during normal operation, not just during a failover event.
Q74 (Domain 2 — Configuration Management & IaC). A "networking" CloudFormation stack exports a VPC ID and subnet IDs via Outputs with Export names, and three separate application stacks import those values using Fn::ImportValue. An engineer later tries to delete the networking stack to restructure it, and the deletion fails. What's the cause, and what must happen before the networking stack can be deleted?
- A. CloudFormation stacks can never be deleted once created, regardless of any dependency
- B. A stack whose output is still referenced by
Fn::ImportValuein another active stack cannot be deleted (or have that specific output removed/changed) until every importing stack stops importing it — each dependent stack must be updated to no longer import the value, or itself deleted, before the exporting stack's deletion will succeed - C. The deletion failure is unrelated to the exports; it must be a permissions issue instead
- D. Cross-stack references are automatically and silently dropped whenever the exporting stack is deleted, so no error should have occurred at all
Check the answer
B. CloudFormation enforces cross-stack reference integrity: an exported output that's actively imported elsewhere via Fn::ImportValue cannot be removed or have its exporting stack deleted until every importing stack has stopped referencing it — this is a deliberate safety mechanism preventing an application stack from silently losing a VPC or subnet ID it still depends on, and it's exactly the kind of ordering constraint nested stacks and nested-stack-style nested-resource patterns don't have to think about the same way nested cross-stack exports do.
Q75 (Domain 1 — SDLC Automation). A company's deployment pipeline itself — the CodePipeline definition, its CodeBuild projects, and its IAM roles — is currently created and maintained by hand in the console, making the pipeline's own configuration a single point of undocumented, unrepeatable state that nobody can confidently recreate if it's ever accidentally deleted. They want the pipeline's own definition version-controlled, code-reviewed, and deployed the same way application infrastructure is, so a pipeline definition change goes through the same rigor as any other infrastructure change. Which general approach solves this "pipeline as code" problem?
- A. Continue configuring the pipeline exclusively through the console, since pipelines themselves cannot be defined as code
- B. Define the pipeline (its stages, actions, and IAM roles) in CloudFormation or CDK, storing that definition in source control and deploying it through its own reviewed, repeatable process — treating the pipeline's own configuration as another piece of managed infrastructure rather than a hand-maintained, undocumented artifact
- C. Take a manual screenshot of the console configuration monthly as the sole backup strategy
- D. Rely entirely on institutional memory among the two engineers who originally built the pipeline
Check the answer
B. A CodePipeline (and its supporting CodeBuild projects and IAM roles) is itself just another set of AWS resources expressible in CloudFormation or CDK — defining it that way and storing the definition in source control turns an undocumented, console-only artifact into a reviewable, repeatable, recoverable piece of infrastructure, closing the exact single-point-of-failure gap the scenario describes. This is the same "treat the pipeline as just another stack" principle behind CDK Pipelines' self-mutating design discussed elsewhere in this course's material.
Score yourself
☺ Like you're 10: Count your correct answers out of 65, turn it into a rough percentage against the real pass mark, then look at which domain cost you the most points — that second part is the useful part.
AWS scores DOP-C02 on a scaled range of 100–1000, with 750 needed to pass. That scaled score is not a simple percentage of correct answers — it's computed using item response theory that weighs questions by difficulty, and AWS doesn't publish the exact conversion formula, so no practice paper, including this one, can compute your real scaled score. As a widely used rule of thumb among test-prep resources, treat answering roughly 75% of the 65 scored questions (about 49/65) as a reasonable target to clear comfortably, not as a guaranteed pass/fail line — verify current guidance on AWS's own exam page before you rely on any number here.
Before you total anything, here's the reveal AWS never gives you on exam day: questions 16, 17, 24, 25, 40, 42, 53, 54, 56, and 57 were this paper's stand-ins for the exam's unidentified, unscored pretest items. Real DOP-C02 sittings mix 10 of these among the 75, and you're never told which — so don't count them below, but don't feel behind if you missed one, either; on the real exam you'd have spent time on it the same way, because there was no way to know.
| Domain | Scored questions in this paper | Your score | If under two-thirds, go here |
|---|---|---|---|
| 1 · SDLC Automation | Q1, 6, 11, 15, 22, 26, 33, 38, 43, 47, 60, 63, 69, 75 | /14 | SDLC Automation |
| 2 · Configuration Management & IaC | Q2, 8, 14, 19, 29, 31, 39, 45, 49, 67, 74 | /11 | Configuration Management & IaC |
| 3 · Resilient Cloud Solutions | Q4, 9, 21, 28, 34, 50, 55, 62, 68, 73 | /10 | Resilient Cloud Solutions |
| 4 · Monitoring & Logging | Q5, 12, 18, 30, 37, 44, 46, 51, 65, 70 | /10 | Monitoring & Logging |
| 5 · Incident & Event Response | Q7, 13, 20, 27, 35, 52, 59, 64, 72 | /9 | Incident & Event Response |
| 6 · Security & Compliance | Q3, 10, 23, 32, 36, 41, 48, 58, 61, 66, 71 | /11 | Security & Compliance |
| Total | 65 scored questions | /65 | ~75% (≈49/65) as a rough target |
On a scenario paper especially, watch for a specific failure pattern: getting the service right but the reasoning wrong — picking option B because "Aurora Global Database sounds fast" rather than because you traced through why the RPO/RTO numbers in the stem actually rule out the other three. That guess-the-vibe pattern scores exactly the same as real understanding on this paper, but it won't survive a scenario the real exam phrases slightly differently. If an answer felt like a guess even though you got it right, reread its explanation anyway.
Beyond the domain breakdown, sort your misses into three piles, because on a scenario paper they mean three different things. A question you got wrong because you didn't recognize the service or option at all is a genuine content gap — reread the linked domain page and lean on Know It Cold for the facts worth memorizing outright. A question you got wrong because you picked a real, plausible service that just wasn't the right one for this specific scenario is an elimination-technique gap — work answer triage & elimination until finding the one clause that rules out three of four options becomes automatic. And a question you got wrong because you ran out of time mid-scenario and guessed is a pacing problem — the fix is more timed reps, not more reading, and the AWS service & command reference is built to make the "which service" half of that faster so the "which scenario clause" half gets your full attention.
Foxy: I got Q73 wrong. I picked the read replica because it mentioned "cross-Region" and that felt like enough.
Professor Owl: "Cross-Region" was true of both options, Foxy — that's exactly why it wasn't the detail that mattered. The stem asked about failover time and write forwarding. That's the clause that ruled the replica out.
Benny the Beaver: Same trap got me on Q11. I saw "ECS" and "rollback" and picked the first ECS-shaped answer without checking whether it was the native rolling update or the CodeDeploy blue/green controller. Two different mechanisms, same two words in the question.
Timmy the Turtle: Which is the entire reason I make you read every scenario twice. The first read tells you what the story is about. The second read tells you which sentence in it is actually the question.
Gizmo the Gremlin: Or — hot tip — just pick whichever answer is the longest one. Longest answer usually sounds the most official. 🤑
Timmy the Turtle: That "trick" would have handed you the wrong answer on at least a dozen questions in this exact paper, Gizmo. Length isn't a signal. The clause that rules out three options is the signal, and it's never in the same spot twice.
Ellie the Elephant: I keep a running list of exactly these near-misses — which two services I actually confused, not just which question I missed. By Set 4 mine was down to one recurring pair.
1. What's the one structural difference between Set 1 and Set 2, given that the domain weights, question count, and scoring are all identical? 2. Why does rereading a scenario stem a second time matter more on this paper than it did on Set 1? 3. Describe the "right service, wrong reasoning" trap this page warns about, and why it's dangerous even when it produces a correct answer. 4. You score 49/65 overall but 3/9 on Incident & Event Response — what's the diagnosis, and where do you go next? 5. What happens to the 10 unscored questions in this paper, and why are you only told which ones they were after you finish?
Check your answers
- The domains, weights, 65/10 scored split, 180-minute clock, and 750/1000 pass mark are all identical — the difference is entirely in question shape. Set 1 asked direct recall ("which service does this"); Set 2 wraps every question in a multi-service scenario where several answer choices are all real, plausible AWS capabilities and only one actually fits the specific constraint stated.
- Because a scenario stem typically buries one clause — a number, a negative, a "without X" constraint — that rules out most of the answer choices, and that clause is easy to skim past on a fast first read. Set 1's direct-recall stems had no equivalent buried clause to miss; a scenario stem does, every time.
- It's picking a service that's genuinely plausible and vaguely associated with the topic (Aurora "sounds fast," ECS "sounds like the rollback answer") rather than because you traced the stem's specific constraint to that exact option. It's dangerous because it scores identically to real understanding on this paper, but won't survive the real exam phrasing the same scenario with a different constraint that rules your guessed answer out instead.
- A domain score of 3/9 is a concentrated, specific content gap — likely in the escalation, automated-remediation, or EventBridge-routing mechanics this domain leans on — while the flat 75%-ish overall average would have hidden exactly where to focus. Reread Incident & Event Response and redo the missed questions cold in a couple of days before moving on.
- They're scattered through the paper exactly like the real exam's pretest items, unidentified while you're taking it, and don't count toward your score — you only learn which ten they were in the "Score yourself" section, because on the real exam you're never told at all, and treating every question as if it counts is the only sound strategy either way.
That's the full sitting. Reset the timer, close every tab except this one, and let the seventy-five scenarios above show you exactly where "I recognize that service" stops being the same thing as "I picked the right one for this specific story" — then go fix precisely that, and nothing else, before you move on to Set 3.