Examkin

Deployment Strategies

83 questions

All types83Multiple choice41Multiple select42
Question 1Question →

A developer is planning the deployment strategy for a critical web application hosted on AWS Elastic Beanstalk. The application is highly sensitive to performance degradation, so the deployment process must maintain 100%100\% of the existing instance capacity at all times. Additionally, if the new version fails post-deployment tests, the developer must be able to roll back to the previous version almost instantly. Which two Elastic Beanstalk deployment strategies or methods will satisfy these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Immutable deployment; Blue/Green deployment via environment URL swap

Answer

Immutable deployment and Blue/Green deployment via environment URL swap
Immutable deployments and Blue/Green deployments via environment URL swapping both maintain 100%100\% of the existing application capacity during deployment. They also provide a rapid rollback path: immutable deployments roll back by terminating the new Auto Scaling group, while Blue/Green deployments roll back by swapping the CNAME records back.

Step-by-Step Solution

1
Analyze the capacity requirement.
The application must maintain 100%100\% of its existing capacity during the deployment. This eliminates strategies that take instances offline without replacing them first, such as rolling and all-at-once.
To prevent performance degradation during the deployment window.
2
Evaluate the rollback requirements.
The deployment must support a rapid, near-instant rollback in case of failure. This rules out rolling with additional batch, which requires a new rolling deployment of the older version to revert.
To minimize the duration of any potential outage or failure.
3
Identify the compliant strategies.
Immutable deployments maintain capacity by launching a parallel Auto Scaling group and roll back instantly by terminating it. Blue/Green deployments maintain capacity in a separate environment and roll back instantly by swapping the CNAMEs back.
Both strategies meet the full capacity and near-instant rollback constraints.

Key Concept

Evaluating Elastic Beanstalk deployment policies based on capacity and rollback speed trade-offs.
Estimated Time:1m 30s
Question 2Question →

A developer is updating a critical serverless API hosted on AWS Lambda using AWS CodeDeploy. The deployment must meet the following requirements:

- Direct only 10%10\% of the production traffic to the new Lambda function version initially.
- Route all remaining traffic to the new version after a 1010-minute monitoring window.
- Roll back the deployment automatically if any error metrics exceed the normal threshold.

Which of the following configuration options should the developer select to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Specify CodeDeployDefault.LambdaCanary10Percent10Minutes as the deployment configuration.; Configure CloudWatch alarms in the CodeDeploy deployment group to monitor error metrics and trigger automatic rollbacks.

Answer

To meet the requirements, the developer must select the Canary 10 percent 10 minutes deployment configuration to manage the traffic routing, and configure CloudWatch alarms on the CodeDeploy deployment group to handle automatic rollbacks on error metrics.
The correct configuration is achieved by using the Canary 10 percent 10 minutes deployment strategy and configuring CloudWatch alarms in the CodeDeploy deployment group. The canary strategy ensures the new version receives 10%10\% of the traffic initially, and shifts the remaining traffic after 1010 minutes. The CloudWatch alarms enable CodeDeploy to monitor the error metrics and perform an automated rollback to the previous version if thresholds are breached.

Step-by-Step Solution

1
Analyze the traffic shifting pattern.
The requirements specify routing 10%10\% of the traffic first, waiting 1010 minutes, and then routing the remaining 90%90\%. This corresponds to a canary deployment strategy with a 1010-minute interval.
Identifying the shift pattern helps filter out linear strategies and incorrect canary intervals.
2
Select the correct predefined AWS CodeDeploy configuration.
Choose the configuration named CodeDeployDefault.LambdaCanary10Percent10Minutes.
This matches the target behavior of a 10%10\% shift followed by a 1010-minute pause before complete routing.
3
Identify the mechanism for automated rollback.
CodeDeploy deployment groups can be associated with CloudWatch alarms (such as Lambda invocation errors).
If an alarm triggers during the deployment, CodeDeploy detects it and automatically executes a rollback to the original Lambda version.

Key Concept

AWS Lambda Canary Deployment and Automated Rollbacks using CodeDeploy
Estimated Time:1m 30s
Question 3Question →

A developer is configuring an AWS CodeDeploy deployment group for a critical serverless application. To minimize the blast radius of potential failures, the developer needs a strategy that shifts traffic to the new AWS Lambda function version gradually over time. If any CloudWatch alarms are triggered during the deployment, CodeDeploy must immediately roll back all traffic to the original version.

Which of the following CodeDeploy deployment configuration types will satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Canary configurations; Linear configurations

Answer

The correct configurations are Canary configurations and Linear configurations.
Canary and Linear configurations are the two native AWS CodeDeploy deployment configuration types that support gradual traffic shifting for serverless applications. Canary configurations route a portion of traffic to the new version, wait for a specified period, and then route the rest. Linear configurations shift traffic in equal increments at regular intervals. If a CloudWatch alarm triggers during either deployment, CodeDeploy immediately routes 100% of the traffic back to the original version by updating the Lambda alias.

Step-by-Step Solution

1
Analyze the requirements from the scenario: gradual traffic shifting to minimize blast radius and immediate rollback capability using CloudWatch alarms.
Identified that the solution must support shifting a fraction of traffic to the new version of the AWS Lambda function first, and instantly routing 100% of traffic back to the old version upon failure.
This narrows the choices to CodeDeploy deployment configurations designed for AWS Lambda traffic shifting.
2
Evaluate the available AWS CodeDeploy configurations for serverless deployments against the requirements.
Canary configurations (e.g., Canary10Percent5Minutes) shift a portion of traffic initially, while Linear configurations (e.g., Linear10PercentEvery1Minute) shift traffic incrementally. Both types support immediate rollback via alias re-pointing.
These two configuration types are the only native CodeDeploy options for AWS Lambda that shift traffic gradually.

Key Concept

AWS CodeDeploy Traffic Shifting Configurations for AWS Lambda
Question 4Question →

A developer is using AWS CodeDeploy to perform an in-place deployment of a new application revision to an Amazon EC2 Auto Scaling group that currently contains 66 running instances. The deployment must satisfy the following constraints:

* A minimum of 33 instances must remain healthy and serve traffic at all times during the deployment process.
* The deployment must complete as quickly as possible while adhering to the healthy host constraint.

Which two CodeDeploy configurations can the developer use to meet these requirements?

Select all that apply

Show answer & explanation

Answer: The default deployment configuration CodeDeployDefault.HalfAtATime; A custom deployment configuration with the minimumHealthyHosts parameter set to a type of FLEET_PERCENT and a value of 5050

Answer

The developer can use the default deployment configuration CodeDeployDefault.HalfAtATime or a custom deployment configuration with the minimumHealthyHosts parameter set to a type of FLEET_PERCENT and a value of 5050.
The correct options are the default configuration that updates half of the instances at a time, and a custom configuration specifying a minimum of 50%50\% fleet health. For a fleet of 66 instances, keeping a minimum of 33 healthy instances requires maintaining at least 50%50\% health. The default configuration that accomplishes this in the fewest steps is the one that updates half the fleet at a time, completing in two batches. Alternatively, a custom configuration using a fleet percentage of 5050 achieves the exact same balance of speed and availability.

Step-by-Step Solution

1
Determine the minimum healthy host percentage and count required.
The target is 33 healthy instances out of 66, which represents exactly 50%50\% of the fleet.
This establishes the boundary conditions for the deployment configurations.
2
Evaluate the default configuration options against speed and capacity constraints.
CodeDeployDefault.HalfAtATime meets the requirement by updating 33 instances at a time (22 steps total). CodeDeployDefault.OneAtATime is too slow (66 steps), and CodeDeployDefault.AllAtOnce violates the healthy instances constraint.
To select the correct predefined deployment configuration.
3
Evaluate custom configuration parameters to match the target threshold.
A custom configuration with minimumHealthyHosts of type FLEET_PERCENT set to 5050 will correctly keep 33 instances healthy. Using HOST_COUNT with a value of 5050 expects 5050 physical hosts, which exceeds the fleet size.
To identify the correct custom deployment configuration settings.

Key Concept

AWS CodeDeploy deployment configurations allow developers to specify the number or percentage of instances that must remain healthy during an in-place deployment to balance availability and speed.
Question 5Question →

A developer is configuring the deployment settings for a production web application hosted on AWS Elastic Beanstalk. The deployment process must satisfy the following requirements:

1. The new application version must be deployed to a completely separate, temporary Auto Scaling group and pass health checks before serving any production traffic.
2. If health checks fail, the rollback must be automatic, immediate, and leave the existing active instances completely untouched.
3. The deployment must avoid any DNS-level routing changes, such as swapping environment URLs.

Which Elastic Beanstalk deployment policy should the developer select?

Show answer & explanation

Answer: Immutable

Answer

Immutable
The correct option is Immutable because it is the only Elastic Beanstalk deployment policy that satisfies all constraints. It deploys the new version to a separate temporary Auto Scaling group under the same environment and load balancer. It validates the new version's health before directing any production traffic to it. If the health checks fail, the rollback is clean and instant since Elastic Beanstalk simply terminates the temporary Auto Scaling group, leaving the original instances untouched. Furthermore, since it uses the same load balancer, it does not require DNS CNAME swaps.

Step-by-Step Solution

1
Analyze the requirement for deploying to a separate, temporary Auto Scaling group with zero pre-traffic production exposure.
This eliminates Rolling and Rolling with Additional Batch, which update instances within the existing Auto Scaling group.
To ensure the active production instances remain completely untouched until health checks pass, the new version must be isolated initially.
2
Evaluate the requirement for avoiding DNS-level changes.
This eliminates Blue/Green deployments that rely on swapping CNAME URLs at the Route 53 or Elastic Beanstalk environment level.
The deployment must occur within the same Elastic Beanstalk environment under the same load balancer without changing CNAME records.
3
Compare Immutable vs Traffic Splitting and All at Once policies.
All at Once causes downtime. Traffic Splitting immediately routes production traffic to the new version before final promotion. Only Immutable meets all constraints by using a temporary Auto Scaling group under the same load balancer, running health checks, and offering clean rollback by simply terminating the temporary group.
Immutable is the only native Elastic Beanstalk policy that provides zero-downtime, separate temporary ASG testing, and clean rollback without DNS changes.

Key Concept

AWS Elastic Beanstalk Deployment Policies
Question 6Question →

A developer is configuring a CI/CD pipeline using AWS CodeDeploy for a serverless API hosted on AWS Lambda and integrated with Amazon API Gateway. The deployment process must adhere to the following requirements:

* Production traffic must be shifted in two stages: an initial 10%10\% of traffic is routed to the new version, followed by the remaining 90%90\% after a 1515-minute evaluation period.
* Prior to routing any production traffic to the new version, a test function must run to verify that the new version can successfully write to an Amazon DynamoDB table.
* If the test function fails, or if a CloudWatch alarm for 5xx5\text{xx} errors on the new version is triggered during the evaluation period, the deployment must immediately roll back.

Which TWO actions must the developer perform to configure the deployment?

Select all that apply

Show answer & explanation

Answer: Set the deployment configuration in AWS CodeDeploy to CodeDeployDefault.LambdaCanary10Percent15Minutes; Specify a validation Lambda function under the BeforeAllowTraffic hook in the AppSpec file to verify database connectivity

Answer

Configure the deployment in AWS CodeDeploy to use the CodeDeployDefault.LambdaCanary10Percent15Minutes configuration, and specify a validation Lambda function under the BeforeAllowTraffic hook in the AppSpec file to verify database connectivity.
To satisfy the deployment requirements, the developer must configure the traffic shifting behavior and implement the pre-traffic validation test. The 'CodeDeployDefault.LambdaCanary10Percent15Minutes' configuration routes 10%10\% of the traffic to the new version of the Lambda function initially, holds it for 1515 minutes to allow for monitoring, and then routes the remaining 90%90\% of traffic. Additionally, CodeDeploy uses the AppSpec file to define deployment lifecycle hooks. For Lambda deployments, the validation test must be executed during the 'BeforeAllowTraffic' hook, which runs before traffic routing begins. If the validation function fails, CodeDeploy automatically stops the deployment and rolls back the traffic.

Step-by-Step Solution

1
Analyze the traffic shifting requirement.
The requirements dictate shifting 10%10\% of traffic initially and the remaining 90%90\% after a 1515-minute evaluation period. This matches a canary deployment configuration, specifically 'CodeDeployDefault.LambdaCanary10Percent15Minutes'.
Identifying the correct built-in configuration ensures the traffic shifting logic adheres to the specifications.
2
Determine the appropriate lifecycle hook for pre-traffic verification.
The verification must run before any production traffic shifts. The correct hook for this in Lambda deployments is 'BeforeAllowTraffic'.
Running the validation code in 'BeforeAllowTraffic' ensures that if the validation fails, traffic is never shifted, preventing service disruption.
3
Verify hook support for AWS Lambda deployments in CodeDeploy.
AWS Lambda deployments only support the 'BeforeAllowTraffic' and 'AfterAllowTraffic' hooks. EC2 hooks like 'BeforeInstall' are unsupported and will cause deployment failures.
Understanding Lambda-specific lifecycle hooks prevents configuration errors in the AppSpec file.

Key Concept

AWS CodeDeploy deployment configurations and AppSpec lifecycle hooks for AWS Lambda.
Question 7Question →

An application developer is deploying an updated version of a microservice REST API using Amazon API Gateway. To minimize blast radius, the developer wants to test the update under production conditions by routing 5%5\% of incoming API traffic to the new deployment. The developer also needs to monitor separate Amazon CloudWatch metrics for the test traffic and the production traffic. Once the new deployment is verified, the developer must promote it to receive 100%100\% of the traffic with minimum administrative overhead and without managing additional API Gateway stages. Which deployment strategy should the developer implement to meet these requirements?

Show answer & explanation

Answer: Configure a canary release on the active API Gateway stage, set the canary traffic percentage to 5%5\%, and then promote the canary to the stage after verification.

Answer

Configure a canary release on the active API Gateway stage, set the canary traffic percentage to 5%5\%, and then promote the canary to the stage after verification.
Configuring a canary release on the active API Gateway stage allows the developer to route a specific percentage of traffic (such as 5%5\%) to a new deployment on the same stage. API Gateway automatically generates separate Amazon CloudWatch metrics for the canary traffic, which can be monitored. When verification is complete, promoting the canary updates the stage deployment to the new version and deletes the canary, meeting all requirements with the lowest administrative overhead and without managing multiple stages.

Step-by-Step Solution

1
Evaluate the requirement for splitting traffic at the API Gateway level with separate metrics and no additional stages.
Identify that API Gateway canary releases support splitting traffic on a single stage and provide separate CloudWatch metrics.
This aligns with minimizing stage management and administrative overhead.
2
Set up the canary release on the active stage with 5%5\% traffic.
5%5\% of incoming requests are routed to the new API deployment, and API Gateway automatically publishes separate CloudWatch metrics for the canary stage.
This allows safe verification of the new version under production load.
3
Promote the canary release.
The new deployment becomes the active deployment for the stage, and the canary is disabled.
This completes the promotion to 100%100\% traffic with zero downtime and no additional stages to delete or manage.

Key Concept

API Gateway Canary Deployments
Estimated Time:2m 30s
Question 8Question →

A developer is configuring the deployment policy for a high-traffic web application hosted on AWS Elastic Beanstalk. The application runs on multiple Amazon EC2 instances. The deployment policy must satisfy the following requirements:

1. The application must maintain 100%100\% of its instance capacity to handle incoming traffic at all times during the deployment.
2. If a deployment failure occurs, the rollback process must be rapid and must not perform any updates or modifications on the original, healthy instances.

Which two deployment strategies should the developer select to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Immutable; Traffic splitting

Answer

The correct strategies are Immutable and Traffic splitting.
The correct strategies are Immutable and Traffic splitting. Both of these strategies maintain 100%100\% instance capacity during deployment by launching a separate, temporary Auto Scaling group for the new version. Furthermore, if a deployment failure occurs, the rollback is rapid and clean because it only requires terminating the temporary Auto Scaling group and redirecting traffic, leaving the original, healthy instances completely untouched.

Step-by-Step Solution

1
Analyze capacity requirements during deployment.
To maintain 100%100\% capacity without reducing instance count, any strategy that takes existing instances offline (All-at-once, Rolling) is eliminated. Strategies that launch new instances (Rolling with additional batch, Immutable, Traffic splitting) are kept.
Eliminating options that reduce capacity ensures the application can handle peak traffic during the update.
2
Analyze rollback requirements in case of failure.
Rolling with additional batch modifies the existing instances. If it fails, rolling back requires redeploying the old version back onto the instances, which takes time and modifies active instances. Immutable and Traffic splitting launch a separate, temporary Auto Scaling group. If they fail, they immediately redirect traffic and terminate the temporary resources, leaving the original instances untouched.
This identifies the strategies that provide the fastest and cleanest rollback without performing out-of-band updates on original instances.

Key Concept

AWS Elastic Beanstalk deployment policies and their impact on capacity, rollback speed, and resource modification.
Question 9Question →

A developer is planning a deployment strategy for a high-traffic production application hosted on AWS Elastic Beanstalk. The application must maintain its full provisioned instance capacity during the deployment to avoid performance degradation. Additionally, if the new application version fails initial health checks, the environment must immediately roll back to the previous version without performing a secondary deployment process.

Which two Elastic Beanstalk deployment strategies will meet these requirements? (Select TWO).

Select all that apply

Show answer & explanation

Answer: Immutable; Traffic splitting

Answer

The Immutable and Traffic splitting deployment strategies satisfy both the capacity and rollback requirements.
The Immutable and Traffic splitting deployment strategies both deploy the new application version to a separate, temporary Auto Scaling group while keeping the original instances fully operational. This satisfies the requirement to maintain 100% capacity. If the update fails health checks, both strategies achieve an immediate rollback by redirecting traffic away from the new instances and terminating the temporary Auto Scaling group, without needing a secondary rolling update.

Step-by-Step Solution

1
Analyze capacity constraints during the deployment process.
The application must maintain 100% of its provisioned instance capacity. This rules out strategies like Rolling, which temporarily take active instances out of service, and All-at-once, which takes all instances offline.
Maintaining capacity prevents performance degradation under high traffic.
2
Analyze rollback constraints on health check failure.
The rollback must be immediate and not require another deployment process. This rules out Rolling with additional batch, because reverting requires performing another rolling update deployment to push the old code back to the instances.
An immediate rollback minimizes the duration of any potential user impact.
3
Identify strategies that launch a temporary Auto Scaling group.
Immutable and Traffic splitting both launch a parallel Auto Scaling group to test the new version while keeping the original group untouched. This maintains capacity and allows instant rollback by redirecting traffic or terminating the temporary group.
These strategies isolate the new deployment from the existing running instances until verification succeeds.

Key Concept

Elastic Beanstalk Deployment Strategies
Question 10Question →

A developer is using AWS CodeDeploy to manage deployments for a containerized application running on Amazon ECS (Fargate) behind an Application Load Balancer (ALB). The application requires zero downtime during updates. The developer needs to implement a deployment strategy where a new version is validated with exactly 10%10\% of production traffic for 15 minutes before shifting the remaining 90%90\% of traffic. Additionally, a database migration script must be executed automatically after the new task set is created but before it receives any production traffic. The deployment must automatically roll back immediately if the load balancer target group's HTTP 5xx errors spike during the validation window.

Which TWO actions should the developer take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Use the CodeDeployDefault.ECSCanary10Percent15Minutes deployment configuration.; Define an AWS Lambda function under the AfterInstall hook in the AppSpec file to execute the database migration script.

Answer

Use the CodeDeployDefault.ECSCanary10Percent15Minutes deployment configuration and define an AWS Lambda function under the AfterInstall hook in the AppSpec file to execute the database migration script.
The correct options are the strategy to use CodeDeployDefault.ECSCanary10Percent15Minutes and using the AfterInstall hook. The deployment configuration Canary10Percent15Minutes routes 10% of traffic to the new task set, waits for 15 minutes, and then routes the remaining 90%. The AfterInstall lifecycle hook in an ECS deployment runs immediately after the replacement task set is created but before it receives any traffic, making it the perfect stage to execute database migrations or pre-traffic checks.

Step-by-Step Solution

1
Analyze the traffic shifting pattern requirements.
The requirement states that 10% of traffic must be routed to the new version for a 15-minute validation period, after which the remaining 90% is shifted. This corresponds directly to a Canary strategy: CodeDeployDefault.ECSCanary10Percent15Minutes.
This establishes the traffic routing configuration for CodeDeploy.
2
Determine the correct lifecycle hook for running database migrations in an ECS deployment.
Identify that the migration must run after the task set is created but before any traffic is routed. In ECS deployments, this matches the AfterInstall hook. EC2 hooks like ApplicationStart are invalid.
This ensures the migration script executes at the correct stage of the deployment sequence without failing due to unsupported platform hooks.
3
Evaluate the rollback trigger configurations.
To roll back immediately within a 15-minute window, the associated CloudWatch Alarm must use a short evaluation period (such as 1 minute or 60 seconds). A 15-minute period would delay the rollback response.
This rules out the incorrect CloudWatch Alarm configuration.

Key Concept

AWS CodeDeploy deployment strategies and AppSpec lifecycle hooks for ECS deployments
Estimated Time:3m 0s
Question 11Question →

A developer is preparing a deployment strategy for a high-traffic HTTP API hosted on AWS Elastic Beanstalk. The deployment must satisfy the following constraints:

1. The API must maintain 100%100\% of its serving capacity throughout the entire deployment process to prevent performance degradation.
2. A small, configurable percentage of live production traffic (e.g., 10%10\%) must be routed to the new version for a 15-minute evaluation period.
3. If any CloudWatch alarms are triggered or health checks fail during this evaluation period, the deployment must automatically roll back by routing all traffic back to the old version and terminating the new instances.
4. The deployment process must be managed entirely within the existing Elastic Beanstalk environment to minimize configuration overhead.

Which deployment policy should the developer configure to meet these requirements?

Show answer & explanation

Answer: Traffic splitting deployment

Answer

Traffic splitting deployment
The correct option is traffic splitting deployment. This deployment policy allows developers to perform canary testing within a single Elastic Beanstalk environment. It launches a temporary Auto Scaling group with the new version, routes a small percentage of production traffic to it, and monitors its health. If any alarms are triggered or health checks fail, Elastic Beanstalk automatically routes all traffic back to the old version and terminates the temporary instances, achieving zero-downtime and 100%100\% capacity maintenance with automated rollback capabilities.

Step-by-Step Solution

1
Analyze the capacity requirement.
The deployment must maintain 100%100\% capacity, which rules out standard Rolling or All-at-once deployments (both temporarily reduce capacity).
To maintain 100%100\% capacity, we need a policy that provisions additional instances before replacing old ones, such as Rolling with additional batch, Immutable, Traffic splitting, or Blue/green.
2
Analyze the traffic routing and testing requirement.
A small, configurable percentage of traffic (e.g., 10%10\%) must be routed to the new version for evaluation, ruling out standard Immutable and Rolling with additional batch policies.
Immutable and Rolling with additional batch immediately serve traffic to the new instances at full scale or in batch increments, without isolating a specific percentage of overall traffic for canary testing.
3
Analyze the environment boundary constraint.
The deployment must occur within a single Elastic Beanstalk environment, ruling out Blue/green deployment.
Blue/green deployment in Elastic Beanstalk requires creating a separate clone environment and swapping CNAMEs, which violates the requirement to avoid multi-environment overhead.
4
Select the policy that meets all criteria.
Traffic splitting deployment meets all constraints: 100%100\% capacity (via temporary Auto Scaling group), configurable canary percentage routing, automated rollback via CloudWatch alarms, and execution within a single environment.
Elastic Beanstalk native traffic splitting is designed specifically for canary testing within a single environment while maintaining 100%100\% capacity.

Key Concept

AWS Elastic Beanstalk Traffic Splitting Deployment
Estimated Time:3m 0s
Question 12Question →

A developer is configuring a blue/green deployment for an Amazon Elastic Container Service (Amazon ECS) service using AWS CodeDeploy and an Application Load Balancer (ALB). The service runs 44 tasks under normal operation. The developer must run automated integration tests against the new version of the application (the replacement task set) in the production environment before routing any live production traffic to it.

Which configuration should the developer implement to meet these requirements?

Show answer & explanation

Answer: Configure a test listener on the ALB that points to the replacement target group, specify this listener in the CodeDeploy deployment group, and run the integration tests during the AfterAllowTestTraffic lifecycle hook.

Answer

Configure a test listener on the ALB that points to the replacement target group, specify this listener in the CodeDeploy deployment group, and run the integration tests during the AfterAllowTestTraffic lifecycle hook.
The correct configuration utilizes a dedicated test listener on the Application Load Balancer (ALB) to route traffic specifically to the replacement target group hosting the Green task set. By specifying this test listener in AWS CodeDeploy, developers can target the new deployment for testing. The AfterAllowTestTraffic lifecycle hook runs immediately after the test listener starts directing traffic to the replacement task set, providing the ideal phase to execute automated validation tests before any live production traffic is shifted.

Step-by-Step Solution

1
Identify the mechanism for routing test traffic in AWS CodeDeploy ECS blue/green deployments.
A dedicated test listener must be configured on the Application Load Balancer to direct traffic to the replacement (Green) target group.
This isolates test traffic from production traffic, preventing real users from hitting the unverified deployment.
2
Determine the appropriate lifecycle hook in the AppSpec file to execute the automated integration tests.
The AfterAllowTestTraffic hook is selected.
This hook runs after the test listener starts directing traffic to the replacement task set, allowing test traffic to reach the new version for validation.
3
Verify that the selected hook and listener combination meets all constraints without exposing the new version to production traffic.
The configuration successfully validates the Green task set using the test listener, and only starts shifting production traffic after tests complete successfully.
This satisfies the zero-downtime and pre-traffic validation requirements.

Key Concept

ECS Blue/Green Deployment Validation with CodeDeploy
Question 13Question →

An application running on Amazon ECS (Fargate) is configured to use AWS CodeDeploy for blue/green deployments. The application resides behind an Application Load Balancer (ALB). The developer needs to configure the deployment pipeline to meet the following requirements:

* The deployment must begin by routing exactly 10%10\% of production traffic to the new task set (replacement task set), and then route the remaining 90%90\% of traffic after exactly 1010 minutes if the deployment remains stable.
* Before any production traffic is routed to the new task set, an automated test suite must run via an AWS Lambda function to validate the deployment's health.
* The deployment must automatically roll back if a specified Amazon CloudWatch alarm is triggered during the 1010-minute baking period.

Which TWO configurations must the developer implement to satisfy these requirements?

Select all that apply

Show answer & explanation

Answer: Set the deployment configuration in the CodeDeploy deployment group to CodeDeployDefault.ECSCanary10Min10Percent.; In the AppSpec file, define the validation Lambda function under the BeforeAllowTraffic lifecycle hook.

Answer

The developer must configure the deployment group to use the CodeDeployDefault.ECSCanary10Min10Percent strategy and define the validation Lambda function under the BeforeAllowTraffic hook in the AppSpec file.
The correct configurations specify using the CodeDeployDefault.ECSCanary10Min10Percent strategy to route the initial 10%10\% of traffic and wait 1010 minutes before routing the rest. Additionally, specifying the BeforeAllowTraffic hook in the AppSpec file ensures the validation Lambda function runs after the new task set is initialized but before production traffic is directed to it.

Step-by-Step Solution

1
Determine the traffic routing requirements.
Initial 10%10\% routing followed by the remaining 90%90\% after a 1010-minute baking period is a Canary pattern (specifically Canary 10% 10Min). Linear routing is ruled out.
Linear configurations shift traffic incrementally at each interval, whereas Canary configurations shift traffic in two distinct phases.
2
Identify the correct lifecycle hook for running validation tests.
The validation tests must run before any production traffic shifts. The BeforeAllowTraffic hook is the correct ECS deployment hook.
In ECS blue/green deployments, BeforeAllowTraffic executes after tasks are provisioned but before production traffic starts shifting. Other hooks like ValidateService are not supported on ECS, and AfterAllowTraffic runs too late.

Key Concept

ECS Blue/Green deployment traffic routing and lifecycle hook orchestration in AWS CodeDeploy
Question 14Question →

A developer is configuring a deployment pipeline for a containerized application running on Amazon ECS (Fargate). The ECS service has a desired task count of 1010. The deployment must comply with the following operational constraints:

- At least 88 tasks must remain healthy and actively serve traffic at all times during the deployment to prevent service degradation.
- Due to strict account resource quotas in the target AWS Region, no more than 1212 tasks for this service can run concurrently at any point during the deployment.
- The system must automatically roll back to the previous stable version if the new container version fails to launch or fails to pass its container health checks.

Which deployment strategy and configuration should the developer implement to satisfy these requirements?

Show answer & explanation

Answer: An ECS rolling update with the minimum healthy percent set to 8080%, the maximum percent set to 120120%, and the ECS deployment circuit breaker enabled with rollback.

Answer

An ECS rolling update with the minimum healthy percent set to 8080%, the maximum percent set to 120120%, and the ECS deployment circuit breaker enabled with rollback.
The correct option is the ECS rolling update with the minimum healthy percent set to 8080% and the maximum percent set to 120120%. This configuration ensures that at least 88 tasks (8080% of 1010) are always healthy and serving traffic, and restricts the ECS scheduler from running more than 1212 tasks (120120% of 1010) concurrently, satisfying the regional quota limit. Enabling the ECS deployment circuit breaker with rollback allows ECS to automatically roll back to the last stable deployment revision if the new tasks fail to reach a steady state, meeting all requirements natively.

Step-by-Step Solution

1
Calculate the minimum healthy task count and maximum task limit based on the percentage parameters.
A minimum healthy percent of 8080% requires at least 88 tasks to remain healthy (10×0.8=810 \times 0.8 = 8). A maximum percent of 120120% limits the total concurrent tasks to 1212 (10×1.2=1210 \times 1.2 = 12).
To verify compliance with the resource quotas and availability constraints specified in the scenario.
2
Evaluate AWS CodeDeploy blue/green deployment capabilities for ECS under task capacity limitations.
All CodeDeploy blue/green deployments for ECS require provisioning a full replacement task set (1010 tasks) before any traffic is shifted, requiring a total of 2020 tasks (200200% capacity).
To determine if CodeDeploy can satisfy the constraint of having at most 1212 concurrent tasks.
3
Verify the configuration needed for automated rollback in the chosen deployment model.
The native ECS deployment circuit breaker automatically monitors task launch and health check failures, triggering an automated rollback to the last stable task definition revision if the deployment fails.
To meet the requirement for automated rollback on container launch or health check failure without manual intervention.

Key Concept

ECS Rolling Updates vs CodeDeploy Blue/Green task provisioning constraints and native deployment circuit breaker rollbacks.
Estimated Time:3m 0s
Question 15Question →

A developer is deploying an updated version of a REST API to Amazon API Gateway. The developer must test the update by routing 15%15\% of production traffic to the new version. The remaining 85%85\% of traffic must continue to use the current version. The developer also needs the ability to instantly roll back the update if errors occur, or fully promote the update to production if it is successful. Which TWO configurations or actions must the developer perform to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a canary release on the existing API Gateway stage and configure the canary traffic percentage to 15%15\%.; Delete the canary release from the stage to roll back, or promote the canary release to make the new version the active production version.

Answer

To meet the requirements, the developer must create a canary release on the API Gateway stage configured to receive 15% of the traffic, and then either delete the canary release to roll back or promote it to replace the production version if successful.
Creating a canary release on the existing stage and specifying 15%15\% traffic natively implements the requested traffic split. Once configured, any new deployment to that stage routes the specified portion of traffic to the new code. Deleting the canary from the stage immediately halts the canary traffic routing and serves 100%100\% of traffic from the production version, fulfilling the instant rollback requirement. Promoting the canary upgrades the stage's production settings to point to the new deployment.

Step-by-Step Solution

1
Set up traffic shifting in API Gateway.
By creating a canary release directly on the target deployment stage and configuring it to receive 15%15\% of traffic, API Gateway automatically splits incoming traffic between the current production release (85%85\%) and the newly deployed canary release (15%15\%).
This natively meets the requirement to route a specific percentage of traffic to the new version without using external routing mechanisms.
2
Manage the lifecycle of the canary deployment.
If errors are detected during testing, deleting the canary release immediately routes 100%100\% of traffic back to the production version. If successful, promoting the canary copies the configuration to the stage, making it the new production release.
This provides instant rollback and clean promotion capabilities directly inside the API Gateway stage settings.

Key Concept

Amazon API Gateway stages support native canary releases. Enabling a canary on a stage allows a developer to route a portion of the traffic to a new deployment, test its stability, and either promote it to production or delete the canary to roll back.
Estimated Time:2m 0s
Question 16Question →

A developer is updating a critical serverless backend API hosted on AWS Lambda by configuring traffic shifting using AWS SAM and AWS CodeDeploy. The deployment must adhere to the following requirements:

1. Traffic must be routed to the new version in a linear, step-by-step progression rather than a single large step-up after an initial canary window.
2. The entire deployment must complete, routing 100% of traffic to the new version, in less than 15 minutes.
3. The deployment must automatically roll back if a CloudWatch alarm is triggered.

Which CodeDeploy deployment configuration should the developer specify in the SAM template's DeploymentPreference section to satisfy these requirements?

Show answer & explanation

Answer: Linear10PercentEvery1Minute

Answer

Linear10PercentEvery1Minute
The configuration that increments traffic by 10% every minute is the only option that is linear (providing a step-by-step progression rather than a sudden shift) and completes the deployment within the 15-minute constraint, taking 9 minutes in total.

Step-by-Step Solution

1
Analyze the requirement for linear, step-by-step progression.
This rules out Canary deployment configurations (like Canary10Percent10Minutes) and AllAtOnce configurations, leaving only Linear options.
Linear configurations shift traffic incrementally over multiple steps, whereas Canary shifts a small percentage, waits, and then shifts the remainder all at once.
2
Calculate the total deployment duration for the remaining Linear options.
Linear10PercentEvery1Minute takes 9 minutes (9 intervals of 1 minute) to complete. Linear10PercentEvery2Minutes takes 18 minutes (9 intervals of 2 minutes) to complete.
The total duration of a Linear10PercentEveryXMinutes configuration is 9 * X minutes, since it starts at 10% and increments by 10% each interval until it reaches 100%.
3
Compare the durations against the maximum completion limit of 15 minutes.
Only Linear10PercentEvery1Minute (9 minutes) is under the 15-minute threshold.
Linear10PercentEvery2Minutes requires 18 minutes, which violates the SLA requirement of completing in less than 15 minutes.

Key Concept

AWS CodeDeploy built-in deployment configurations for AWS Lambda and SAM allow developers to choose between linear and canary traffic shifting. Calculating the total deployment duration (number of steps multiplied by the interval) is critical to meeting deployment time SLAs.
Estimated Time:2m 0s
Question 17Question →

A developer is configuring a CI/CD pipeline to deploy updates to an AWS Lambda function that is integrated with an Amazon API Gateway REST API. The developer needs to implement a deployment strategy that routes 10%10\% of the incoming API traffic to the new Lambda version for a 2020-minute evaluation period. If any 5xx5\text{xx} errors are detected during this period, the traffic must automatically and immediately roll back to the stable version. The deployment must not require changes to the API Gateway stage configuration.

Which two configurations should the developer implement to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure the API Gateway integration to target a Lambda function alias instead of a specific version ARN or the LATESTLATEST qualifier.; Configure an AWS CodeDeploy deployment group to use the deployment configuration named `CodeDeployDefault.LambdaCanary10Percent20Minutes` and associate it with a CloudWatch alarm monitoring API Gateway 5xx5\text{xx} errors.

Answer

To meet the requirements, the developer must configure the API Gateway integration to target a Lambda function alias instead of a specific version ARN or the LATESTLATEST qualifier, and configure an AWS CodeDeploy deployment group to use the deployment configuration named `CodeDeployDefault.LambdaCanary10Percent20Minutes` and associate it with a CloudWatch alarm monitoring API Gateway 5xx5\text{xx} errors.
Targeting a Lambda function alias from API Gateway allows AWS CodeDeploy to shift traffic at the Lambda level by shifting the alias routing configuration between two versions. Selecting the `CodeDeployDefault.LambdaCanary10Percent20Minutes` deployment configuration routes exactly 10%10\% of traffic to the new version for a 2020-minute window while monitoring the associated CloudWatch alarms. If the alarm for 5xx5\text{xx} errors fires, CodeDeploy automatically rolls back the alias configuration to route all traffic back to the stable version, achieving an automated rollback.

Step-by-Step Solution

1
Establish version-level addressing for the Lambda function.
Configure the API Gateway integration to point to a Lambda function alias (e.g., `prod`).
Lambda version routing requires an alias. Pointing directly to a version ARN prevents CodeDeploy from dynamically shifting weights because versions are immutable.
2
Select the deployment configuration that matches the traffic-shifting requirements.
Identify `CodeDeployDefault.LambdaCanary10Percent20Minutes` as the correct configuration.
The scenario requires routing a constant 10%10\% of traffic to the new version for a 2020-minute evaluation period before shifting 100%100\% of traffic, which matches the definition of this canary configuration.
3
Configure automated rollback triggers.
Associate the CodeDeploy deployment group with a CloudWatch alarm monitoring API Gateway 5xx5\text{xx} errors.
If 5xx5\text{xx} errors occur during the 2020-minute evaluation, the alarm triggers and CodeDeploy immediately rolls back the alias routing weights to point 100%100\% of traffic back to the stable version.

Key Concept

Lambda Canary Deployments with AWS CodeDeploy
Estimated Time:2m 0s
Question 18Question →

A developer needs to update a web application running on AWS Elastic Beanstalk. The deployment must meet the following constraints:
- The application must have zero downtime during the update.
- The deployment must maintain 100% of the active instance capacity at all times.
- The update must be performed within the existing Elastic Beanstalk environment.

Which of the following Elastic Beanstalk deployment policies satisfy these constraints? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Rolling with additional batch; Immutable

Answer

The Rolling with additional batch and Immutable deployment policies meet all the constraints.
The Rolling with additional batch policy launches a new batch of instances first to maintain the original capacity before rolling out the update to existing instances. The Immutable policy launches a temporary Auto Scaling group to deploy the new version alongside the existing group. Both methods ensure 100% of active instance capacity is maintained, have zero downtime, and operate within the existing environment.

Step-by-Step Solution

1
Evaluate the requirement for zero downtime and 100% capacity maintenance within a single Elastic Beanstalk environment.
The policies that do not temporarily reduce capacity (like Rolling) or take the entire environment offline (like All-at-once) must be selected.
This filters out All-at-once and Rolling.
2
Evaluate the requirement to perform the update within the existing Elastic Beanstalk environment.
The Blue/Green deployment method is ruled out because it requires launching a separate, new environment and swapping URLs.
This filters out Blue/Green.
3
Identify the remaining valid Elastic Beanstalk deployment policies.
Rolling with additional batch and Immutable deployment policies both maintain 100% capacity, ensure zero downtime, and run within the existing environment.
These policies fulfill all stated requirements.

Key Concept

AWS Elastic Beanstalk deployment policies and their impact on environment capacity, downtime, and cost.
Question 19Question →

A developer is planning to update a non-critical internal application deployed on AWS Elastic Beanstalk. The update will be performed during off-peak hours over the weekend. To stay within budget, the deployment must not provision any additional EC2 instances. The company accepts that the application will be temporarily offline during the deployment process.

Which deployment strategy meets these requirements?

Show answer & explanation

Answer: All at once

Answer

All at once
The 'All at once' strategy is the only Elastic Beanstalk deployment policy that does not provision any additional EC2 instances during the update. It applies the deployment package to all existing instances at the same time. While this causes a short period of downtime (unavailability) during which the application is offline, this aligns with the company's acceptance of weekend downtime and satisfies the strict budget constraint of zero additional instances.

Step-by-Step Solution

1
Analyze the scenario constraints.
The deployment must not provision any additional EC2 instances (minimal cost) and can tolerate downtime (offline during the weekend).
This establishes the boundaries for acceptable deployment strategies.
2
Evaluate the resource provisioning behavior of each strategy.
Rolling with additional batch, Immutable, and Traffic splitting all require provisioning new instances during the deployment. Only the All at once strategy deploys directly to existing instances without launching new ones.
This filters out strategies that violate the zero-additional-instance cost constraint.
3
Select the strategy that allows downtime and uses only existing instances.
The All at once strategy is selected as it updates all instances simultaneously, causing downtime but requiring no additional resource costs.
This matches all criteria described in the scenario.

Key Concept

AWS Elastic Beanstalk deployment strategy tradeoffs regarding cost and capacity.
Estimated Time:45s
Question 20Question →

A developer is configuring a deployment strategy for a multi-instance AWS Elastic Beanstalk environment. The deployment must satisfy the following constraints:

* The application must maintain 100% of its capacity at all times during the deployment.
* There must be zero downtime.
* The update must be deployed to the entire fleet without splitting production traffic or performing canary testing.

Which of the following Elastic Beanstalk deployment strategies will satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Immutable; Rolling with additional batch

Answer

The Immutable and Rolling with additional batch deployment strategies are correct because they both maintain 100% capacity throughout the deployment and ensure zero downtime without splitting production traffic.
The Immutable strategy creates a full set of new instances in a separate Auto Scaling group, ensuring full capacity is maintained on the old group until cutover. The Rolling with additional batch strategy launches a temporary batch of new instances before starting the deployment to maintain 100% capacity during the rolling process. Neither strategy splits live production traffic for evaluation purposes.

Step-by-Step Solution

1
Analyze the constraint of maintaining 100% capacity during deployment.
This eliminates the standard Rolling strategy (which reduces capacity during updates) and the All-at-once strategy (which causes downtime).
We must identify strategies that launch temporary additional instances to offset the ones being upgraded.
2
Analyze the constraint of zero downtime.
This confirms that All-at-once is incorrect as it takes all instances offline at the same time.
Downtime must be avoided completely.
3
Analyze the constraint of not splitting production traffic or performing canary testing.
This eliminates the Traffic splitting strategy, which is designed to route a small percentage of production traffic to the new version for verification.
Traffic splitting acts as a canary deployment and violates the requirement.

Key Concept

AWS Elastic Beanstalk deployment strategies and their capacity, downtime, and traffic-routing trade-offs.
Estimated Time:1m 0s
Page 1 / 5Next
Deployment Strategies Practice Questions — AWS Certified Developer - Associate | Examkin