Practice Set 2: every answer explained.

Why B

CodePipeline emits three distinct event granularities — pipeline, stage, and action. The requirement is a stage-level failure for one named pipeline, so the pattern must combine the "CodePipeline Stage Execution State Change" detail-type with both a FAILED state and a pipeline filter. The pipeline-execution pattern is the wrong granularity and, because it omits the pipeline field, it would also match failures from every other pipeline in the account. The action-execution pattern fires once per failing action, which is exactly the retry-level noise the team wants to avoid. The CodeBuild pattern only observes the build project and would stay silent when the Test or Deploy stage fails.

Why A

A CodeDeploy deployment group can roll back automatically on deployment failure, when a specified CloudWatch alarm threshold is met, or when a deployment is stopped — the first two are the checkboxes exposed in the console. Wiring a 5xx-rate alarm into the deployment group covers exactly the case described here, where the deployment itself succeeds but the service degrades afterwards. The claim that rollback is limited to in-place EC2 deployments is wrong — on-premises instances and blue/green deployments support it as well. SNS triggers are notification-only and have no acknowledgement semantics that could drive a rollback. And the option asserting that no automatic rollback exists contradicts the advanced settings on every deployment group.

Why B

The pre_build phase is for preparation that the build itself depends on — authenticating to the registry, resolving the repository URI, and computing the image tag. Retrieving an ECR authorization token and piping it into docker login is the canonical pre_build step. Building the image is the work of the build phase, and tagging it can only happen after the image exists, so it belongs to build as well. Pushing the image must wait until the build has produced and tagged it, which places it in post_build.

Why C

CodePipeline has a native ECR source action and a native Amazon ECS (Blue/Green) deploy action that delegates the traffic shift to CodeDeploy, giving you the validation window and automatic rollback without custom work. Amazon ECS has since added its own built-in blue/green deployment strategy that does not involve CodeDeploy at all, and it is now the simpler starting point for greenfield services — but of the four approaches offered here, the CodeDeploy-backed pipeline action is the one that meets the requirement. Adding a CodeBuild stage to rebuild an image that already exists is wasted work, and driving the ECS service through CloudFormation gives up the managed blue/green traffic shifting. CodeDeploy alone cannot form a pipeline — it has no source stage and will not react to an ECR push on its own. Self-managing Jenkins and hand-rolling the traffic shift is the most operational overhead of the four, not the least.

Why A

A change set is CloudFormation’s preview mechanism: the CHANGE_SET_REPLACE action mode computes the diff without touching resources, a manual approval action pauses the pipeline for a human to read it, and a second action with the CHANGE_SET_EXECUTE mode applies it once approved. A stack policy can block specific updates but shows nobody what a deployment intends to do, so it prevents rather than reveals. Deleting and recreating the stack destroys data and causes a long outage. CodeDeploy deploys application revisions to compute targets and cannot manage CloudFormation stacks at all.

Why B

Swapping environment CNAMEs is Elastic Beanstalk’s blue/green pattern. The new version is fully warmed and validated in its own environment before any customer reaches it, and rolling back is simply a second swap, which takes effect as soon as DNS resolves again. Rolling updates and immutable updates both replace instances inside the live environment, so recovering from a bad release means deploying the old version again rather than flipping a switch. Redirecting the old environment with a 301 changes the URL customers see and browsers cache permanent redirects aggressively, which makes the rollback unreliable.

Why B

Elastic Beanstalk has a purpose-built application version lifecycle policy that deletes versions once they exceed a maximum count or age. Deleting the source bundle from S3 is a separate opt-in setting on that policy — by default Beanstalk leaves the bundle in place to avoid data loss. The policy is native, requires no code, and never removes a version that is currently deployed to an environment or to one terminated within the last ten weeks. A scheduled Lambda function achieves a similar result but adds code, permissions, and failure modes for something the platform already does. An AWS Config rule only reports on the condition and would still leave the team to clean up by hand. An S3 lifecycle rule deletes the bundle objects but leaves the application version records in place, so the version limit is still reached.

Why A

Drift detection is the feature for out-of-band changes that already happened: it inspects each supported resource, compares it with the properties CloudFormation expects, and reports each one as IN_SYNC or MODIFIED with the exact property differences. That is precisely the console-edit scenario described. A change set looks forward rather than backward, previewing what a proposed update would do to a stack that is assumed to be in its expected state. A stack policy is a guardrail that permits or denies updates and reports nothing. Rollback triggers watch CloudWatch alarms during an in-progress update and can abort it, which does not help once the update has long finished.

Why D

DependsOn is the explicit ordering mechanism — CloudFormation will not begin creating the application server until the database has reached CREATE_COMPLETE. Position in the template is irrelevant because CloudFormation parallelizes creation and derives ordering only from references and DependsOn, so reordering the Resources section changes nothing. CloudFormation resources are flat; there is no parent-child nesting of one resource inside another. A bare WaitCondition with a long timeout only makes the stack sit and wait — without a signal from the application it eventually fails, and it still does not sequence the two resources.

Why C and E

A CreationPolicy with a ResourceSignal tells CloudFormation to hold the resource in CREATE_IN_PROGRESS until it receives the expected number of success signals or the timeout expires, and the cfn-signal helper script sends that signal from the end of the bootstrap. The two work only as a pair — the policy without the signal times out, and the signal without the policy is discarded. A stack policy governs which resources an update may change and has no bearing on creation status. Auto Scaling lifecycle hooks apply to instances launched by an Auto Scaling group, not to a standalone instance resource. A DeletionPolicy only controls what happens when a resource is removed.

Why A and E

CloudFormation custom resources support exactly two provider types: an SNS topic, which fans the request out to whatever is subscribed, and a Lambda function, which is by far the more common choice. Both are supplied as ARNs. An SQS queue, an EventBridge rule, and a Step Functions state machine are not valid ServiceToken targets. The failure is not a template validation error — ServiceToken is typed as a plain string, so the template parses and the stack operation fails later, when CloudFormation cannot deliver the request to the target and the custom resource times out. A state machine name rather than an ARN would be invalid regardless, since ServiceToken always takes an ARN.

Why C

NoEcho is the parameter attribute built for this: when it is true, CloudFormation returns the value as a row of asterisks in the console, in describe-stacks responses, and in stack events. There is no Hidden parameter attribute and no generic Password resource property in CloudFormation — both would fail template validation. The stack Metadata section is free-form documentation that CloudFormation never interprets, so marking a parameter sensitive there changes nothing. NoEcho masks display only; for real secret management, reference AWS Secrets Manager with a dynamic reference so the value never enters the template at all.

Why D

Systems Manager Automation is the managed runbook engine, and EventBridge is what turns an alarm state change into an invocation. Systems Manager reaches the instance through the SSM Agent rather than an inbound port, so no SSH ingress is needed, and every execution is recorded with its steps, parameters, and output. Paging a human meets the audit requirement but not the automation one, and it is slow at three in the morning. An hourly cron job ignores the alarm entirely, so it either runs when nothing is wrong or waits up to an hour when something is. Having Lambda open an SSH session reintroduces the inbound access the requirement rules out and means managing keys and network paths by hand.

Why C

Weighted routing covers both release patterns: a blue/green cutover is a weighted record set flipped from 100/0 to 0/100, and a canary is the same mechanism moved in small increments. Failover routing is the policy designed for active-passive disaster recovery, promoting the standby record only when the primary’s health check fails. Latency routing sends users to the Region with the best response time, which the operator cannot control, making it unsuitable for a deliberate release cutover. Simple routing offers no traffic split at all, so it cannot express a canary.

Why B and C

RTO and RPO define how quickly the business must be serving traffic again and how much data it can afford to lose; those two numbers are what separate backup and restore from pilot light, warm standby, and multi-site active-active. Budget is the other primary input, because each step up that ladder costs materially more to keep running. Instance types, database engine, and load balancer type are downstream implementation details that follow from the strategy — and in most designs they simply mirror what production already uses, so answering them first tells the engineer nothing about which strategy to pick.

Why C

S3 Cross-Region Replication copies each log file to a bucket in another Region automatically as it is delivered, which keeps the audit history readable if the original Region becomes unavailable. Encrypting the bucket with KMS protects confidentiality but does nothing for availability. A CloudTrail trail delivers to exactly one S3 bucket, so there is no second destination to configure in the console. A scheduled Lambda copier could work but reimplements a native S3 feature, adds code and IAM permissions to maintain, and leaves a replication gap between runs.

Why D

Scaling in is driven by a CloudWatch alarm on the group’s aggregated metric wired to an Auto Scaling scaling policy, which lowers desired capacity and lets the group terminate an instance according to its termination policy. A complete design also needs a matching scale-out policy, since a scale-in policy alone would shrink the group and never grow it back. An SQS queue is a message buffer and cannot act on an Auto Scaling group. The load balancer routes and health-checks traffic; it never changes group capacity. Paging a human works but is manual, slow, and not the automation the requirement asks for.

Why B and D

Dedicated Hosts expose the underlying physical server, including its sockets and cores, which is what a socket- or core-bound license needs. License Manager is the service purpose-built for the reporting half: a license configuration encodes the entitlement and its rules, it tracks consumption as instances launch, and a CLI call returns current usage that a pipeline step can gate on. The two services are formally coupled — AWS requires Dedicated Hosts when the counting type is Cores or Sockets. Maintaining a DynamoDB ledger reimplements that tracking by hand and drifts the moment an instance is launched outside the pipeline. Reserved Instances are a billing construct and Elastic IPs are network addresses — neither pins a workload to particular hardware. An AWS Config rule counting instances misses the point when the license is measured in sockets or cores rather than instance count.

Why A

Centralizing the logs in CloudWatch Logs solves the disappearing-instance problem, and metric filters plus Logs Insights let the team search across the whole fleet and turn recurring error patterns into metrics and alarms without leaving AWS. Forwarding those same logs to an external tool adds a dependency and cost for capability CloudWatch already provides. Invoking a Lambda function per error builds a custom log pipeline with no search interface and no retention story. AWS Config records resource configuration changes and has no concept of application logs at all.

Why B

Elastic Load Balancing access logging is optional and off by default. Until it is enabled and pointed at a bucket with a policy that lets the service write to it, no objects are ever delivered — which matches the completely empty bucket. Missing IAM permissions would produce an access denied error rather than an empty listing. The remaining two options describe a data flow that does not exist: the load balancer writes access logs from its own observation of the connections it handles, so neither the Auto Scaling group nor the registered instances send it anything to log.

Why C

A CloudWatch dashboard widget can source its metrics from any Region, so one dashboard can present all five side by side and give on-call a single pane of glass. Building one dashboard per Region is the manual workaround the requirement is explicitly trying to eliminate. There is no mechanism for registering an instance with CloudWatch in a different Region — metrics are published to the Region the resource runs in. And the claim that cross-Region visualization is impossible is simply false; only the storage of metrics is Regional, not their display.

Why D

CodeGuru Profiler works by running a low-overhead agent inside the live application, aggregating stack traces, and presenting them as a flame graph in which the widest frames are the methods burning the most CPU — alongside recommendations that often translate directly into smaller instances. Profiler can surface anomalies in latency and CPU profiles, but it does not perform deployments and therefore cannot roll one back. Heap analysis is a genuine Profiler feature, but memory is not the reported symptom here; CPU spikes and latency are. CodeGuru Reviewer is a static analysis tool for source code and pull requests and never observes a running process.

Why C and D

Standby is the direct answer: Amazon EC2 Auto Scaling does not run health checks on an instance in a standby state, and the instance is deregistered from the target group while it keeps running and stays reachable over SSH or Systems Manager. A launching lifecycle hook is the other route, because it holds a new instance in Pending:Wait before it is ever health-checked. Note the timeout arithmetic: the hook’s heartbeat timeout accepts 30 to 7200 seconds and defaults to 3600, so 24 hours cannot be set on the parameter directly — you reach it by calling RecordLifecycleActionHeartbeat to reset the clock, bounded by a global wait-state limit of 48 hours or 100 times the heartbeat timeout, whichever is smaller. Reverting the AMI removes the very instances the engineer wants to examine. Switching the group’s health check type away from ELB would stop the terminations, but it blinds the group to unhealthy instances fleet-wide, which the requirement rules out. Lowering desired capacity gives no control over which instance is terminated.

Why D

Service last accessed data is produced by IAM access advisor, and it can be generated for an organizational unit or the whole organization from the management account, which is precisely the scoping input the operator needs. The AWS Organizations console manages accounts, OUs, and policies; it does not display access advisor data. AWS Config records resource configuration state and compliance, not which principals called which services. Resource Groups collects and tags resources for bulk operations and reports nothing about service usage history.

Why A

An API Gateway resource policy is a policy attached to the API itself and can express both required conditions in one document — an aws:SourceIp condition for the office ranges and an AWS account or role principal for the two permitted accounts. The account half only takes effect when the methods use IAM authorization, since a request must be SigV4-signed for API Gateway to know which account it came from. IAM policies alone govern what identities in those accounts may do and cannot restrict by source IP at the API, and adding AWS WAF brings request filtering but not the account-level restriction. Caching is a performance feature and CloudTrail is an audit trail; neither blocks a request. A resource policy that allows the office ranges from any AWS account enforces only half the requirement, since any AWS account could then call the API from an office address.