Deployment practice questions

Create two separate Amazon RDS databases and use an Amazon Route 53 weighted routing policy to distribute traffic.

Why wrong: This adds complexity and cost. It also means each task set writes to a different database, which is not the desired outcome.

Use an Application Load Balancer (ALB) with stickiness to route each user to the correct task set.

Why wrong: Stickiness doesn't solve the underlying database connection problem; it only keeps a user on the same task set during a session.

Use AWS CloudFormation to create a new database stack for each deployment and update the task definition dynamically.

Why wrong: This is overly complex and unnecessary. The goal is to use the same database, not create a new one for each deployment.

Deployment type: blue/green, Deployment configuration: CodeDeployDefault.ECSAllAtOnce

Why wrong: This shifts all traffic at once and does not include automatic rollback on health check failure.

Deployment type: blue/green, Deployment configuration: CodeDeployDefault.ECSLinear10PercentEvery1Minutes

Why wrong: This shifts traffic incrementally but does not enable automatic rollback.

Deployment type: blue/green, with an Application Load Balancer

Why wrong: An ALB is typically required for blue/green on ECS, but it does not automatically provide rollback behavior.

AutoPublishAlias

Why wrong: AutoPublishAlias is used to automatically create a Lambda version and alias; it does not affect API Gateway traffic shifting.

ProvisionedConcurrencyConfig

Why wrong: This configures provisioned concurrency for Lambda functions, not API traffic shifting.

EventInvokeConfig

Why wrong: EventInvokeConfig controls retries and maximum age for asynchronous Lambda invocations, not API traffic.

Create one ECS service with both containers in the same task definition, but only expose the web server port.

Why wrong: Both containers would be in the same task and would scale together. The worker would also be in the public subnet, potentially exposing it, and independent scaling is not possible.

Create one ECS service with two tasks, each containing one container.

Why wrong: This is essentially two tasks in one service, which would still share the same service scaling settings and placement. It does not allow independent scaling or subnet placement per container.

Create one ECS service with two containers in the same task, and use a service discovery to expose the worker.

Why wrong: Service discovery is for internal DNS, not for scaling or network access. The worker would be in the same task and subnet as the web server, likely exposing it.

CodeDeployDefault.AllAtOnce

Why wrong: This deploys to all instances at the same time, causing downtime if any instance is taken offline.

CodeDeployDefault.HalfAtATime

Why wrong: This deploys to half the instances at a time, which may reduce capacity more than desired.

CodeDeployDefault.BlueGreen

Why wrong: Blue/Green is a deployment type, not a configuration for in-place updates; it creates a separate environment.

Update the ECS service to set the desired count of the new task set to zero.

Why wrong: This might remove the new task set, but does not manage traffic routing through CodeDeploy and may cause inconsistencies.

Delete the new task set.

Why wrong: Simply deleting the task set does not return traffic to the original; the listener rule still points to the new target group.

Update the Application Load Balancer listener rule to forward traffic to the original target group.

Why wrong: This bypasses CodeDeploy's lifecycle hooks and is not the proper way to perform a controlled rollback.

Set the 'Reroute traffic to replacement instances' to 'Immediately'.

Why wrong: This shifts traffic to the new instances immediately without waiting for health checks, which could route requests to unhealthy instances and cause errors.

Set the 'Reroute traffic to replacement instances' to 'Wait for time' and specify a wait time.

Why wrong: This waits for a fixed duration before rerouting traffic, but does not guarantee that instances have passed health checks; they might still be unhealthy after the wait period.

Set the deployment to terminate the original instances before rerouting traffic.

Why wrong: Terminating original instances before rerouting traffic would cause downtime because no instances are available to serve traffic during the transition.

CodeDeployDefault.AllAtOnce

Why wrong: AllAtOnce deploys to all instances simultaneously, taking the entire fleet out of service and causing downtime.

CodeDeployDefault.HalfAtATime

Why wrong: HalfAtATime deploys to half (2) of the instances at a time, which still takes a significant portion of capacity out.

CodeDeployDefault.LambdaCanary10Percent5Minutes

Why wrong: This configuration is designed for Lambda functions, not EC2 instances, and is not applicable here.

All at once deployment

Why wrong: All at once deploys to all instances simultaneously in the same environment. It causes downtime because all instances are updated at the same time and the application becomes unavailable during deployment.

Rolling deployment with additional batch

Why wrong: Rolling deployment updates instances in batches within the same environment. While it minimizes downtime, it does not provide the ability to fully test the new version before traffic is routed to it.

Immutable deployment

Why wrong: Immutable deployment launches a new Auto Scaling group with the new version and then swaps instances. It is similar to blue/green but within the same environment and does not use a separate environment for testing.

All at once

Why wrong: This policy replaces all instances at the same time, causing application downtime during the deployment.

Rolling

Why wrong: Rolling updates instances in batches, but it terminates old instances before new ones are put into service, which can temporarily reduce capacity and cause downtime.

Immutable

Why wrong: Immutable deployments launch a completely new environment with new instances, then swap the CNAME. This provides zero downtime but launches many new instances, not minimizing the number.

One

Why wrong: A single target group can only point to one set of tasks, so it cannot support the two environments (blue and green) required for a blue/green deployment.

Three

Why wrong: Three target groups are not required for a basic blue/green deployment; two are sufficient.

Four

Why wrong: Four target groups exceed the minimum requirement and would add unnecessary complexity.

The lifecycle hooks for the new task set are failing.

Why wrong: Lifecycle hooks run before traffic is shifted; if they fail, the deployment would not proceed to traffic shift, so this does not match the described sequence.

The target group for the new task set is not configured correctly.

Why wrong: Incorrect target group configuration might cause traffic routing issues, but it would not directly trigger a rollback; the deployment would likely complete with routing errors.

The deployment group's rollback configuration triggers due to alarm threshold.

Why wrong: Rollback due to CloudWatch alarms is possible, but the scenario states the rollback happens 'after a few minutes' immediately after traffic shift, which is typical of post-traffic validation failure, not an alarm that takes time to evaluate.

Set the deployment configuration to 'AllAtOnce' and enable termination of the original task set

Why wrong: The 'AllAtOnce' deployment configuration is not valid for ECS blue/green deployments. ECS blue/green uses 'Canary' or 'Linear' or custom configurations based on traffic shifting. 'AllAtOnce' is for Lambda or EC2/On-Premises compute platforms. Also, termination of the original task set is done after success, not on failure.

Define a blue/green deployment using an AppSpec file with a 'Hooks' section to specify a 'BeforeAllowTraffic' hook that checks health. If the check fails, CodeDeploy automatically rolls back.

Why wrong: Hooks can be used to run validation scripts, but automatic rollback on failure is configured separately in the deployment group under 'Rollback configuration'. The hooks themselves do not trigger a rollback; they can cause the deployment to fail, but the rollback behavior must be explicitly enabled.

Use a manual approval step in the pipeline to decide whether to terminate the new task set.

Why wrong: A manual approval step does not provide automatic rollback on failure. It requires human intervention and does not automatically terminate the new task set on failure.

DeploymentPreference with Type: Canary10Percent30Minutes

Why wrong: This would shift 10% initially and wait 30 minutes, not the required 5% and 15 minutes.

DeploymentPreference with Type: Linear10PercentEvery10Minutes

Why wrong: This shifts traffic linearly in 10% increments every 10 minutes, not the canary pattern with a single final shift.

DeploymentPreference with Type: AllAtOnce

Why wrong: AllAtOnce shifts 100% of traffic at once, which is not a canary deployment and would not meet the canary requirement.

DefinitionBody

Why wrong: This property defines the OpenAPI specification of the API. It does not set the stage name.

StageDescription

Why wrong: This property provides a description of the stage but does not set its name.

EndpointConfiguration

Why wrong: This property configures the endpoint type (e.g., REGIONAL, EDGE) and does not set the stage name.

CodeDeployDefault.OneAtATime

Why wrong: This is slower as it deploys to one instance at a time.

CodeDeployDefault.AllAtOnce

Why wrong: Deploys to all instances simultaneously, which could temporarily drop healthy instances below 50% if any fail.

CodeDeployDefault.MinHealthyPercent

Why wrong: This is not a predefined deployment configuration; it is a setting within custom configurations.

Use the CloudFormation stack's Outputs to trigger a Lambda function that runs tests.

Why wrong: CloudFormation Outputs are used to export stack values, not to trigger actions.

Configure a post-deployment hook in the SAM template that runs tests.

Why wrong: SAM does not support post-deployment hooks; all lifecycle events are handled by CloudFormation custom resources or CodePipeline.

Add a manual approval step after Deploy, then run tests manually.

Why wrong: Manual approval requires human intervention, which is not automated.

Set the DeploymentStyle to 'BLUE_GREEN' and configure the 'LoadBalancerInfo' with the target group.

Why wrong: This configures a blue/green deployment, but does not set up automatic rollback. Rollback still requires additional configuration.

Create a lifecycle hook for the Auto Scaling group to trigger a rollback script.

Why wrong: Lifecycle hooks allow you to perform custom actions before instances launch or terminate, but they do not inherently trigger a CodeDeploy rollback.

Set a TriggerConfiguration in the deployment group to send notifications on deployment failure.

Why wrong: TriggerConfiguration is used for SNS notifications, not for automatic rollback. Rollback must be configured separately.

Take a snapshot of the database before each deployment and restore it after the deployment completes.

Why wrong: Snapshots capture data at a point in time, but any data written during the deployment would be lost. This is not a reliable method for zero data loss.

Use the Elastic Beanstalk environment's 'Swap environment URLs' feature to perform a blue/green deployment.

Why wrong: Swapping URLs does not protect the database; if the old environment is terminated, the in-environment database is also terminated, causing data loss.

Create a new Elastic Beanstalk environment with a new RDS instance and migrate data manually.

Why wrong: This approach involves complex data migration and still risks data loss during the transition.

Create a separate pipeline for the development branch and configure it with the test stage.

Why wrong: While this would work, it is less efficient than using a single pipeline with a branch filter. Managing multiple pipelines adds complexity.

Add a test stage in the pipeline and configure a 'branch' condition on the test action using a Lambda function.

Why wrong: You cannot add conditions directly to actions in CodePipeline. Using a Lambda function to check the branch would require custom logic and is overly complex.

Add a test stage in the pipeline and use a 'Manual approval' action that requires a human to verify the branch.

Why wrong: Manual approval would require human intervention every time, which is not efficient and does not automatically limit the pipeline to the development branch.