Deployment, Provisioning, and Automation practice questions

Create a maintenance window with a rate schedule of 30 days and use an AWS-ApplyPatchBaseline document with operation 'Scan' and reboot option 'RebootIfNeeded'.

Why it fails: A rate schedule cannot specify a particular day of the week. The operation 'Scan' only checks for missing patches without installing them.

Create a maintenance window with a cron schedule of cron(0 2 14 * ? *) and use an AWS-RunPatchBaseline document with operation 'Install' and reboot option 'RebootIfNeeded'.

Why it fails: This cron schedule triggers on the 14th day of every month, not the second Tuesday.

Create a maintenance window with a cron schedule of cron(0 2 2 * 2 *) and use an AWS-InstallPatchBaseline document with operation 'Install' and reboot option 'NoReboot'.

Why it fails: The cron expression is invalid; the correct format uses ? for day-of-week and * for month. Also, AWS-InstallPatchBaseline is not a valid SSM document.

In-place deployment

Why it fails: In-place deployment does not shift traffic gradually; it updates instances directly, causing downtime and no traffic shifting.

Blue/green deployment with Linear10PercentEvery10Minutes configuration

Why it fails: Blue/green with Linear10PercentEvery10Minutes automatically shifts 10% every 10 minutes, fully automated, without any pause for manual approval.

Blue/green deployment with AllAtOnce configuration

Why it fails: Blue/green with AllAtOnce shifts all traffic to the new version immediately, not matching the requirement.

CodeDeployDefault.AllAtOnce

Why it fails: CodeDeployDefault.AllAtOnce is not a canary configuration because it deploys the new revision to every instance in the deployment group at the same time, with no incremental traffic shifting. This means the entire fleet and all user traffic are updated immediately, offering zero opportunity to validate the new version on a small subset. It does not meet the requirement to first shift only 10% of traffic, so it is incorrect.

CodeDeployDefault.HalfAtATime

Why it fails: This configuration updates half of the target instances at a time, then shifts traffic in 50% increments rather than the specified 10% initial canary. After the first half is deployed, 50% of traffic is routed to the new version, which is far too large a blast radius for the stated 10%/5-minute requirement. Because it does not provide a low-risk 10% shard, it fails to match the required deployment behavior.

Custom configuration with 10% and manual approval

Why it fails: While a custom deployment configuration could be created to shift 10% of traffic, that only defines the traffic-shifting pattern; it does not include a 5-minute wait or automatic approval. Adding a manual approval step would require human intervention, which is slower and error-prone, and CodeDeploy has no built-in 'manual approval' in its deployment configurations—you'd need additional automation. Since the predefined Canary10Percent5Minutes already provides the exact 10% shift and 5-minute wait without extra steps, using a custom configuration with manual approval is less efficient and unnecessary.

CodeDeployDefault.AllAtOnce

Why it fails: This configuration deploys the new application revision to all instances at once, causing every instance to shift traffic simultaneously with no staged intervals. Since it provides zero incremental canary progression, it cannot satisfy the requirement of shifting 25% of traffic every 10 minutes, nor would it allow a safe rollback before a larger portion of the fleet is exposed.

CodeDeployDefault.OneAtATime

Why it fails: This configuration shifts traffic one instance at a time, but the interval between each shift is fixed at 5 minutes rather than the required 10 minutes. It also defines shifts by instance count rather than percentage, so the actual traffic increment varies based on fleet size (e.g., one out of five is 20%, not 25%), making it impossible to guarantee a 25% step every 10 minutes.

CodeDeployDefault.HalfAtATime

Why it fails: This configuration shifts traffic in only two large increments of 50% each, using a default interval of 5 minutes between them. A 50% step is far too aggressive for the desired 25% gradual rollout, and the 5-minute interval does not match the stipulated 10-minute waiting period, so the health-check feedback and rollback window would be insufficient.

Stack Policies

Why it fails: A stack policy is an IAM-style JSON document attached to a stack that specifies which resources are protected from update or deletion attempts. It enforces write-time authorization by preventing unintentional changes, but it does not generate a list or diff of proposed modifications. Rather than offering a preview, a stack policy simply blocks certain operations on designated resources, so it cannot be used to review changes before they occur.

Resource Signals

Why it fails: Resource signals, typically implemented via cfn-signal and a WaitCondition or CreationPolicy, are used to coordinate the creation or update of resources by indicating whether a given action completed successfully. The stack waits for a specified number of signals before continuing, which helps detect provisioning failures but does not forecast or describe what changes are coming. Their sole purpose is synchronization and validation during execution, not advance preview of proposed actions.

Nested Stacks

Why it fails: Nested stacks let you abstract and reuse common infrastructure patterns by declaring AWS::CloudFormation::Stack resources within a root template, enabling modular template composition. They help manage complexity and avoid duplicated code, but they do not include any inherent capability to preview updates at the parent stack level. While you could manually create change sets on a nested stack, nested stacks themselves provide no mechanism to review proposed changes across the entire stack.

Rolling

Why it fails: A rolling deployment updates the existing Auto Scaling group in batches, so the load balancer continues to route traffic to instances that are still running the old version while others are being replaced. Because there is no separate staging environment, the new version is exposed to production traffic immediately, making it impossible to fully validate behavior before any users hit it. If a batch fails, you must roll back or continue with mixed versions, adding complexity and risk.

Rolling with additional batch

Why it fails: Rolling with additional batch first launches extra instances with the new version to maintain capacity and reduce the chance of resource exhaustion, but those instances are immediately added to the existing Auto Scaling group and load balancer. This means both old and new versions receive production traffic throughout the deployment, so there is no isolated window to test the new release before users are affected. It improves availability but does not offer the clean blue/green separation needed for pre-routing validation.

All at once

Why it fails: An all-at-once deployment terminates every running instance and replaces them with new ones in a single operation, which is the fastest strategy but causes a full service outage during the transition. There is no point during which the new version can be validated without taking the old environment down first, and any failure means the application is unavailable until the new fleet is healthy or you manually roll back. This is rarely acceptable for a web 2.0 production environment.

VPC: A managed VPN service for connecting on-premises networks to AWS.

Why it fails: This description mischaracterizes a VPC; it actually describes AWS Site-to-Site VPN, which creates encrypted IPsec tunnels into your VPC from on-premises routers. A VPC is the virtual network into which those VPN tunnels connect, not the tunneling service itself. Additionally, a VPC does not incur a per-hour service fee for the network itself, whereas managed VPN endpoints are billable resources.

NAT Gateway: A component that allows inbound internet traffic to reach private instances.

Why it fails: A NAT Gateway exclusively supports outbound traffic from private subnets to the internet and only allows replies to that established traffic; it will not accept unsolicited inbound connections. This is the opposite of the described behavior. To expose private instances to inbound internet traffic, you would place an Application Load Balancer or NAT instance in a public subnet, or use a bastion host, because NAT Gateway is fundamentally not an ingress path.

Use the '--disable-rollback' flag when updating the stack.

Why it fails: The '--disable-rollback' flag prevents CloudFormation from rolling back the stack to its last known good state if the update fails, but it provides no preview of the changes that will be made. When you use this flag, the update proceeds directly, and any resource replacement—such as an RDS instance with a new physical ID—will occur without warning. If the replacement causes downtime or data loss, you will only discover it after the fact. This flag is about failure behavior, not change review.

Use a nested stack to isolate the RDS resource.

Why it fails: Using a nested stack to isolate the RDS resource does not create a mechanism for previewing or approving changes before they happen. Nested stacks simply group resources into separate stacks under a parent stack; the parent update orchestrates updates to nested stacks, but CloudFormation still applies any changes—including replacements—automatically as part of the update operation. The isolation may limit the blast radius or allow independent lifecycle management, but it does not surface a change report or require manual consent before a replacement occurs. Thus, it does not address the need to know about a destructive change in advance.

Use the '--parameters' option to specify a parameter that controls replacement.

Why it fails: The '--parameters' option is used only to supply input values to the template; it does not trigger any validation or warning about the consequences of those values. If you change a parameter that is referenced in an RDS resource property (e.g., a DB instance identifier or availability zone), CloudFormation will apply the new value during the update. If that value causes a replacement, the resource will be replaced silently, without any prior notification. Parameter changes are not inherently dangerous themselves; the danger lies in how they affect resource properties, and that impact can only be assessed through a change set or other review mechanism.

CodeDeployDefault.AllAtOnce

Why it fails: AllAtOnce deploys to every instance simultaneously, so no batch is health-checked before the next proceeds, directly violating the staged requirement. It suits non-production environments or trivial changes where downtime and instant rollback across the whole fleet are acceptable.

CodeDeployDefault.HalfAtATime

Why it fails: HalfAtATime splits the fleet into two fixed halves, not arbitrary batch sizes, and the second half begins once the first passes health checks. It fits simple two-phase rollouts, but the stem demands configurable batch counts with per-batch validation, which this predefined configuration cannot express.

CodeDeployDefault.Custom

Why it fails: CodeDeployDefault.Custom is not a real predefined configuration name; custom configurations are user-created and referenced by their own names, so this value cannot be selected. It tempts administrators wanting tailored batch sizes, who must instead create a named custom deployment configuration specifying the percentage.

Rolling update

Why it fails: A rolling update incrementally replaces running instances with new ones using an updated AMI or user data, but it terminates each old instance without preserving its local state. If the EC2 application stores sessions, in-memory caches, or files on instance-store volumes or non-replicated EBS volumes, those data are destroyed as each instance is cycled. Because the application is mission-critical, this approach risks partial and complete state loss during the update, making it unsuitable.

Canary deployment

Why it fails: A canary deployment launches a small number of instances with the new version and routes a fraction of live traffic to them, then gradually increases the percentage. While this limits blast radius, it does not solve the underlying state problem: if session state is bound to a specific EC2 instance or local disk, shifting traffic between the canary and the stable fleet causes users to lose context. The canary's value lies in validating the new code, not in preserving state, so it is still an unsafe choice for this stateful workload.

Immutable update

Why it fails: An immutable update launches a fresh set of instances from a new launch template or AMI, allows them to pass health checks, and then terminates the old instances as a batch. All local state on the old instances—whether on instance store or EBS root volumes—is irretrievably lost when the fleet is replaced, and there is no mechanism to migrate state before cutover. Because the application is mission-critical and presumably holds state locally, an immutable update would cause a hard service interruption.

Remove DependsOn clauses to allow parallel resource creation.

Why it fails: CloudFormation already creates independent resources in parallel by default, so removing DependsOn only helps if an unnecessary explicit dependency is artificially serializing the deployment. However, this is a template design change rather than a rollback flag or timeout adjustment, and it does not address other causes of slowness such as resource provisioning time or wait conditions. In many cases, DependsOn is required for correct ordering, so stripping it out can break stack semantics without providing a guaranteed speedup.

Set the '--disable-rollback' flag.

Why it fails: The '--disable-rollback' flag alters what happens when a stack operation fails: it instructs CloudFormation to leave successfully created resources in place instead of rolling them back, which is useful for debugging but has no effect on the speed of resource creation. Slow deployments are caused by resource provisioning time, wait conditions, or serialization, not by rollback behavior. Since rollback occurs only after a failure, disabling it cannot accelerate a successful deployment.

Increase the timeout on the WaitCondition.

Why it fails: A WaitCondition has a timeout that limits how long CloudFormation waits for the required signals before proceeding or failing. Increasing that timeout would extend the maximum wait period, so if a signal is slow or missing, the stack will idle even longer, making the deployment slower rather than faster. This option is counterproductive because it increases the total time in the worst case.

The instances are in a private subnet without a NAT gateway.

Why it fails: The assumption that a private subnet without a NAT gateway prevents CodeDeploy is incorrect when VPC endpoints are configured. CodeDeploy can use a gateway endpoint for Amazon S3 to fetch application revisions, and an interface endpoint for the CodeDeploy service for API calls, so no public IP or NAT is strictly required. If the revision is stored in S3 and the route to the VPC endpoint exists, the agent can download it even from a private instance.

The instances do not have internet access.

Why it fails: Similarly, having no internet access at all does not block a deployment if the environment uses VPC endpoints. The CodeDeploy agent communicates with the CodeDeploy API and downloads the revision from S3; both of these are reachable through endpoints without crossing the internet. Without endpoints, the agent would need internet to reach the service, but the question does not indicate endpoints are absent, so the lack of internet alone is not the root cause.

The application's health check is failing on the target group.

Why it fails: A failing target group health check will cause the load balancer to deregister the instance and stop routing traffic to it, but it does not cause the CodeDeploy deployment to fail at the revision-download step. CodeDeploy evaluates health checks after the new version has been installed and the instance is registered back into the target group; a pre-existing health check failure might be a symptom, not the reason the deployment cannot download the revision from S3. Therefore, this condition is unrelated to the observed failure when the revised application is being deployed.

AWS Lambda.

Why it fails: AWS Lambda is a serverless compute service that executes code in response to events; it is not designed to orchestrate a multi-stage CI/CD pipeline. While you could write Lambda functions to invoke build or deploy tools, Lambda lacks native pipeline state management, stage sequencing, approval gates, and integrated failure/rollback handling. Using Lambda as the primary CI/CD engine would require custom orchestration code, effectively reinventing AWS CodePipeline in an unnecessary and brittle way.

AWS CodeBuild.

Why it fails: AWS CodeBuild is a fully managed build service that compiles source code, runs unit tests, and produces deployable artifacts as a single build job. It does not orchestrate the end-to-end release process, because it has no built-in concept of source commits automatically triggering sequential stages, nor does it manage deploys to environments or manual approval checkpoints. In a CodePipeline-based workflow, CodeBuild typically runs as a build action within one stage, not as the pipeline orchestrator itself.

Amazon CloudWatch Events.

Why it fails: Amazon CloudWatch Events (now part of Amazon EventBridge) is an event bus that routes AWS service events to targets like Lambda functions, SNS topics, or Step Functions. It can be configured to detect a CodeCommit push and trigger an action, but it does not provide the workflow state machine needed to sequence build, test, and deploy stages with rollback and approval controls. Using CloudWatch Events alone would leave you to implement all pipeline logic manually, which is why CodePipeline, not CloudWatch Events, is the correct CI/CD service.

The Auto Scaling group has a cooldown period that prevents termination.

Why it fails: Auto Scaling cooldown delays scaling activities after a previous action; it does not block CodeDeploy from terminating original instances during blue/green cleanup. The likely cause is a termination hook or the deployment group's original instance termination setting being disabled.

The new instances failed the initial health check.

Why it fails: The stem states the new instances passed all health checks, so this contradicts the given facts. Failed health checks would trigger a rollback, leaving old instances serving traffic. This option would be relevant only when replacement instances genuinely fail validation.

The deployment was rolled back automatically.

Why it fails: A rollback would restore the original environment and typically terminate the replacement instances, not leave old ones running after a successful deployment. The stem confirms health checks passed, so no rollback occurred. Rollback applies when validation or lifecycle events fail.

Add a separate stage for approval in the pipeline.

Why it fails: In AWS CodePipeline, an approval action is an action of category "Approval" that lives inside a stage—not a stage itself. Adding a separate stage would still require you to place an Approval action within that stage to actually pause the pipeline for manual review; a stage alone cannot gate the pipeline or notify reviewers. Therefore, this approach either creates an empty stage or duplicates what the Approval action already provides, and it does not satisfy the requirement for a manual approval gate.

Configure an AWS Lambda function to approve automatically.

Why it fails: Manual approval is specifically designed for human review and judgment; configuring a Lambda function to automatically approve would bypass that control entirely and defeat the purpose of the manual gate. While you could technically have a Lambda function invoke the PutApprovalResult API, doing so would require additional custom code, IAM roles, and event triggers, and it would violate the requirement for a human in the loop. The question explicitly calls for a manual approval step, so an automated Lambda approver is both contrary to that intent and unnecessarily complex compared to the native CodePipeline approval mechanism.

Enable CloudWatch Logs for the pipeline.

Why it fails: CloudWatch Logs is used for ingesting and storing application and pipeline execution logs—it does not generate outbound notifications or alert approvers about a pending manual approval. While CloudWatch Logs can help you troubleshoot why a pipeline step failed, the CodePipeline manual approval action does not send its notifications to a log stream; it uses SNS for that purpose. Therefore, enabling CloudWatch Logs would only add log data for diagnostics and would not satisfy the need to notify approvers, making it irrelevant to the manual approval requirement.

Place the RDS instance in a separate nested stack.

Why it fails: Placing the RDS instance in a separate nested stack only organizes the template structure and does not add any intrinsic protection. CloudFormation still treats resources within the nested stack as part of the parent stack update, and any property change that triggers replacement will be applied. Nested stacks do not have an automatic safeguard against resource replacement.

Enable termination protection on the CloudFormation stack.

Why it fails: Termination protection only prevents the entire stack from being deleted via the console or API, not from being updated. During an update, CloudFormation can still replace the RDS instance if a property change requires it, and termination protection is not evaluated for individual resources. Therefore, enabling it does not address the risk of accidental replacement.

The IAM role does not have permission to assume the role.

Why it fails: If the application is already using the IAM role, the role assumption has succeeded and temporary credentials have been issued. The policy shown in the exhibit is an identity-based permission policy, not a trust policy; trust policies govern who can assume a role, while identity-based policies define what actions the assumed role can perform. Therefore, permission to assume the role is irrelevant to an S3 PutObject authorization failure.

The application is using the wrong AWS credentials.

Why it fails: If the application were using wrong AWS credentials, it would typically fail authentication or receive an AccessDenied error unrelated to a specific prefix. Since the policy is attached to the role the application is running under, the credentials are valid and the identity context is correct. The error is tied to the S3 resource scope in the authorization policy, not to credential validity. Wrong credentials would not result in a permission gap limited to the uploads/ prefix.

The policy does not include the 's3:PutObject' action for the bucket itself.

Why it fails: The s3:PutObject action is an object-level operation and cannot be granted on the bucket resource itself; the resource must be an object ARN like arn:aws:s3:::my-bucket/* or arn:aws:s3:::my-bucket/uploads/*. The policy already includes a resource pattern of my-bucket/*, which grants s3:PutObject on all objects under the bucket. Therefore, the claim that the policy omits the action for the bucket is factually incorrect. The real issue is whether the resource pattern explicitly covers the exact uploads/ prefix being used by the application.

The CloudFormation template uses an unsupported template format

Why it fails: Incorrect. CloudFormation accepts both JSON and YAML template formats. If the template were in an unsupported format, CloudFormation would reject it during template validation and stack creation would fail immediately, not after twenty minutes. A timeout after 20 minutes indicates that template parsing succeeded and resource provisioning actually began, so an unsupported template format cannot be the cause.

The instance type specified is not available in the chosen Availability Zone

Why it fails: Incorrect. When an instance type is not offered in the specified Availability Zone, the EC2 RunInstances API returns an explicit error such as InvalidInstanceType or InsufficientInstanceCapacity right away. CloudFormation would surface that error before any long-running provisioning work and would not wait 20 minutes. The observed timeout suggests the launch request was accepted but the instance never reached a ready state.

Insufficient IAM permissions for CloudFormation to create EC2 instances

Why it fails: Incorrect. Insufficient IAM permissions are evaluated before CloudFormation begins provisioning resources. The API call to create the EC2 instance would return an AccessDenied or similar authorization error immediately, and CloudFormation would roll back the stack at once. A 20-minute wait followed by cancellation is characteristic of an operational delay, not an authorization failure.

The CodeDeploy agent version on the instances

Why it fails: While an outdated or faulty CodeDeploy agent can cause deployment problems, it is not the primary suspect for this specific error. Agent version issues typically manifest as 'agent not found' or 'unable to connect to CodeDeploy' errors before lifecycle events are even attempted. Here, the deployment reaches the ApplicationStop hook, meaning the agent is running and able to execute the deployment steps. Thus, the agent version is unlikely to be the culprit; the failing hook script is the more direct and immediate cause.

The Auto Scaling group's minimum size

Why it fails: Although the Auto Scaling group's minimum size is set to 2, this is not the root cause of the error. The 'too few healthy instances' message occurs after instances have failed their deployment lifecycle events, causing them to remain in an unhealthy state. If the group were undersized, the ASG would launch additional instances to meet the minimum, but this would not fix a deployment script failure. The error reflects that instances are actively failing deployment, not that the group lacks capacity.

The load balancer health check configuration

Why it fails: The load balancer health check configuration affects how traffic is routed to instances, but it does not directly cause the deployment failure error. CodeDeploy uses load balancer health checks to deregister and re-register instances during the deployment workflow, yet the error message indicates a problem with instance-level deployment execution, not the load balancer's health check criteria. A misconfigured health check might delay traffic shifting, but it would not cause instances to fail the ApplicationStop hook or other lifecycle events. The instance deployment failure itself is what drives the error.

Delete the stack and create a new one with the updated template

Why it fails: Deleting the stack and recreating it with the updated template is a destructive, manual approach that requires you to provision an entirely new database instance from scratch. CloudFormation does not automatically preserve data or configuration unless you explicitly export snapshots or use external backups, and the application will experience complete downtime during the entire rebuild. This method also introduces a risk of configuration drift because any stack outputs, custom resources, or dependent stacks that reference the original stack's resources must be manually updated or re-linked. Unlike a replacement update, this does not orchestrate the handoff between old and new resources, so it fails the goal of minimizing disruption.

Disable deletion protection on the DB instance before the update

Why it fails: Disabling deletion protection on the RDS DB instance before the update addresses a possible guardrail that might block the update, but it does nothing to minimize downtime or preserve availability. While deletion protection would prevent CloudFormation from deleting the database during a replacement, disabling it only allows the deletion to proceed—it does not create a snapshot, provision a replacement, or reroute traffic. Even if deletion protection is off, CloudFormation's default update behavior for RDS may still use a modify-with-snapshot strategy, but disabling protection alone does not trigger that behavior or optimize for minimal downtime. This step is a prerequisite for some operations, yet it is neither sufficient nor the best practice for a low-downtime database replacement.

Modify the DB instance endpoint in the application configuration after update

Why it fails: Modifying the application's database endpoint after the update is a reactive, manual post-step that assumes the application can easily change its connection string without downtime. In practice, the endpoint change must occur only after the new database is fully ready, but during the update the application is still pointing to the old instance, which may be deleted or become unreachable—causing an outage. This approach also requires knowing the new endpoint, updating every consumer, and coordinating the switchover precisely, which is error-prone and not automated. CloudFormation's replacement update with a snapshot can create the new DB, take a snapshot of the old one, and then update other resources in the stack that reference the DB endpoint, but relying on external manual configuration changes undermines that automation.