CCNA Deployment, Provisioning, and Automation Questions

Adding a load-based layer and specifying CPU utilization thresholds lets OpsWorks Stacks watch the layer's load metrics and automatically add or remove instances when CPU crosses upper or lower limits, with configurable cooldown and evaluation periods. This directly satisfies the CPU-based demand requirement because the layer scales out to more instances when CPU is high and scales in when it drops. Load-based instances are one of the built-in OpsWorks scaling types (along with time-based and 24/7 instances), and they are the only option listed that triggers scaling based on actual utilization.

The CloudFormation service role must have a permissions policy that explicitly grants the actions needed to create, update, and delete the stack's resources, because CloudFormation assumes this role to make those API calls on your behalf. Editing the role's IAM policy to include the required permissions, such as the relevant ec2:* or s3:* actions (or a narrowly scoped set), will allow the stack operation to proceed. This is the correct remedy because the service role's trust policy already permits CloudFormation to assume it; the missing piece is the authorization for the resource operations.

CloudWatch Events (now integrated with Amazon EventBridge) natively supports CodePipeline as a target, so you can create a rule with an event pattern for s3:ObjectCreated:* from the source bucket. When the S3 object is created, the event is matched and CodePipeline automatically starts an execution without any polling, custom code, or intermediary services, making this the fully event-driven and direct solution.

Creating a custom build image and pushing it to Amazon ECR lets you pre-install the exact Java JDK version (e.g., OpenJDK 17.0.9) along with any required build tools and system libraries. CodeBuild then uses that image as the environment baseline, so every build start from a consistent, immutable configuration. This approach supports image tagging and version rollback, and it eliminates the need for runtime package installation in the buildspec.

OneAtATime deploys to a single instance at a time, verifies that it is healthy, and then proceeds to the next. This is the most cautious approach and matches the requirement of deploying to a small number (one) first, then continuing to the rest.

AWS Systems Manager Maintenance Windows is the purpose-built service for scheduling and executing administrative tasks during defined time windows while preserving availability. It allows you to register an Auto Scaling group as a target and assign tasks (such as Patch Manager or custom Automation) with rate control to limit concurrency and error thresholds, ensuring only a controlled subset of instances is patched at a time. Maintenance Windows supports stop times, task priorities, and integration with Run Command and Automation documents, which can be used to recycle instances, refresh launch templates, or place instances in Standby during the maintenance activity. This orchestration is precisely what enables zero-downtime patching across a fleet managed by Auto Scaling, making it the correct answer.

In CodePipeline, a manual approval action is a stage action with category Approval that pauses the pipeline execution at that point. Once the action is reached, the pipeline enters a Wait state and notifies designated approvers via SNS; deployment to CloudFormation proceeds only after an authorized IAM user or role approves the change. This is the native mechanism designed to block progression until human sign-off, making it the correct way to require confirmation before deployment.

A stack policy can specify the allowed update actions per resource. By denying the 'Replace' action for the security group, CloudFormation will fail updates that would require recreating the security group, protecting it from accidental replacement.

Using AWS Secrets Manager with a dynamic reference allows CloudFormation to retrieve a secret at deployment time without exposing the value in the template, console, or logs. An AWS::SecretsManager::Secret resource with GenerateSecretString can automatically create a random password, and the rest of the stack can reference it via {{resolve:secretsmanager:secret-id:SecretString}}. This approach integrates with IAM policies, supports fine-grained permissioning, and can enable automatic rotation via a Lambda function, making it the AWS recommended best practice for secrets in infrastructure as code.

AWS CloudFormation StackSets lets you deploy the same CloudFormation template into multiple AWS accounts and Regions from a single administrator account. It creates stack instances in target accounts using either service-managed permissions with AWS Organizations or self-managed execution roles, and it includes deployment safeguards such as failure tolerance and maximum concurrent account thresholds. This is the native service designed specifically for orchestrated cross-account, cross-Region infrastructure rollout.

DeletionPolicy: Retain is the correct choice because it tells CloudFormation to leave the RDS DB instance untouched when the stack is deleted. The resource is removed from the stack's management, but the database remains live, accessible, and incurring costs in your AWS account. This exactly matches the goal of preserving the database after stack deletion.

In the CloudFormation event history, a 'Resource creation cancelled' status for a stack resource is the result of a WaitCondition or WaitConditionHandle timing out. For a WaitCondition resource, CloudFormation pauses the stack creation until it receives a success signal (typically sent by cfn-signal) from the launched resources. If that signal is not delivered within the specified Timeout period, the resource is marked as cancelled and the entire stack creation is stopped and rolled back. This failure mode is distinct from error-driven rollbacks because the resource itself never finished creating — it was simply waiting on an external signal that never arrived.

Blue/green in CodeDeploy for EC2 Auto Scaling groups provisions a separate, temporary 'green' replacement fleet alongside the original 'blue' fleet. After the green instances pass the configured health checks and tests, the load balancer or target group shifts production traffic from blue to green, enabling an immediate, nearly zero-downtime release. Because the blue fleet remains untouched until deployment completion, rollback is trivial: just flip traffic back and terminate green. This is the only option that both eliminates downtime and provides a built-in instant rollback path.

Change sets in AWS CloudFormation provide a summary of proposed changes to resources, including creations, modifications, and deletions, and flag any replacements. By reviewing a change set before executing it, you can detect unintended resource replacements (e.g., an RDS instance being replaced due to an immutable parameter) and abort the update if needed, thereby minimizing risk of change-related downtime or data loss.

The child stack persists after rollback, because CloudFormation leaves it in a terminal state for inspection. Its Events tab lists every resource created or attempted within the child, including the exact failure reason (e.g., an EC2 instance's user-data script exit code, an IAM permission denial, or a resource creation timeout). This is the authoritative source of diagnostic information because the parent stack only sees the child as an atomic resource.

Separate CodePipeline stages with cross-account actions using IAM roles is the correct architecture because CodePipeline natively supports cross-account actions by assuming a role in the target account for each stage. The pipeline in the originating account uses a source stage, then invokes a deployment action that assumes an IAM role in the destination account, allowing you to deploy the same artifact to multiple accounts sequentially or in parallel. This design enforces least privilege, keeps the pipeline state centralized while distributing execution, and meets the requirement of deploying to multiple accounts without combining resources.

Run Command's SendCommand API accepts a target that can be a tag key-value pair, like tag:Environment=Production, and every SSM agent that matches will execute the AWS-RunShellScript or AWS-RunPowerShellScript document immediately in a one-time, unmanaged fashion. This satisfies the requirement of running a script once across the fleet, with output optionally streamed to S3 or CloudWatch Logs for auditing. Because no association, schedule, or patch baseline is involved, it is the simplest and most direct SSM primitive for this task.

When you enable S3 Versioning, every object version has a unique versionId, and a GetObject request that specifies that version requires an explicit s3:GetObjectVersion permission in addition to s3:GetObject. The deployment workflow is calling GetObject with a versionId to fetch a unique revision, and the policy only grants the standard object-level actions. Without s3:GetObjectVersion, AWS rejects the request with AccessDenied, making this the exact root cause.

When an Elastic Beanstalk environment uses a custom AMI through a launch template, the template holds the exact AMI ID. Updating the source AMI or rebuilding the environment does not change that ID. You must explicitly edit the launch template's ImageId (or use a new launch template version) and then rebuild, otherwise EC2 instances continue to launch with the original AMI. This is the direct cause of the environment still running the old configuration.

The BeforeInstall hook is a lifecycle event in a CodeDeploy deployment. If the script exits with any non-zero exit code, CodeDeploy treats that as an unrecoverable failure and immediately stops the deployment, marking the instance as failed. A bug such as a missing command, a syntax error, or a failed dependency check would produce exactly this behavior, and the agent log would show the script's error output.

CloudFormation is the native AWS infrastructure-as-code service: you define resources in a JSON or YAML template, and the service provisions, updates, and deletes them as a stack with order-aware dependencies and automatic rollback on failures. It supports almost every AWS resource and allows drift detection to compare actual configuration to template state. This exactly matches the goal of automating creation of Amazon infrastructure.

Configuring the migration step as a sequential action with OnFailure set to ABORT causes CodePipeline to immediately stop the pipeline execution when that action fails, without running any subsequent actions or stages. The existing deployment remains untouched because no further deployment stages are triggered after the failure. This matches the requirement precisely: the pipeline halts and the prior version stays in place.

CloudFormation dynamic references (e.g., {{resolve:ssm-secure:MyParameter}}) resolve secure string parameter values from Systems Manager Parameter Store during stack create and update operations, so the plaintext secret never appears in the template itself. The secure string is encrypted with a customer-managed or AWS-managed KMS key, and CloudFormation retrieves the decrypted value only at stack operation time, which prevents secrets from being exposed in template files, repository history, or AWS CloudTrail logs.

Run Command invocations use the SSM Agent's existing outbound HTTPS connection (port 443) — no inbound rule changes are needed. The command output for each instance is stored separately in S3, allowing the team to review per-instance results. Commands can target instances by tag (e.g., Environment=production) to avoid listing all 150 instance IDs manually.

EC2 Image Builder is the purpose-built AWS service for producing golden AMIs. A component encapsulates the PowerShell script logic, a recipe bundles that component with a base image and OS settings, and a pipeline can be scheduled to run weekly to automatically build, validate, and register the AMI. It also supports post-build testing and cross-account/region distribution, giving a fully managed, auditable image lifecycle with minimal operational overhead.

AWS::S3::Bucket is the CloudFormation resource type that directly provisions an S3 bucket as part of a stack. It supports configuration properties such as BucketName, VersioningConfiguration, AccessControl, and Encryption, allowing the bucket to be created with the desired settings. When included in a template, CloudFormation handles the full lifecycle of the bucket, including creation, updates, and deletion on stack removal.

CloudFormation enforces strict type validation for resource properties, and the MinSize attribute for AWS::AutoScaling::AutoScalingGroup is defined as an integer. When a value like "1" is passed as a quoted string, CloudFormation rejects the template because it does not match the expected Integer type. The fix is to remove the quotes or use the intrinsic function with a proper numeric value in the template.

AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy form a fully managed CI/CD service chain: CodePipeline is the orchestrator that automatically starts on a new CodeCommit push, CodeBuild compiles and packages the application into an artifact, and CodeDeploy deploys that artifact to compute services such as EC2 or Lambda. This trio natively supports stage progression, artifact handoff, rollback alarms, and permission transitions without custom code, making it the only choice that delivers end-to-end automated deployment from a repository event.

This is the correct approach because Elastic Beanstalk's Auto Scaling group uses CloudWatch alarms to drive scaling actions based on the average CPU utilization of the EC2 instances in the environment. You can define a scaling trigger—either a simple/step scaling policy tied to a CloudWatch alarm or a target tracking policy that continuously adjusts capacity to keep CPU near a target value. When the alarm enters an ALARM state (e.g., CPU exceeds 70% for 5 minutes), the policy proactively launches additional instances, and when it returns to OK, it terminates excess instances, providing dynamic, workload-aware scaling.

The Elastic Beanstalk console provides a supported, declarative way to change the environment's instance type. When updated, Elastic Beanstalk modifies the Auto Scaling launch configuration and then applies a rolling update strategy, progressively replacing instances so that at least the minimum capacity stays available. This preserves all environment-level settings and can be done with minimal or zero downtime, making it the correct approach.

By creating subnets in multiple Availability Zones and then referencing those all subnets in the Auto Scaling group's network configuration, you enable the group to automatically distribute instances across all the specified AZs. This is the canonical method for achieving high availability, as the Auto Scaling group will balance instances among the AZs and, if one AZ becomes unhealthy or has insufficient capacity, it can launch replacement instances in the other AZs. Without this multi-subnet specification, the group cannot spread itself across AZs, because it can only launch instances into the subnets explicitly provided.

The patch baseline filters patch approvals by severity (e.g., CRITICAL, IMPORTANT). The maintenance window triggers the AWS-RunPatchBaseline SSM document on schedule. All 200 instances receive the same baseline and schedule, replacing manual inconsistency with automated consistency. Patch compliance is recorded in the Patch Manager compliance dashboard.

Updating the CloudFormation stack with a larger AllocatedStorage value invokes RDS's online storage scaling, so the disk can be expanded while the instance remains available. CloudFormation translates the template change into a ModifyDBInstance operation; with ApplyImmediately not set to true, the change is applied during the next scheduled maintenance window, avoiding an unplanned outage. This keeps the existing endpoint and replication topology intact and is the least disruptive, infrastructure-as-code-friendly approach.

AWS CodeDeploy is the dedicated application deployment service that performs in-place or blue/green deployments with configurable traffic routing (canary, linear, or all-at-once). When deploying to an EC2 Auto Scaling group, CodeDeploy creates a new auto-scaling group for the green fleet, installs the revision, and then shifts traffic via the attached load balancer. This gives the administrator fine-grained control over the rollout and rollback behavior.

An IAM role with S3 access is the correct and secure way to grant an EC2 instance permissions. When you attach the role to an instance profile and associate it with the instance, EC2 automatically retrieves temporary credentials from the instance metadata service (IMDSv2), which are rotated every few hours. The application can then make S3 API calls using the AWS SDK without ever managing static credentials. This leverages least privilege and eliminates the risk of exposed access keys.

AWS CodeDeploy is purpose-built for application deployment to EC2 instances, including those in an Auto Scaling group. It supports blue/green deployments with traffic shifting via an Application Load Balancer, allowing zero-downtime releases by registering new instances and shifting traffic gradually. Its integration with ASG lifecycle hooks ensures that new instances launched during scaling out automatically receive the latest application revision, making it the correct choice.

CodeDeploy's error is generic, so instance-level detail is decisive. The CodeDeploy agent writes lifecycle event logs to /opt/codedeploy-agent/deployment-root on each EC2 instance, revealing the actual failure (hook script, permissions, or missing dependencies) behind the aggregate deployment-group message.

The DeletionPolicy attribute with value Retain is the correct CloudFormation resource-level setting to preserve an S3 bucket when its stack is deleted. It instructs CloudFormation to skip deleting the underlying resource, so the bucket and all objects remain in the AWS account as an orphaned resource. This is designed exactly for the use case of retaining stateful data such as S3 buckets or DynamoDB tables after infrastructure teardown.

The create-change-set command constructs a change set that describes the modifications CloudFormation would make to the stack if the updated template were applied, without actually changing any resources. You can then use describe-change-set or the CloudFormation console to review every resource action (Add, Modify, Remove) including property details and whether a replacement will occur, before you decide to call execute-change-set. This two-phase approach is specifically designed to give you a safe, non-destructive preview of the update, which is exactly what the question requires.

AWS CloudFormation StackSets with automatic deployment is the native, service-integrated method for account baselining. When a new account is added to an AWS Organization, StackSets with service-managed permissions automatically creates stack instances in that account, using the organization's trusted access to deploy the baseline template. This eliminates the need for custom event-driven orchestration and ensures consistent governance across the entire organization.

Updating the custom cookbook source (e.g., S3, Git, or HTTP) on the OpsWorks stack and then running the 'deploy' lifecycle recipe is the correct and intended method for rolling out application changes. The deploy recipe triggers a stack-wide command that executes your custom Chef recipes on all online instances in the selected layer or stack, following the defined deployment lifecycle (before_deploy, deploy, after_deploy). This ensures all instances receive the same application update in a coordinated, automated fashion, and because OpsWorks uses Chef, the recipe can handle dependencies, configuration templates, and service restarts consistently across the fleet.

Configuring an SSH key in the OpsWorks stack is the correct method because OpsWorks natively supports private Git repositories by letting you supply a private SSH key in the Repository SSH Key field for custom cookbooks. You add the matching public key as a deploy key on the GitHub repository with read-only access, and OpsWorks uses that key to authenticate when it downloads or updates cookbooks on your instances. This keeps the repository private and avoids storing plaintext credentials, while also allowing Chef to automatically pull the latest cookbook revisions during stack updates and instance setup.

Configuring the deregistration delay on the load balancer target group and enabling CodeDeploy's load balancer integration ensures that CodeDeploy automatically deregisters each instance, waits for in-flight requests to complete (based on the deregistration delay), performs the deployment, and then re-registers the instance. This built-in integration is the recommended way to avoid downtime during in-place deployments. CodeDeploy also waits for the instance to pass health checks before marking the deployment successful. This configuration is set in the deployment group's load balancer section.

AWS CloudFormation with the AWS Serverless Application Model (SAM) is the definitive infrastructure-as-code approach for serverless applications. SAM is an open-source framework that extends CloudFormation with simplified syntax to define serverless resources like Lambda functions, API Gateway APIs, and DynamoDB tables in a template, then transforms them into full CloudFormation stacks. It also provides local testing via the SAM CLI, supports automatic IAM role generation, and enables deployment through CodeDeploy for safer Lambda traffic shifting, making it purpose-built for serverless. By using SAM, a SysOps administrator can version, review, and reliably replicate the entire serverless application in a repeatable, auditable way.

CloudWatch metrics track CPU, memory, network, and request latency, while Elastic Beanstalk aggregates application and web server logs that can expose 5xx errors, stack traces, or slow queries. Reviewing these data sources together reveals whether the performance issue is due to a bottleneck, a recent deployment, or a resource limitation, allowing you to make a data-driven adjustment. This is the correct first step before any scaling action to ensure the actual root cause is addressed.

Changing the S3 bucket name in the CloudFormation template to a unique name resolves the conflict because the CreateBucket API only needs a name that is not already taken globally. This is the correct approach because it allows CloudFormation to provision a brand-new bucket without naming collision. Alternatively, you could omit the BucketName property entirely so CloudFormation generates a unique name with a random suffix, but specifying a deliberate unique name works equally well.

When a stack update fails and the automatic rollback also fails, the stack enters the UPDATE_ROLLBACK_FAILED state. To recover, you must first resolve the underlying cause, such as an insufficient IAM permission or a resource that cannot be rolled back, then call the ContinueUpdateRollback API or use the AWS Management Console to resume the rollback. This action transitions the stack to UPDATE_ROLLBACK_COMPLETE, restoring it to its last known stable configuration.

User data in the launch configuration runs at each instance boot, so newly launched Auto Scaling instances install the CodeDeploy agent automatically. This satisfies the requirement that instances joining the group have the agent present before CodeDeploy attempts deployment.

Stack policies are JSON-based IAM-style policies attached to a CloudFormation stack that act as an explicit guard against certain update actions. By configuring a stack policy that denies the Update:Replace action for the RDS DB instance resource (using "Effect": "Deny" and "Action": ["Update:Replace"]), CloudFormation will refuse to replace the database during any stack update. This is exactly the protection the administrator needs to ensure the database is not inadvertently replaced.

This is correct because when you launch an instance in a VPC, AWS requires you to reference security groups by their group ID (e.g., sg-12345678), not by their name. In a VPC, the CLI parameter "--security-group-ids" expects the resource ID, and passing the name "default" (how it appears in the console) causes a "security group does not exist" error. The default VPC's default security group has a unique ID, and you must retrieve and use that ID to successfully launch the instance.

CloudFormation does not automatically create an intrinsic dependency between a DBInstance and a DBSubnetGroup when the DBSubnetGroup is referenced by its name string rather than through the Ref function. Since the DBSubnetGroupName property in an RDS DBInstance expects a string, passing a literal name or a parameter does not establish a resource dependency, so CloudFormation may attempt to create the DBInstance before the DBSubnetGroup exists. This results in an error such as 'The specified DB Subnet Group does not exist' or 'DBSubnetGroup not found.' Adding an explicit DependsOn attribute to the DBInstance forces CloudFormation to wait until the DBSubnetGroup has been successfully created, making the creation order deterministic and resolving the failure.

Deploy is the OpsWorks lifecycle event explicitly designed for deploying applications. When you deploy, OpsWorks runs the Deploy recipes on specified instances, which typically perform tasks like pulling source code from a repository, running database migrations, and restarting application services. This is the correct event to use whenever you need to roll out a new version of an application to existing instances.

Blue/green deployment provisions a complete second environment (green) alongside the current production environment (blue), allowing you to run tests against the new version while old traffic continues to flow. Once the new environment is validated, you shift traffic at the load balancer or DNS level—either all at once or gradually—making the cutover near-instantaneous. If the new environment fails, you simply switch traffic back to the still-available blue environment, enabling instant rollback with zero downtime, which is why this is the correct choice for high-availability web applications.

A blue/green deployment strategy is a best practice because it provisions the new application version in a separate 'green' environment alongside the existing 'blue' one, allowing traffic to be switched over only after the new version passes health checks. This minimizes downtime and gives an almost instantaneous rollback path by simply redirecting traffic back to blue if a problem is detected. In AWS, this works with CodeDeploy, Elastic Beanstalk, and ECS, though stateful workloads like databases require careful compatibility analysis between the two environments.

Custom cookbooks are Chef cookbooks (recipes, templates, and files) that you store in a repository such as S3 or Git and assign to an OpsWorks layer. OpsWorks runs these cookbooks automatically during lifecycle events (Setup, Configure, Deploy, Undeploy), so you can use a template resource inside a recipe to render configuration files consistently on every instance in the layer. This is the native, supported way to manage configuration files in OpsWorks, and it is the correct answer because it integrates with the layer lifecycle and ensures ongoing convergence.

On Amazon Linux 2, Ruby and wget are not installed by default, and the CodeDeploy agent is a Ruby application that also relies on wget to download deployment artifacts. If these dependencies are missing, the agent process either fails to start or crashes immediately, so the instance never registers with CodeDeploy and the deployment hangs at the 'Stop' or 'BeforeInstall' step. The standard installation procedure requires running `yum install -y ruby wget` before installing the agent, so an AMI that omits them will cause exactly this failure.

A load-balanced environment provisions an Elastic Load Balancer (ALB or NLB) in front of the EC2 instances running the microservices. This allows incoming traffic to be distributed across multiple instances, provides a stable endpoint for external clients, and enables services to discover each other via the load balancer DNS name. It also supports health checks, auto scaling, and rolling deployments, which are essential for production microservices.

Rolling deployment with rollback updates an Auto Scaling group in controlled batches, replacing or re-launching a subset of instances at a time while the remaining instances continue serving traffic. Elastic Load Balancing health checks verify each batch before the next begins, and if errors exceed a threshold, CodeDeploy or a similar tool automatically redeploys the previous version to restore service. This provides both gradual exposure and a safety net, which matches the requirement of deploying a new version with rollback capability.

Attaching an IAM role to the EC2 instances using an instance profile is the correct, secure mechanism for granting access to S3. When a role is attached, the instance can retrieve temporary, automatically rotating credentials from the instance metadata service (IMDSv2), which are assumed via STS. This eliminates the need to distribute or manage long-term access keys, reduces the risk of credential exposure, and simplifies permission updates because changes to the role policy take effect immediately for all associated instances.

A dynamic reference using {{resolve:ssm:parameter-name}} is resolved by CloudFormation at the time a stack operation is performed, not when the template is authored. This means that when you update the stack after the Systems Manager Parameter Store value changes, CloudFormation automatically retrieves the current AMI ID and uses it for resource creation or replacement. It is the only option that inherently satisfies the requirement to automatically adopt the latest AMI ID without editing the template or providing manual input.

The SSM Agent is required for an EC2 instance to communicate with AWS Systems Manager and receive Run Command documents. Additionally, the instance must have an attached IAM role that grants the AmazonSSMManagedInstanceCore managed policy, allowing it to register, send heartbeats, and pull commands from the SSM service. Without both the agent running and the correct IAM permissions, the instance never appears in the Managed Instances list, so Run Command returns 'Instance ID not found' when you target it. This is the definitive cause when resolving this specific error.

Change sets are the correct method for previewing CloudFormation updates. They generate a summary of the actions CloudFormation will perform when you execute the change set, explicitly flagging each resource as 'Static' (no change), 'Update' (in-place modification), or 'Replace' (recreation with a new physical ID). This allows you to inspect the exact impact before committing, so you can avoid unintended resource recreation and associated data loss or downtime.

An outdated AMI often contains yum or apt repository URLs that point to deprecated or retired endpoints. When cloud-init executes user data that runs package installs, the package manager tries to reach those old repositories and receives a 404 or 'repository not found' response, causing the boot-time failure. This is a common issue with Amazon Linux AMIs that have reached end-of-life, where the original repositories are no longer maintained and the instance cannot update or install software despite successfully booting.

A stack policy can explicitly deny update, replace, or delete actions on specific resources. By applying a policy that denies update to the RDS resource, the CloudFormation update will fail if it attempts to modify the RDS instance, thus protecting it from accidental replacement.

Immutable deployment creates a completely separate Auto Scaling group with a new launch template or configuration running the new application version. It lets the new fleet fully initialize, pass health checks, and register with the load balancer before traffic is shifted away from the old fleet. Because the old fleet remains untouched until traffic has moved and can be instantly restored by redirecting traffic back, it provides zero downtime and a trivial rollback mechanism.

CodeDeploy's rollback feature automatically redeploys the last known successful revision to every instance in the deployment group, using the same AppSpec and lifecycle hooks to ensure a clean, consistent transition. The rollback is initiated from the console and runs as a new deployment, honoring deployment configuration settings such as minimum healthy hosts, so it performs a proper rolling update rather than a crude file copy. This restores the working state and provides audit logs for what was rolled back and when, making it the correct and safe recovery method.

Blue/green with a new Auto Scaling group and an Application Load Balancer is the correct answer because it creates a fully independent second environment (green) with its own ASG, then shifts traffic at the ALB listener level from the old (blue) to the new (green) target group. If health checks on the green target group fail or any deployment validation fails, the ALB can instantly route traffic back to the blue target group, making rollback a trivial DNS/rebinding change. This pattern avoids in-place modifications, eliminates downtime, and is explicitly designed for automated health-check-based cutover and rollback.

The BeforeInstall script's exit code is the definitive indicator of hook failure: CodeDeploy expects a 0 for success, and any non-zero value tells the agent to mark the deployment as failed. The deployment logs on the instance, typically under /opt/codedeploy-agent/deployment-root/deployment-logs/, store standard output and standard error for each script, while the CodeDeploy console provides a truncated view of the last 100 lines. Reviewing these logs will reveal the actual error message and the command that failed, enabling you to correct the script or its environment.

Decoupling the database from Elastic Beanstalk is the recommended approach because it gives you full control over RDS features like Multi-AZ failover and read replicas. By creating a separate Multi-AZ RDS instance, you enable synchronous standby replication and automatic failover, and adding read replicas handles read scaling. Updating environment properties (e.g., RDS_HOSTNAME) to reference the new database makes the application use it, and deleting the old EB-managed DB avoids abandoned resources. This solution satisfies high availability and is a standard production practice.

A direct stack update is the correct method because CloudFormation compares the modified template against the current stack and applies the changed InstanceType property to the existing EC2 instance without replacement. The update can be submitted via the AWS Management Console, AWS CLI, or API, and because this is a simple, in-place attribute change, it minimizes downtime and avoids extra operational overhead. This approach is the fastest and least disruptive way to achieve the desired configuration.

The trust policy on an IAM role defines which entities, such as AWS services, are allowed to call sts:AssumeRole to temporarily obtain the role's credentials. For Lambda to execute, that policy must include the service principal lambda.amazonaws.com in the Principal element; otherwise, the AssumeRole call is denied and the invocation fails before the function code runs. Adding a permissions policy alone is insufficient, because Lambda must first be allowed to assume the role.

Running aws cloudformation describe-stack-events --stack-name <stack-name> retrieves every event in the stack's lifecycle, including the most recent update attempt. Each event includes the LogicalResourceId, ResourceStatus (e.g., UPDATE_FAILED), and the ResourceStatusReason field, which contains the specific error message from the underlying AWS service that caused the failure. Reviewing the events in reverse chronological order lets you pinpoint exactly which resource failed and why, making this the definitive troubleshooting command for failed CloudFormation operations.

AWS CodePipeline is the correct choice because it is a fully managed continuous delivery service that orchestrates the build, test, and deploy phases of a release process. It lets you model the entire workflow as a series of stages — Source, Build, Test, Deploy — with sequential or parallel actions, and automatically triggers each stage when the previous one succeeds. CodePipeline integrates natively with AWS CodeCommit, CodeBuild, CodeDeploy, Elastic Beanstalk, ECS, and third-party tools like GitHub and Jenkins, making it the central coordinator for a CI/CD pipeline rather than just a tool that executes a single step. Its pipeline structure and transition gates provide the end-to-end automation a DevOps engineer needs for a microservices delivery workflow.

Deleting the failed stack is the correct first step because CloudFormation creation failures can leave resources in a transient or partially rolled-back state, and the stack cannot be updated or reused while it is in ROLLBACK_COMPLETE. Then changing the DB instance identifier parameter to a globally/regionally unique name avoids the RDS naming conflict that caused the failure; RDS DB instance identifiers must be unique per account within a Region. Finally, recreating the stack with the new parameter allows CloudFormation to provision a fresh DB instance without colliding with an existing resource, so this is the only approach that directly addresses the root cause.