Examkin

AWS Elastic Beanstalk

30 questions

All types30Multiple choice15Multiple select15
Question 1Question →

A developer is preparing a source bundle to deploy a web application to AWS Elastic Beanstalk. The developer wants to include configuration files that install additional software packages and define system environment variables. In which directory must these configuration files be placed to ensure Elastic Beanstalk processes them during deployment?

Show answer & explanation

Answer: A folder named .ebextensions at the root level of the application source bundle

Answer

A folder named .ebextensions at the root level of the application source bundle
The correct answer specifies placing files in a directory named .ebextensions at the root level of the application source bundle. AWS Elastic Beanstalk automatically looks for configuration files with a .config extension inside this directory during deployment to customize the environment's resource configuration.

Step-by-Step Solution

1
Identify the mechanism Elastic Beanstalk uses for custom configuration files.
Elastic Beanstalk relies on YAML or JSON configuration files (ending in .config) to configure the environment.
This allows developers to define packages, services, files, and commands to run on the EC2 instances.
2
Determine the required naming convention and location for these files.
The configuration files must be stored within a directory named .ebextensions, which must be located at the root of the application source bundle.
Elastic Beanstalk only parses configuration files that are situated in this specific root folder.

Key Concept

AWS Elastic Beanstalk Custom Configurations (.ebextensions)
Question 2Question →

An organization is deploying a Node.js web application to a single-instance environment on AWS Elastic Beanstalk. The application must store local application log files in a custom directory on the host Amazon EC2 instance. Additionally, the application needs to retrieve database credentials dynamically at runtime from AWS Systems Manager Parameter Store.

Which two actions must a developer take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Create a directory named `.ebextensions` at the root of the application source bundle, and place a configuration file inside it to create the custom log directory.; Attach an IAM policy with `ssm:GetParameters` permissions to the IAM role associated with the Elastic Beanstalk EC2 instance profile, and retrieve the parameters using the application code.

Answer

Create a directory named `.ebextensions` at the root of the application source bundle to place the configuration file, and attach an IAM policy with `ssm:GetParameters` permissions to the IAM role associated with the EC2 instance profile.
The correct options are creating the `.ebextensions` directory at the root to contain the configuration file, and granting Systems Manager permissions to the EC2 instance profile role. The `.ebextensions` directory is the standard location for environment customization files, and the EC2 instance profile role provides permissions to the application code running on the EC2 instances.

Step-by-Step Solution

1
Configure instance initialization using Beanstalk configuration files.
Create a directory named `.ebextensions` at the root of the source bundle and place configuration files (e.g., `.config`) inside it.
Elastic Beanstalk platform engine detects and processes configuration files only when they are placed in a folder named `.ebextensions` with a leading dot at the root level of the application zip archive.
2
Establish secure permissions for Parameter Store access.
Add `ssm:GetParameters` permissions to the EC2 instance profile role used by the environment.
Since the application code running on the EC2 instances needs to call the Systems Manager API, the instance profile role provides the necessary temporary credentials via the EC2 Instance Metadata Service.

Key Concept

AWS Elastic Beanstalk environment customization and application permissions using instance profiles.
Question 3Question →

A developer is packaging a Python application for deployment to AWS Elastic Beanstalk. The application requires a custom Unix user to be created on the host Amazon EC2 instances during environment provisioning. To automate this, the developer creates a configuration file named `01_user.config` containing the user definition. However, after deploying the application source bundle to the Elastic Beanstalk environment, the user is not created and the configuration is ignored.

The layout of the deployed application zip file is as follows:

/
├── application.py
├── requirements.txt
└── config/
└── .ebextensions/
└── 01_user.config

Which action must the developer take to ensure Elastic Beanstalk applies the configuration?

Show answer & explanation

Answer: Move the `.ebextensions` directory to the root of the application source bundle.

Answer

Move the `.ebextensions` directory to the root of the application source bundle.
For AWS Elastic Beanstalk to apply customization settings defined in `.config` files, the `.ebextensions` directory must be at the root of the application source bundle. Placing it inside a folder such as `config/` will cause Elastic Beanstalk to ignore the configurations.

Step-by-Step Solution

1
Analyze the zip file structure of the deployed application.
The `.ebextensions` directory is located inside a `config/` subdirectory.
AWS Elastic Beanstalk scans the root directory of the application source bundle for a folder specifically named `.ebextensions`.
2
Determine the correct directory path and name requirements for configuration files.
The folder must be named `.ebextensions` (with a leading dot) and must be at the root level.
If the folder is placed in a subdirectory or does not have the leading dot, the Elastic Beanstalk platform engine will skip parsing any `.config` files inside it.
3
Move the directory to the root level and deploy the application.
The configuration file will be parsed and the custom user will be successfully created.
Placing the folder at the root matches the expected path pattern that the Elastic Beanstalk host agent searches for during provisioning.

Key Concept

AWS Elastic Beanstalk requires configuration files to be placed in a directory named `.ebextensions` at the root of the application source bundle.
Estimated Time:1m 30s
Question 4Question →

A developer is packaging a web application to be deployed on AWS Elastic Beanstalk. The application requires custom environment configurations and package installations during deployment. To achieve this, which directory at the root of the application source bundle must contain the custom configuration files?

Show answer & explanation

Answer: .ebextensions

Answer

The directory named '.ebextensions' must be placed at the root of the application source bundle to store Elastic Beanstalk configuration files.
The correct option is '.ebextensions'. AWS Elastic Beanstalk searches for configuration files (which must end in '.config') in a directory named '.ebextensions' located at the root of the application source bundle. This allows developers to configure environment options, install packages, and create files on the EC2 instances.

Step-by-Step Solution

1
Identify the purpose of Elastic Beanstalk configuration files.
The files (ending in '.config') are used to customize the software, packages, and environment properties of the EC2 instances in the Elastic Beanstalk environment.
This is a standard way to manage configuration as code in Elastic Beanstalk.
2
Determine the required directory name and location in the application zip/source bundle.
The directory must be named '.ebextensions' (with a leading dot) and positioned at the root level of the source bundle.
Elastic Beanstalk agent runs scripts to parse this specific directory during deployment; any other location or misspelled directory name is ignored.

Key Concept

AWS Elastic Beanstalk configuration files must be stored in the '.ebextensions' folder at the root of the application source bundle.
Question 5Question →

A developer needs to configure a deployment strategy for an application running on AWS Elastic Beanstalk. The application must maintain 100%100\% of its capacity to handle traffic during the deployment process. Due to budget constraints, the developer must minimize the cost of temporary resources launched during the deployment, ruling out a complete duplicate environment or a double-capacity deployment. Which deployment policy should the developer configure?

Show answer & explanation

Answer: Rolling with additional batch

Answer

Rolling with additional batch
The Rolling with additional batch deployment policy launches a new batch of instances with the updated application version first. Once the new batch passes health checks, Elastic Beanstalk updates a batch of the old instances. This process continues until all instances are updated. Because the additional batch is created first, the environment's capacity never drops below 100%100\%, and the additional cost is limited only to the size of the temporary batch rather than a full duplicate environment.

Step-by-Step Solution

1
Analyze capacity requirements.
The application must maintain 100%100\% capacity during deployment, which rules out policies that reduce instance count or take instances offline (such as All at once or standard Rolling).
Ensuring capacity requirements are prioritized first helps filter out policies that cause downtime or reduced capacity.
2
Analyze budget constraints and temporary resource usage.
The requirement to minimize the cost of temporary resources rules out the Immutable policy, which doubles the instance footprint by creating a full replica Auto Scaling group.
Evaluating cost constraints separates policies that maintain capacity using small incremental batches from those using full environment duplication.
3
Select the optimal Elastic Beanstalk deployment policy.
Rolling with additional batch is selected because it keeps full capacity by launching a small extra batch of instances first, avoiding the high cost of duplicating the entire environment.
This strategy satisfies both the 100%100\% capacity constraint and the cost-efficiency constraint.

Key Concept

AWS Elastic Beanstalk Deployment Policies
Estimated Time:1m 30s
Question 6Question →

A company runs a high-traffic web application on AWS Elastic Beanstalk. The development team has created a new version of the application that requires custom environment properties and packages a shell script that must run on the underlying EC2 instances during deployment. The deployment must satisfy the following requirements:
- The application must maintain 100% of its serving capacity during the deployment to prevent latency spikes.
- In the event of a deployment failure (such as a health check timeout on the new version), the environment must automatically revert to the previous version with zero downtime and no manual intervention.
- The custom shell script must execute successfully during the deployment before the new version starts receiving production traffic.

Which deployment strategy and configuration action should the developer use to meet these requirements?

Show answer & explanation

Answer: Configure the deployment policy to Immutable. Place the configuration file for the shell script inside a directory named .ebextensions at the root of the application source bundle.

Answer

Configure the deployment policy to Immutable and place the configuration file inside a directory named .ebextensions at the root of the application source bundle.
The Immutable deployment policy fulfills the requirement of maintaining 100% capacity by launching a temporary Auto Scaling group alongside the original one. It also satisfies the automatic rollback requirement because if the health checks fail on the new instances, Elastic Beanstalk automatically deletes the temporary Auto Scaling group, leaving the original instances untouched. Additionally, placing the configuration files in a directory named exactly .ebextensions at the root of the application source bundle ensures that Elastic Beanstalk parses and executes the custom scripts.

Step-by-Step Solution

1
Analyze the capacity requirement during deployment.
The requirement is to maintain 100% serving capacity. This rules out 'All at once' and standard 'Rolling' policies (which take instances out of service), leaving 'Rolling with additional batch' and 'Immutable' as candidates.
Maintaining capacity avoids performance degradation during updates.
2
Analyze the rollback requirement.
The environment must automatically and immediately revert on failure with no manual intervention. 'Rolling with additional batch' does not support automated rollback (it halts and requires a manual rollback deployment). Only 'Immutable' automatically terminates the new temporary Auto Scaling group on failure, achieving instant rollback with zero impact on the active group.
An Immutable deployment isolates the new version in a separate Auto Scaling group during validation, allowing safe and automatic cleanup if it fails.
3
Determine the correct folder path for Elastic Beanstalk configuration files.
Elastic Beanstalk configuration files must reside in the .ebextensions/ folder at the root of the application source bundle. A directory named ebextensions (without the leading dot) will be ignored by Elastic Beanstalk.
Elastic Beanstalk's platform agent specifically looks for the hidden .ebextensions directory to execute configuration scripts.

Key Concept

AWS Elastic Beanstalk deployment policies and .ebextensions configuration
Question 7Question →

A developer is migrating a Node.js web application to an AWS Elastic Beanstalk environment running on an Amazon Linux 2023 platform. The application requires two specific configurations:
1. It must execute a custom shell script named `configure-auth.sh` to download and configure an SSL certificate *after* the application files are extracted and staged on the host, but *before* the application process is launched.
2. It must configure a system environment variable named `DB_MAX_CONN` with a value of `100` across all instances.

Which two actions should the developer take to successfully deploy these customizations? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Place the script `configure-auth.sh` in the `.platform/hooks/predeploy/` directory of the application source bundle and ensure it has execute permissions.; Create a configuration file named `db.config` containing the option settings for the `aws:elasticbeanstalk:application:environment` namespace and place it in the `.ebextensions/` directory at the root of the source bundle.

Answer

The developer must place the script in the `.platform/hooks/predeploy/` directory with execution permissions, and place the environment variable configuration file in the `.ebextensions/` directory.
The correct options state that the hook script must be located in `.platform/hooks/predeploy/` with execution permissions, and the configuration file for the environment variable must be located in `.ebextensions/` at the root of the source bundle. Under Amazon Linux 2 and Amazon Linux 2023 platforms, Elastic Beanstalk uses `.platform/hooks/predeploy/` to run custom scripts after the source bundle has been extracted and staged but before the application process is executed. The `.ebextensions/` directory containing configuration files is the standard mechanism to set environment variables through the `aws:elasticbeanstalk:application:environment` namespace.

Step-by-Step Solution

1
Determine the platform hook structure for Amazon Linux 2023.
Identify that script files must be placed in the `.platform/hooks/` subdirectories to execute during lifecycle stages (specifically `predeploy` for actions after staging but before running).
Elastic Beanstalk's Amazon Linux 2 and Amazon Linux 2023 platforms use `.platform/hooks/` instead of older platform hooks methods.
2
Ensure script execution permission.
Add execution permission (`chmod +x`) to `configure-auth.sh` before archiving the bundle.
Scripts in platform hooks must be executable to run successfully.
3
Determine environment variable configuration location.
Identify that the standard configuration directory is `.ebextensions/` (with a leading dot).
Elastic Beanstalk reads configuration files matching `*.config` in the `.ebextensions/` directory at the root of the source bundle.
4
Specify namespace and variable value.
Use `aws:elasticbeanstalk:application:environment` configuration namespace to set `DB_MAX_CONN` to `100`.
This is the correct namespace to inject system environment variables into the application runtime.

Key Concept

AWS Elastic Beanstalk Amazon Linux 2/2023 Platform Customization via .platform and .ebextensions
Estimated Time:3m 0s
Question 8Question →

A developer needs to deploy a new version of a high-traffic web application to an AWS Elastic Beanstalk environment. The deployment must satisfy the following requirements:
- The environment must maintain 100%100\% of its current instance capacity during the deployment to prevent performance degradation.
- In the event of a deployment failure, the rollback process must be quick and have zero impact on the active, healthy instances currently serving production traffic.
- Custom environment properties and configuration files must be applied automatically as part of the application source bundle.

Which deployment strategy and configuration approach should the developer use?

Show answer & explanation

Answer: Use the Immutable deployment policy, and place the configuration files in a .ebextensions folder at the root of the source bundle.

Answer

Use the Immutable deployment policy, and place the configuration files in a .ebextensions folder at the root of the source bundle.
The Immutable deployment policy ensures that a completely new set of instances (in a temporary Auto Scaling group) is created to deploy the new version alongside the existing instances. This maintains 100%100\% capacity of the original environment during the deployment. If the deployment fails, Elastic Beanstalk terminates the new Auto Scaling group, causing zero impact to the original, running instances and allowing an instant rollback. Custom configuration files must be located in a folder named .ebextensions (with a leading dot) at the root of the application source bundle to be processed by Elastic Beanstalk.

Step-by-Step Solution

1
Analyze the capacity requirement during deployment
The requirement specifies that the application must maintain 100%100\% capacity during deployment. This rules out the Rolling policy, which reduces instance capacity as it updates batches.
To maintain 100%100\% capacity, the deployment policy must provision additional instances before taking existing ones out of service or updating them.
2
Analyze the rollback and failure recovery requirement
The rollback must be instant and have zero impact on the existing running instances. Rolling with additional batch requires a rolling rollback to redeploy the previous version, whereas Immutable creates a parallel Auto Scaling group that can be instantly terminated upon failure without touching the original instances.
Immutable deployment offers the cleanest and fastest rollback mechanism because the original production environment remains untouched until the new version passes health checks.
3
Verify the configuration file directory naming convention
Elastic Beanstalk requires configuration files to be placed in a folder named .ebextensions (with a leading dot) at the root of the source bundle. Misnaming it as ebextensions causes the configuration to be ignored.
Elastic Beanstalk specifically scans for the .ebextensions directory at the root level of the application zip archive during provisioning.

Key Concept

AWS Elastic Beanstalk Deployment Policies and Configuration Files
Question 9Question →

A developer needs to configure an update strategy for an application running on AWS Elastic Beanstalk. The application must maintain 100%100\% of its provisioned capacity throughout the deployment process to avoid performance degradation. Which two Elastic Beanstalk deployment policies will ensure that capacity is never reduced during the update? (Select TWO)

Select all that apply

Show answer & explanation

Answer: Immutable; Rolling with additional batch

Answer

The Immutable and Rolling with additional batch deployment policies both ensure that capacity is never reduced during the update.
The Immutable and Rolling with additional batch deployment policies both maintain 100%100\% of the environment's provisioned capacity during an update. Immutable launches a temporary Auto Scaling group to deploy the new version, while Rolling with additional batch launches an extra batch of instances before updating existing ones. In both cases, the existing healthy capacity is never reduced.

Step-by-Step Solution

1
Analyze the capacity requirement during deployment
The application requires 100%100\% of its provisioned capacity to be active at all times.
To prevent performance degradation during the update process.
2
Evaluate in-environment Elastic Beanstalk deployment policies
Immutable deployment deploys to a new temporary Auto Scaling group before switching, and Rolling with additional batch launches an extra batch of instances before updating existing ones. Both keep existing instances fully operational.
To select the strategies that do not take existing capacity offline without replacement.

Key Concept

AWS Elastic Beanstalk deployment policies and their impact on environment capacity.
Question 10Question →

A development team is preparing to update an application hosted on AWS Elastic Beanstalk. The new version requires the installation of an OS-level utility (xml2) on the underlying EC2 instances. Additionally, to guarantee clean system states, the team requires that the update is only applied to newly provisioned instances rather than modifying the existing ones in-place. The update must maintain the application's full serving capacity throughout the deployment process, but the team wants to avoid performing a manual DNS redirection or CNAME swap. Which two configuration steps should the developer perform to meet these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Create a configuration file inside a directory named .ebextensions at the root level of the application source bundle to install the package.; Configure the deployment policy for the environment to use Immutable updates.

Answer

To meet the requirements, the developer must create a configuration file inside a directory named .ebextensions at the root level of the application source bundle, and configure the environment's deployment policy to use Immutable updates.
To satisfy the requirement of installing custom OS-level packages, the configuration file must be placed inside the .ebextensions directory at the root level of the source bundle. To satisfy the deployment requirements (clean instances, full serving capacity, and no manual CNAME swap), the Immutable deployment policy must be used. This policy provisions a secondary Auto Scaling group with the new version, merges it with the existing group once healthy, and then terminates all the old instances, ensuring no configuration residue exists.

Step-by-Step Solution

1
Determine the correct directory structure for Elastic Beanstalk customization files.
Identify that custom packages must be defined under a .ebextensions folder at the root level of the application source bundle.
Elastic Beanstalk ignores configuration folders that lack the leading dot, such as ebextensions.
2
Evaluate the deployment strategies against the zero-downtime, no CNAME-swap, and clean-instance constraints.
Identify that Immutable deployment provisions a temporary Auto Scaling group with new instances, validates health, and then merges them, terminating the old instances.
Rolling and Rolling with additional batch strategies update existing instances in-place, which leaves configuration residue. A CNAME swap requires manual environment creation and DNS redirection, which is forbidden by the scenario constraints.

Key Concept

AWS Elastic Beanstalk configuration files (.ebextensions) and environment deployment policies.
Question 11Question →

A developer is preparing a Node.js web application for deployment on AWS Elastic Beanstalk. The application requires a public environment variable named `APP_COLOR` to be accessible across all instances. Additionally, the application must retrieve a highly sensitive database password that is rotated on a weekly basis. Which two actions should the developer take to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Configure the `APP_COLOR` variable under the Environment properties section of the Elastic Beanstalk environment configuration.; Store the database password in AWS Secrets Manager and retrieve it programmatically using the AWS SDK during application startup.

Answer

Configure the public variable in the Elastic Beanstalk Environment properties, and store the sensitive database password in AWS Secrets Manager, retrieving it programmatically at runtime.
The correct options are to configure the environment properties directly in Elastic Beanstalk for non-sensitive values and to retrieve sensitive credentials programmatically from AWS Secrets Manager. Environment properties in Elastic Beanstalk are ideal for simple public configuration variables such as application color, as they are passed directly to the environment. AWS Secrets Manager is the designated service for storing sensitive secrets that require automatic rotation, such as database passwords, and can be queried securely via the AWS SDK at runtime.

Step-by-Step Solution

1
Identify the storage method for non-sensitive public configuration
Environment properties are suitable for public values like APP_COLOR.
Environment properties allow configuration without hardcoding or using external secret stores.
2
Identify the storage method for sensitive credentials with automatic rotation requirements
AWS Secrets Manager is selected because it manages secrets and supports automatic weekly rotation.
Systems Manager Parameter Store does not support native automatic rotation for secrets.
3
Validate directory structure and configuration file placement constraints in Elastic Beanstalk
The configuration folder must be named .ebextensions with a leading dot, not ebextensions.
Failing to use the leading dot causes Elastic Beanstalk to ignore configuration files.

Key Concept

Configuring AWS Elastic Beanstalk applications with environment properties and managing secrets securely.
Question 12Question →

A developer needs to configure autoscaling thresholds and environment properties for a web application deployed via AWS Elastic Beanstalk. To ensure consistency across development, staging, and production environments, the developer wants these configurations to be version-controlled in the Git repository alongside the application source code. Which of the following approaches should the developer use to satisfy these requirements?

Show answer & explanation

Answer: Place a YAML configuration file ending with a `.config` extension inside a folder named `.ebextensions` at the root of the application source bundle.

Answer

Place a YAML configuration file ending with a `.config` extension inside a folder named `.ebextensions` at the root of the application source bundle.
Placing configuration files with a `.config` extension inside the `.ebextensions` folder at the root of the application source bundle is the standard way to package environment configurations with the application code. This ensures they are version-controlled in the repository and automatically applied to the Elastic Beanstalk environment during deployment.

Step-by-Step Solution

1
Determine the mechanism for packaging configurations with Elastic Beanstalk source code.
Identify that Elastic Beanstalk uses configuration files inside the source bundle to customize the environment.
This ensures the configuration is tracked in Git alongside the code.
2
Identify the correct directory name and file extension required by Elastic Beanstalk.
The directory must be named `.ebextensions` (with a leading dot) at the root of the project, and files must end with `.config`.
Elastic Beanstalk specifically scans this folder path and suffix during application deployment.

Key Concept

AWS Elastic Beanstalk Configuration Files (.ebextensions)
Question 13Question →

A developer is packaging a Node.js web application for deployment to an AWS Elastic Beanstalk environment running on an Amazon Linux 20232023 platform. The developer needs to run a custom shell script that modifies application files after the application source bundle has been unpacked, but before the application version is started and traffic is routed to it. Which approach should the developer use to ensure the script executes at the correct stage of the deployment lifecycle?

Show answer & explanation

Answer: Place the script inside the `.platform/hooks/predeploy/` directory of the application source bundle and ensure it has executable permissions.

Answer

Place the script inside the `.platform/hooks/predeploy/` directory of the application source bundle and ensure it has executable permissions.
The correct option is to place the script inside the `.platform/hooks/predeploy/` directory. On Amazon Linux 2 and Amazon Linux 2023 platforms, Elastic Beanstalk runs scripts placed in this folder after the application source archive is unpacked into the staging folder but before the application process is started. This matches the developer's requirement to modify unpacked files prior to execution.

Step-by-Step Solution

1
Analyze the target operating system platform and version.
The platform is Amazon Linux 2023, which supports `.platform/` hooks for customizing deployments.
AWS Elastic Beanstalk platforms based on Amazon Linux 2 and Amazon Linux 2023 use the `.platform/` directory structure for lifecycle hooks, replacing the older behavior of running raw scripts directly from `.ebextensions/`.
2
Determine the exact lifecycle stage required for the script execution.
The script must execute after unpacking the source code but before the application runs.
This corresponds to the 'predeploy' phase in Elastic Beanstalk deployment lifecycle stages.
3
Identify the correct directory path and file requirements within the application bundle.
The path is `.platform/hooks/predeploy/`, and files inside must be executable.
Scripts in `.platform/hooks/predeploy/` run automatically at the predeploy phase. Omission of the leading dot in configuration directories or using configuration hooks (`confighooks`) designed for configuration updates will prevent execution during a standard code deployment.

Key Concept

AWS Elastic Beanstalk Platform Hooks (.platform/hooks)
Question 14Question →

A developer is configuring a deployment strategy for a web application running on AWS Elastic Beanstalk. The application must maintain full capacity (100%100\%) throughout the deployment process to handle steady traffic, and the developer wants to avoid performing any DNS routing changes or CNAME swaps. Which two deployment policies satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Rolling with additional batch; Immutable

Answer

Rolling with additional batch and Immutable are the correct deployment policies.
The correct options are 'Rolling with additional batch' and 'Immutable'. 'Rolling with additional batch' maintains full capacity by launching a new batch of instances before taking existing ones out of service. 'Immutable' maintains full capacity by deploying a temporary Auto Scaling group next to the original one and only cleaning up the old instances once the new ones pass health checks. Neither policy requires DNS or CNAME swaps.

Step-by-Step Solution

1
Analyze capacity requirements during deployment.
The application requires maintaining full capacity (100%100\%) at all times, meaning the deployment must not take any active instances out of service without first replacing their capacity.
This rules out the standard Rolling policy, which takes batches offline, and the All at once policy, which takes all instances offline.
2
Analyze DNS and routing requirements.
The developer wants to avoid DNS changes or CNAME swaps.
This rules out Blue/Green deployment, which relies on swapping the URLs of two separate environments (a DNS-level change).
3
Evaluate the remaining Elastic Beanstalk deployment policies.
Rolling with additional batch launches new instances first to maintain capacity, and Immutable creates a temporary parallel Auto Scaling group to test the new version before replacing the old one. Neither requires DNS changes.
Both of these options satisfy both the full capacity and no-DNS-swap constraints.

Key Concept

AWS Elastic Beanstalk deployment policies and their impact on environment capacity, downtime, and DNS routing.
Question 15Question →

A development team is deploying a web application to an AWS Elastic Beanstalk environment running on an Amazon Linux 2023 platform. The application requires two configuration changes: First, a custom shell script must execute after the application source code has been extracted to the staging directory but before it is moved to the final path. Second, a custom system daemon (systemd service) must be configured to start automatically when each EC2 instance boots. Which combination of files and directory structures must the developer include in the application source bundle to satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: A shell script inside the `.platform/hooks/predeploy/` directory to run the custom script.; A configuration file ending in `.config` inside the `.ebextensions/` directory containing a `services` block to enable and start the system daemon.

Answer

The correct options are placing the custom shell script under the `.platform/hooks/predeploy/` directory and placing a `.config` configuration file under the `.ebextensions/` directory containing a `services` block.
To execute custom scripts during specific deployment phases on Amazon Linux 2023, scripts must be placed in `.platform/hooks/predeploy/`. To manage system services, a `.config` file within the `.ebextensions/` folder containing a `services` section must be used.

Step-by-Step Solution

1
Determine the directory structure required for custom hook scripts on Amazon Linux 2023 platforms.
Identify that platform hooks must reside in `.platform/hooks/` and that the `predeploy` phase runs after extraction but before the app goes live.
Elastic Beanstalk AL2023 platforms look for hooks in `.platform/hooks/` rather than `.ebextensions/`.
2
Determine how to manage system-level configuration such as starting daemons or services on boot.
Identify that the `.ebextensions/` directory contains `.config` files, which support a `services` section to configure system daemon startup.
The `.ebextensions/` files are processed during deployment to declare system configuration resources.

Key Concept

AWS Elastic Beanstalk configuration files and platform hooks directory layout
Estimated Time:2m 0s
Question 16Question →

A developer is deploying a web application using AWS Elastic Beanstalk. The developer wants to include custom configuration files (with a `.config` extension) to install packages and define environment properties. In which directory at the root of the application source bundle must the developer place these files to ensure they are processed during deployment?

Show answer & explanation

Answer: .ebextensions

Answer

The `.ebextensions` directory at the root of the application source bundle.
To customize the EC2 instances in an Elastic Beanstalk environment, configuration files (ending in `.config`) must be placed in a directory named `.ebextensions` at the root of the application source bundle. Elastic Beanstalk automatically detects and applies these configurations during deployment.

Step-by-Step Solution

1
Identify where Elastic Beanstalk looks for configuration files in the source bundle.
The platform search mechanism looks at the root of the uploaded zip source bundle.
Elastic Beanstalk needs a standard, predictable location to find customization files.
2
Determine the exact directory naming convention.
The required directory name must start with a period and be followed by 'ebextensions' (resulting in `.ebextensions`).
Omitting the leading period or using a different name will cause the deployment agent to ignore the customization files.

Key Concept

Elastic Beanstalk custom configuration via .ebextensions
Estimated Time:45s
Question 17Question →

A developer is configuring a web application for deployment on AWS Elastic Beanstalk. The application requires a runtime environment variable named 'DATABASE_URL'. Additionally, the application requires an Amazon S3 bucket for storing user uploads, and this bucket's lifecycle must be tied directly to the Elastic Beanstalk environment. Which two configuration steps should the developer perform to satisfy these requirements? (Select TWO.)

Select all that apply

Show answer & explanation

Answer: Place a '.config' configuration file inside a directory named '.ebextensions' at the root of the application source bundle, defining the environment variable under the 'aws:elasticbeanstalk:application:environment' namespace.; Place a '.config' configuration file inside a directory named '.ebextensions' at the root of the application source bundle, defining the S3 bucket under the 'Resources' block using CloudFormation syntax.

Answer

To satisfy the requirements, the developer must place a '.config' file within a '.ebextensions' directory at the root of the application source bundle. In this file, the 'DATABASE_URL' environment variable should be defined under the 'aws:elasticbeanstalk:application:environment' namespace, and the Amazon S3 bucket should be defined as a resource under the 'Resources' block using standard CloudFormation syntax.
The correct options describe placing '.config' files in a folder named '.ebextensions' at the root of the source bundle. To configure environment variables, the developer uses the 'aws:elasticbeanstalk:application:environment' namespace inside the configuration file. To provision custom resources like an S3 bucket that share the environment's lifecycle, the developer includes standard CloudFormation resource definitions under the 'Resources' key in the configuration files.

Step-by-Step Solution

1
Identify the directory location and file extension for Elastic Beanstalk configuration files.
The files must have a '.config' extension and must be placed in a folder named '.ebextensions' (with a leading period) at the root of the source bundle.
Elastic Beanstalk only processes configuration files that reside in this specific directory path.
2
Determine the namespace for setting environment properties/variables.
The correct namespace is 'aws:elasticbeanstalk:application:environment' within the 'option_settings' block of the configuration file.
This namespace informs Elastic Beanstalk to inject the properties as environment variables accessible by the application code at runtime.
3
Define the custom resource with a lifecycle tied to the Elastic Beanstalk environment.
Add a 'Resources' block containing the Amazon S3 bucket definition using AWS CloudFormation syntax in one of the '.config' files.
Elastic Beanstalk parses the 'Resources' section of '.config' files and adds those resources directly to the environment's underlying CloudFormation stack, managing their lifecycle together.

Key Concept

AWS Elastic Beanstalk configuration files ('.ebextensions') and resource provisioning
Estimated Time:2m 0s
Question 18Question →

A developer is preparing a deployment package for a Python application to be deployed on AWS Elastic Beanstalk. The application requires a Linux system package to be installed on the hosting EC2 instances during deployment, and a custom database connection string environment variable to be configured. Which two configurations should the developer include in the application source bundle to meet these requirements?

Select all that apply

Show answer & explanation

Answer: Create a folder named `.ebextensions` at the root of the source bundle and place a file ending with `.config` inside it to define the required Linux package.; Define the database connection string environment variable under the `aws:elasticbeanstalk:application:environment` namespace in a `.config` file within the `.ebextensions` folder.

Answer

Create a folder named `.ebextensions` at the root of the source bundle and place a file ending with `.config` inside it to define the required Linux package; and define the database connection string environment variable under the `aws:elasticbeanstalk:application:environment` namespace in a `.config` file within the `.ebextensions` folder.
The correct configurations involve creating a `.ebextensions` folder at the root of the source bundle containing `.config` files. System packages are installed using the `packages` key, and environment variables are set using the `aws:elasticbeanstalk:application:environment` namespace within these files.

Step-by-Step Solution

1
Identify the mechanism for custom environment configuration and package installation in AWS Elastic Beanstalk.
AWS Elastic Beanstalk uses configuration files under the `.ebextensions` directory at the root of the source bundle.
This is the native mechanism for customization of the platform and application environment during deployment.
2
Determine the correct directory naming and location rules.
The folder must be named `.ebextensions` with a leading dot and must be at the root of the zip source bundle.
Elastic Beanstalk checks this specific path; missing the dot (e.g. `ebextensions`) or using `.elasticbeanstalk` (reserved for local EB CLI) will cause configurations to be ignored.
3
Identify the standard namespace for environment variables inside the configuration files.
The namespace to define environment properties is `aws:elasticbeanstalk:application:environment`.
Specifying variables within this namespace injects them as environment variables accessible to the application code.

Key Concept

AWS Elastic Beanstalk environment customization using .ebextensions configuration files
Question 19Question →

A developer is deploying an update to a production web application hosted on AWS Elastic Beanstalk. The update must satisfy the following constraints:

* The application must maintain its full capacity of active instances throughout the deployment process to handle consistent user traffic.
* If the new version fails to deploy or pass health checks, the environment must roll back to the previous version automatically and as quickly as possible.
* The update must not require a DNS CNAME swap, as the domain name is mapped to a static resource external to the environment.
* The configuration must be managed programmatically as code inside the application source bundle.

Which configuration file path and content structure will satisfy these requirements?

Show answer & explanation

Answer: A file named `.ebextensions/deployment.config` with the following content:

yaml
option_settings:
aws:elasticbeanstalk:command:
DeploymentPolicy: Immutable

Answer

A file named `.ebextensions/deployment.config` with the `DeploymentPolicy` set to `Immutable` under the `aws:elasticbeanstalk:command` namespace.
The correct option specifies a file inside the `.ebextensions/` directory with the `DeploymentPolicy` configured as `Immutable`. The Immutable policy meets all requirements: it maintains 100% capacity by deploying a temporary Auto Scaling group, requires no CNAME swap since it updates the existing environment, and performs an immediate, automated rollback by terminating the new Auto Scaling group if the deployment or health checks fail.

Step-by-Step Solution

1
Analyze the capacity and rollback requirements.
The requirement to maintain 100% capacity during updates rules out All at Once and Rolling deployments. The requirement for immediate, automatic rollback rules out Rolling with Additional Batch.
Immutable deployments launch a full set of new instances in a separate Auto Scaling group, keeping the old ones at 100% capacity. If health checks fail, the new Auto Scaling group is terminated instantly.
2
Evaluate the DNS CNAME swap constraint.
The requirement to avoid DNS or CNAME swaps rules out Blue/Green deployments.
Blue/Green deployment requires swapping the CNAMEs of two separate Elastic Beanstalk environments, which violates the constraint.
3
Identify the correct configuration mechanism and folder path.
The configuration must be defined inside the `.ebextensions/` folder at the root of the source bundle.
Elastic Beanstalk configuration files must reside in the `.ebextensions/` directory (with a leading dot). Files in directories without the leading dot, such as `ebextensions/`, are ignored.

Key Concept

AWS Elastic Beanstalk Immutable deployment policy and configuration files
Question 20Question →

A development team is deploying a worker application to an AWS Elastic Beanstalk Worker Tier environment. The application processes high-compute tasks received from an Amazon SQS queue, with each task taking approximately 4545 minutes (27002700 seconds) to complete. During testing, the team notices that tasks are frequently reprocessed by different worker instances before the original instance completes them, and the worker daemon logs indicate timeout failures before the application returns an HTTP status code. Which two configuration steps must the developer perform to resolve these issues and support this long-running processing requirement?

Select all that apply

Show answer & explanation

Answer: Create a configuration file inside the `.ebextensions` directory with a `.config` extension, and set the `InactivityTimeout` parameter to 30003000 in the `aws:elasticbeanstalk:sqsd` namespace.; Create a configuration file inside the `.ebextensions` directory with a `.config` extension, and set the `VisibilityTimeout` parameter to 30003000 in the `aws:elasticbeanstalk:sqsd` namespace.

Answer

Create a configuration file inside the `.ebextensions` directory with a `.config` extension, and set the `InactivityTimeout` parameter to 30003000 in the `aws:elasticbeanstalk:sqsd` namespace; and create a configuration file inside the `.ebextensions` directory with a `.config` extension, and set the `VisibilityTimeout` parameter to 30003000 in the `aws:elasticbeanstalk:sqsd` namespace.
In an Elastic Beanstalk worker tier environment, the local daemon (`sqsd`) retrieves messages from an SQS queue and posts them to the application. If processing takes 4545 minutes (27002700 seconds), the daemon must wait longer than the default 300300 seconds for the HTTP response. Increasing `InactivityTimeout` in the `aws:elasticbeanstalk:sqsd` namespace to 30003000 seconds prevents premature HTTP timeouts. Concurrently, increasing the `VisibilityTimeout` in the same namespace to 30003000 seconds keeps the message hidden from other instances while the worker processes it, preventing duplicate processing.

Step-by-Step Solution

1
Analyze the worker tier daemon mechanics
Identify that the Elastic Beanstalk worker daemon (`sqsd`) pulls messages from SQS and forwards them via HTTP POST to the local application. The default HTTP connection inactivity timeout is 300300 seconds.
Since tasks take 4545 minutes (27002700 seconds), the daemon's connection will time out unless `InactivityTimeout` is increased.
2
Analyze message visibility constraints
Identify that the SQS visibility timeout must exceed the task processing time (27002700 seconds) to prevent duplicate processing by other worker instances.
Setting the `VisibilityTimeout` option in the daemon configuration to 30003000 seconds prevents the message from returning to the queue during processing.
3
Verify configuration file structure and namespace rules
Confirm that Elastic Beanstalk looks for configurations in the `.ebextensions/` directory at the root of the source bundle. The configuration must target the `aws:elasticbeanstalk:sqsd` namespace.
Any deviation in folder naming (e.g. omitting the leading dot) or using incorrect namespaces will result in the parameters being ignored.

Key Concept

AWS Elastic Beanstalk Worker Tier Daemon Configuration
Page 1 / 2Next