AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 676–750

AWS CodePipeline webhooks are the native, built-in mechanism for external systems to trigger pipeline executions via an HTTPS POST request. When you create a webhook, CodePipeline generates a dedicated URL and registers a secret token; the external service, such as an issue tracker or a third-party version control system, includes that token in its HTTP call so CodePipeline can verify the request and map the payload to the appropriate pipeline and input variables. This provides secure, bidirectional integration with external tools, enabling an issue tracker to start a pipeline when a pull request or issue is updated, and is the correct service for this scenario.

The OpsWorks Deploy command triggers the deploy lifecycle stage on the stack, running the deployment recipes that update application code and configuration on each registered instance. Because OpsWorks Stacks lets you configure the batch size and pause time, instances are updated one batch at a time while the remaining instances continue serving traffic, which minimizes downtime during the update. This is the native rolling-update mechanism for an OpsWorks-managed stack and directly addresses the requirement to update the existing fleet with minimal service interruption.

The ALB emits TargetResponseTime only when it actually processes requests. For any 5-minute interval in which no request was routed through the load balancer, CloudWatch receives no samples and therefore publishes no datapoint. The get-metric-statistics output contains a datapoint only for each period with at least one request, so periods with no traffic are simply missing from the result rather than appearing as zero. This exactly explains why fewer datapoints than expected are returned.

Target tracking is a dynamic scaling policy that uses a control loop to continuously compute the required capacity needed to keep the CloudWatch metric at the specified target value. Rather than reacting with binary on/off alarms, it applies proportional adjustments based on the current deviation from 50% CPU utilization, smoothing out capacity changes and preventing the overshoot/undershoot cycle that causes oscillation. This gives the Auto Scaling group a clear, single objective that balances responsiveness with stability.

Creating a custom Docker image with the library preinstalled makes the library available at the very start of every build because CodeBuild runs build phases inside that image. Custom images let you pin the exact library version and all transitive runtime dependencies, ensuring reproducibility and eliminating repeated download/compile overhead. This is a best practice when the build consistently requires specialized binaries, libraries, or tools that are not present in CodeBuild's standard managed images.

Removing the count() and bin() aggregation and running a query that returns the raw @timestamp and @message fields around 12:00 will display the actual error strings, stack traces, and exception types that caused the spike. This is the definitive method for root-cause analysis because it lets you see exactly what the application logged at the moment of failure, such as a TimeoutException, a 500 Internal Server Error, or a specific failed database call. You can then filter further using regular expressions or parse commands to isolate the common pattern.

AllAtOnce is a predefined CodeDeploy deployment configuration that sets the minimum healthy instances to 0, causing the deployment to update every target instance simultaneously. This configuration is valid and useful when you accept full fleet downtime during deployment, such as in development environments or for infrastructure with elastic load balancer deregistration. It is one of the named configurations you can select directly in the AWS CodeDeploy console or CLI.

Deploying across multiple Availability Zones (AZs) provides infrastructure-level fault isolation because each AZ has independent power, cooling, and network access. This architecture ensures that an outage in one AZ does not take down the entire workload, supporting a higher availability SLA. For example, running EC2 instances in two or more AZs with an Application Load Balancer allows traffic to continue to healthy AZs even if one becomes isolated.

This is the correct approach because CodePipeline's manual approval action has an 'SNSTopicArn' configuration field that, when set, causes the pipeline to publish an approval notification to the specified SNS topic. Each email address (or other endpoint) subscribed to that topic receives the notification, and any of those subscribers—assuming they have the necessary IAM permissions—can review and approve or reject the action via the AWS console, CLI, or API. This design cleanly supports multiple approvers and also allows you to use other SNS protocols such as SMS or Lambda for custom notification flows.

This is correct because the ECS deploy action in CodePipeline consumes an image definitions file, typically named imagedefinitions.json, formatted as a JSON array mapping each ECS container name to its image URI (for example, [{"name":"web","imageUri":"123456789012.dkr.ecr.us-east-1.amazonaws.com/my-app:latest"}]). CodeBuild generates this file as a pipeline artifact after pushing the image to ECR, and CodePipeline uses it to create/update the task definition and trigger the deployment. The file must be at the artifact root with the recognized name; any other JSON structure or filename will cause the deploy action to fail.

In a blue/green deployment, you provision a second Elastic Beanstalk environment (the green environment) with the new application version, run tests against it, and then use the Swap Environment URLs feature to atomically redirect the existing CNAME to the new environment. This avoids any downtime during the cutover and leaves the old (blue) environment intact for instant rollback if issues arise after the swap.

CloudFormation tracks the AWS::Lambda::Function Code property using the literal values of S3Bucket, S3Key, and optionally S3ObjectVersion. Uploading new code to a different S3 key—or to the same key with a new object version ID—makes one of those template properties change, so a stack update sees a diff and refreshes the Lambda function's code. This is the standard practice because CloudFormation does not automatically compare content hashes or ETags; it relies on explicit property changes. If you reuse the same key and do not specify a version (or S3 versioning is disabled), CloudFormation will not detect the update and the function continues running old code.

The deregistration delay (connection draining) is the time ALB gives in-flight requests to finish after a target is deregistered. On ECS Fargate, when a task is stopped, the ALB stops routing new requests and, if the delay is too short, forcibly closes the connection before long-running requests complete, causing clients to receive 502/503 responses. For high-latency or streaming workloads, the delay must exceed the longest expected request duration.

Creating a custom Docker image that pre-installs all dependencies means those dependencies already exist inside the image's local file system when the CodeBuild container starts, so there is no download phase at all. The build can proceed directly to compilation, packaging, and testing, making the build time deterministic and dramatically shorter for a monolith. This image should be stored in Amazon ECR and updated whenever the dependency set changes, ensuring the build environment is both fast and consistent.

A manual approval action pauses the pipeline at the stage boundary, requiring a nominated approver to review and release the change before production deployment proceeds. This directly satisfies the stem's constraint that manual approval is required before deploying to production, without altering the Test stage or build artefacts.

CloudTrail writes log files to S3 as compressed JSON objects, and S3 Event Notifications fire as soon as each object is created, triggering a Lambda function in near-real-time. The Lambda can decompress the log file, parse individual events, and apply precise filters—such as specific event names, source IPs, or IAM principals—before publishing only the high-risk actions to SNS. This serverless, event-driven pattern scales automatically with account activity and avoids the cost and noise of notifying on every raw CloudTrail event, making it both efficient and cost-effective for high-volume accounts.

AWS Config rules with auto-remediation are the correct choice because they provide continuous monitoring and automated correction. A managed rule like s3-bucket-server-side-encryption-enabled detects non-compliant buckets, and the associated remediation action (via SSM Automation or a custom Lambda) automatically applies SSE-S3 default encryption to the bucket. This is the only option that both detects existing non-compliant buckets and actively modifies their configuration to become compliant, satisfying the organization's requirement in real time.

Setting the minimum and maximum number of instances for the Auto Scaling group is an absolute prerequisite for any elastic scaling in Elastic Beanstalk. These values define the allowed capacity range that the Auto Scaling group can scale within, and without them the Auto Scaling group cannot adjust its size. Every scaling activity, whether scale-out or scale-in, must respect these boundaries, making this a mandatory configuration element.

A 503 status code from the health check endpoint indicates that the target instance is reachable at the HTTP layer, but the application logic serving the root path '/' is returning a Service Unavailable error. Elastic Load Balancing requires a 2xx or 3xx response for the health check to mark the instance healthy; any 4xx or 5xx status counts as unhealthy. Verify that the web server or application is configured to serve '/' with a 200 OK during normal operation and that there are no authentication, redirect, or maintenance-mode rules that cause a 503 on that specific path. This is the correct troubleshooting step because the health check is working as designed—it is detecting an application-level failure.

ECS Service Connect provides a resilient service mesh that simplifies inter-service communication by giving each service a stable DNS name and managing traffic distribution at the application layer. It enables fine-grained traffic splitting, automatic retries, and connection draining, which collectively reduce latency and improve reliability between microservices. This is a direct remedy for latency caused by inefficient service-to-service calls, as it optimizes the network path and avoids overloading individual task instances.

Using a process-only health check (e.g., checking that the PID exists) means the ECS/ALB considers the container healthy whenever the runtime is alive, regardless of whether the app can actually serve HTTP traffic. As a result, intermittent 500 errors caused by a hung worker, exhausted connection pool, or an unhandled exception inside request handling remain invisible to the health check, so the task stays in service and keeps receiving traffic. A valid health check should send a real request to the application's endpoint and verify the response code.

Scaling consumers on ApproximateNumberOfMessagesVisible directly matches fleet capacity to the actual backlog, so added workers drain the queue during peaks and terminate when it empties. This satisfies the latency constraint without over-provisioning, since capacity tracks demand rather than a fixed schedule or CPU proxy.

CodeDeploy treats any non-zero exit code from a lifecycle event script as a definitive failure, regardless of the underlying cause. When the agent executes a script, it captures the process exit status; if it is not 0, the deployment immediately stops, marks the overall deployment as Failed, and runs any configured OnFailure hooks. This is the direct trigger for the failure, even if the script printed an error message before exiting.

A manual approval action in CodePipeline pauses the pipeline at that stage until an IAM user with approval permissions reviews and approves or rejects the promotion. This is the standard control gate between staging validation and production release, satisfying the requirement for a deliberate go/no-go decision before any prod traffic is changed.

If the instance security group does not allow inbound traffic from the ALB's security group on the health-check port, the ALB's TCP or HTTP health-check probes are silently dropped. Because the instance never completes the health-check handshake, the target fails the required number of consecutive checks and the ALB marks it unhealthy. This is a classic misconfiguration that often appears right after adding the ALB, and it also blocks normal client traffic routed by the load balancer.

The `--disable-rollback` flag on `aws cloudformation update-stack` instructs CloudFormation to leave the stack in its failed state instead of reverting to the previous successful template. This is the correct way to prevent rollback because it preserves the partially updated resources—including any S3 buckets, EC2 instances, or custom resources—for root-cause analysis and manual remediation. The stack status becomes `UPDATE_FAILED`, and the original resources remain untouched until you intervene.

Upgrading to BUILD_GENERAL1_MEDIUM is the correct fix because CodeBuild compute tiers directly define the memory and vCPU available to the build environment: GENERAL1_SMALL provides 3 GB, while GENERAL1_MEDIUM provides 7 GB. This increases the total addressable memory for the Maven JVM, native code, and metaspace, directly resolving the OutOfMemoryError without altering the application or its dependencies. It is also cost-effective because you only pay for builds that use the larger compute type, and the price increase is modest compared to the engineering effort of optimizing memory usage.

The AWS Batch job definition includes a `timeout` field that sets the maximum duration a job attempt is allowed to run before Batch forcibly terminates it as a timeout. Increasing this value to 3600 seconds (60 minutes) directly accommodates longer video processing tasks, preventing premature termination when the workload legitimately needs more than the current limit. This is the intended control for adjusting how long Batch permits a single job attempt to execute.

Attaching a customer-managed IAM policy with an explicit 'Deny' effect for all actions on all resources immediately revokes both console and programmatic access for the compromised users. IAM's evaluation logic gives explicit denies precedence over any allow, so even if the user still has attached policies with broad permissions, the deny-all policy overrides them. This containment action preserves the user objects and their audit trail for forensic analysis, allowing you to safely investigate and later rotate credentials or delete the users if needed. Unlike disabling keys or changing password policies, this approach covers all access methods simultaneously.

For a custom AWS Config rule to evaluate a resource on configuration changes, the rule's scope must include that resource type. If the rule is defined without AWS::EC2::Instance in its 'Resource types' scope (or if it is scoped to a specific tag/resource ID that does not match), AWS Config will not send evaluation events to the Lambda function for EC2 instances. In this scenario, the rule has the correct trigger type (change) but its scope does not cover EC2 instances, so Config never invokes the Lambda function on instance launch. This is the exact cause of the DevOps team's issue.

This pattern combines an AWS Direct Connect private or public virtual interface with an IPSec Site-to-Site VPN to create a dedicated, private, and encrypted link from your data center to AWS. Direct Connect ensures a consistent, low-latency connection that does not traverse the public internet, while the VPN overlay encrypts all IP traffic between your edge and the AWS virtual private gateway. The combination satisfies both the encryption mandate and the need for predictable, dedicated bandwidth, making it the best choice for this scenario.

In a target group's health-check settings, increasing the interval spaces out probe requests, while increasing the unhealthy threshold demands more consecutive failures before an instance is marked unhealthy. Together, these settings build a longer smoothing window: sporadic errors such as brief 503s during a rolling deploy or dependency hiccup will not immediately cause a healthy instance to be replaced. The instance remains in service and in rotation until the failures are sustained over an extended period, which is exactly the desired behavior when the goal is to reduce replacement churn. The trade-off is that genuinely dead instances take longer to detect, but that is acceptable in many critical applications that favor stability over instantaneous failover.

CloudFormation emits stack status change events to CloudWatch Events (Amazon EventBridge) whenever a stack transitions to a terminal state. A rule can filter for detail-type 'CloudFormation Stack Status Change' and the 'status-detail' of 'CREATE_FAILED', then route the event to an SNS topic. This is the native, event-driven mechanism for receiving notifications about stack creation failures, and it includes the stack name and status in the event payload.

VPC Flow Logs capture IP traffic metadata for ENIs in the VPC, recording fields like source address, destination address, port, protocol, and the action — ACCEPT or REJECT — for each connection. By publishing flow logs to Amazon S3 and using Amazon Athena with its SerDe, you can run SQL queries to filter on action = 'REJECT' and aggregate the denied connection attempts by source IP, port, or time. This directly reveals which connections are being blocked, making it the correct way to investigate denied traffic.

IRSA associates a Kubernetes ServiceAccount with an IAM role by annotating the ServiceAccount with the role ARN and configuring an OIDC trust policy. A projected service account token is exchanged via STS AssumeRoleWithWebIdentity for short-lived AWS credentials, and the AWS SDK automatically reads AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE. This gives each microservice a distinct IAM role with scoped permissions and no long-lived keys stored in the cluster.

CloudWatch Logs for CodeDeploy is the correct source because it centralizes deployment events and error messages. When you configure a log group for the deployment group, lifecycle event execution details—such as BeforeInstall, AfterInstall, ApplicationStart, and the associated script output—are streamed into CloudWatch Logs. This lets you query and filter by deployment ID and instance ID, making it the fastest way to identify which lifecycle hook failed and why, rather than logging into individual instances.

Amazon CloudFront is a global content delivery network that terminates connections at edge locations and can be configured with multiple origins, including an origin group where the primary origin's failure triggers automatic failover to a secondary origin. This origin failover is initiated when the primary returns specific HTTP error codes or fails connection attempts, making it a key component for routing requests to a healthy Region. Additionally, edge caching shields the origin and improves performance, which is essential for a globally resilient application.

IAM policy conditions using the Condition element enable you to scope permissions by context keys such as aws:SourceIp or aws:CurrentTime. This allows you to enforce geofencing or business-hours-only access, reducing the blast radius of stolen credentials. For example, a Deny statement with a condition can block all access outside a corporate CIDR range.

AWS Config is the correct service for managing configuration drift because it continuously records and evaluates the configuration of AWS resources against desired baseline rules. When a resource's configuration changes from the recorded baseline, AWS Config flags it as noncompliant, providing a precise, rule-driven mechanism to detect drift. You can define custom or managed rules that represent your desired state, and AWS Config will produce a detailed compliance history and configuration timeline for every tracked resource, enabling automated remediation via Systems Manager Automation or Lambda.

Reserved concurrency caps the number of concurrent executions for the function. When all slots are busy, Lambda immediately rejects new invocations with a Throttle error. Because the code never starts, no START/END/REPORT lines are emitted, so CloudWatch Logs for the function remain empty. The S3 event notification will retry for a few hours, but each throttled attempt leaves no log.

The source action's branch filter ensures the pipeline only starts when commits are pushed to main, preventing feature branch work from entering the pipeline. The manual approval step immediately preceding the production deployment stage provides a human gate before the final artifact is deployed, meeting the requirement to require approval for production releases while keeping lower environments automated. This arrangement minimizes unnecessary builds and accurately enforces change management only where needed.

Elastic Beanstalk saved configurations provide a native way to snapshot an environment's option settings, environment variables, and solution stack into a re-usable YAML file. You can save a known-good configuration using the console or `eb config save`, and later restore it to the same or a different environment to roll back any undesired changes. Because saved configurations are purpose-built for this scenario, they give you an auditable, restorable record of environment settings without requiring code deployments or external tools.

The dynamic reference syntax {{resolve:secretsmanager:secret-id:secret-string}} is correct because CloudFormation resolves it to the actual secret value at stack creation or update time. The full syntax allows you to specify a JSON key, version stage, or version ID, giving you precise control over which secret value is injected into a resource property. CloudFormation calls GetSecretValue on your behalf, so the secret never appears in the template, change sets, or the rendered stack template. To use this, ensure the CloudFormation execution role has the secretsmanager:GetSecretValue permission for the target secret.

An Auto Scaling group configured across multiple Availability Zones automatically distributes instances among those AZs and enforces the desired capacity by replacing any instance that fails its health checks. This provides both high availability and operational automation: if an entire AZ becomes impaired, the ASG launches replacement instances in the remaining healthy AZs, and it also performs capacity rebalancing when AZs become imbalanced. Combined with an Elastic Load Balancer, this is the standard AWS pattern for building a fault-tolerant, self-healing application tier.

Amazon S3 event notifications are designed with at-least-once delivery semantics, meaning the same s3:ObjectCreated:Put event can be delivered more than once, especially during retries or internal service-side replication. Each delivered notification is seen by CodePipeline as a new source change, so a single object upload can start duplicate pipeline executions. Versioning is irrelevant to this behavior because the duplicate is a delivery-level retry, not a new object version.

This is the correct cause. CloudWatch Logs acts under the service principal logs.amazonaws.com when performing server-side encryption with an AWS KMS customer managed key. If the KMS key policy does not include a statement granting this principal the kms:Encrypt and kms:DescribeKey actions (and denies are absent), the service cannot encrypt the log events. In such a case, log delivery may continue to succeed but the data is stored without the intended encryption, exactly matching the symptom described.

EBS volumes are network-attached block storage that exist independently of the EC2 instance lifecycle, so when an instance terminates the volume can be detached and reattached to a replacement instance. Data written to an EBS volume survives Auto Scaling scale-in as long as the volume's DeleteOnTermination attribute is set to false and the application writes to that mount point. This approach makes application state durable across instance replacements without requiring a distributed storage architecture or application code changes, because the application still sees a standard block device.

SCPs set the maximum permissions for member accounts, so denying retention changes except for a governance role prevents developers from shortening retention. Combined with a StackSet or Config rule that establishes the 400-day baseline, this gives centralized, drift-resistant enforcement across all accounts, including future ones, which matches the requirement.

When a resource is deleted outside of Terraform, the state still contains the old resource until a refresh reconciles it with the live AWS inventory. Running terraform plan without a preceding terraform refresh — or with refresh explicitly disabled — lets Terraform compare configuration only against stale state, so it concludes the rule still exists and reports no changes. A manual deletion is exactly the kind of drift that refresh is designed to detect; skipping it hides the missing security group rule from the planner.

The Setup lifecycle event runs recipes when an instance is added to the layer, so security patches and logging-agent configuration apply automatically. This satisfies the requirement for automatic onboarding without manual intervention on each new instance.

CodeDeploy enforces a minimum number of healthy hosts as a safety condition, and when the deployment group has exactly one instance, any positive minimum healthy host count makes an in-place deployment impossible. With a setting of 100% or 1, taking that only instance out of service to deploy to it would reduce the healthy host count to 0, violating the constraint and aborting the deployment at the very start. The error message specifically mentions that the deployment was aborted because the minimum number of healthy hosts was not met.

AWS CloudTrail is the purpose-built service that records every API call made in your AWS account as an event, including the identity of the caller, the source IP address, the requested action, and the response returned. It supports management events, data events, and CloudTrail Insights events, and it can deliver these immutable audit logs to an S3 bucket or CloudWatch Logs for retention and analysis. As the only option that natively records API activity, CloudTrail is the correct choice for auditing all API calls.

Clearing a CodeBuild project's cache removes previously downloaded dependency artifacts, such as those stored in the local Maven repository (~/.m2) or in an S3 cache bucket. On the next build, Maven must reach out to remote repositories to re-download every JAR it needs, adding significant network and I/O time on top of the compile itself. Because the buildspec commands are unchanged, the only impact is that dependency resolution is no longer incremental, directly explaining the increased build duration.

Instrumenting the application with AWS X-Ray creates an end-to-end trace for each user request as it traverses your application, generating a service map and detailed segments/subsegments for each downstream call (e.g., web APIs, SQL queries, external HTTP calls). This lets you pinpoint which specific operation contributes the most latency on EC2, including CPU-bound code vs. I/O wait, and correlate trace data with host metrics. Unlike other options, X-Ray provides the distributed tracing needed to identify and reason about internal request bottlenecks in a complex application.

The health check grace period for the Auto Scaling group is too short. When an Auto Scaling group launches a new instance, it waits for the health check grace period before evaluating the instance's EC2 health status. If this period expires before CodeDeploy has installed and started the application, the ASG may consider the instance unhealthy and terminate it, interrupting the deployment. This causes the deployment to fail on those instances, even though the CodeDeploy agent and IAM permissions are fine. The correct fix is to increase the ASG health check grace period to cover the full deployment duration, including bootstrapping and application startup.

AWS WAF is a web application firewall that integrates directly with an Application Load Balancer to inspect and filter HTTP(S) requests before they are forwarded to your EC2 instances. It provides managed rules specifically designed to detect and block common web exploits, including SQL injection and cross-site scripting, and you can define custom rules to handle unique business logic. This is the appropriate service to stop malicious requests from ever reaching the web server, directly addressing the requirement for protection against web exploits.

No action is required because the CloudFormation service applies a mutual-exclusion lock to each stack: from the moment an UpdateStack call is accepted until the update, rollback, or clean-up finishes, any subsequent UpdateStack, DeleteStack, or ExecuteChangeSet operation on the same stack is rejected with a ValidationError such as 'Stack is currently in an update state'. This built-in serialization prevents concurrent modifications and preserves stack consistency without any downstream code, IAM policy, or auxiliary lock. Therefore, the design is already safe, and adding extra mechanisms is redundant.

This statement uses an explicit Deny on all s3:* actions, conditioned on aws:SecureTransport being false. Any request made to the bucket over plain HTTP is therefore blocked regardless of the principal or whether an Allow policy exists; HTTPS requests are not affected by this Deny. The effect is to require TLS for every S3 API operation on the bucket.

Amazon CloudWatch Logs is the correct choice because it can centrally aggregate logs from multiple AWS accounts, Regions, and on-premises sources via the CloudWatch Logs agent, Kinesis Data Firehose, or subscription filters. It provides native log analytics with Logs Insights, metric filters to create custom metrics, and CloudWatch Dashboards to visualize log-derived data in real time. This directly satisfies the need for centralized collection, analysis, and dashboard visualization without requiring additional services.

Amazon CloudWatch is the native monitoring service for Amazon RDS, automatically collecting and storing database metrics such as CPU utilization, free memory, read/write throughput, and ReplicaLag for MySQL read replicas. These metrics are published as time-ordered data points and can be visualized on dashboards, trigger alarms via Amazon CloudWatch Alarms, and feed AWS Auto Scaling. With Enhanced Monitoring, it can also expose OS-level metrics, making it the correct source for diagnosing load and replication issues.

AWS CloudTrail is the correct service for auditing IAM policy changes because it records every API call as an event, including the identity of the requesting principal, the timestamp, source IP, request parameters, and response elements. You can view these events directly in the CloudTrail event history or create a trail for long-term storage in S3 and analysis via CloudWatch Logs or Athena, making it the authoritative audit source.

CodePipeline automatically starts an S3 source only when the bucket is configured with an event notification that sends object-created events to the pipeline's trigger. Typically, this is implemented via an Amazon S3 event notification targeting an Amazon EventBridge rule, or via a CloudWatch Events rule that filters on the bucket's PUT operations. Without that configuration, uploading a new file to the bucket does not cause the pipeline to initiate, leaving it in a 'Succeeded' or previous state until a manual release is triggered. This exactly matches the reported symptom.

AWS WAF provides application-layer (Layer 7) inspection and can be associated directly with an ALB. By creating a web ACL that references an IP set containing the offending client IP and setting the default or custom rule action to 'Block', requests from that IP are denied before they reach the ALB. This is the purpose-built, scalable mechanism for IP-based blocking in front of an ALB, and it can be implemented without altering routing or security group configurations.

When an update fails and the automatic rollback is also unsuccessful, CloudFormation leaves the stack in the UPDATE_ROLLBACK_FAILED state. The ContinueUpdateRollback API or console action is the designed recovery mechanism; it retries the rollback of resources that failed, allowing you to skip resources with known issues and restore the stack to a usable state before fixing underlying problems and reattempting the update.

CodeArtifact acts as an intermediary upstream repository, caching packages from public registries such as npmjs, Maven Central, or PyPI. When CodeBuild first requests a dependency, CodeArtifact fetches it from the public source and stores a copy in your domain; subsequent builds retrieve the cached copy directly from CodeArtifact. This reduces external network round trips, minimizes build-time latency, and protects against upstream outages or sudden changes in public repositories.

RDS cross-region automated backups continuously copy automated backups and applicable transaction logs from the source DB instance to a destination AWS Region without manual intervention. This allows the database to be restored to a specific point in time, or to the latest restorable time, in the secondary region, making recovery from a regional outage repeatable and largely automated. Because the backups are managed by RDS and restored through the standard restore workflow, this option directly supports automated cross-region recovery.

When you specify a tag in the Tags parameter of the AWS CloudFormation stack, CloudFormation automatically applies that tag to every resource in the stack that supports tagging during stack creation and update operations. This is a native cloudformation capability that propagates the tag at launch time, ensuring the CostCenter tag is consistently applied without custom code or post-creation processing. Resources that do not support tagging are the only exceptions, but the tag is applied to all taggable resources as part of the stack lifecycle.

Denying s3:DeleteObject via an SCP on the CloudTrail log bucket is correct because it directly protects the integrity of historical audit logs. Even if a user in a member account has IAM permissions to call cloudtrail:StopLogging or cloudtrail:DeleteTrail, they cannot destroy the existing evidence stored in S3, and the trail will continue to deliver new logs as long as it is active. This is a critical safeguard because attackers often attempt to delete logs to hide their activity, and SCPs provide a central, unchangeable control across all member accounts.

IteratorAge is the correct metric to monitor for Kinesis-triggered Lambda because it directly measures the age of the oldest unprocessed record, reported in milliseconds. When the Lambda consumer can't keep up with the shard's data rate, the iterator age grows, indicating that stream records are sitting unprocessed for longer — a clear sign of a processing bottleneck or backlog. A sustained increase in IteratorAge typically drives alarms for scaling out the Lambda function or increasing the number of shards, making it the definitive indicator of stream processing lag.

This design completely addresses the SAM pipeline lifecycle: a CodeBuild stage runs `sam package`, which uploads the function code and dependencies to S3 and writes a packaged template that CloudFormation can parse. Each environment's deploy stage then runs `sam deploy` (or uses the packaged template with CloudFormation) under environment-specific parameters, and a manual approval action preceding each higher environment provides the required release gate. Because every stage is a separate CodePipeline stage, approvals are isolated and promotions are sequential, preventing any single action from accidentally deploying to all environments.

In CodeDeploy, lifecycle hook scripts (such as BeforeInstall) run on the target instance and use the instance's IAM role, not the CodeDeploy service role. If the S3 object is encrypted with an AWS KMS customer-managed key, the script's `aws s3 cp` or `aws s3api get-object` call requires both s3:GetObject on the bucket/object and kms:Decrypt permission for that key. Even if s3:GetObject is allowed, lacking kms:Decrypt causes the S3 client to fail with an AccessDeniedException when it attempts to retrieve the plaintext, making the lifecycle hook exit non-zero and the deployment fail. This is the exact scenario that produces a script failure pointing to encryption authorization.

Adding an Approval stage to the CodePipeline with an SNS topic is the correct approach because the approval action pauses all subsequent stage transitions until a designated reviewer clicks Approve (or Reject) in the console or invokes PutApprovalResult. The SNS topic sends email or other notifications to the approver, and the pipeline resumes only after the approval token is returned. This provides a auditable, controlled human decision point that is natively supported by CodePipeline.

RDS does not natively perform cross-region automatic failover to a read replica. You must implement custom health monitoring, for example using Route 53 health checks or a Lambda function, to detect primary DB instance or AZ failure; upon detection, the automation invokes PromoteReadReplica to convert the replica into a standalone primary and then updates application DNS or database endpoints to redirect traffic. This is the only way to achieve the stated automated failover objective.

Creating a new launch template with a fully patched AMI and updating the Auto Scaling group to use it enables an instance refresh, which performs a rolling replacement of all current instances without downtime. This immutable infrastructure pattern guarantees that every launched instance is patched from the start, eliminating any configuration drift. An instance refresh gradually replaces instances while respecting the ASG's health check and minimum capacity, so application availability is maintained throughout the process.

This is correct because ec2:ResourceTag/Environment is the IAM condition key that checks the value of the Environment tag on the EC2 resource (instance, volume, etc.) that the request targets, and StringEquals ensures the tag must exactly equal "Production". By adding this Condition block to the policy statement, the allowed actions are only granted when the resource being acted upon carries that tag, effectively scoping permissions to Production instances. This is the standard pattern for tag-based, resource-level access control for EC2.