Deployment practice questions

AutoPublishAlias

Why it fails: AutoPublishAlias is a property within the AWS Serverless Application Model (SAM) that automatically creates a new Lambda function version and updates a specified alias to point to this new version upon deployment. While crucial for managing Lambda function versions and enabling alias-based invocation, it solely operates at the Lambda function level. It does not provide any mechanism for gradual traffic shifting or canary deployments for an associated API Gateway stage, which requires specific API Gateway deployment configurations.

ProvisionedConcurrencyConfig

Why it fails: ProvisionedConcurrencyConfig is used to pre-initialize a specified number of execution environments for a Lambda function, ensuring low latency for invocations by avoiding cold starts. While vital for performance-sensitive applications, especially those invoked via API Gateway, its sole purpose is to manage Lambda function readiness. It has no direct control over how API Gateway routes traffic between different versions of an API or its underlying Lambda functions during a deployment.

EventInvokeConfig

Why it fails: EventInvokeConfig defines the asynchronous invocation behavior for a Lambda function, specifically controlling retry attempts, maximum event age, and dead-letter queue (DLQ) destinations for failed invocations. This configuration is relevant for event sources like S3, SQS, or direct asynchronous API calls to Lambda. However, it pertains exclusively to the asynchronous processing characteristics of a Lambda function and does not influence the synchronous request routing or traffic shifting mechanisms of an API Gateway stage.

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

Why it fails: Setting the desired count of the new ECS task set to zero will scale down the running tasks, effectively stopping new instances from being launched. However, this action does not automatically revert the Application Load Balancer (ALB) listener rule that CodeDeploy configured to direct traffic to the new task set's target group. Consequently, the ALB would continue attempting to route traffic to an empty or non-existent target group, leading to service disruption and errors, as CodeDeploy's traffic management lifecycle is bypassed.

Delete the new task set.

Why it fails: Directly deleting the new task set via the ECS console or API removes the underlying ECS resources, but it does not address the Application Load Balancer's configuration. The ALB listener rule, which was automatically updated by CodeDeploy to forward traffic to the new task set's target group, would remain unchanged. This results in the ALB attempting to route traffic to a target group that no longer exists, causing severe service disruption and HTTP 5xx errors for end-users, as CodeDeploy's controlled rollback mechanisms are entirely circumvented.

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

Why it fails: Manually updating the Application Load Balancer listener rule to forward traffic to the original target group, while technically possible, bypasses CodeDeploy's integrated deployment and rollback mechanisms entirely. This approach circumvents CodeDeploy's lifecycle hooks, which are crucial for orchestrating traffic shifts, monitoring health, and performing cleanup of old resources. Bypassing CodeDeploy can lead to an inconsistent deployment state, complicate future deployments, and prevent automated rollbacks from functioning correctly, making it an uncontrolled and error-prone method.

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

Why it fails: Configuring 'Reroute traffic to replacement instances' to 'Wait for time' introduces a fixed delay before traffic is shifted to new instances. While this provides a buffer, it does not guarantee that the new instances are actually healthy and ready to serve requests after the specified time. The wait time is arbitrary and might be too short for complex applications to fully initialize and pass all internal health checks, or unnecessarily long, delaying the deployment without added safety. This method lacks the crucial feedback loop of actual instance health.

Set the 'Reroute traffic to replacement instances' to 'Wait for health check' and specify the ELB health check.

Why it fails: Setting 'Reroute traffic to replacement instances' to 'Wait for health check' and specifying the ELB health check is the most robust and recommended approach for zero-downtime deployments. This configuration ensures that the Elastic Load Balancer continuously monitors the health of the newly launched instances according to predefined criteria (e.g., HTTP 200 response on a specific path). Traffic is only rerouted to these new instances once they have successfully passed the ELB health checks, guaranteeing that users are always directed to fully operational and healthy application instances.

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

Why it fails: Setting the deployment to terminate the original instances before rerouting traffic is a 'recreate' deployment strategy that inevitably causes significant downtime. During the period when original instances are being shut down and new instances are still launching and initializing, no instances are available to serve incoming traffic. All user requests would fail, resulting in a complete service interruption until the new application version is fully deployed and ready to receive traffic, which is unacceptable for high-availability applications.

CodeDeployDefault.AllAtOnce

Why it fails: AllAtOnce stops every instance in the Auto Scaling group concurrently, so all four are offline during deployment, directly violating the zero-downtime requirement. It is tempting because it completes fastest, and would be correct for development or test environments where brief total outage is acceptable.

CodeDeployDefault.HalfAtATime

Why it fails: HalfAtATime takes 50% of instances out of service simultaneously, so with four instances two are offline at once, risking capacity loss against the zero-downtime requirement. It is tempting because it balances speed and availability, and would be correct for a non-critical deployment tolerating partial capacity reduction.

CodeDeployDefault.LambdaCanary10Percent5Minutes

Why it fails: LambdaCanary10Percent5Minutes applies only to AWS Lambda compute platforms, so it cannot deploy to an EC2 Auto Scaling group at all. It is tempting because canary shifting limits blast radius, and would be correct for a serverless Lambda function requiring gradual traffic shifting.

The lifecycle hooks for the new task set are failing.

Why it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: 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 it fails: A manual approval step in AWS CodePipeline introduces a human gate, preventing the automatic rollback behavior required for efficient failure recovery. While it allows for a decision point, it does not provide the automated, immediate failure detection and rollback capabilities inherent to CodeDeploy's 'Rollback configuration'. Its primary function is to control pipeline progression, not to automatically terminate a failed new task set or revert to the original deployment without intervention.

DeploymentPreference with Type: Canary10Percent30Minutes

Why it fails: This option specifies a canary deployment that would initially shift 10% of the traffic to the new version, then wait 30 minutes before shifting the remaining 90%. While a valid canary strategy for phased rollouts, it does not align with the specific requirement for a 5% initial shift and a 15-minute waiting period. Therefore, it fails to meet the precise parameters requested for the application's rollout.

DeploymentPreference with Type: Linear10PercentEvery10Minutes

Why it fails: This `Linear` deployment type implements a gradual traffic shift, moving 10% of the traffic to the new function version every 10 minutes until 100% is reached. This differs fundamentally from a canary deployment, which involves an initial small percentage shift followed by a single, larger cutover after a specified observation period. The linear approach provides a different risk mitigation pattern and does not fulfill the specific canary requirement.

DeploymentPreference with Type: AllAtOnce

Why it fails: The `AllAtOnce` deployment strategy immediately shifts 100% of the application's traffic to the new Lambda function version without any phased rollout. This approach offers no opportunity for incremental testing or early issue detection with a small subset of users. Consequently, it completely bypasses the core principle of a canary deployment, which is to minimize risk by gradually exposing users to the new code.

Add a test stage in the pipeline and configure a 'branch' filter on the source action to only trigger for the development branch.

Why it fails: This is the recommended approach. The source action's 'Branch' field can be set to 'development', so the pipeline only executes when changes are pushed to that branch. The test stage will then run as part of that execution.

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

Why it fails: CodePipeline does not support configuring 'branch' conditions directly on individual actions within a stage using a Lambda function as a conditional gate. While a Lambda function can be invoked as an action itself, it cannot act as a pre-condition to conditionally execute *another* action based on source branch metadata. Implementing such logic would require the Lambda to perform the conditional check and then potentially trigger or skip subsequent actions via AWS SDK calls, which is an overly complex and non-standard pattern for this requirement.

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

Why it fails: Using a 'Manual approval' action to verify the branch is an inefficient and inappropriate solution for automatically limiting pipeline execution to a specific branch. Manual approvals are designed for human gatekeeping before critical deployments, not for automated branch-based filtering. This approach would require constant human intervention for every change, negating the benefits of automation and failing to automatically restrict pipeline runs to only the development branch.

CanarySetting

Why it fails: CanarySetting is a sub-property of DeploymentPreference, not a top-level attribute in SAM. It specifies the canary configuration within deployment preferences.

StageName

Why it fails: StageName is used to name the API Gateway stage, not to configure deployment strategies.

MethodSettings

Why it fails: MethodSettings is used to configure API Gateway settings like caching and throttling for individual methods, not traffic shifting.

Set the deployment style to in-place and enable automatic rollback with event triggers.

Why it fails: This is vague; automatic rollback must specify which events trigger it. Without selecting 'instance failure', it won't roll back on health check failures.

Configure a deployment configuration with a minimum healthy hosts of 90% and enable CloudWatch alarm-based rollback.

Why it fails: CloudWatch alarm-based rollback requires a separate alarm, which is not mentioned. The requirement is to roll back on instance failure, not on an alarm.

Set the deployment style to blue/green and enable automatic rollback for deployment failure.

Why it fails: Blue/green is a deployment style, but the requirement is for automatic rollback on instance failure. 'Deployment failure' is a broader event that may not capture instance health check failures within 10 minutes.

Define a lifecycle hook in the Auto Scaling group that terminates instances with failing health checks.

Why it fails: Auto Scaling group lifecycle hooks are designed to pause instances during launch or termination events, allowing custom actions like installing software or registering with load balancers before the instance fully enters service or is removed. While they can react to instance health, they operate at the instance level and do not possess the functionality to trigger an AWS CodeDeploy application deployment rollback. Their scope is managing instance state transitions, not the overall application deployment version.

Set the deployment configuration to use a minimum healthy host percentage of 80% and a timeout of 5 minutes.

Why it fails: CodeDeploy deployment configurations, such as `MinimumHealthyHosts` and `Deployment Timeout`, govern the behavior *during* the deployment process itself. `MinimumHealthyHosts` ensures a specified percentage of instances remain healthy and available throughout the deployment, while `Deployment Timeout` defines the maximum time allowed for the deployment to complete. These settings prevent a deployment from stalling or causing excessive downtime, but they do not automatically initiate a rollback based on application health issues detected *after* the deployment has successfully finished.

Configure the AppSpec file with a rollback section that specifies the health check failure threshold.

Why it fails: The AppSpec file (`appspec.yml`) is used by AWS CodeDeploy to manage the deployment of application revisions, specifying source files, permissions, and lifecycle event hooks for scripts to execute on instances. It defines *how* the application is deployed, but it does not include a dedicated "rollback section" or functionality to configure health check failure thresholds for automatic rollbacks. Rollback triggers and associated settings are configured directly within the CodeDeploy deployment group's console or API.

Rolling deployment

Why it fails: Rolling deployment updates the existing environment by replacing instances in batches. It does not create a separate environment for partial traffic.

Immutable deployment

Why it fails: Immutable deployment launches a full set of new instances in a new Auto Scaling group alongside the old ones, then swaps. It does not easily allow partial traffic splitting without additional setup.

All at once deployment

Why it fails: This updates all instances simultaneously, causing downtime and no gradual traffic shift.

Store the secret in an environment property with the value set in plaintext.

Why it fails: Storing secrets directly as plaintext environment properties in the Elastic Beanstalk console or configuration files is highly insecure. These values are visible to anyone with console access, potentially logged in application logs, and can be exposed in configuration dumps or version control. This practice violates security best practices by hardcoding sensitive information, making credential rotation difficult and significantly increasing the risk of compromise.

Use an .ebextensions configuration file to set the environment variable.

Why it fails: While `.ebextensions` configuration files can be used to set environment variables, placing a secret's value directly within these files means it is stored in plaintext within your application's source code and deployment package. This exposes the secret in version control systems, build artifacts, and potentially in the Elastic Beanstalk environment's configuration history. It does not provide a secure mechanism for secret management and makes the secret easily discoverable.

Use Elastic Beanstalk platform hooks to retrieve the secret at startup.

Why it fails: Elastic Beanstalk platform hooks allow custom scripts to run at various stages of the deployment lifecycle, including application startup. While a script could theoretically retrieve a secret from Secrets Manager, this approach requires manual implementation of the retrieval logic, IAM permissions, and robust error handling within the script. It introduces unnecessary complexity, is less robust, and lacks the native, integrated security features and simplicity offered by the dedicated Secrets Manager integration.

All at once

Why it fails: This strategy replaces all existing instances with new ones simultaneously. During the replacement process, no instances are available to serve traffic, leading to complete service interruption and significant downtime. It is generally unsuitable for production environments requiring high availability, as it forces a full outage until all new instances are healthy and ready.

Rolling

Why it fails: A rolling deployment updates instances in batches, taking a subset of instances offline, updating them, and bringing them back online before moving to the next batch. While it reduces total downtime compared to 'All at once,' it introduces a period where both old and new application versions are running concurrently, which can lead to compatibility issues or inconsistent user experiences. Furthermore, a health check gap is required between batches, potentially causing brief service degradation or increased latency during the transition.

Rolling with additional batch

Why it fails: This strategy mitigates the capacity reduction of a standard rolling deployment by launching a new, temporary batch of instances with the updated application version before terminating any old instances. Once the new batch is healthy, traffic is directed to it, and then the old instances are gradually terminated. Although it minimizes downtime by maintaining full capacity, it does not provide a fully isolated environment for comprehensive testing of the new version with live traffic before it starts serving users, limiting pre-release validation.

Use the Ref function to refer to the security group in the EC2 instance properties

Why it fails: The Ref intrinsic function retrieves the physical ID of a resource, such as a Security Group ID, and inserts it into another resource's property, like an EC2 instance's SecurityGroupIds. While Ref does create an *implicit* dependency, where CloudFormation understands the Security Group must exist before the EC2 instance can reference it, it does not *explicitly* declare the dependency in the same declarative manner as the DependsOn attribute. The question asks to 'define the dependency' explicitly, making DependsOn a more direct and robust solution for guaranteeing creation order.

Use the AWS::NoValue intrinsic function

Why it fails: The AWS::NoValue intrinsic function is specifically designed to remove a property from a resource or a parameter from an output when used within a conditional statement. For instance, it can conditionally omit a tag or a security group from a resource's definition. It serves no purpose in defining or enforcing creation order dependencies between distinct resources, as its function is solely to control the presence or absence of properties, not their sequencing or inter-resource relationships.

Use the Condition attribute on the EC2 instance

Why it fails: The Condition attribute on a resource determines whether that resource is created or updated based on a predefined condition in the CloudFormation template. If the condition evaluates to `false`, the resource is skipped entirely during stack operations, effectively preventing its creation. This attribute controls the *existence* of a resource based on a logical evaluation, not the *order* in which it is provisioned relative to other resources. Therefore, it cannot be used to ensure a security group is created before an EC2 instance.

Create a custom platform using the Packer tool and specify it in the environment configuration.

Why it fails: Creating a custom platform using Packer allows you to define a base AMI with pre-installed software, specific configurations, or even a different operating system, beyond what standard Elastic Beanstalk platforms offer. Packer automates the creation of this custom AMI, which is then registered as a custom platform version within Elastic Beanstalk. Environments can subsequently be launched using this custom platform, ensuring all instances start with your precise requirements baked directly into the image.

Use the Elastic Beanstalk console to change the AMI ID in the environment configuration after creation.

Why it fails: Elastic Beanstalk environments are designed for immutability at the underlying AMI level once provisioned. The console does not provide an option to directly modify the AMI ID of an existing environment's EC2 instances. Such a fundamental change would necessitate terminating and recreating the instances, which Elastic Beanstalk manages by launching a *new* environment with the desired base image, rather than modifying an active one.

Launch a new environment with a different platform version that includes the required software.

Why it fails: While launching a new environment with a different standard platform version might provide some pre-installed software, it is insufficient if the required software is highly specialized or not included in any of AWS's managed platforms. Standard platform versions offer a curated set of operating systems and runtimes, but they do not allow for arbitrary custom software to be pre-baked into the base image. If the specific software is truly unique and not part of any existing platform, a custom platform is the only viable approach.

All at once.

Why it fails: This deployment method updates all instances in the environment simultaneously. During the update process, all instances are taken out of service or become unavailable, leading to a complete service interruption and significant downtime. It offers no opportunity for pre-release testing with live traffic, making it unsuitable for production applications requiring high availability.

Rolling with additional batch.

Why it fails: This strategy maintains full capacity by launching a new batch of instances with the updated application version before terminating any old instances. Traffic is then gradually shifted to these new instances in batches, ensuring continuous service availability throughout the rollout. However, it does not support canary testing, as all instances eventually receive the new version without a mechanism to test a small percentage of traffic independently before full rollout.

Traffic splitting.

Why it fails: Traffic splitting is a sophisticated blue/green deployment strategy that routes a configurable percentage of incoming traffic to a newly deployed application version while the majority still goes to the stable version. This enables robust canary testing, allowing developers to monitor performance and identify issues with a small user subset before incrementally increasing traffic to 100%. It significantly minimizes risk by providing a controlled, gradual rollout and an immediate rollback capability by simply adjusting traffic weights.

All at once

Why it fails: This strategy updates all instances in the environment concurrently. While simple to implement, it results in application downtime because all instances are taken offline simultaneously during the deployment process. Furthermore, if the new version fails, there's no automated or quick rollback mechanism; you would need to manually redeploy the previous working version, leading to additional downtime and operational effort.

Rolling

Why it fails: Rolling deployments update a batch of instances at a time, leaving other batches running the old version. This approach reduces the overall impact compared to "All at once" but can still cause brief periods of reduced capacity or intermittent downtime as batches are taken offline for updates. Rollback is not straightforward; it typically involves performing another rolling deployment with the previous application version, which can be time-consuming.

Rolling with additional batch

Why it fails: This strategy launches a new, temporary batch of instances running the new application version alongside the existing instances. Once the new batch is healthy, traffic is shifted, and the old instances are terminated. While this method minimizes downtime by maintaining full capacity throughout the update, it still lacks an immediate, one-click rollback feature; reverting to the previous version necessitates initiating another complete deployment cycle.

All at once

Why it fails: The "All at once" deployment strategy involves terminating all existing instances in the Elastic Beanstalk environment simultaneously before provisioning new instances with the updated application code. This approach leads to a complete and unavoidable period of application downtime and a temporary loss of all capacity during the entire deployment cycle. While it is the fastest method, it is generally unsuitable for production environments requiring high availability or continuous service.

Rolling

Why it fails: A "Rolling" deployment updates instances in batches, replacing a subset of existing instances with new ones running the updated application version. During each batch update, the environment's capacity temporarily decreases because the old instances are taken offline before the new ones are fully provisioned and ready to serve traffic. Although this reduces downtime compared to an "All at once" deployment, it does not guarantee full capacity throughout the process, potentially impacting application performance.

Immutable

Why it fails: Immutable deployments create a completely new environment with new instances, then swap CNAMEs. This maintains capacity but doubles the number of instances temporarily; it does not keep the exact same number of instances at all times.

All at once

Why it fails: The "All at once" deployment strategy updates all instances in the Elastic Beanstalk environment simultaneously. During this process, all existing instances are taken offline or become unavailable while the new application version is deployed. This directly results in significant downtime for the application, failing to meet the requirement for avoiding downtime.

Rolling

Why it fails: The "Rolling" deployment strategy updates instances in batches, rather than all at once. While this reduces the overall downtime compared to an "All at once" deployment, each batch of instances experiences downtime during its update cycle. Furthermore, the environment operates at reduced capacity during the deployment, and a failed deployment can still impact a portion of the live application, making it unsuitable for strict zero-downtime requirements.

Traffic splitting disabled

Why it fails: "Traffic splitting disabled" is a configuration option related to blue/green deployments, specifically preventing the gradual shifting of traffic. While traffic splitting is a component of some zero-downtime strategies, simply disabling it does not define a deployment strategy that inherently avoids downtime. It merely indicates that if a blue/green deployment were to occur, traffic would be switched instantly rather than gradually, but it doesn't specify the underlying mechanism for creating the new environment or updating instances to achieve zero downtime.