Examkin

Deployment Strategies

83 questions

All types83Multiple choice41Multiple select42
Question 41Question →

A developer is configuring the deployment settings for a critical production API hosted on AWS Elastic Beanstalk. The application currently runs on an Auto Scaling group of 8 instances and experiences a constant heavy workload. The deployment of the new application version must meet the following requirements:

- The environment must maintain its full capacity of 8 healthy instances running the current version during the deployment process.
- If the deployment fails, the rollback must be immediate and must not require redeploying the previous version to the instances, preventing any service disruption to the active environment.
- The new version must be deployed to new instances and pass health checks before any production traffic is routed to them.

Which Elastic Beanstalk deployment strategy satisfies these requirements?

Show answer & explanation

Answer: Immutable

Answer

The immutable deployment strategy satisfies the requirements by launching a temporary Auto Scaling group to deploy the new application version, maintaining full capacity of the original environment, and allowing for an immediate, non-disruptive rollback if health checks fail.
The correct answer is the immutable deployment strategy. An immutable deployment ensures that a temporary Auto Scaling group is created to host the new version of the application, running alongside the existing Auto Scaling group. This setup maintains the full capacity of the original instances (8 instances) during the update. If health checks on the new instances fail, the rollback is immediate and clean because AWS Elastic Beanstalk only needs to terminate the temporary Auto Scaling group. The active instances in the original Auto Scaling group remain completely untouched, ensuring zero disruption and avoiding any redeployment steps for rolling back.

Step-by-Step Solution

1
Analyze the capacity requirement.
Since the environment must maintain its full capacity of 8 healthy instances running the current version, any strategy that takes existing instances offline (such as Rolling or All-at-once) is ruled out. This leaves 'Immutable' and 'Rolling with additional batch' as potential options.
To ensure peak performance is not degraded during the deployment.
2
Evaluate the rollback and active environment constraints.
A rollback must be immediate and must not perform redeployment steps on the existing active instances. 'Rolling with additional batch' updates the existing instances in the active Auto Scaling group; if a failure occurs, it must perform a rollback by redeploying the older version back to the updated instances, which takes time and modifies active instances. 'Immutable' uses a separate temporary Auto Scaling group, so a rollback simply involves terminating that group, leaving the original group completely untouched.
To determine which strategy isolates the rollback impact and provides the fastest recovery time.
3
Confirm health check validation.
The immutable deployment strategy validates the health of all instances in the temporary Auto Scaling group before cutting over traffic, meeting the validation requirement.
To verify that the chosen strategy aligns with all remaining constraints.

Key Concept

AWS Elastic Beanstalk Immutable deployments isolate new version instances in a temporary Auto Scaling group, ensuring full capacity is maintained and rollbacks are immediate and clean.
Question 42Question →

A company is evaluating AWS deployment strategies for its web application to ensure that any new version is deployed to brand new instances rather than updating the existing instances in-place. This approach is required to allow a clean separation of environments and a rapid rollback if issues are detected in production. Which two deployment strategies satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Blue/green deployment; Immutable deployment

Answer

The correct strategies are blue/green deployment and immutable deployment, as both strategies provision entirely new instances for the new application version rather than updating existing instances in-place.
Blue/green deployment and immutable deployment are designed to launch new instances for the new deployment version. Blue/green deployment creates a duplicate environment where the new version is tested before shifting traffic. Immutable deployment replaces the existing instances with new ones by launching a temporary Auto Scaling group, verifying the instances, and terminating the old ones. Both strategies preserve the original instances unchanged during the initial deployment phase, allowing for a fast and clean rollback.

Step-by-Step Solution

1
Analyze the scenario constraints and requirements.
The target strategy must deploy the application to brand new instances and avoid in-place updates to facilitate a clean separation and quick rollback.
This allows filtering out any deployment strategies that update existing instances directly.
2
Evaluate the deployment strategies against the requirement of using new instances.
Blue/green deployment creates a separate parallel environment of new instances. Immutable deployment provisions new instances in a separate Auto Scaling group or environment before terminating the old ones.
Both methods fulfill the core requirement of using new instances to avoid configuration drift and allow rapid rollback.
3
Identify why other options fail.
Rolling, all-at-once, and in-place updates deploy code directly onto the existing virtual machines, meaning they update the instances in-place.
This confirms that only blue/green and immutable deployments meet all constraints.

Key Concept

Identifying deployment strategies that utilize new instances (immutable and blue/green) versus those that update existing instances in-place (rolling and all-at-once).
Question 43Question →

A developer is updating a web application hosted on an AWS Elastic Beanstalk environment. The developer needs to deploy the new application version as quickly as possible. The application is for internal testing, so temporary downtime during the deployment is acceptable, and there is no budget for additional Amazon EC2 instances. Which Elastic Beanstalk deployment strategy meets these requirements?

Show answer & explanation

Answer: All-at-once

Answer

All-at-once
The All-at-once deployment strategy deploys the new version to all instances simultaneously. It is the fastest deployment method and does not require any additional instances, making it the most cost-effective. However, it takes all instances out of service during the deployment, resulting in temporary downtime.

Step-by-Step Solution

1
Identify the deployment constraints from the scenario
The requirements are: fastest deployment time, acceptance of temporary downtime, and zero budget for additional EC2 instances.
Understanding the constraints is necessary to narrow down the viable deployment strategies.
2
Evaluate the deployment strategies against the capacity/cost constraint
Strategies that launch additional EC2 instances (Immutable, Rolling with additional batch) are eliminated because there is no budget for extra instances.
This filters out strategies that violate the zero extra cost constraint.
3
Compare the remaining strategies (All-at-once vs. Rolling) against the speed and downtime constraints
All-at-once is faster than Rolling and takes all instances out of service, which fits the downtime tolerance. Rolling avoids downtime but is slower.
This identifies the option that best matches the speed and downtime requirements.

Key Concept

AWS Elastic Beanstalk deployment strategies trade-offs between downtime, deployment speed, and cost.
Question 44Question →

A developer is deploying a new version of a critical web application to AWS Elastic Beanstalk. The application must maintain 100%100\% availability (no downtime) and full capacity during the deployment. If a failure occurs, the deployment must support a rapid rollback to the previous version. The developer has no budget constraints. Which two deployment strategies meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Blue/Green deployment; Immutable deployment

Answer

Blue/Green deployment and Immutable deployment
Blue/Green and Immutable deployments satisfy all requirements. A Blue/Green deployment swaps DNS/CNAME records between two separate environments, maintaining 100%100\% capacity and allowing an instant rollback. An Immutable deployment creates a temporary Auto Scaling group with the new version, ensuring 100%100\% capacity is maintained and allowing a rapid rollback by simply deleting the new group.

Step-by-Step Solution

1
Identify the constraints specified in the deployment scenario.
The key constraints are: zero downtime, 100%100\% capacity maintained, rapid rollback capabilities, and no budget constraints.
This sets up the criteria used to evaluate each Elastic Beanstalk deployment option.
2
Evaluate the impact of each deployment strategy on application capacity and downtime.
All-at-once causes downtime. Rolling reduces capacity during the update. Rolling with additional batch, Immutable, and Blue/Green all maintain 100%100\% capacity and have no downtime.
This narrows the candidate list to strategies that maintain full application availability.
3
Assess the rollback speed of the remaining strategy options.
Rolling with additional batch requires a slow rolling deployment of the older version to roll back. Blue/Green (CNAME swap) and Immutable (terminating the new Auto Scaling group) both support near-instantaneous rollbacks.
This identifies the final two strategies that satisfy the rapid rollback constraint.

Key Concept

AWS Elastic Beanstalk deployment strategies differ in their impact on environment capacity, downtime, and rollback time.
Estimated Time:1m 0s
Question 45Question →

A developer is configuring a deployment for a web application running on an Auto Scaling group of four Amazon EC2 instances using AWS CodeDeploy. The deployment must meet the following constraints:
- The application must experience zero downtime, meaning at least some instances must remain online and healthy to serve traffic at all times.
- Due to strict budget limitations, no additional EC2 instances can be provisioned during the deployment.

Which two AWS CodeDeploy default deployment configurations satisfy these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: CodeDeployDefault.OneAtATime; CodeDeployDefault.HalfAtATime

Answer

The correct configurations are CodeDeployDefault.OneAtATime and CodeDeployDefault.HalfAtATime.
The correct configurations are CodeDeployDefault.OneAtATime and CodeDeployDefault.HalfAtATime. Because the deployment must not launch additional EC2 instances, it must be performed in-place. To prevent downtime, the deployment configuration must ensure that some instances remain online and healthy during the update. CodeDeployDefault.OneAtATime updates one instance at a time (keeping three online), and CodeDeployDefault.HalfAtATime updates two instances at a time (keeping two online). Both options satisfy the zero-downtime and zero-additional-cost constraints.

Step-by-Step Solution

1
Analyze the deployment platform and constraints.
The platform is Amazon EC2. The constraints are zero downtime (at least one instance must remain online) and zero additional instances (the update must be in-place).
This establishes that we must use an in-place deployment strategy for EC2 that does not deploy to all instances simultaneously.
2
Evaluate CodeDeploy default in-place configurations.
CodeDeployDefault.OneAtATime deploys to 1 of 4 instances (leaving 3 healthy). CodeDeployDefault.HalfAtATime deploys to 2 of 4 instances (leaving 2 healthy). CodeDeployDefault.AllAtOnce deploys to 4 of 4 instances (leaving 0 healthy).
Both OneAtATime and HalfAtATime maintain application availability during the in-place update process.
3
Filter out configurations that violate the constraints.
AllAtOnce causes downtime. Blue/Green requires provisioning a replacement Auto Scaling group (incurring extra instance costs). ECSLinear10PercentEvery1Minute is incompatible with EC2 deployments.
This confirms that only the two selected in-place configurations meet both the availability and budget requirements.

Key Concept

AWS CodeDeploy in-place deployment configurations for EC2 that balance fleet capacity and update progress without provisioning new instances.
Question 46Question →

A developer is configuring a blue/green deployment for a microservice hosted on Amazon Elastic Container Service (Amazon ECS) using AWS CodeDeploy. The deployment must meet the following operational requirements:

* Traffic must be shifted in two increments: 10%10\% of traffic must be routed to the new task set immediately, followed by the remaining 90%90\% after a 1515-minute evaluation period.
* The original task set must remain active for exactly 11 hour (6060 minutes) after traffic is fully routed to the new task set to allow for manual rollback if issues arise, after which the original task set should be automatically terminated.

Which two configurations will satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Configure the deployment settings in the deployment group to use the Canary10Percent15Minutes deployment configuration.; Configure the deployment group's blue/green deployment settings to wait 60 minutes before terminating the original task set.

Answer

Configure the deployment settings in the deployment group to use the Canary10Percent15Minutes deployment configuration, and configure the deployment group's blue/green deployment settings to wait 60 minutes before terminating the original task set.
To shift 10%10\% of traffic immediately and the remaining 90%90\% after a 1515-minute evaluation period, the Canary10Percent15Minutes configuration is required. To retain the original task set for 11 hour after traffic shifting completes, the developer must specify a termination wait time of 6060 minutes in the deployment group settings.

Step-by-Step Solution

1
Analyze traffic shifting requirements to choose the correct CodeDeploy configuration.
The requirement calls for shifting 10%10\% of traffic immediately and the remaining 90%90\% after a 1515-minute window. This represents a canary deployment pattern with a 1515-minute evaluation interval, pointing to Canary10Percent15Minutes.
Linear configurations shift traffic incrementally over multiple steps (e.g., 10%10\% every 1515 minutes), which does not match the two-increment canary requirement.
2
Determine the proper mechanism for delaying the termination of the old task set.
Identify that the CodeDeploy deployment group settings contain a specific configuration for specifying the termination wait time of the original (blue) task set.
Configuring this to 6060 minutes allows the old task set to remain active for exactly 11 hour after traffic is fully shifted, facilitating manual rollback if needed.
3
Evaluate AppSpec lifecycle hooks to identify incorrect configuration options.
Verify that ECS deployments support specific hooks (such as BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, and AfterAllowTraffic) but do not support EC2 hooks like ApplicationStop.
Attempting to use ApplicationStop in an ECS AppSpec file will cause deployment validation errors.

Key Concept

AWS CodeDeploy deployment configurations and task set lifecycle management for ECS blue/green deployments.
Question 47Question →

A developer is updating a serverless application hosted on AWS Lambda and wants to roll out a new function version using AWS CodeDeploy. The deployment must route 10%10\% of incoming traffic to the new version initially. After a 1010-minute observation period, if no errors are detected by Amazon CloudWatch alarms, all remaining traffic (90%90\%) must be routed to the new version. Which AWS CodeDeploy deployment configuration meets these requirements?

Show answer & explanation

Answer: CodeDeployDefault.LambdaCanary10Percent10Minutes

Answer

CodeDeployDefault.LambdaCanary10Percent10Minutes
The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes shifts 10%10\% of the traffic to the new Lambda version initially, waits for a 1010-minute interval to monitor for errors via CloudWatch alarms, and then routes the remaining 90%90\% of the traffic to the new version.

Step-by-Step Solution

1
Analyze the traffic shifting requirement
The requirement specifies routing 10%10\% of traffic to the new version initially, waiting 1010 minutes, and then shifting all remaining 90%90\% of traffic to the new version.
This traffic shifting pattern describes a canary deployment strategy (an initial small slice of traffic followed by a single promotion of all remaining traffic after a specific delay) rather than a linear or all-at-once deployment.
2
Identify the corresponding AWS CodeDeploy predefined configuration
The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes matches the 10%10\% initial traffic split and 1010-minute wait duration.
AWS CodeDeploy provides predefined deployment configurations for Lambda. The Canary configurations specify the percentage to shift and the wait time before shifting the remaining traffic. The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes implements a single 1010-minute step before routing all remaining traffic.

Key Concept

AWS CodeDeploy deployment configurations for AWS Lambda allow developers to gradually shift traffic between versions using Canary or Linear strategies.
Question 48Question →

A developer is configuring an in-place deployment in AWS CodeDeploy for an application running on an Auto Scaling group with 1010 Amazon EC2 instances. To prevent performance degradation during peak hours, the application must maintain at least 60%60\% of its capacity (66 instances) to serve traffic at all times during the deployment. The developer also wants to complete the deployment in the shortest time possible. Which deployment configuration should the developer use to meet these requirements?

Show answer & explanation

Answer: Create a custom deployment configuration with the minimum healthy hosts set to a fleet percentage of 60%60\%.

Answer

Create a custom deployment configuration with the minimum healthy hosts set to a fleet percentage of 60%60\%.
The correct option is the custom deployment configuration with the minimum healthy hosts set to a fleet percentage of 60%60\%. This ensures that at least 66 instances (which is 60%60\% of 1010 instances) remain healthy and serving traffic throughout the deployment. Consequently, CodeDeploy can update up to 44 instances concurrently, minimizing the total deployment duration while satisfying the capacity constraint.

Step-by-Step Solution

1
Calculate the number of healthy instances required during the deployment.
The application requires at least 60%60\% of 1010 instances to be healthy, which equals 10×0.60=610 \times 0.60 = 6 healthy instances.
This establishes the minimum capacity baseline that must be maintained.
2
Determine the maximum number of instances that can be updated concurrently.
Maximum updating instances = Total instances - Minimum healthy instances = 10−6=410 - 6 = 4 instances.
To complete the deployment in the shortest time, we must update the maximum allowable number of instances concurrently.
3
Evaluate the predefined CodeDeploy configurations against the constraints.
HalfAtATime updates 55 instances (leaving 55 healthy, violating the limit). OneAtATime updates 11 instance (taking too long). AllAtOnce updates all 1010 (violating the limit).
Predefined configurations do not optimize for updating exactly 44 instances at a time while keeping 66 healthy.
4
Define the custom configuration parameters.
A custom configuration with minimum healthy hosts set to a fleet percentage of 60%60\% (or a host count of 66) is required.
Setting the minimum healthy hosts to a fleet percentage of 60%60\% ensures exactly 66 instances remain healthy, permitting 44 instances to update concurrently, thus meeting both capacity and speed constraints.

Key Concept

AWS CodeDeploy deployment configurations and minimum healthy hosts parameters.
Question 49Question →

A developer is configuring the deployment policy for a web application running on an AWS Elastic Beanstalk environment. The environment currently consists of 88 Amazon EC2 instances. To meet strict SLA requirements, the deployment must maintain 100%100\% of the current serving capacity (88 instances) at all times during the update. Additionally, the development team wants to minimize the additional infrastructure costs during the deployment process by avoiding the temporary doubling of instances or provisioning a second environment. Which Elastic Beanstalk deployment policy should the developer select?

Show answer & explanation

Answer: Rolling with additional batch

Answer

The Rolling with additional batch deployment policy should be selected.
The 'Rolling with additional batch' policy launches a new batch of instances first to maintain 100%100\% capacity during the deployment. It then updates the remaining instances in batches. Because it only launches one batch of new instances at a time rather than a full duplicate of the environment, it is more cost-effective than the 'Immutable' policy while still preventing any capacity reduction.

Step-by-Step Solution

1
Analyze capacity requirements
The deployment must maintain 100%100\% capacity (88 instances) at all times during the deployment process.
To prevent performance degradation and meet SLA requirements during the update.
2
Evaluate cost and resource constraints
The solution must minimize extra instance costs and avoid doubling the instance count to 1616 or setting up a secondary environment.
To satisfy the constraint of minimizing additional infrastructure costs during deployment.
3
Compare candidate Elastic Beanstalk deployment policies
Rolling reduces capacity. All-at-once causes downtime. Immutable maintains capacity but doubles the instance count. Rolling with additional batch launches only a single additional batch (e.g., 22 instances for a 25%25\% batch size) to maintain capacity, making it the most cost-effective option that meets all constraints.
To select the policy that perfectly aligns with both capacity preservation and cost optimization.

Key Concept

AWS Elastic Beanstalk deployment policies trade-offs between capacity, cost, and rollback capability
Question 50Question →

A developer is configuring a rolling update deployment for an application hosted on an Amazon Elastic Container Service (Amazon ECS) cluster using the EC2 launch type. The service runs with a desired task count of 44. Due to strict memory constraints on the container instances, the cluster cannot run more than 66 tasks simultaneously. Additionally, the application must maintain at least 50%50\% of its desired capacity (22 tasks) at all times to handle incoming baseline traffic.

Which two parameters should the developer configure in the ECS service definition to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Set `minimumHealthyPercent` to 5050.; Set `maximumPercent` to 150150.

Answer

Setting the minimum healthy percent to 5050 and the maximum percent to 150150 in the ECS service definition deployment configuration.
To satisfy the requirements, the developer must configure the deployment parameters of the ECS service relative to the desired task count of 44. The minimum healthy percent represents the lower limit of healthy tasks that must remain running during a deployment, calculated as 24×100%=50%\frac{2}{4} \times 100\% = 50\%. The maximum percent represents the upper limit of tasks that can be running, calculated as 64×100%=150%\frac{6}{4} \times 100\% = 150\%. Together, these parameters allow the ECS service to perform a rolling update by launching up to 22 new tasks before terminating old ones, while never dropping below 22 active tasks or exceeding 66 total tasks.

Step-by-Step Solution

1
Calculate the required minimum healthy percent from the capacity constraint.
The minimum required active capacity is 22 tasks out of a desired count of 44. Expressed as a percentage: 24×100%=50%\frac{2}{4} \times 100\% = 50\%. Therefore, the minimum healthy percent must be set to 5050.
This guarantees that ECS will not terminate tasks below the 50%50\% threshold (22 tasks) during the rolling update.
2
Calculate the required maximum percent from the resource constraints.
The maximum allowed concurrent capacity is 66 tasks out of a desired count of 44. Expressed as a percentage: 64×100%=150%\frac{6}{4} \times 100\% = 150\%. Therefore, the maximum percent must be set to 150150.
This configuration allows ECS to start up to 22 new tasks of the new version before terminating any old tasks, while ensuring the cluster memory limit is not exceeded.

Key Concept

Amazon ECS Rolling Update Deployment Parameters
Estimated Time:1m 30s
Question 51Question →

A developer is designing a deployment strategy for a high-traffic web application hosted on Amazon EC2 instances. The company requires a canary deployment strategy where 10%10\% of the production traffic is routed to the new version of the application for validation. The rollout must allow for an immediate rollback to the stable version in the event of an application error, without waiting for client DNS caches to expire.

Which approach should the developer implement to meet these requirements?

Show answer & explanation

Answer: Configure an Application Load Balancer (ALB) with a single listener and two target groups (one for the stable version and one for the new version). Set the listener routing rule to distribute traffic with a weight of 90%90\% to the stable target group and 10%10\% to the new target group.

Answer

Configure an Application Load Balancer (ALB) with a single listener and two target groups (one for the stable version and one for the new version). Set the listener routing rule to distribute traffic with a weight of 90%90\% to the stable target group and 10%10\% to the new target group.
Configuring an Application Load Balancer (ALB) with weighted target groups shifts traffic at the application layer (HTTP/HTTPS). The client resolves a single DNS name for the load balancer, which then determines how to route requests. When a rollback is required, changing the listener rule weight immediately routes all traffic to the stable target group. This occurs instantly at the ALB level, bypassing client-side DNS caching and TTL limitations.

Step-by-Step Solution

1
Analyze the requirement for a canary deployment that routes 10%10\% of traffic to the new version.
The solution must support weighted routing where 90%90\% goes to the stable version and 10%10\% to the new version.
This establishes the target traffic split for validation.
2
Analyze the constraint regarding immediate rollback without waiting for client DNS caches to expire.
DNS-level routing options (such as Route 53 Weighted routing) are disqualified due to DNS cache TTL latencies.
If an error occurs, client browsers that have cached the DNS record pointing to the canary version will continue to send traffic to it, violating the immediate rollback constraint.
3
Select the application-layer routing mechanism that bypasses DNS cache latency.
An Application Load Balancer (ALB) with weighted target groups distributes traffic at the HTTP layer.
Because the client connects to the same ALB DNS name, updating the listener rule to route 100%100\% of traffic back to the stable target group instantly redirects all subsequent requests without any DNS propagation delay.

Key Concept

Application Load Balancer weighted target groups shift traffic at the HTTP layer, bypassing DNS caching limitations during canary deployments.
Question 52Question →

A developer has updated an API hosted on Amazon API Gateway. To minimize the risk of the new version affecting users, the developer wants to test the update by routing 5%5\% of the incoming API calls to the new version, while the remaining 95%95\% of the traffic goes to the current version. The developer wants to monitor the performance of the new version using CloudWatch and easily promote it to full production once verified. Which approach meets these requirements with the least operational complexity?

Show answer & explanation

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

Answer

Configure a canary release on the existing API Gateway stage, set the canary traffic percentage to 5%5\%, and promote the canary after verification.
The correct answer is to configure a canary release on the existing API Gateway stage. When a canary release is enabled, API Gateway automatically routes a specified percentage of API traffic (in this case, 5%5\%) to the new deployment. The developer can monitor the performance of this canary using Amazon CloudWatch metrics and easily promote it to the production release once verified, which requires the least operational effort.

Step-by-Step Solution

1
Identify the deployment target service and the primary goal.
The target is Amazon API Gateway, and the goal is to shift 5%5\% of traffic to a new version of the API and monitor performance.
Understanding the service context helps isolate native features from external workarounds.
2
Evaluate the native deployment features of Amazon API Gateway.
Amazon API Gateway natively supports canary releases directly on an existing deployment stage.
This features allows splitting traffic at the HTTP request level and integrating directly with CloudWatch for testing.
3
Analyze and eliminate alternative architectures based on complexity.
Route 53 weighted routing requires custom domains; Lambda alias routing operates at the backend layer rather than the API stage layer; ALB target groups are structurally redundant and complex.
This confirms that API Gateway canary release is the path of least operational complexity.

Key Concept

API Gateway Canary Deployments
Estimated Time:1m 30s
Question 53Question →

A developer is configuring a blue/green deployment for an Amazon Elastic Container Service (Amazon ECS) service using AWS CodeDeploy. The deployment must shift traffic to the new task set gradually to allow for monitoring, but the entire deployment process must finish shifting 100%100\% of the traffic in less than 1010 minutes.

Which TWO predefined deployment configurations will meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: CodeDeployDefault.ECSLinear10PercentEvery1Minute; CodeDeployDefault.ECSCanary10Percent5Minutes

Answer

The configurations CodeDeployDefault.ECSLinear10PercentEvery1Minute and CodeDeployDefault.ECSCanary10Percent5Minutes meet the requirements.
The correct configurations are CodeDeployDefault.ECSLinear10PercentEvery1Minute and CodeDeployDefault.ECSCanary10Percent5Minutes. The linear configuration shifts 10%10\% of traffic each minute, completing the transition in 99 minutes. The canary configuration shifts 10%10\% first, waits 55 minutes, and then shifts the remaining 90%90\%, completing the transition in 55 minutes. Both configurations satisfy the requirements of shifting traffic gradually and completing the deployment in less than 1010 minutes.

Step-by-Step Solution

1
Analyze the requirement to shift traffic gradually.
Discard the all-at-once configuration since it shifts traffic immediately and does not allow for gradual transition or monitoring.
Gradual shifting is a strict constraint specified in the prompt.
2
Calculate the total traffic shifting duration for each remaining configuration.
The 1-minute linear configuration takes 99 minutes, the 5-minute canary configuration takes 55 minutes, the 3-minute linear configuration takes 2727 minutes, and the 15-minute canary configuration takes 1515 minutes.
This determines which configurations complete within the required 10-minute window.
3
Select the configurations that meet the duration constraint.
The 1-minute linear configuration and the 5-minute canary configuration both complete in less than 1010 minutes.
Only these two configurations satisfy both the gradual shifting and the time constraint of less than 10 minutes.

Key Concept

AWS CodeDeploy ECS Deployment Configurations
Question 54Question →

A company runs a high-traffic web application on an AWS Elastic Beanstalk environment. The application is highly sensitive to performance degradation, so the deployment of a new version must maintain 100% of the environment's instance capacity to handle traffic at all times. Additionally, if the new version fails health checks, the environment must roll back automatically with minimal rollback time and no manual intervention. The developer wants to avoid configuring a secondary environment or changing DNS records. Which deployment strategy should the developer select to meet these requirements?

Show answer & explanation

Answer: Immutable deployment

Answer

Immutable deployment
The correct strategy is an Immutable deployment. This policy launches a temporary Auto Scaling group with the new application version and tests it. If the instances pass health checks, Elastic Beanstalk moves them to the main Auto Scaling group and terminates the old instances. If they fail, the temporary Auto Scaling group is terminated immediately, achieving a clean and fast rollback without modifying any of the original instances and maintaining 100% capacity throughout the process.

Step-by-Step Solution

1
Analyze the capacity requirement.
The requirement specifies that the deployment must maintain 100% of the environment's instance capacity. This rules out 'All at once' and 'Rolling' deployments, as they temporarily take instances out of service.
To prevent performance degradation during the deployment process.
2
Analyze the environment and DNS requirements.
The deployment must occur within the existing environment without creating a secondary environment or changing DNS records (CNAME swap), which rules out external Blue/Green deployments.
To simplify management and satisfy the single-environment constraint.
3
Evaluate the rollback and failure recovery requirements.
The strategy must support automatic rollback with minimal recovery time if health checks fail. An immutable deployment creates a temporary Auto Scaling group to test the new version, making rollbacks as simple as terminating the temporary group. A rolling with additional batch deployment would require a slow, manual rollback deployment of the previous version if some instances had already been updated.
To find the strategy that minimizes the blast radius and rollback time within a single environment.

Key Concept

AWS Elastic Beanstalk deployment policies and their trade-offs regarding capacity, downtime, and rollback mechanisms.
Estimated Time:1m 30s
Question 55Question →

A developer is configuring an AWS CodeDeploy deployment group for an in-place deployment to a fleet of 10 Amazon EC2 instances. The deployment must not provision any new EC2 instances due to budget limitations. Additionally, the application must maintain at least 50% of its healthy instance capacity at all times during the update to handle the incoming traffic load.

Which two CodeDeploy default deployment configurations can the developer select to meet these requirements? (Choose two.)

Select all that apply

Show answer & explanation

Answer: CodeDeployDefault.OneAtATime; CodeDeployDefault.HalfAtATime

Answer

CodeDeployDefault.OneAtATime and CodeDeployDefault.HalfAtATime
The correct configurations are CodeDeployDefault.OneAtATime and CodeDeployDefault.HalfAtATime. An in-place deployment to a fleet of 10 EC2 instances requires at least 5 instances (50%) to remain healthy at all times. CodeDeployDefault.OneAtATime updates one instance at a time, keeping 90% capacity active. CodeDeployDefault.HalfAtATime updates up to 5 instances at a time, keeping exactly 50% capacity active. Both satisfy the minimum capacity requirement.

Step-by-Step Solution

1
Analyze the deployment target and capacity constraints.
The deployment is in-place on a fleet of 10 EC2 instances and requires at least 50% capacity (5 instances) to remain healthy at all times.
To identify which deployment configurations are compatible with EC2 and satisfy the minimum instance count requirements.
2
Evaluate compatible CodeDeploy deployment configurations for EC2.
CodeDeployDefault.OneAtATime, CodeDeployDefault.HalfAtATime, and CodeDeployDefault.AllAtOnce are default configurations for EC2. Configurations prefixed with ECS or Lambda are incompatible.
To filter out platform-incompatible configurations.
3
Calculate the active capacity during deployment for the remaining configurations.
OneAtATime keeps 90% (9 instances) active. HalfAtATime keeps 50% (5 instances) active. AllAtOnce keeps 0% (0 instances) active. Only OneAtATime and HalfAtATime meet the 50% threshold.
To select the configurations that satisfy the capacity constraint.

Key Concept

AWS CodeDeploy deployment configurations for EC2 in-place deployments.
Question 56Question →

A developer is updating a web application running on an AWS Elastic Beanstalk environment. The application is highly sensitive to customer-facing bugs, so the developer wants to test the new version using a small percentage of real production traffic (10%10\%) for a duration of 1515 minutes. If the new version triggers any Amazon CloudWatch alarms during this time, the traffic must immediately route back to the old version. If no alarms are triggered, the remaining 90%90\% of traffic should automatically shift to the new version. Which deployment policy should the developer configure in the Elastic Beanstalk environment?

Show answer & explanation

Answer: Traffic splitting

Answer

Traffic splitting
Traffic splitting is the correct answer because it is the only native AWS Elastic Beanstalk deployment policy that allows developers to perform canary testing. It launches a temporary Auto Scaling group with the new version, routes a specified percentage of traffic (e.g., 10%10\%) to it for a set evaluation period (e.g., 1515 minutes), monitors health using CloudWatch alarms, and automatically rolls back if alarms are triggered, or promotes the deployment to 100\% traffic if successful.

Step-by-Step Solution

1
Analyze the requirement to route a small fraction (10%10\%) of live production traffic to a new version of the application for validation.
Identify that this represents a canary deployment pattern, which requires splitting load balancer traffic between the existing environment and a new deployment.
This rules out standard rolling, rolling with additional batch, and immutable deployment policies, which update instances without fractional traffic routing.
2
Evaluate the rollback and promotion criteria (1515 minutes of evaluation using CloudWatch alarms, followed by automatic promotion or rollback).
Determine that the deployment policy must natively support CloudWatch alarm monitoring and automated rollback/promotion based on health status.
Traffic Splitting in Elastic Beanstalk allows configuring a specific evaluation time (e.g., 1515 minutes) and linking CloudWatch alarms to trigger a rollback.
3
Select the Elastic Beanstalk deployment policy that matches these constraints.
The Traffic Splitting policy is chosen as it is the only native Elastic Beanstalk policy designed specifically for percentage-based traffic shifting and automatic CloudWatch-based rollbacks.
Other policies like Immutable and Rolling with additional batch do not support fractional traffic splitting.

Key Concept

AWS Elastic Beanstalk Traffic Splitting Deployment Policy
Question 57Question →

A high-traffic API is hosted on an AWS Elastic Beanstalk environment. The development team is preparing to deploy a major update. The deployment must satisfy the following operational requirements:

* The system must maintain at least its baseline capacity at all times to prevent performance degradation.
* A fast rollback mechanism must be available to restore the previous version within minutes if post-deployment health checks or alarms fail.
* The update must be contained within the existing environment without provisioning a separate, duplicate Elastic Beanstalk environment or performing a CNAME swap.

Which TWO of the following deployment strategies should the developer select to satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Immutable deployment; Traffic splitting deployment

Answer

Immutable deployment and Traffic splitting deployment are the correct strategies.
Immutable deployment and Traffic splitting deployment both launch a temporary Auto Scaling group to deploy the new application version alongside the existing instances. This maintains 100%100\% of the baseline capacity during deployment. If the deployment fails (e.g., health checks fail or CloudWatch alarms trigger), Elastic Beanstalk can perform a fast rollback by immediately terminating the temporary instances and routing all traffic back to the original instances, without requiring external DNS changes or CNAME swaps.

Step-by-Step Solution

1
Analyze the capacity requirement.
Since baseline capacity must be maintained at 100%100\% at all times, strategies like Rolling and All-at-once, which take existing instances out of service, are eliminated.
This leaves Immutable, Traffic splitting, Rolling with additional batch, and Blue/green as candidates.
2
Analyze the environment boundary constraint.
The requirement states that the update must be contained within the existing environment without a CNAME swap.
This eliminates Blue/green deployment, which requires creating a separate Elastic Beanstalk environment and performing a CNAME swap.
3
Analyze the rollback speed requirement.
Rolling with additional batch requires a full redeployment of the previous version to rollback, which is slow. Immutable and Traffic splitting deploy to a temporary Auto Scaling group, enabling rapid rollback by terminating the new instances and reverting routing.
This identifies Immutable and Traffic splitting as the only two strategies that meet all requirements.

Key Concept

AWS Elastic Beanstalk Deployment Strategies
Question 58Question →

A company runs a containerized web application on Amazon ECS using the AWS Fargate launch type. The ECS service is configured with a desired count of 88 tasks. Due to strict budget constraints, the developer cannot allocate any additional Fargate tasks or capacity during a deployment. However, the application must remain online, maintaining at least 50%50\% of its desired processing capacity throughout the update process.

Which two deployment configuration values should the developer specify in the ECS service definition to meet these requirements?

Select all that apply

Show answer & explanation

Answer: `minimumHealthyPercent` set to 5050; `maximumPercent` set to 100100

Answer

Setting the minimum healthy percent to 5050 and the maximum percent to 100100.
Specifying a `maximumPercent` of 100100 and a `minimumHealthyPercent` of 5050 satisfies all constraints. Setting `maximumPercent` to 100100 ensures that Amazon ECS does not provision any extra Fargate tasks beyond the desired count during the deployment, adhering to the strict budget limits. Setting `minimumHealthyPercent` to 5050 ensures that at least half of the tasks (44 out of 88) remain running and healthy during the update, maintaining the required processing capacity online.

Step-by-Step Solution

1
Analyze the capacity and resource constraint.
The constraint states that no additional tasks or capacity can be allocated during the deployment. Therefore, the maximum number of concurrent running or pending tasks must be capped exactly at the desired count, which is 100%100\%. This determines that `maximumPercent` must be 100100.
Setting `maximumPercent` to 100100 prevents Amazon ECS from scaling up and provisioning extra Fargate tasks during the update.
2
Analyze the availability constraint.
The application must maintain at least 50%50\% of its processing capacity online at all times. Since the desired count is 88 tasks, at least 44 tasks must remain running and healthy. This determines that `minimumHealthyPercent` must be 5050.
Setting `minimumHealthyPercent` to 5050 guarantees that Amazon ECS will only stop up to 44 tasks at a time, keeping the remaining 44 active to handle incoming traffic.

Key Concept

Amazon ECS Rolling Updates Configuration
Question 59Question →

A developer is updating a serverless API backend running on AWS Lambda. The deployment must minimize user-facing impact by routing 10%10\% of the incoming traffic to the new Lambda version for a test window of 1010 minutes, while monitoring a CloudWatch alarm. If the alarm remains green, the remaining 90%90\% of traffic must shift to the new version immediately. If the alarm is triggered, the deployment must revert to the original version. Which AWS CodeDeploy configuration meets these requirements?

Show answer & explanation

Answer: CodeDeployDefault.LambdaCanary10Percent10Minutes

Answer

CodeDeployDefault.LambdaCanary10Percent10Minutes
The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes routes 10% of traffic to the new Lambda version, waits 10 minutes, and then immediately routes the remaining 90% if no alarms are triggered. This perfectly aligns with the requirement for a 10-minute test window at 10% traffic followed by an immediate shift of the remaining traffic.

Step-by-Step Solution

1
Analyze the traffic shifting requirement
The deployment requires routing 10% of traffic initially, waiting for a specific test duration, and then routing the remaining 90% immediately.
This behavior corresponds to a Canary deployment strategy rather than a Linear or All-At-Once deployment strategy.
2
Identify the required test window duration
The test window duration is specified as 10 minutes.
This requires a configuration that specifies a 10-minute wait time.
3
Select the matching pre-defined AWS CodeDeploy configuration
The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes meets both the 10% initial shift and 10-minute duration criteria.
CodeDeployDefault.LambdaCanary10Percent10Minutes routes 10% of traffic first and shifts the remaining 90% after 10 minutes if health checks pass.

Key Concept

AWS CodeDeploy Canary vs Linear configurations for serverless deployments
Estimated Time:1m 30s
Question 60Question →

A developer needs to deploy a new version of an application to an active AWS Elastic Beanstalk environment. The application must maintain 100% of its instance capacity to handle traffic during the deployment process. The deployment must be completed within the existing environment without creating a second, separate Elastic Beanstalk environment. Which two deployment strategies will meet these requirements? (Select two.)

Select all that apply

Show answer & explanation

Answer: Rolling with additional batch; Immutable

Answer

The correct strategies are 'Rolling with additional batch' and 'Immutable' because they both maintain full capacity throughout the deployment process and run entirely within the existing Elastic Beanstalk environment.
The correct strategies are the 'Rolling with additional batch' and 'Immutable' deployment strategies. The 'Rolling with additional batch' strategy launches a temporary batch of instances first, ensuring that the environment's capacity never drops below 100% during the rolling update. The 'Immutable' strategy launches a full set of new instances in a temporary Auto Scaling group, ensuring full capacity is maintained, and performs a clean switchover within the existing environment once health checks pass.

Step-by-Step Solution

1
Analyze the capacity requirement
The application must maintain 100% capacity. This rules out standard 'Rolling' (which reduces capacity by the batch size) and 'All at once' (which takes all instances offline).
Determining which deployment strategies preserve capacity.
2
Analyze the environment boundary constraint
The deployment must occur within the existing environment. This rules out 'Blue/Green (Environment Swap)' because it requires provisioning a new, separate Elastic Beanstalk environment.
Filtering out strategies that require multiple environments.
3
Identify matching strategies
'Rolling with additional batch' and 'Immutable' both run in the existing environment, provision temporary instances to maintain 100% capacity, and clean up the extra instances afterward.
Selecting the remaining compliant strategies.

Key Concept

Elastic Beanstalk deployment policies balance cost, deployment speed, capacity, and environmental overhead.
Estimated Time:1m 30s
PreviousPage 3 / 5Next
Deployment Strategies Practice Questions — AWS Certified Developer - Associate — Page 3 | Examkin