AWS Certified DevOps Engineer Professional DOP-C02 (DOP-C02) — Questions 1051–1125

Patch Manager automates the entire patching process by using a patch baseline to define which patches are approved, when they are approved (e.g., after a test period expressed in days), and how those rules are applied to tagged instance groups. Maintenance windows schedule when the patching runs on test and production fleets, ensuring production patches are installed only after the baseline's approval delay lets the test fleet validate them. This combination provides automation, a testing gate, and controlled rollout windows, which directly satisfies the requirement.

For an IAM role to decrypt an object using a customer managed key, the KMS key policy must explicitly include the role (or an account principal with delegation) in a statement that allows kms:Decrypt. Even if the IAM role's permissions policy grants kms:Decrypt, KMS requires both the IAM policy and the key policy to authorize the action. If the key policy only allows a different principal or restricts access to specific roles, the decryption fails—this is the most direct cause of the error.

A cross-Region read replica uses the database engine's native asynchronous replication from the primary RDS instance to a secondary instance in another Region. The lag is typically low (often well under 60 seconds), so it can satisfy an RPO of less than one minute, and because the replica is a fully open read-only instance you can promote it to primary quickly, giving a low RTO. This makes it the core mechanism for a resilient cross-Region disaster recovery plan that meets both RPO and RTO requirements.

Setting up CloudWatch alarms on the Secrets Manager rotation Lambda function's failure metrics or on the RotationFailed event (via Amazon EventBridge and CloudTrail) is essential because rotation failures can occur silently without directly impacting the application. If a failure goes unnoticed, the secret may remain stale for an extended period; more critically, the Lambda might have created and stored a new version but failed to promote it to AWSCURRENT, leaving the database and Secrets Manager in an inconsistent state. An alarm ensures administrators are notified quickly to prevent both stale credential burnout and potential data-plane outages.

Correct. ElastiCache Redis supports encryption in transit via TLS, which must be enabled when creating the cluster, and the application must be configured to connect using TLS.

Combining a bucket policy in Account A that grants the IAM user ARN from Account B permissions on the target S3 bucket with an IAM user policy in Account B that approves the same actions is the standard method for cross-account S3 access. The bucket policy acts as the resource-based authorization, defining who can interact with the bucket and its objects; the IAM user policy acts as the identity-based authorization, allowing the user to invoke those S3 APIs. Without both explicit allows, the request is denied by AWS's default deny behavior.

The Execute Recipes feature in AWS OpsWorks Stacks allows you to run a specified recipe on selected instances immediately. This initiates an ad-hoc Chef run that pulls the latest cookbook from your configured source and executes the recipe's logic, directly applying the changes to the existing instances. It is the intended mechanism for manually applying cookbook updates without recreating or redeploying instances.

This design uses CodePipeline stages to gate flow: a stage with parallel unit-test actions runs the per-microservice unit suites concurrently, cutting total test wall-clock time, and the stage only completes when every action succeeds. The subsequent integration-test stage is serial relative to unit tests, so integration testing starts only after all unit suites are green, preserving deterministic dependency ordering while still exploiting parallelism where safe.

The RDS instance's security group must have an inbound rule that allows TCP traffic on the database port (e.g., 3306, 5432) from the security group ID attached to the CodeBuild project's elastic network interface. This is the standard way to permit traffic between AWS resources within a VPC, because security group rules reference other security groups as sources. The CodeBuild project must also be configured with VPC settings (VPC ID, subnets, and security groups) so its ENI is placed in the same network context as the RDS instance, enabling the security group-to-security group allow.

Setting AWS_DEFAULT_REGION in the CodeBuild project's environment configuration is the correct fix because CodeBuild injects all project-level environment variables into every phase of the build, making the value available to the AWS CLI, SDKs, and all build commands without any buildspec changes. This approach is explicit, portable, and aligns with AWS best practices for configuring tooling at the project level rather than relying on phase-scoped shell exports.

Amazon Inspector is a vulnerability management service that scans workloads for software vulnerabilities and unintended network exposure. Its CodePipeline integration uses the Inspector Scan action to automatically inspect container images stored in Amazon ECR during the pipeline, blocking deployment if critical findings are discovered. This catches CVE-level issues in dependencies and OS packages before release, making it a direct preventive control.

To download an object from an S3 bucket, the calling principal must be granted the s3:GetObject action. Without this permission, S3 returns an AccessDenied error even if other S3 actions like ListBucket or PutObject are allowed, so adding s3:GetObject is the minimal and correct fix for a build process that retrieves artifacts.

In a CloudFormation template, the Lambda function's Code property, when referencing an S3 bucket, can include the S3ObjectVersion attribute. Because CloudFormation treats any template property change as a stack update trigger, explicitly specifying the object version creates a new template value whenever the zip file in S3 is modified. Without this version, CloudFormation compares only the bucket and key, both of which stay constant, so it considers the resource unrmodified and skips the Lambda update—even if the S3 object's contents were replaced. Adding the S3ObjectVersion forces a resource replacement or update, making it the simplest and most direct way to ensure the stack updates on code changes.

CloudTrail Insights is the correct choice because it automatically applies machine learning to management events, including IAM AssumeRole, to establish a normal baseline and flag anomalous activity. It requires no manual filter definitions—you simply enable Insights on the trail, and it begins detecting unusual API call rates or error rates, logging them as separate Insights events. This is purpose-built for identifying abnormal role assumption patterns, such as an unexpected spike in AssumeRole calls or a new principal assuming roles outside its normal context.

RDS Proxy manages connection pooling and reduces database load.

AWS Systems Manager Run Command is a capability of AWS Systems Manager that lets you securely push commands to managed EC2 instances and on-premises machines without requiring SSH, RDP, or bastion hosts. The SSM Agent polls for commands, executes them, and can report status back, enabling admins to run scripts, install software, or change system settings across a fleet. Features such as tag-based targets, rate controls, and integration with IAM make it specifically designed for this kind of on-demand configuration activity.

Multiple AZs provide high availability and health checks ensure quick replacement.

For a private subnet to reach the internet via a NAT gateway, its route table must contain a route with a destination of 0.0.0.0/0 and a target of the NAT gateway's ID. This route tells the instance's traffic to be forwarded to the NAT gateway, which then performs source NAT using its Elastic IP. Without this specific route, the instance's outbound packets have no defined next hop to the internet, causing connectivity to fail.

Running a performance/load test stage (e.g., using AWS CodeBuild with Apache JMeter or Artillery against the deployed API endpoint) validates that the serverless application can sustain expected concurrency and throughput without exceeding Lambda concurrency limits or API Gateway throttling quotas. It catches issues like cold start latency, inadequate memory allocation, or downstream dependency bottlenecks that unit tests miss. In serverless, load tests also confirm that provisioned concurrency or auto-scaling behavior works as intended under spike traffic.

AWS CodeDeploy provides a native ECS deployment mechanism that can shift traffic from the old to the new task definition using blue/green or rolling configurations with an Application Load Balancer. In a CodePipeline-based CI/CD flow, this is the deployment action that makes the newly built image actually run on the ECS service, so it is essential to the pipeline.

The DependsOn attribute explicitly declares a dependency edge from the Lambda function back to the S3 bucket, forcing CloudFormation to wait until the bucket resource has reached CREATE_COMPLETE before it starts provisioning the Lambda function. This is the definitive way to guarantee creation order, especially when the function needs the bucket to exist for side effects such as populating an environment variable, writing to the bucket, or associating permissions, and no implicit dependency exists in the template. Unlike implicit references, DependsOn works even if the bucket is not directly referenced in any property of the Lambda function, making it the correct answer.

Calling PutMetricData with StorageResolution=1 creates a high-resolution custom metric with 1-second granularity, making the data available for CloudWatch alarms in as little as 10 seconds instead of the 60-second standard resolution. This lower storage resolution is the key to detecting critical issues faster because CloudWatch can evaluate alarms at a 10- or 30-second period. Without this parameter, your metrics default to 60-second resolution and alarm latency remains as high as a minute.

Amazon CloudWatch Alarms are the action engine that watches a single CloudWatch metric, a math expression, or an anomaly detection band over a specified time period, then transitions to an ALARM state when the observed value breaches a defined threshold. You can configure the alarm to publish to an SNS topic, trigger Auto Scaling, or execute an EC2 action such as a reboot when the anomaly condition persists. In this solution, the alarm consumes the band produced by CloudWatch Anomaly Detection and calls the monitoring hook when unusual metric behavior is detected.

Configuring the target group for HTTPS forces the ALB to negotiate a TLS session with each EC2 instance, so backend traffic is encrypted as well. Each instance must present a valid certificate that the ALB trusts, typically installed on the instance's web server or TLS terminator, to complete the handshake. This provides encryption in transit across both the client-to-ALB and ALB-to-instance segments.

Amazon EventBridge is a serverless event bus that can natively consume Auto Scaling group state changes such as EC2 instance launch, terminate, and lifecycle hook notifications. Using event patterns that filter on the aws.autoscaling source and detail types like EC2 Instance Launch Successful, EventBridge matches relevant events in near real time and routes them to targets such as SNS topics for email/SMS alerts. It is the correct service because it provides built-in event ingestion, filtering, and routing without requiring custom code or external monitoring agents, making it ideal for health and lifecycle monitoring.

Caching the secret prevents the application from using the new password.

An ALB returns 503 Service Unavailable when it cannot handle incoming requests due to scaling activity or when all targets are unhealthy. During a traffic surge, the ALB nodes scale up by provisioning additional capacity, and during this scaling activity the ALB may temporarily reject or fail to accept new requests, causing clients to receive 503 responses. This matches the scenario described, making it the correct explanation for the issue.

The correct remediation is to first raise the Lambda timeout to a value that comfortably covers the actual processing duration for a batch, then set the SQS visibility timeout to at least that same timeout so the queue does not redeliver a message while the function is still processing it. Adding a dead-letter queue to the source SQS provides a safety net: after the configured retries (maxReceiveCount), messages that still fail are diverted to the DLQ, preserving them for analysis instead of silently expiring. This combination directly resolves the timeout issue and handles residual failures cleanly.

CloudFormation is an infrastructure-as-code service that declares the entire serverless application stack, including the Lambda function, IAM role, event source mappings, and environment variables. Updating the stack applies code and configuration changes in a deterministic order and supports rollback on failure, making it a valid CI/CD deployment step. It treats the Lambda function as a managed resource, and can be invoked via CodePipeline or directly. This is a correct approach because it ensures drift-free, auditable releases.

Amazon EC2 Auto Scaling is the service that continuously monitors the health of EC2 instances using EC2 status checks and, when configured, Elastic Load Balancing health checks. If an instance fails these checks, Auto Scaling automatically terminates it and launches a replacement instance to maintain the desired or minimum fleet size. This health-based replacement is an inherent capability of an Auto Scaling group, making it the correct answer for automatically replacing unhealthy instances.

Configuring the source action with CodeCommit as the source provider and specifying the 'develop' branch is exactly how CodePipeline implements automatic change detection for a CodeCommit repository. The action references the repository and branch; on each update to that branch, CodePipeline uses an automatically managed CloudWatch Events rule (or event polling) to trigger a new pipeline execution. This is the recommended native integration, and it ensures every commit to the 'develop' branch starts the pipeline without custom webhooks or manual steps.

Using a dynamic stack name parameter, such as inserting the branch name into the stack name (e.g., `MyApp-${Branch}`), lets each branch deploy to a unique CloudFormation stack. This isolation prevents resource name collisions when multiple branches are deployed concurrently, supports per-branch rollback and lifecycle management, and eliminates the need to manually reconfigure the pipeline when a new branch is created.

Enabling S3 caching in a CodeBuild project stores the dependency cache (e.g., Maven's .m2, npm's node_modules, or Python's pip cache) in an Amazon S3 bucket between builds, so the build only downloads changed or missing packages instead of re-fetching the full dependency set each time. This directly reduces the time spent on network I/O, which is often the dominant cost for builds with many third-party libraries. By setting the 'cache' type to S3 and specifying a bucket, subsequent builds restore the cache at the start, making the compilation faster. This is the recommended approach because it targets the common bottleneck of dependency resolution.

A manual approval action in CodePipeline is a first-class, natively integrated gate that pauses the pipeline execution at a defined stage boundary (e.g., after build, before deploy). When the action runs, CodePipeline sends an SNS notification to the designated approver topic, and the execution remains in a Waiting state until an authorized user explicitly approves or rejects it via the console, CLI, or SDK. This is the intended AWS pattern for a human review gate because it is fully managed, has no custom polling logic, and automatically resumes the pipeline only upon approval — making it superior to any ad-hoc script or external approval mechanism.

The stack update failed because the Lambda function specifies a runtime that is not available in the region. AWS Lambda runtimes are region-specific; some runtimes may not be supported in all regions, causing a validation error when CloudFormation attempts to create or update the function.

Disabling sticky sessions on the ALB is a necessary precondition for a horizontally scalable, fault-tolerant design. With stickiness off, the ALB can route any request to any healthy target, so if an instance fails, the next request can be served by a different instance — assuming the session state is stored externally (for example, in ElastiCache or DynamoDB). This makes the application effectively stateless at the instance level, which also allows Auto Scaling to add or remove instances without worrying about breaking client sessions on a particular host.

The ECS task definition's memory limit is a hard limit enforced by Docker; when the container's memory utilization consistently exceeds 80%, it is likely approaching or hitting that ceiling, leading to OOM kills or severe performance degradation. Increasing the memory limit lets the container allocate more heap or working set, directly relieving the memory bottleneck. This is a vertical scaling action, and you must also ensure the EC2 instance has enough free memory to support the increased limit.

When an S3 bucket policy explicitly denies s3:GetObject for a condition like aws:SourceVpc, that explicit deny overrides any grant provided by IAM policies. Because the ECS task's traffic originates from inside a VPC, the deny condition matches and S3 returns AccessDenied despite the role having correct permissions. This is a classic case where a correct IAM role is not enough, and bucket policy deny statements must be reviewed for VPC conditions.

The error message in the build log explicitly returns AccessDenied for the CreateInvalidation action, which means the IAM role assumed by CodeBuild does not include a statement allowing cloudfront:CreateInvalidation on the target distribution. Even though the role is correctly associated and used, it lacks this specific identity-based permission, so the aws cloudfront create-invalidation API call fails. This is an IAM policy gap, not a misconfiguration of the project or the distribution.

Adding an Amazon Inspector scan action as a test stage in CodePipeline is correct because Inspector is natively integrated as a pipeline action that can scan application artifacts such as container images and Lambda functions for software vulnerabilities and unintended network exposure. The action can be configured to fail the pipeline if findings meet a defined severity threshold, providing an automated, shift-left security gate that runs during the deployment process itself rather than after resources are live.

The ECS deployment circuit breaker is a native ECS feature that continuously monitors the health of a service deployment by watching for failed health checks, crashes, or task startup failures. If it detects that the new version is unhealthy, it automatically cancels the deployment and rolls back the service to the previous stable revision, without manual intervention. This makes it the only option that directly addresses deployment failures as part of the ECS service update path.

Automated integration tests that exercise real interactions between services (for example, using contract tests or a dedicated test environment) catch API mismatches, schema changes, and network configuration errors before production. By running these tests early in the CI/CD pipeline, you shift left defect detection, reduce the cost of fixes, and increase confidence that independently deployed services will interoperate correctly.

Modifying the RDS instance to a larger instance class is the correct immediate response because it directly adds vCPU, memory, and often dedicated EBS bandwidth to handle the current workload. Amazon RDS supports scaling instance classes with minimal downtime, especially for Multi-AZ deployments where a failover masks the restart. This scale-up action provides the compute headroom needed to bring CPU utilization back to acceptable levels and is the standard first step when a CPU alarm indicates that the instance is simply undersized for the traffic.

Enabling S3 Versioning is the correct first-line protection because it retains every version of an object, including the original, whenever an overwrite (PUT) or delete (DELETE) occurs. With versioning, an overwritten object's previous version is preserved as a non-current version, and a DELETE action only inserts a deletemarker, leaving all prior versions intact. You can recover accidental changes by simply fetching a previous version, making it the foundational mechanism that enables other features like lifecycle rules, MFA Delete, and point-in-time restores.

Change sets provide an itemized, read-only prediction of the exact modifications CloudFormation will apply to a stack when an updated template or parameter set is executed, listing each resource as being added, removed, or replaced without actually altering the stack. They are generated by calling CreateChangeSet, allowing the team to inspect the impact in a CI/CD pipeline and then explicitly execute the change set only after human approval. This makes change sets the correct mechanism for implementing a controlled pre-update review and approval workflow.

After Systems Manager applies OS patches to a managed instance, you must capture that patched state into a new Amazon Machine Image. Because launch configurations are immutable, you cannot edit the existing launch configuration's AMI ID; you must create a new launch configuration that references the patched AMI so any instance launched from it starts with the verified, patched baseline.

Changing environment properties in the Elastic Beanstalk console is the standard configuration-management action for existing environments. Elastic Beanstalk treats property updates as a configuration change, not an application-version deployment, so it applies them through a rolling update that replaces instances in batches while continuously serving traffic. The platform automatically orchestrates health checks between batches, so there is no downtime and no need to rebuild the environment or upload a new artifact.

With a 5-minute period, 3 evaluation periods, and 3 datapoints to alarm, the alarm enters ALARM state only when every one of the three most recent 5-minute data points breaches the threshold. This means the metric must be continuously in breach for 15 minutes, filtering out transient spikes and providing a reliable signal of a sustained problem. It is the appropriate setting for production alarms that should page responders only after a consistent degradation.

A 503 response from the ALB health check means the target instance accepted the TCP connection and returned an HTTP response, but the response status code was not a success (2xx/3xx). If the health check path is '/health' and the application does not define that route, the web server returns a 503 error because no handler matches the request. To resolve this, the health check path must be changed to an existing endpoint or the application must implement an endpoint that returns 200 OK on '/health'.

KMS key policies are resource-based policies attached directly to the customer master key, and they are evaluated for every KMS API action against that key. The policy can include a Condition block that references SAML-derived session attributes, such as a session tag mapped from an attribute in the SAML assertion, to allow kms:Decrypt only when the expected attribute value is present. This is the correct approach because it centralizes the decryption restriction at the key resource itself, ensuring that any principal attempting to use the key must satisfy the condition regardless of their IAM permissions.

A service role is an IAM role that CloudFormation assumes to make API calls on your behalf when creating, updating, or deleting stacks. By specifying a service role with least privilege, you ensure CloudFormation only has the permissions required to provision the intended resources, limiting the impact if a resource definition is malicious or misconfigured. This also enables separation of duties because users can create stacks without holding direct resource permissions, and all actions are attributed to the service role.

Increasing the rate-based rule's threshold is the appropriate response because the rule currently flags legitimate traffic when it should only block genuinely anomalous request floods. AWS WAF rate-based rules count requests that match a rule's conditions from a single source IP over a 1- or 5-minute evaluation window; if your legitimate users share an office IP or traverse a NAT gateway, their aggregate requests can exceed a threshold set too close to peak traffic. By raising the threshold above your historical maximum legitimate request volume per IP, you preserve protection against distributed or bot-driven floods while eliminating false positives from normal usage spikes.

Access logs provide detailed per-request data including timestamp, target status, and response time, enabling correlation of errors with slow targets.

Reviewing the canary's CloudWatch Logs is the correct first step because each canary run emits a dedicated log stream containing step-by-step execution details, error and stack traces, HTTP response bodies, and console output from the canary script. Since the canary has already failed, these logs are the definitive source for pinpointing the root cause—whether it's an assertion failure, a timeout, an invalid response, or an unexpected HTTP status.

AWS CodeCommit is a fully managed source-control service that hosts private Git repositories, supporting branches, commits, pull requests, and merge operations with IAM-based access control. It matches the description of a source-control service because it is the central repository where developers store, version, and collaborate on code. Its native Git compatibility and tight AWS integration enable seamless use with other DevOps services, but its core identity is version control, not building or deploying.

AWS CloudTrail is the principal service that logs all management, data, and insight API calls across an AWS account, capturing identity, request context, and response details. It is correct for this scenario because you need API-call logging, but to make the resulting log files truly tamper-proof you must configure CloudTrail to deliver them to an S3 bucket with Object Lock enabled. CloudTrail also supports log file integrity validation, yet that only detects tampering, whereas Object Lock prevents it.

Using a customer-managed KMS key with a cross-account key policy is correct because CodePipeline stores build artifacts in S3, which must be encrypted. By default, AWS-managed keys are scoped to a single account, so to share artifacts with a target account you must use a customer-managed key and explicitly grant the target account's principals decrypt permission via a cross-account key policy. This provides secure, auditable cross-account artifact transfer without exposing the key material, and it lets you enforce encryption at rest with full control over key rotation and access.

Conditional writes enable optimistic concurrency by allowing the application to assert a precondition—such as an item version or updated timestamp—before the write commits. If the condition evaluates to false because another concurrent write modified the item, DynamoDB rejects the request without overwriting, forcing the application to re-read and retry. This prevents silent data loss from last-writer-wins and is the appropriate DynamoDB-native way to enforce a safe update workflow in a multi-region setup.

The correct approach uses a parameterized AWS CloudFormation template that defines a complete CodePipeline (source, build, deploy) for a given repository, and combines it with an EventBridge rule that detects the `CreateRepository` API call from CodeCommit (via CloudTrail) and triggers a Lambda function. That Lambda function validates the input and invokes `CreateStack` (or `UpdateStack`) with the repository name as a parameter, automatically provisioning a dedicated pipeline for each new microservice as soon as the repo is created. This delivers event-driven, infrastructure-as-code automation, ensuring every pipeline is identical, versioned, and created without human interaction, thereby meeting the scalability and consistency goals of the team.

The CloudWatch Embedded Metric Format encodes custom metric values inside a structured JSON log event; when the Fargate task's awslogs driver sends that log to CloudWatch Logs, CloudWatch automatically extracts the declared metrics into the specified namespace for graphing and alarms. This requires no separate daemon, sidecar, or SDK call—developers only add a serialization layer to application logging, making it the minimal-code path you asked for.

This is correct because an HTTP request sets the aws:SecureTransport context key to false, and the Deny statement is scoped to exactly that condition. The policy likely contains an Allow for the S3 action on the folder, but the explicit Deny for non-secure transport takes precedence under AWS's evaluation logic. As a result, the user's GET request over HTTP is denied, while the same request sent over HTTPS would be allowed if the other permissions match.

Monitor CPU and memory utilization in CloudWatch to detect resource exhaustion. Increasing task size (CPU and memory) provides more resources per task, preventing OOM or CPU throttling without changing task count.

The security group associated with the CodeBuild project's ENI acts as the source for all traffic leaving the build environment. For the build to successfully fetch packages from an internal PyPI repository, the repository's security group must have an inbound rule that permits HTTPS (or the appropriate port) from the CodeBuild security group ID. If this inbound rule is missing, the repository silently drops the request, causing timeouts or connection refused errors during dependency installation. This is the most common cause of such failures when routing and NACL settings are already configured correctly.

This is the only option that provides automatic detection and remediation. An AWS Config managed or custom rule can evaluate each security group and mark it NON_COMPLIANT if it contains an ingress rule with 0.0.0.0/0. You can attach that rule to a Systems Manager Automation document, which uses aws:executeAwsApi to call RevokeSecurityGroupIngress and remove the offending rule, or trigger an AWS Lambda function; this remediation runs automatically on each configuration change. Thus it directly satisfies the requirement to revert unauthorized changes.

The SSM Agent maintains a control-plane communication channel over HTTPS to the Systems Manager regional endpoints, either through the public internet, a NAT gateway, or interface VPC endpoints. If outbound access is blocked by security groups, network ACLs, or route tables, the instance cannot register with Systems Manager, receive patch commands, or report status, yet the agent may continue running locally without logging an explicit error. Therefore, verifying that the instance can resolve and connect to endpoints like ssm.<region>.amazonaws.com on port 443 is the first diagnostic step.

The correct approach is to add a second ALB listener for HTTPS port 443 with an ACM certificate in the same AWS region, and configure the existing HTTP listener (port 80) with a default action to redirect all traffic to HTTPS using a 301 response. This terminates TLS at the load balancer, encrypting the client-to-ALB connection, while a security group rule restricting inbound traffic to port 443 further enforces the policy. ACM automatically renews the certificate as long as DNS validation is configured, making it a fully managed, low-maintenance solution.

CloudWatch Logs Insights can query multiple log groups simultaneously.

A change in logical ID causes CloudFormation to create a new resource and delete the old one.

Memory-based scaling will add tasks when memory is high, preventing memory exhaustion.

The Lambda event source mapping for an SQS queue governs message deletion: it only deletes a message after the function returns a success response. By ensuring the mapping does not delete messages on failure (which is the standard behavior unless the function reports success), the failed message remains in the source queue. On subsequent polls, the event source mapping receives it again and invokes the function, giving the desired retry behavior. This is the correct way to let Lambda retry processing of a failed message.

Calling the UpdateStack API (or the update operation in the console) on a stack in CREATE_FAILED state is the correct recovery path. CloudFormation only re-evaluates the resources that depend on the changed parameter, so the failed RDS instance is created while already-created resources remain untouched and no downtime is introduced. Any other approach either destroys existing resources or is not applicable to a creation failure.

When the new version applied a forward-only database schema migration, the schema changed irreversibly for the running environment. CodeDeploy rolled back the ECS task set to the old code, but that old code cannot understand the new schema, causing errors, failed health checks, and a broken application. This is the recognized cause: database changes are not automatically rolled back, so they break the previous version. The fix is to implement reverse migrations or use an expansion-contraction pattern.

The correct procedure is to increment the version number in your platform definition file and then run the AWS CLI command `aws elasticbeanstalk create-platform-version`, which uploads the new packer template and associated configuration to build a fresh, immutable platform version. This new version can then be used as the `PlatformArn` in your environment's configuration, allowing the patched AMI to be deployed without affecting existing environments that reference the old version. This workflow is the documented way to apply changes to a custom platform.