Examkin

Deployment

376 questions

All types376Multiple choice191Multiple select171Ordering14
Question 101Question →

A developer attempts to create a new AWS CloudFormation stack to deploy a web application. The stack creation fails because of an invalid AMI ID parameter, and the stack enters the ROLLBACK_COMPLETE status. The developer updates the template with the correct AMI ID.

Which action should the developer take to deploy the resources successfully?

Show answer & explanation

Answer: Delete the stack in the ROLLBACK_COMPLETE status, and then create a new stack using the updated template.

Answer

Delete the stack in the ROLLBACK_COMPLETE status, and then create a new stack using the updated template.
When a CloudFormation stack fails to create on its very first attempt, it rolls back all created resources and enters the ROLLBACK_COMPLETE status. Stacks in the ROLLBACK_COMPLETE status cannot be updated; they must be deleted before a new stack can be created with the same name and the corrected template.

Step-by-Step Solution

1
Identify the stack's current state and origin of failure.
The stack failed during initial creation and rolled back successfully to the ROLLBACK_COMPLETE state.
Before deciding on a recovery action, the developer must determine if the stack was previously successful or if it failed on its first creation attempt.
2
Evaluate the update capability of the stack in the current state.
AWS CloudFormation does not allow update operations on stacks that fail initial creation (ROLLBACK_COMPLETE). Updates are only allowed on successfully created stacks or stacks that fail during a subsequent update (UPDATE_ROLLBACK_COMPLETE).
This determines whether the existing stack can be updated or must be recreated.
3
Perform stack cleanup and recreation.
Delete the failed stack and create a new one using the corrected template.
This removes the failed stack metadata from the account and allows the deployment to start fresh with the corrected parameters.

Key Concept

CloudFormation Stack Lifecycle and Rollback States
Question 102Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline to automate the release of a containerized web application. The pipeline needs to retrieve source code, build a Docker image, deploy the application to Amazon ECS, and verify its status. Arrange the pipeline actions in the correct chronological sequence from start to finish.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence of pipeline actions is: retrieve source code using AWS CodeCommit, build the Docker image using AWS CodeBuild, deploy the application using AWS CodeDeploy, and run integration tests using AWS Lambda.
The correct order follows the standard pipeline design: first obtaining source code (Source), compiling and producing the artifact (Build), deploying the artifact to the target platform (Deploy), and finally validating the live deployment (Test/Invoke).

Step-by-Step Solution

1
Trigger the pipeline by obtaining source files.
Source code is packaged as a source artifact and stored in the CodePipeline artifact bucket.
Subsequent compilation and packaging require access to the raw source code.
2
Pass the source artifact to CodeBuild to construct the build output.
A Docker image is built, pushed to Amazon ECR, and a build artifact containing the task definition template is created.
Deployment actions require a built container image and configuration templates to proceed.
3
Pass the build artifact to CodeDeploy to update Amazon ECS.
The target ECS service initiates a rolling update or green/blue deployment using the new task definition.
The application must be deployed to the runtime environment before it can be verified or accessed by clients.
4
Invoke AWS Lambda to run post-deployment validation tests.
Integration tests run against the live endpoint, and CodePipeline receives a success or failure status signal.
Post-deployment checks verify that the live system behaves correctly after changes are applied.

Key Concept

AWS CodePipeline Stage and Action Sequencing
Question 103Question →

A developer is updating a critical, high-traffic API application deployed on AWS Elastic Beanstalk. The application must maintain full serving capacity during the deployment process. If any instance running the new version fails, the system must trigger an automatic rollback to the previous version with the absolute minimum time to restore the original state. The developer wants to avoid the overhead of managing a separate environment for Blue/Green deployments. Which deployment policy best satisfies these requirements?

Show answer & explanation

Answer: Immutable

Answer

The Immutable deployment policy satisfies these requirements by maintaining full capacity and allowing rapid, clean rollbacks.
The Immutable deployment policy creates a temporary Auto Scaling group and launches a new set of instances running the updated version alongside the original instances. This ensures 100% of the active serving capacity is maintained. If the new instances fail health checks, AWS Elastic Beanstalk immediately terminates the temporary Auto Scaling group. This results in an extremely fast rollback with zero impact on the original instances and requires no manual intervention or secondary environment management.

Step-by-Step Solution

1
Analyze the capacity requirement during deployment.
The application must maintain 100% serving capacity, which rules out 'Rolling' (which reduces capacity during deployment) and 'All at once' (which takes all instances out of service).
Eliminating deployment policies that reduce or eliminate service capacity.
2
Evaluate the rollback speed and complexity requirement.
The rollback must be automatic and extremely fast. 'Rolling with additional batch' requires updating instances in batches back to the original version, which takes time. 'Immutable' deployments can be rolled back immediately by terminating the temporary Auto Scaling group.
Determining the policy that provides the fastest recovery from a deployment failure.
3
Check the infrastructure overhead constraint.
The developer wants to avoid managing a separate environment, which is required for Blue/Green deployments but not for Immutable deployments.
Selecting the policy that performs the update within the existing environment without external management overhead.

Key Concept

AWS Elastic Beanstalk Immutable Deployment Policy
Estimated Time:1m 30s
Question 104Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline to deploy a serverless web application. The pipeline needs to pause automatically after the test stage and wait for a QA manager to review the test results before deploying to the production stage. Which of the following is the correct configuration to implement this manual approval step?

Show answer & explanation

Answer: Add a manual approval action to a stage in the pipeline before the production deployment action, and optionally configure an Amazon SNS topic for notifications.

Answer

Add a manual approval action to a stage in the pipeline before the production deployment action, and optionally configure an Amazon SNS topic for notifications.
The correct answer provides the standard, native method for introducing a human review step in AWS CodePipeline. The Manual Approval action type natively pauses the pipeline execution without consuming compute resources, and integrates with Amazon SNS to notify the reviewers.

Step-by-Step Solution

1
Identify the pipeline requirement for pausing execution for a human reviewer.
The requirement is a manual approval gate before production deployment.
Understanding the design requirements helps select the native AWS CodePipeline feature meant for this purpose.
2
Evaluate native CodePipeline features for approvals versus custom scripting.
CodePipeline provides a built-in 'Manual Approval' action type that halts transition natively.
Using native actions is more cost-effective, secure, and easier to maintain than custom polling mechanisms.
3
Verify correct configuration details for the Manual Approval action.
A manual approval action is added to a pipeline stage, with an optional SNS topic to notify the QA team.
Configuring SNS ensures the team is proactively alerted when an approval is pending.

Key Concept

AWS CodePipeline manual approval actions allow a pipeline execution to be paused at a specific stage until approval is received.
Question 105Question →

An organization has a deployment pipeline configured in AWS CodePipeline in Account A. The pipeline needs to deploy a containerized application to Amazon ECS in Account B. The developer creates a cross-account deployment IAM role in Account B. Which configuration must be implemented to allow the pipeline in Account A to assume this role and perform the deployment?

Show answer & explanation

Answer: Configure the trust policy of the IAM role in Account B to allow the CodePipeline service role in Account A to perform the sts:AssumeRole action, and configure the deployment action in Account A to use this role ARN.

Answer

Configure the trust policy of the IAM role in Account B to allow the CodePipeline service role in Account A to perform the sts:AssumeRole action, and configure the deployment action in Account A to use this role ARN.
For cross-account deployments, the deployment action in Account A's pipeline must assume an IAM role in Account B. This is achieved by adding a trust policy to the role in Account B that allows the pipeline's service role in Account A to perform the sts:AssumeRole action. The deployment action in the pipeline is then configured to use the ARN of the role in Account B.

Step-by-Step Solution

1
Identify the mechanism AWS CodePipeline uses to interact with resources in a different AWS account.
Cross-account access in AWS requires role assumption (sts:AssumeRole) rather than static credentials.
Using IAM roles avoids the security risks associated with managing static access keys.
2
Determine where to configure the trust relationship and how the role is assumed.
The trust policy must be configured on the target role in Account B to trust the pipeline's role in Account A.
Trust policies specify which external entities are allowed to assume the role.
3
Specify the role in the pipeline action configuration.
The deployment action in Account A's pipeline is updated to reference the target role's ARN in Account B.
This tells CodePipeline which role to assume when executing that specific action.

Key Concept

AWS CodePipeline cross-account resource deployment using IAM roles and trust policies.
Question 106Question →

A developer is configuring an AWS CloudFormation template to deploy an Amazon RDS DB instance. The database requires a master password that must be stored securely and rotated automatically every 30 days to comply with company security policies. Which configuration should the developer use to reference and manage the password?

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager, and reference it in the CloudFormation template using a secretsmanager dynamic reference.

Answer

Store the database password in AWS Secrets Manager, and reference it in the CloudFormation template using a secretsmanager dynamic reference.
The correct option stores the database password in AWS Secrets Manager, which natively supports automatic rotation, and references it using the secretsmanager dynamic reference in the template. This ensures that the secret is kept secure and is retrieved dynamically during deployment.

Step-by-Step Solution

1
Analyze the requirements: secure storage of a database password and support for automatic rotation.
Identify that AWS Secrets Manager is the appropriate service for credentials requiring automatic rotation, whereas Systems Manager Parameter Store does not support native rotation.
Choosing the correct AWS service ensures security compliance and automation features are utilized.
2
Determine how to reference the secret in the CloudFormation template.
Identify that the secretsmanager dynamic reference should be used.
Dynamic references retrieve sensitive information at deployment time without storing it in plaintext or parameters.

Key Concept

AWS CloudFormation Dynamic References and Secrets Management
Question 107Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. The pipeline has three stages:
1. Source: An Amazon S3 source action.
2. BuildAndTest: A stage containing three actions: a CodeBuild build action with `runOrder: 1`, a CodeBuild linting action with `runOrder: 1`, and a CodeBuild unit test action with `runOrder: 2` that requires the output artifact of the build action.
3. Deploy: An AWS Elastic Beanstalk deploy action.

When a new code revision is uploaded to the Amazon S3 source bucket, in what chronological order does AWS CodePipeline process the actions and transitions for a successful execution? Arrange the steps from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct chronological sequence is: first, the source action retrieves the revision and uploads it to the artifact store; second, the build and lint actions run concurrently; third, the build action completes and uploads its output artifact; fourth, the unit test action runs using the build output; and finally, the pipeline transitions to the Deploy stage.
AWS CodePipeline processes executions stage-by-stage. Within a stage, actions with the same runOrder value (such as the build and lint actions, both with runOrder 1) are executed in parallel. Actions with a higher runOrder (such as the unit test action with runOrder 2) will wait to execute until all actions with lower runOrder values have successfully completed. Furthermore, any output artifacts required as inputs by subsequent actions must be uploaded before those actions can start. Finally, the pipeline only transitions to the next stage (Deploy) once all actions in the current stage (BuildAndTest) have completed successfully.

Step-by-Step Solution

1
Analyze stage boundaries and action execution sequence.
Identify that the Source stage must complete first, creating the initial source artifact.
AWS CodePipeline is artifact-driven; subsequent stages cannot start without the input artifact from the source stage.
2
Determine execution order of parallel actions in the BuildAndTest stage.
Identify that the build action and linting action run concurrently.
Actions within the same stage that share the same runOrder value (in this case, 1) are executed in parallel.
3
Identify the transition criteria between runOrder levels.
Recognize that the unit test action (runOrder 2) must wait for all runOrder 1 actions to finish and the build output artifact to be uploaded.
CodePipeline executes actions sequentially based on runOrder. An action with runOrder 2 starts only after all runOrder 1 actions complete and its required input artifacts are available.
4
Determine when the stage transitions to the next stage.
Confirm that the Deploy stage starts after the unit test action completes.
A pipeline transition to a subsequent stage occurs only when all actions in the preceding stage have executed successfully.

Key Concept

AWS CodePipeline execution order, action runOrder concurrency, and stage transition logic.
Question 108Question →

A developer is managing a production infrastructure stack deployed via AWS CloudFormation. The stack contains an Amazon RDS DB instance and an Amazon ECS service. To prevent accidental replacement or deletion of the production database, the developer applies a stack policy to the stack. The policy contains a Deny statement for all update actions on the RDS DB instance resource, while allowing updates on all other resources.

The developer now needs to update the database engine version of the RDS DB instance. The developer attempts to perform a stack update with a template containing the new engine version, but the update fails due to the stack policy.

Which of the following is the correct method to update the database engine version while preserving the protective stack policy for future updates?

Show answer & explanation

Answer: Perform the stack update by using the AWS CLI update-stack command, passing a temporary stack policy that allows the update to the database resource in the --stack-policy-during-update-body parameter.

Answer

Perform the stack update by using the AWS CLI update-stack command, passing a temporary stack policy that allows the update to the database resource in the --stack-policy-during-update-body parameter.
The correct answer is to perform the stack update by using the AWS CLI update-stack command while passing a temporary stack policy that allows the update to the database resource in the --stack-policy-during-update-body parameter. When a stack policy is associated with a CloudFormation stack, all resources are protected by default unless explicitly allowed. To update a protected resource, the developer must temporarily override the stack policy during the update process. The --stack-policy-during-update-body parameter allows providing a temporary policy that permits the update. Once the update completes, CloudFormation automatically reverts to the original stack policy, maintaining the protection for subsequent updates.

Step-by-Step Solution

1
Define a temporary stack policy JSON document that explicitly allows updates (such as Update:Modify) to the target RDS DB instance resource.
A JSON stack policy document is created for temporary use during the update.
This policy is required to temporarily override the existing Deny rule on the database resource.
2
Run the aws cloudformation update-stack command with the --stack-policy-during-update-body flag, referencing the temporary stack policy.
CloudFormation executes the stack update and successfully applies the database engine version update.
Passing the temporary policy allows CloudFormation to bypass the permanent Deny rule for the duration of this single update transaction.
3
Verify that the update has completed and the stack status is UPDATE_COMPLETE.
The stack policy reverts to the original, permanent policy containing the Deny rule.
The temporary policy is only active during the update process, ensuring the database remains protected against accidental updates afterwards.

Key Concept

CloudFormation Stack Policies and temporary overrides during updates
Estimated Time:2m 30s
Question 109Question →

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 110Question →

A developer is configuring a simple release pipeline in AWS CodePipeline. The pipeline has a source stage, a build stage using AWS CodeBuild, and a deployment stage using AWS CodeDeploy. The developer needs to pass the compiled build output from the build stage to the deployment stage.

How should the developer configure the pipeline to transfer these files between the stages?

Show answer & explanation

Answer: Define an output artifact in the build stage action, and reference it as an input artifact in the deployment stage action.

Answer

Define an output artifact in the build stage action, and reference it as an input artifact in the deployment stage action.
AWS CodePipeline manages the flow of data between stages through input and output artifacts. When a stage like CodeBuild runs, it can package its output into a ZIP file and upload it to the pipeline's S3 artifact bucket as an output artifact. Subsequent stages, such as CodeDeploy, can then download this ZIP file by referencing it as an input artifact.

Step-by-Step Solution

1
Identify the standard mechanism in AWS CodePipeline for transferring files (like build outputs) between stages.
CodePipeline uses artifacts (input and output) backed by an Amazon S3 bucket to share files across pipeline actions.
This maintains statelessness and isolation between stage execution environments.
2
Configure the source or build stage to produce an output artifact.
The build stage (CodeBuild) writes the compiled output files to a zip file in the pipeline S3 bucket, registered as an output artifact.
This makes the build artifacts available to downstream stages.
3
Configure the deployment stage to consume the artifact.
The deployment stage (CodeDeploy) specifies the output artifact from the build stage as its input artifact.
This allows CodeDeploy to download the correct files from the pipeline S3 bucket to execute the deployment.

Key Concept

AWS CodePipeline uses input and output artifacts to share files between pipeline actions and stages.
Question 111Question →

A developer is deploying an update to a Python application hosted on AWS Elastic Beanstalk using the Amazon Linux 2023 platform. The deployment requires running a database migration script that is packaged inside the application source code. This script must run after the application source archive is extracted to the staging directory, but before the application version is deployed and the web server is restarted. Which approach should the developer use to run the script at the correct stage?

Show answer & explanation

Answer: Place the migration script in the .platform/hooks/predeploy/ directory of the application source bundle.

Answer

Place the migration script in the .platform/hooks/predeploy/ directory of the application source bundle.
The correct answer is to place the script in the .platform/hooks/predeploy/ directory. In modern Elastic Beanstalk platforms (Amazon Linux 2 and Amazon Linux 2023), developers can run custom scripts at specific lifecycle events using platform hooks. Scripts placed in the .platform/hooks/predeploy/ folder are executed after the application archive is extracted to the staging folder but before the application version is deployed and the web server is restarted. This is the correct phase for running database migrations or setting up environment-specific configuration files.

Step-by-Step Solution

1
Identify the target platform environment and configuration requirements.
The application runs on Amazon Linux 2023, which supports platform hooks and .ebextensions.
Platform hooks provide a structured way to run scripts at specific lifecycle events on modern Elastic Beanstalk platforms.
2
Evaluate the execution timing of different hooks.
The predeploy platform hook runs after the application source archive is extracted but before the application is deployed.
This matches the requirement to run the migration script on the extracted source files before the new version becomes active.
3
Package the script in the correct directory.
Creating the directory .platform/hooks/predeploy/ and putting the executable script in it ensures execution at the correct stage.
Elastic Beanstalk automatically executes any scripts located in this specific platform directory during deployment.

Key Concept

AWS Elastic Beanstalk Platform Hooks
Estimated Time:1m 30s
Question 112Question →

A developer is managing an AWS CloudFormation stack. The developer needs to update the stack template to add a new Amazon DynamoDB table, store a database password that requires automatic rotation, and store a non-sensitive configuration parameter. Which of the following actions should the developer take to accomplish this? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager.; Store the non-sensitive configuration parameter in AWS Systems Manager Parameter Store.

Answer

The developer should store the database password in AWS Secrets Manager and store the non-sensitive configuration parameter in Systems Manager Parameter Store.
The correct options are storing the database password in AWS Secrets Manager and storing the non-sensitive configuration parameter in AWS Systems Manager Parameter Store. Secrets Manager provides built-in rotation capabilities, which meets the security requirement, while Parameter Store is a cost-effective solution for non-sensitive data.

Step-by-Step Solution

1
Evaluate the sensitivity and lifecycle requirements of the database password.
The password is a sensitive credential requiring automatic rotation, which points to AWS Secrets Manager.
AWS Secrets Manager provides built-in rotation integration for databases.
2
Evaluate the sensitivity of the configuration parameter.
The parameter is non-sensitive configuration data, which points to AWS Systems Manager Parameter Store.
Parameter Store is more cost-effective for storing non-sensitive configuration parameters.

Key Concept

Distinguishing between AWS Secrets Manager and Systems Manager Parameter Store for storing CloudFormation parameters.
Question 113Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline in Account A (111122223333111122223333) to automate deployments to Account B (444455556666444455556666) using AWS CloudFormation. The pipeline fails during the Deploy stage with an access denied error when attempting to assume the deployment IAM role in Account B. Additionally, the CloudFormation template must retrieve a database password that requires automatic rotation every 3030 days. Which combination of actions should the developer take to resolve the deployment failure and meet the security requirements?

Show answer & explanation

Answer: Update the trust policy of the deployment IAM role in Account B to allow the CodePipeline service role of Account A to perform the sts:AssumeRole action. Store the database password in AWS Secrets Manager and configure automatic rotation.

Answer

Update the trust policy of the deployment IAM role in Account B to allow the CodePipeline service role of Account A to perform the sts:AssumeRole action. Store the database password in AWS Secrets Manager and configure automatic rotation.
The correct action is to update the trust policy of the target IAM role in Account B to allow Account A's CodePipeline service role to perform the sts:AssumeRole action, and to store the credentials in AWS Secrets Manager which natively handles automatic rotation. This properly satisfies both cross-account trust requirements and credential lifecycle security rules.

Step-by-Step Solution

1
Configure cross-account IAM role assumption.
The Deploy action in Account A's CodePipeline can now assume the IAM role in Account B to create or update the CloudFormation stack.
To deploy resources across AWS accounts, the CodePipeline service role in the source account must be granted permission to assume a role in the destination account. The destination account's role must trust the source role via its trust policy.
2
Select the correct credential storage service.
AWS Secrets Manager is selected to store the database password.
AWS Secrets Manager provides native, out-of-the-box support for database credential rotation, whereas Systems Manager Parameter Store does not.

Key Concept

Cross-account pipeline deployments and secret rotation management.
Question 114Question →

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 115Question →

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 116Question →

A developer is configuring a standard release pipeline in AWS CodePipeline to automate deployment. The pipeline must pull source code from an AWS CodeCommit repository, run tests and compile the code using AWS CodeBuild, require a manual sign-off from the quality assurance team, and finally deploy the application to AWS Elastic Beanstalk.

Arrange the actions in the correct sequence of execution from first to last.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of actions in the pipeline is: Source action (AWS CodeCommit), Build action (AWS CodeBuild), Manual approval action, and Deploy action (AWS Elastic Beanstalk).
AWS CodePipeline processes stages sequentially. The pipeline must first fetch the source code, compile and test it in the build phase, pause for manual verification, and finally deploy the verified package.

Step-by-Step Solution

1
Retrieve the source code from AWS CodeCommit.
The latest revision of the source code is retrieved and package artifacts are created.
Subsequent stages require the source code to perform builds and deployments.
2
Trigger the AWS CodeBuild environment to compile the application and run unit tests.
The application code is verified and a deployment package is generated.
Building the application generates the necessary artifacts that need to be reviewed and deployed.
3
Halt the pipeline for a Manual Approval action.
The pipeline execution pauses, and a notification is sent to the QA team for review.
This guarantees that the built artifacts are verified and approved before they reach the production environment.
4
Deploy the application using the AWS Elastic Beanstalk deployment action.
The verified application version is deployed to the Elastic Beanstalk environment.
Deploying is the final step in the pipeline after the application has been built and approved.

Key Concept

AWS CodePipeline action execution order
Question 117Question →

A developer is preparing a Java application package for deployment to an AWS Elastic Beanstalk environment. The application requires a custom system-level utility, `htop`, to be installed on the underlying Amazon EC2 instances. Additionally, the application requires an environment variable named `DB_HOST` to be accessible at runtime. Which two actions should the developer take to satisfy these requirements?

Select all that apply

Show answer & explanation

Answer: Create a configuration file ending with `.config` inside a directory named `.ebextensions` at the root of the application source bundle, and use the `packages` section to define the `htop` installation.; Configure the `DB_HOST` environment variable in the Environment Properties section of the Elastic Beanstalk environment configuration.

Answer

Create a configuration file ending with `.config` in a folder named `.ebextensions` at the root of the application source bundle to install the package, and configure the environment variable in the Environment Properties section under the Elastic Beanstalk environment configuration.
The correct solution involves leveraging `.ebextensions` at the root of the source bundle to configure package dependencies and using the Environment Properties configuration setting to handle variable values, satisfying both host-level and application-level requirements.

Step-by-Step Solution

1
Determine how to run custom package installations on the host instance during Elastic Beanstalk deployment.
Identify that the `.ebextensions` directory must be located at the root of the source bundle and contain a `.config` file with a `packages` block.
This directory is read by the Elastic Beanstalk platform agent to apply customizations before the application starts.
2
Determine how to provide configuration settings to the application environment at runtime.
Identify that Elastic Beanstalk supports Environment Properties for injecting variables into the execution context.
Setting these properties ensures they are parsed by the OS and available to the Java application code via system environment checks.

Key Concept

AWS Elastic Beanstalk instance customization via `.ebextensions` configuration files and runtime environment variable configuration.
Question 118Question →

A developer is configuring a deployment pipeline in AWS CodePipeline to deploy a serverless application across two AWS accounts. The pipeline resides in Account A, and the application must be deployed to Account B using an AWS CloudFormation action in the deploy stage. The pipeline execution fails at the deploy stage with an access denied error when attempting to assume the deployment IAM role created in Account B.

How should the developer configure the IAM policies to successfully allow the pipeline in Account A to assume the deployment role in Account B?

Show answer & explanation

Answer: Configure the trust policy of the deployment role in Account B to allow the sts:AssumeRole action from the CodePipeline service role in Account A, and grant the CodePipeline service role in Account A permission to call sts:AssumeRole on the deployment role in Account B.

Answer

Configure the trust policy of the deployment role in Account B to allow the sts:AssumeRole action from the CodePipeline service role in Account A, and grant the CodePipeline service role in Account A permission to call sts:AssumeRole on the deployment role in Account B.
The correct option correctly establishes two-way trust for cross-account role assumption. The trust policy of the target role in Account B must trust the CodePipeline service role in Account A, and the CodePipeline service role must have an identity-based policy allowing it to assume the target role in Account B.

Step-by-Step Solution

1
Configure the trust policy in the target account (Account B)
The deployment IAM role in Account B is updated to list the AWS CodePipeline service role ARN from Account A as a trusted principal that can perform sts:AssumeRole.
Establishing trust in the target account's role is mandatory for any cross-account access to succeed.
2
Configure the permissions policy in the source account (Account A)
An identity-based policy is attached to the CodePipeline service role in Account A allowing the sts:AssumeRole action on Account B's deployment role ARN.
The source principal must have explicit permission to assume the external role.
3
Reference the target role in the pipeline configuration
The pipeline deploy stage action configuration is updated with the roleArn parameter pointing to the target deployment role in Account B.
This instructs CodePipeline to assume the cross-account role when executing the CloudFormation action.

Key Concept

Cross-account role assumption in AWS CodePipeline
Question 119Question →

A developer is configuring an AWS CodeBuild project that must run within a private subnet of a VPC to perform integration tests against a private Amazon RDS PostgreSQL database. The build process needs to retrieve an encrypted database password from AWS Systems Manager Parameter Store and pull a base image from a private Amazon ECR repository located in a shared-services AWS account. During the build execution, the build fails in the early phases with connection timeouts and permission errors. Which combination of actions should the developer take to resolve these issues? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Ensure the CodeBuild project is associated with private subnets that route outbound traffic through a NAT Gateway, or configure Interface VPC endpoints within the VPC for Systems Manager and Amazon ECR.; Grant the CodeBuild service role the ssm:GetParameters and kms:Decrypt permissions for the parameter and its custom KMS key, and retrieve the password using the env: parameter-store block in the buildspec.

Answer

Configure private subnets with a NAT Gateway or VPC endpoints to establish connectivity, and retrieve the SecureString parameter via the env: parameter-store block while granting the service role both ssm:GetParameters and kms:Decrypt permissions.
For CodeBuild to communicate with AWS services when running inside a VPC, it requires route paths either via a NAT Gateway inside private subnets or Interface VPC endpoints. For SecureString parameters, the parameters must be retrieved using the env: parameter-store block, and the service role must be granted ssm:GetParameters and kms:Decrypt permissions.

Step-by-Step Solution

1
Diagnose the network timeout error during the early build phases.
Identify that CodeBuild containers launched inside a VPC do not have route paths to external AWS service public endpoints (like Systems Manager or Amazon ECR) by default.
Establishing outbound paths via a NAT Gateway or using local Interface VPC Endpoints inside the VPC is required for VPC-enabled CodeBuild projects to access external resources.
2
Address the Systems Manager Parameter Store access configuration.
Map the parameter inside the env: parameter-store section of the buildspec file rather than env: variables.
Only env: parameter-store triggers CodeBuild to retrieve and decrypt SecureString values from Systems Manager Parameter Store during the build lifecycle.
3
Grant the necessary IAM permissions to the CodeBuild service role.
Ensure the role has ssm:GetParameters and kms:Decrypt permissions for the custom KMS customer managed key (CMK) used to encrypt the password.
AWS-managed default KMS keys cannot be shared across accounts if cross-account access is needed, and accessing custom keys requires explicit ssm and kms permissions.

Key Concept

Configuring AWS CodeBuild VPC connectivity, ECR access, and IAM service role permissions to decrypt SecureString parameters in a buildspec.
Estimated Time:3m 0s
Question 120Question →

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
PreviousPage 6 / 19Next
Deployment Practice Questions — AWS Certified Developer - Associate — Page 6 | Examkin