Deployment practice questions

AutoPublishAlias

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

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: This option is incorrect because 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 wrong: 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 wrong: 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 wrong: 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.

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.

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

Why wrong: 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 wrong: 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 wrong: 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.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

AWS::S3::BucketPolicy

Why wrong: A bucket policy controls access to the S3 bucket itself, not the permissions for S3 to invoke Lambda.

AWS::Lambda::EventSourceMapping

Why wrong: Event source mappings are used for streaming or poll-based sources like SQS, DynamoDB Streams, or Kinesis, not for S3 event notifications.

AWS::IAM::Role

Why wrong: An IAM role defines what actions the Lambda function can perform, not who can invoke it.

Rolling deployment

Why wrong: Rolling deployment updates instances in batches, which can cause temporary performance degradation and does not allow for easy URL swap.

Immutable deployment

Why wrong: Immutable deployment launches new instances with the new version and then terminates old ones, but it does not involve swapping URLs between environments.

All at once deployment

Why wrong: All at once updates all instances simultaneously, causing downtime during the update.

Rolling deployment

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

Immutable deployment

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.

Include a buildspec.yml file in the root directory.

Why wrong: The buildspec.yml file is read exclusively by AWS CodeBuild during the build phase of a CI/CD pipeline to specify install, pre_build, build, and post_build commands along with artifact locations; it has no role in Elastic Beanstalk environment provisioning, and Elastic Beanstalk never parses or executes this file.

Include an appspec.yml file.

Why wrong: appspec.yml is the deployment specification consumed by AWS CodeDeploy to define lifecycle event hooks such as BeforeInstall, AfterInstall, and ApplicationStart plus file mappings for EC2/on-premises or Lambda deployments; the Elastic Beanstalk platform itself does not read or act on this file even when CodeDeploy coexists with a Beanstalk deployment.

Include a cron.yaml file.

Why wrong: cron.yaml is a legacy Elastic Beanstalk worker-tier file used solely to schedule periodic tasks that get pushed to an SQS queue and processed by the worker daemon; it has no option_settings mechanism and therefore cannot set arbitrary environment variables on the underlying EC2 instances.

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

Why wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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 wrong: 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.