AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 226–300

Configuring CodeBuild to use a VPC with a NAT gateway is the correct solution because it provides a deterministic, controlled egress path for outbound internet traffic. By running the build in private subnets behind a NAT gateway that routes via an Internet Gateway, the build environment can reliably pull layers from Docker Hub, install packages, and access private VPC resources. This overrides the default AWS-managed network's unpredictable connectivity and gives you proper security group and routing control, making the build network behavior explicit and dependable.

This is correct because CodeDeploy natively supports Lambda deployment with canary, linear, and all-at-once traffic-shifting strategies, letting you validate a new version before promoting it. CodeBuild runs automated tests first, then CodeDeploy updates the Lambda alias gradually, monitoring CloudWatch alarms for automatic rollback. This is the AWS-recommended managed deployment path for serverless applications.

Creating a custom Docker image that includes all required software and pushing it to Amazon ECR lets you reference that image in the CodeBuild project's environment, so CodeBuild launches build containers from a pre-baked image. This avoids repeated package installation on every run, significantly reducing build time and removing dependence on internet-accessible package repositories during the build. The image provides a deterministic and immutable toolchain, which improves reproducibility, and you can version the image (using tags or image digests) and update it via its own build pipeline for rolling upgrades.

Granting cloudwatch:PutMetricData only authorizes the API call; it does not construct or complete it. The Lambda function must send a MetricDatum object that includes both a MetricName and a numeric Value (or StatisticValues/Values), along with other optional fields like Dimensions and Timestamp. If these required fields are missing or empty, the API call cannot create a metric data point, regardless of how permissive the attached IAM policy is.

The warm standby pattern keeps a fully functional, scaled-down copy of the application running in the DR region, so the entire stack is ready for production traffic almost immediately after failover. RDS data is continuously replicated to the DR region (via cross-region read replicas or Aurora global replication), keeping the RPO near zero—well within the 15-minute target. Because compute, storage, and networking are already provisioned, RTO is also met by simply scaling up and shifting traffic rather than building infrastructure from scratch.

A spread placement strategy with the field attribute:ecs.availability-zone explicitly distributes tasks evenly across the Availability Zones used by the cluster or service. For Fargate, this strategy works in conjunction with your VPC subnets, ensuring tasks are placed in each configured AZ before any are duplicated. This directly satisfies the requirement that a single AZ failure does not take down all instances of the microservice.

Amazon CloudWatch Container Insights automatically discovers and collects pod-level metrics from Amazon EKS, including CPU, memory, network, and disk utilization, and presents them through pre-built dashboards. By defining CloudWatch Alarms on these metrics, operators receive proactive notifications when thresholds are breached, making this a fully managed, integrated solution for monitoring and alerting on container resource usage.

Deploying the application in a second AWS Region and using Route 53 failover routing gives you active-passive or active-active DNS-level failover: Route 53 health checks continuously monitor the primary endpoint, and when it is unhealthy, DNS queries are answered with the secondary Region's IP addresses. This directly addresses an entire Region becoming unavailable, as long as the secondary Region has the resources and the data needed to serve traffic. For a critical application, combine this with RDS Cross-Region Read Replicas or Aurora Global Database for proper data durability.

SSE-S3 is correct because it is Amazon S3's built-in server-side encryption that requires no additional configuration that the customer must perform. With SSE-S3, Amazon owns and manages the encryption keys on your behalf, using AES-256 with 256-bit keys, and applies encryption automatically to new objects written to S3. This provides a simple, fully managed, and effortless way to encrypt data at rest, aligning exactly with the stated requirement.

An Auto Scaling group with a desired capacity continuously monitors instance health via EC2 status checks and optionally Elastic Load Balancing health checks, automatically terminating and relaunching failed instances. By spreading the ASG across multiple Availability Zones and setting the desired count, you ensure that if an instance or an entire AZ fails, replacement capacity is launched to maintain the required number of instances, making this a core high-availability mechanism.

Enabling MFA for privileged users requires a second authentication factor, so a stolen or phished password alone cannot produce a console login or an authenticated API call. This control directly blocks account takeover from reused passwords, keylogging, or credential stuffing, because the attacker must also possess the virtual or hardware token. AWS recommends enforcing MFA with an IAM policy that explicitly denies actions unless aws:MultiFactorAuthPresent is true, which makes MFA mandatory rather than optional.

This configuration provides global DNS-level failover by associating Route 53 health checks with endpoints in each region. If the primary region's health check fails, Route 53 automatically rewrites DNS responses to direct traffic to the standby region, with failover typically occurring within a few minutes depending on TTL and health-check intervals. However, this requires the application to be designed for multi-region operation, with data replication between regions and compute capacity pre-provisioned in the secondary region to actually serve traffic. This is the core pattern for regional disaster recovery and meets the requirement for a highly available architecture across regions.

A CloudWatch alarm is the correct mechanism because it continuously evaluates an EC2 instance's time-series metrics, such as CPUUtilization or StatusCheckFailed, against a defined threshold. When the metric crosses the threshold, the alarm state transitions to ALARM and automatically publishes a message to an SNS topic, which can deliver email, SMS, or invoke a Lambda function. Alarms can also be configured to perform EC2 actions like stop or reboot, making them the native AWS service for threshold-based metric notification.

If the visibility timeout is shorter than the time it takes for the Lambda function to process the message, the message becomes visible again in the queue before the function completes. Another Lambda invocation can then receive and process the same message, leading to duplicate processing. This is a common misconfiguration. The visibility timeout should be set to at least the function's timeout plus a buffer to prevent this. Even if the function eventually succeeds, the duplicate processing has already occurred.

AWS AppConfig is purpose-built for this exact scenario because it separates configuration from code and provides a managed deployment lifecycle. By creating a configuration profile that references the SSM parameter, AppConfig treats each change as a new configuration version, runs your Lambda validator to catch malformed or unsafe values, and then rolls out the update using the specified deploy strategy (e.g., linear or canary with bake time). The ECS service is updated through AppConfig's integration with ECS—either via the AppConfig agent that supplies the new configuration or by triggering a task definition update—so the application receives the new value without a container rebuild. This gives you controlled rollout, automatic rollback on alarms, and auditability, which is exactly what a configuration management solution should provide.

AWS Config enables this by hosting a custom rule that invokes a Lambda function on a schedule using the rule's 'maximum execution frequency' setting, evaluating all IAM users' access keys for age. The Lambda function can use IAM API calls such as ListAccessKeys and GetAccessKeyLastUsed to identify keys older than 90 days, then rotate them by creating a new access key, deactivating the old key, and deleting the old key after a grace period. This is a well-known pattern because AWS Config provides the periodic orchestration and compliance evaluation while Lambda handles the actual IAM operations.

Automatic rollback in the deployment group triggers CodeDeploy to redeploy the last known-good revision once the health check failures terminate instances and the deployment fails, satisfying the requirement to restore the previous working version without manual intervention.

AWS CloudFormation Guard is a policy-as-code tool that can be run in CodeBuild. Integrating `cfn-guard validate` as a build step ensures templates are validated before deployment, and the pipeline stops on failure. This requires minimal setup: install Guard in the build environment, run the command, and check the exit code. It is a native, serverless approach with no infrastructure to manage.

Correct: The Application Load Balancer natively emits the HTTPCode_ELB_5XX_Count metric to CloudWatch, representing the number of 5xx responses returned by the load balancer itself. Create a CloudWatch Alarm on this metric using the Sum statistic over a period (e.g., 5 minutes) and set a threshold, optionally using a math expression to divide by RequestCount to track the error ratio. This is the simplest and most direct method because it uses existing metrics with no additional setup, latency, or cost.

SNS email subscriptions start in the 'Pending Confirmation' state; SNS sends an initial confirmation email to the endpoint and no notifications are delivered until the recipient clicks the link in that message. If the recipient never confirms, the subscription stays inactive, so even though CodePipeline publishes approval messages to the topic, SNS discards them for that unconfirmed endpoint. Therefore, confirming the subscription is the correct first troubleshooting step.

CloudFormation refuses to update any stack in a failed terminal state such as ROLLBACK_COMPLETE, because the stack's resources are in an inconsistent or partially provisioned state. The stack must be deleted and recreated (or, if applicable, brought back to a workable state via ContinueUpdateRollback for other rollback states) before an update operation can run.

AWS Config's managed rules continuously evaluate security group configurations against policies such as 'restricted-ssh' or 'vpc-sg-open-only-to-a-specific-port'. When a rule detects a non-compliant inbound rule, a configured AWS Systems Manager Automation document, such as AWS-DisablePublicAccessForSecurityGroup, automatically removes or tightens the offending rule, providing the required detect-and-remediate control loop without manual intervention.

Correct. When the alarm evaluates at 10:10, it considers the two most recent consecutive periods—10:05 and 10:10—both of which have CPU utilization above 80%. Since the alarm is configured with two evaluation periods and the threshold of 80%, both consecutive periods satisfy the condition, causing the alarm to enter ALARM state. At 10:05, only one period had breached, so the alarm was still OK.

A change set is a read-only preview of the exact modifications CloudFormation will make to a running stack, including whether each resource is created, updated, replaced, or deleted. By generating a change set before executing, you can inspect the action on every resource and confirm that the update does not introduce unintended destructive changes or interruption. Execution is a separate, explicit step, which gives engineers a checkpoint in the IaC workflow.

Configuring CloudTrail to stream events to CloudWatch Logs provides near-real-time delivery of management events, including DeleteBucket. A CloudWatch Events (EventBridge) rule can use an event pattern to match the specific DeleteBucket API call and directly target a Lambda function as its target. This creates a low-latency, event-driven pipeline that automatically invokes the Lambda function without polling or human intervention, enabling immediate remediation or alerting.

CodeBuild placed in the VPC uses its own security group as the traffic source. If the RDS security group lacks an inbound rule permitting that CodeBuild security group on the database port, connections time out, matching the stem's VPC-configured constraint.

Placing the backend ECS service in a private subnet with no route to an internet gateway ensures it has no public IP and cannot be reached from the internet. This is correct for internal-only workloads because the backend does not need outbound internet access, and any required image pulls can be handled via VPC endpoints or pre-pulled images. This isolation reduces the attack surface and aligns with the principle of least privilege.

An Auto Scaling group spanning multiple Availability Zones and using Elastic Load Balancing health checks meets the resilience requirement: the ELB sends HTTP/HTTPS health checks to each instance, and when an instance is marked unhealthy, the ASG terminates it and launches a new one to maintain desired capacity. Multi-AZ distribution ensures that even if one AZ fails, the remaining instances continue serving traffic, and the ASG can launch replacements in other AZs. This combination provides both automated fault replacement and cross-AZ high availability.

AWS Secrets Manager is a purpose-built service for centrally managing the entire secret lifecycle, including storing, retrieving, and automatically rotating secrets such as database credentials, API keys, and OAuth tokens. It enforces fine-grained IAM access policies, integrates with AWS KMS for encryption, and supports automatic rotation via AWS Lambda with built-in integrations for RDS, Redshift, and DocumentDB. This makes it the most comprehensive choice for managing secrets.

A CloudWatch alarm is the correct monitoring construct to watch a metric such as StatusCheckFailed or CPUUtilization. It evaluates the metric against a threshold over a specified number of evaluation periods and transitions to ALARM, OK, or INSUFFICIENT_DATA, then triggers a configured SNS action. The alarm is the central component that converts raw metric data into an operational notification, making it the appropriate mechanism for alerting on the instance's status check result.

The correct root cause is a timeout mismatch: CloudFront waits for an origin response within its configured origin timeout (default 30 seconds), while the ALB has an idle timeout (default 60 seconds) that can close the connection to the backend if no bytes flow. If the ALB idle timeout is shorter than CloudFront’s timeout, the ALB can terminate a long-running request before the backend finishes, causing CloudFront to receive no response and return 504. Since the ALB logs show 200 for completed requests, the occasional slow requests are being cut off by this idle setting; aligning the ALB idle timeout to be greater than CloudFront’s origin timeout (or tuning backend latency) is the fix.

For cross-account deployments, the pipeline service role in the source account must contain a policy that explicitly grants the `sts:AssumeRole` action on the ARN of the destination account's cross-account role. This is in addition to the trust policy on the cross-account role that allows the service role to assume it. Without this permission, CodePipeline's attempt to switch into the production account fails with a 403 AccessDenied at the AssumeRole step, which is exactly the described symptom. This is the root cause of the deployment failure.

Security groups act as a virtual firewall at the instance level. By referencing the CodeBuild project's security group as a source in the RDS security group's inbound rule, you allow traffic specifically from the Elastic Network Interfaces (ENIs) that CodeBuild uses when it runs inside the VPC. This is the most direct and least-privileged way to permit the integration tests to reach RDS, because it avoids opening the database to CIDR ranges or the entire VPC. It also updates automatically if CodeBuild's IP addresses change, as long as the security group ID remains the same.

DynamoDB throttling occurs when write requests exceed the provisioned write capacity (WCUs) of the table. If the Lambda function writes processed items back to the same table, insufficient WCUs will cause ProvisionedThroughputExceededException, leading to retries and stream processing failures. Increasing the write capacity reduces throttling, allowing the stream-triggered writes to succeed and the function to make progress.

Enabling automatic key rotation on a customer-managed KMS key at creation schedules KMS to generate new cryptographic material every 365 days while preserving the same key ID, ARN, and aliases. S3 bucket policies and IAM policies still reference the same key, so no re-encryption of existing objects or policy updates are required. KMS automatically keeps all versions of the backing material available for decryption, so data encrypted before rotation remains decryptable without interruption.

CloudWatch alarm actions publish notifications to the configured SNS topic, but the publish operation only succeeds if the topic has at least one active, confirmed subscriber endpoint, such as an email address that has clicked the confirmation link. When subscriptions are still in PendingConfirmation state or no subscription exists, the message is silently dropped while the alarm continues to show ALARM. Therefore, even though the alarm is firing correctly, no notification reaches the engineer because the delivery path lacks a confirmed subscriber. This is the root cause.

This is correct because Amazon EventBridge natively captures ECR image push events (e.g., the 'ECR Image Action' event type) and can directly target an AWS Lambda function. Lambda can then call CloudFormation's UpdateStack API, passing the new image URI as a parameter to the stack, thereby updating the infrastructure in an event-driven, serverless manner. This pattern is simple, requires no persistent compute, and integrates seamlessly with CloudFormation's parameter-based updates.

Correct. SCPs are service control policies that set maximum permissions for all IAM principals in an account, and they can include conditions that deny S3 bucket creation when SSE-KMS is specified. If the organization's SCP only allows SSE-S3 encryption (or denies kms:GenerateDataKey or kms:CreateGrant), then any CloudFormation template that specifies SSE-KMS encryption for the bucket will be rejected with an AccessDenied error, regardless of the IAM service role or the target bucket configuration. This perfectly matches the scenario where the error occurs only when certain encryption settings are present in the template.

Detaching the instance from the Auto Scaling group and removing it from the load balancer is the correct first step because it immediately stops new traffic from reaching the instance while also preventing the ASG from automatically replacing or terminating it. This preserves the running state for forensic collection, including memory and volatile data, and allows you to investigate safely without the instance being scaled away or continuing to affect production traffic. The instance stays alive but is decoupled from both the horizontal scaling and the request path.

The AppSpec hooks section contains a location field that must point to a script actually present in the extracted application revision. During a lifecycle event, the agent resolves that path against the deployment archive's directory structure; if the file is not there—perhaps due to a typo, an absolute path instead of a relative one, or omitted from the bundle—the operating system returns ENOENT and CodeDeploy reports ScriptMissing. Fixing the AppSpec path to match the bundled script resolves the deployment.

CloudFront caches objects at edge locations until their TTL expires, so after you update files in Amazon S3 the edge locations continue serving the old copies. An invalidation request explicitly removes the specified file paths from every CloudFront edge cache, forcing subsequent requests to fetch the latest version from the S3 origin. You can target an individual file with /path/file.js or use a wildcard like /images/* to clear a whole directory. This is the intended, immediate mechanism for propagating content updates without waiting for natural cache expiry.

CodeBuild only produces output artifacts if the project (or buildspec `artifacts` section) is configured to do so with a matching name. The pipeline's Build action expects an output artifact literally named 'BuildArtifact'; if the CodeBuild project defines a different artifact name, or omits artifact output entirely, the build may succeed but the pipeline's build stage will fail when resolving the expected artifact. This mismatch is the most common reason for a Build stage failure when the build logs show a successful build.

A timeout typically indicates a network connectivity issue between ALB and instance.

The aws:SourceIp condition key in a bucket policy compares the source IP address of the requester as seen by S3, which is the public IP address after any network address translation (NAT) or internet gateway processing. In a VPC, instances typically use private RFC 1918 IP addresses, which are not exposed to S3 when traffic traverses a NAT gateway or the internet. Thus, a policy specifying private IP ranges will never match, causing access to be denied for legitimate VPC clients.

Enabling trusted access for AWS CloudFormation in AWS Organizations allows StackSets to use the organization's structure (accounts and OUs) to automatically determine the set of target accounts. With service-managed permissions, any account added to the organization or an OU is automatically included in deployments, removing the need to manually maintain account lists. This centralization is a best practice for multi-account infrastructure management.

Using `StringNotEquals` on the KMS key ID correctly denies every `PutObject` request whose encryption key is not the specified ARN. This ensures that only objects encrypted with the designated customer-managed KMS key can be written to the bucket, enforcing SSE-KMS with that exact key.

CodeBuild projects have a configurable 'Timeout' property (default 60 minutes) that caps the total time from build start to the last phase, including download, install, build, and post-build. When a build runs past this limit, CodeBuild forcibly terminates it and records a 'BUILD_TIMEOUT' error, which matches the scenario described. To resolve it, the DevOps team can increase the timeout in the CodeBuild project settings (via console, AWS CLI, or CloudFormation), setting it up to 480 minutes (8 hours) for standard builds. This directly addresses the root cause rather than masking a resource or syntax problem.

A health check timeout set too low can cause the ALB to mark otherwise functional instances as unhealthy when the application's response time occasionally exceeds the timeout. The ALB health check settings include an interval, timeout, and unhealthy threshold; if a slow application misses the timeout a few consecutive times, the target is deregistered and the ALB returns 503 Service Unavailable when no healthy targets remain. This matches the symptom of intermittent errors under load, as the application may respond normally at times but exceed the timeout during traffic spikes.

CodeDeploy's blue/green deployment with an Application Load Balancer is the correct solution because it provisions a completely new Auto Scaling group (the green environment) running the new revision and registers it with a new or existing target group. The ALB only shifts traffic to the green target group after all instances pass health checks, while the blue instances continue serving requests during the entire setup and validation. After a configurable wait time, the original blue ASG is terminated, ensuring no point where users have no service. This architecture provides true zero downtime because the old fleet remains fully operational until the new fleet is verified.

Placing the EC2 instances in a private subnet with no internet gateway (IGW) route ensures they cannot receive unsolicited inbound traffic from the internet. The ALB, deployed in a public subnet, is the only intentional ingress point; it forwards traffic to the instances over the private VPC network, which does not require an IGW. This design prevents direct exposure of instance IPs and relies on the security group to restrict traffic to just the ALB's interface.

The bucket policy's condition key is tied to the s3:GetObject action, which only governs read requests. To enforce encryption during uploads, the policy must target s3:PutObject, because that is the action that accepts the x-amz-server-side-encryption header and where a missing encryption header should be denied. Placing the condition on GetObject only denies reading unencrypted objects, leaving uploads allowed without encryption.

A warm standby architecture places a fully functional but possibly smaller ECS service behind an ALB in us-west-2, and Route 53 health checks automatically shift user traffic when us-east-1's ALB or service is unhealthy. ElastiCache Global Datastore for Redis maintains a cross-region replica with sub-second replication lag, so the secondary can serve reads and writes after promote without a point-in-time restore. This combination keeps both RPO and RTO under 30 minutes because failover is automated and data is already in the secondary region.

CloudTrail event history retains management events for the last 90 days, and each event record includes the sourceIPAddress field, which identifies the IP address from which the API call was made. Searching event history for the DeleteBucket event, or a similar deletion event, and expanding the event details will show the sourceIPAddress in the raw event record. This is the direct and correct way to retrieve the requester's IP for a specific CloudTrail event.

The EC2 dynamic inventory plugin queries the AWS API and groups hosts by their tags, so `Environment: Production` becomes a selectable group or filterable host pattern. This satisfies the requirement to target only tagged production instances without maintaining a static inventory file that would drift as instances launch or terminate.

AWS X-Ray tracing on the Lambda function provides an end-to-end view of the invocation, showing each subsegment's duration, including the time spent in external HTTP calls, AWS SDK operations, and service integrations. It automatically captures the trace for every invocation without requiring code changes (unless you need custom subsegments), and the trace timeline reveals exactly which downstream call or code block is consuming the most time. This makes X-Ray the correct tool to diagnose performance bottlenecks in a production Lambda, as it gives the per-invocation, subsegment-level detail that the other options lack.

An origin group with health checks lets CloudFront monitor the primary origin using HTTP or HTTPS requests; when the origin returns errors or times out, CloudFront automatically fails over to a designated secondary origin. This gives near-instant recovery without manual intervention, directly addressing the overwhelmed origin scenario described in the question. Health checks are essential for the failover mechanism to know when to stop sending traffic to the failing origin.

CloudWatch Logs Insights parses JSON log events automatically, so a query can filter on the request ID field and return matching lines in seconds across the entire log group. This requires no additional infrastructure, making it the lowest-effort solution for the stated search requirement.

Installing the CloudWatch Logs agent (or the newer unified CloudWatch agent) on each EC2 instance enables real-time delivery of log data to the CloudWatch Logs service, which stores it durably and independently of the instance lifecycle. Because logs are streamed continuously as they are generated, they survive instance termination, crashes, or scale-in events without requiring manual offload steps. This is the AWS-recommended managed solution for centralized log collection and retention.

CloudFront's origin-facing IP ranges change periodically, so a static security group rule based on a previously captured list will block newer edge locations. Those blocked connections surface as 'Origin Connect Error' and intermittent 503s, matching the stem's requirement that the ALB accept traffic only from CloudFront.

Enabling cluster mode on ElastiCache for Redis partitions the keyspace across multiple shards, with each shard having its own primary node to handle writes independently. Adding shards increases aggregate write throughput and lets you scale beyond the limits of a single node, while also supporting larger datasets by distributing memory. This is the correct answer because it directly addresses a write-heavy workload by horizontally scaling the data plane and maintains Redis' low-latency session state access.

Running `npm ci` instead of `npm install` is the recommended fix because it performs a clean, lockfile-driven installation and never attempts to modify the global package cache, thus eliminating the permission conflict. The presence of a valid `package-lock.json` ensures that exact dependency versions are resolved and installed without npm calculating a new dependency tree, which can trigger hidden writes to system locations. This approach is purpose-built for CI/CD pipelines and greatly reduces the chance of inconsistent state or permission failures.

The CodeBuild managed build image is version-specific and does not include every language runtime; for example, the Amazon Linux 2 x86_64 standard image version 3.0 has Java, Python, Node.js, and Ruby, but no Go binary on its PATH. When the buildspec runs 'go build', the shell returns 'go: command not found' because the executable is simply not installed in the selected image. The correct remedy is to select an image that includes Go (such as a newer standard image with the Go runtime), add a runtime-versions entry for golang, or provide a custom Dockerfile that installs Go.

Local caching in CodeBuild persists declared dependency directories between builds on the same host, so package managers such as npm or Maven skip re-downloading. Specifying cache paths in buildspec.yaml directly cuts the 30-minute runtime without altering the pipeline structure.

AWS CloudFormation is the definitive Infrastructure-as-Code service that uses declarative JSON/YAML templates to provision and manage all resources in a stack, including EC2 instances, RDS databases, VPCs, and security groups as a single unit. Stack creation handles dependency ordering and rollback on failure, while stack deletion removes the complete set of resources, enabling reliable automation of ephemeral environments. The ability to set a deletion policy on resources like RDS allows you to control whether the database is retained or deleted, making cleanup predictable and safe.

This is exactly what the policy authorizes: it includes the StartBuild action to begin a build and BatchGetBuilds to retrieve detailed information about those builds, with the Resource set to the specific CodeBuild project ARN shown in the exhibit. The policy therefore grants the minimum permissions needed to start and observe builds for only that one project.

CloudFront Origin Failover is the native, minimal-configuration solution: you create an origin group containing two S3 buckets as the primary and secondary origins, and attach that group to your cache behavior. When the primary origin returns a configurable HTTP error code (commonly 5xx) or a connection timeout, CloudFront automatically retries the request against the secondary bucket in us-west-2, all within the same edge location and without involving DNS or custom code. This requires no additional compute, no Route 53 policies, and no application modifications—only enabling Cross-Region Replication between the two buckets so content stays consistent. It is the only option that leverages a built-in CloudFront feature designed specifically for this use case, meeting both the fault-tolerance and low-operational-overhead requirements.

Saved configurations serialize an environment's settings—such as instance type, autoscaling limits, environment variables, and security group rules—into a reusable template. A DevOps team can save a tuned production environment's configuration and then apply that exact template when creating a new environment, either through the Elastic Beanstalk console or the eb config save command. This ensures consistency across environments, but it should not be used for deploying code; it only captures environment-level options.

The ContinueUpdateRollback operation is the correct recovery mechanism specifically designed for stacks that fail during an update and subsequently fail to roll back automatically, landing in UPDATE_ROLLBACK_FAILED. It instructs CloudFormation to resume the rollback to the last known good state, optionally skipping resources that are causing repeated failures via the ResourcesToSkip parameter after manually fixing them. This restores the stack to a stable, updatable condition without destroying the underlying infrastructure.

Fargate tasks provisioned in a private subnet have no route to the internet unless a NAT gateway is configured in a public subnet. Because ECR's API and Docker Hub need outbound HTTPS access, and image layers are fetched from Amazon S3, the task's image pull fails without a NAT gateway or VPC endpoints for ECR (both API and DKR) and S3. This manifests as a 'CannotPullContainerError' or 'ResourceInitializationError' in the task's stopped reason. Adding a NAT gateway or the appropriate VPC endpoints resolves the issue.

The `aws deploy create-deployment` command is a valid, top-level CodeDeploy API operation that starts a new deployment for an application. You provide the application name, deployment group name, and a revision (for example, `--s3-location` or `--github-location`), and it returns a `deploymentId` that you can later query with `get-deployment`. This is the standard way to trigger a deployment from the CLI.

These CloudWatch metrics are emitted specifically for responses returned by the registred targets, such as EC2 instances or ECS tasks, after the load balancer forwards the request. By applying a Sum statistic over your monitoring window, you get the exact number of 4xx and 5xx status codes produced by your backend application, which is precisely what you need to detect target-side errors. Unlike ELB-level metrics, these don't include errors generated by the load balancer itself.

If the CodeBuild project is configured with a local dependency cache or an S3 cache that stores the Maven ~/.m2/repository, an interrupted download or a stale snapshot can leave cached JARs missing classes or mismatched with the declared POM versions. This directly produces NoClassDefFoundError at runtime because a class that existed during compilation is absent from the cached artifact on the classpath. Clearing the cache forces CodeBuild to re-resolve dependencies from their remote repositories, eliminating the corrupted or out-of-sync state.

When a CloudFormation stack has a TimeoutInMinutes value and that timeout is exceeded, or when a user calls CancelUpdateStack or moves to cancel the operation in the console, all resources that are still in a CREATE_IN_PROGRESS state are marked with status 'Resource creation cancelled'. This is an orchestration-level interruption: CloudFormation abandons the pending resource creation and begins rolling back the stack. Because the EC2 instance creation was still in progress when the stack operation was aborted, the event correctly indicates this is the most plausible explanation.

To use a customer-managed KMS key, the key policy must explicitly grant the CloudWatch Logs service principal (logs.<region>.amazonaws.com) the required cryptographic permissions: kms:Encrypt, kms:Decrypt, kms:ReEncrypt, kms:GenerateDataKey, and kms:DescribeKey. Without an Allow statement, CloudWatch Logs cannot decrypt the key for the log group, and the association or ingest operations will fail. The key policy is the sole authorization mechanism for this integration.