Deployment

376 questions

All types376 Multiple choice191 Multiple select171 Ordering14

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

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.

Store the database password in AWS Systems Manager Parameter Store as a Standard String parameter and enable native automatic rotation.

Create a configuration file named `env_vars.config` inside a directory named `ebextensions` at the root of the application source bundle.

Embed the database password directly as a plain-text configuration value within the application source code files.

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

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.

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.

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

A developer is managing an application deployed via AWS CloudFormation. The application's database credentials are stored in AWS Secrets Manager and referenced in the CloudFormation template using the dynamic reference `{{resolve:secretsmanager:ProductionDBSecret:SecretString:Password}}` within the `UserData` property of an `AWS::EC2::LaunchTemplate` resource.

The database administrator rotates the database password in AWS Secrets Manager. Subsequently, the developer initiates a stack update to increase the `MaxSize` property of the `AWS::AutoScaling::AutoScalingGroup` resource that uses this launch template. The stack update completes successfully, but the newly launched EC2 instances fail to connect to the database, while existing instances continue to function until their cached credentials expire.

What is the cause of this issue, and how should the developer resolve it?

The developer should store the password in Systems Manager Parameter Store as a SecureString and use the `{{resolve:ssm-secure:ParameterName:Version}}` dynamic reference instead, as Parameter Store parameters automatically trigger a stack update and resource replacement whenever the parameter value changes.

The manual update of the database password created a drift condition between the stack template and the deployed resources, preventing CloudFormation from resolving the secret. The developer must run drift detection on the stack, resolve the drift, and perform a stack import.

The Launch Template resource was not modified during the stack update, so CloudFormation did not re-resolve the dynamic reference to fetch the new password. The developer must update the template by appending the new secret's version ID or version stage to the dynamic reference to force a Launch Template update.

The stack update failed during the Auto Scaling group scaling activity due to the incorrect credential, placing the stack in the `UPDATE_ROLLBACK_IN_PROGRESS` state. The developer must manually delete the newly created EC2 instances and use the `ContinueUpdateRollback` CLI command to force the stack back to `UPDATE_COMPLETE`.

Show answer & explanation

Answer: The Launch Template resource was not modified during the stack update, so CloudFormation did not re-resolve the dynamic reference to fetch the new password. The developer must update the template by appending the new secret's version ID or version stage to the dynamic reference to force a Launch Template update.

Answer

The Launch Template resource was not modified during the stack update, so CloudFormation did not re-resolve the dynamic reference. The developer must update the template by appending the new secret's version ID or version stage to the dynamic reference to force a Launch Template update.

CloudFormation resolves dynamic references only during stack creation or when the specific resource containing the dynamic reference is updated. Since the stack update only modified the `MaxSize` property of the `AWS::AutoScaling::AutoScalingGroup` resource, the `AWS::EC2::LaunchTemplate` resource was not modified, and CloudFormation did not re-resolve the Secrets Manager dynamic reference. Consequently, the launch template continued to use the old resolved password value. To resolve this, the template must be updated to force an update of the launch template resource. Appending the new secret's version ID or version stage (such as the specific version UUID) to the dynamic reference changes the template definition of the launch template, forcing CloudFormation to update the launch template and retrieve the new secret value.

Step-by-Step Solution

Analyze why the new EC2 instances are failing to connect.

The new instances are launched using the launch template that still contains the old database password because the dynamic reference was not re-resolved.

CloudFormation only resolves dynamic references when the resource defining them is created or updated. The stack update only changed the Auto Scaling group's MaxSize, leaving the Launch Template untouched.

Determine the correct method to force CloudFormation to resolve the updated secret.

The Launch Template resource must be modified in the template so that CloudFormation initiates an update for it.

By changing the resource's definition, CloudFormation is triggered to update the Launch Template and fetch the updated value of the dynamic reference.

Apply the change using the Secrets Manager dynamic reference version ID/stage suffix.

Update the dynamic reference to specify the new version ID (e.g., `{{resolve:secretsmanager:ProductionDBSecret:SecretString:Password::version-id}}`).

This updates the launch template resource in the CloudFormation template, prompting CloudFormation to re-resolve the reference during the stack update.

Key Concept

CloudFormation dynamic references are only resolved during resource creation or updates. Changing properties of other resources (like Auto Scaling group size) does not trigger re-resolution of dynamic references in unchanged resources.

Alternative Method

Another way to force the launch template to update and re-resolve the dynamic reference is to update a non-disruptive parameter or property on the launch template itself, such as adding or changing a metadata property or changing the launch template version in the Auto Scaling group template definition.

Estimated Time:3m 0s

Question 83Question →

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?

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

Create a folder named `ebextensions` without a leading period at the root of the application source bundle, and place a JSON configuration file inside it.

Create an `appspec.yml` file at the root of the application source bundle to define the environment settings and Auto Scaling parameters.

Save the environment configurations through the Elastic Beanstalk console and upload the exported JSON configuration file to the root of a central Amazon S3 bucket.

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

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.

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

A developer is packaging a Node.js web application for deployment to an AWS Elastic Beanstalk environment running on an Amazon Linux $2023$ 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?

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

Place the script inside the `.ebextensions/` folder and execute it using the `commands` key in a configuration file.

Place the script inside the `ebextensions/` folder of the source bundle and configure it to run using the `container_commands` key in a configuration file.

Place the script inside the `.platform/confighooks/predeploy/` directory of the application source bundle.

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

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/`.

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.

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

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

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

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

An ECS rolling update with the minimum healthy percent set to

80

%, the maximum percent set to

120

%, and the ECS deployment circuit breaker enabled with rollback.

An ECS rolling update with the minimum healthy percent set to

100

%, the maximum percent set to

150

%, and the ECS deployment circuit breaker enabled with rollback.

An AWS CodeDeploy blue/green deployment using the CodeDeployDefault.ECSAllAtOnce configuration, with automated rollbacks configured via CloudWatch alarms.

An AWS CodeDeploy blue/green deployment using a custom canary configuration (ECSCanary10Percent5Minutes) to limit task provisioning, with automated rollbacks configured via CloudWatch alarms.

Show answer & explanation

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

Answer

An ECS rolling update with the minimum healthy percent set to

80

%, the maximum percent set to

120

%, and the ECS deployment circuit breaker enabled with rollback.

The correct option is the ECS rolling update with the minimum healthy percent set to

80

% and the maximum percent set to

120

%. This configuration ensures that at least

8

tasks (

80

% of

10

) are always healthy and serving traffic, and restricts the ECS scheduler from running more than

12

tasks (

120

% of

10

) concurrently, satisfying the regional quota limit. Enabling the ECS deployment circuit breaker with rollback allows ECS to automatically roll back to the last stable deployment revision if the new tasks fail to reach a steady state, meeting all requirements natively.

Step-by-Step Solution

Calculate the minimum healthy task count and maximum task limit based on the percentage parameters.

A minimum healthy percent of

80

% requires at least

8

tasks to remain healthy (

10 \times 0.8 = 8

). A maximum percent of

120

% limits the total concurrent tasks to

12

(

10 \times 1.2 = 12

To verify compliance with the resource quotas and availability constraints specified in the scenario.

Evaluate AWS CodeDeploy blue/green deployment capabilities for ECS under task capacity limitations.

All CodeDeploy blue/green deployments for ECS require provisioning a full replacement task set (

10

tasks) before any traffic is shifted, requiring a total of

20

tasks (

200

% capacity).

To determine if CodeDeploy can satisfy the constraint of having at most

12

concurrent tasks.

Verify the configuration needed for automated rollback in the chosen deployment model.

The native ECS deployment circuit breaker automatically monitors task launch and health check failures, triggering an automated rollback to the last stable task definition revision if the deployment fails.

To meet the requirement for automated rollback on container launch or health check failure without manual intervention.

Key Concept

ECS Rolling Updates vs CodeDeploy Blue/Green task provisioning constraints and native deployment circuit breaker rollbacks.

Estimated Time:3m 0s

Question 86Question →

A developer is configuring a deployment strategy for a web application running on AWS Elastic Beanstalk. The application must maintain full capacity ( $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

Rolling with additional batch

Immutable

Rolling

All at once

Blue/Green deployment via CNAME swap

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

Analyze capacity requirements during deployment.

The application requires maintaining full capacity (

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.

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).

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

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

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.

A shell script inside the `.ebextensions/hooks/` directory to run the custom script.

An `appspec.yml` file at the root of the source bundle containing the script path under the `ApplicationStart` hook.

A shell script inside the `.ebextensions/predeploy/` directory to execute during the predeploy stage.

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

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/`.

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

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?

ebextensions

.elasticbeanstalk

.ebextensions

.platform

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

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.

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

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

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.

Store a configuration file within a directory named 'ebextensions' (without a prefix dot) located at the root of the application package to configure the settings and resources.

Add an 'appspec.yml' file to the root of the project source, specifying the database connection string and S3 bucket details in the hooks section.

Configure a 'buildspec.yml' file at the root level to provision the S3 bucket and inject the database environment variable during the deployment phases.

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

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.

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.

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

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

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.

Create a folder named `ebextensions` (without a leading period) at the root of the source bundle and place the configuration files there.

Create a folder named `.elasticbeanstalk` at the root of the source bundle and place the configuration files there.

Create an `appspec.yml` file at the root of the source bundle and define the package installation and environment variables under the lifecycle hooks.

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

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.

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.

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

A developer manages a production environment deployed using an AWS CloudFormation stack. The stack contains an Amazon RDS DB instance, an Amazon EC2 instance, and an IAM role. A system administrator manually changed the security group of the RDS DB instance in the Amazon VPC Console to address a transient connection issue.

During a subsequent stack update to upgrade the database engine version and add policies to the IAM role, the update fails during the RDS DB instance modification. CloudFormation attempts to roll back the changes, but the rollback fails and remains stuck in the `UPDATE_ROLLBACK_FAILED` state because the manually modified security group configuration prevents the database rollback. The developer must complete the stack update, ensuring the new IAM policies are applied and the database is upgraded.

Which sequence of actions must the developer perform to resolve this issue?

Execute `aws cloudformation update-stack` with the `--force` parameter to override the rollback state and directly apply the upgraded database engine version and IAM policies. Then, run drift detection on the stack and select the auto-reconcile option to automatically revert the manual security group changes.

Execute `aws cloudformation continue-update-rollback` specifying the logical ID of the RDS DB instance in the `--resources-to-skip` parameter to transition the stack to `UPDATE_ROLLBACK_COMPLETE`. Revert the manual security group modifications on the RDS DB instance in the Amazon VPC Console to align the resource's physical state with the template, and then perform a new stack update with the corrected database engine version and the updated IAM role template.

Execute `aws cloudformation rollback-stack` to force the stack state back to `ROLLBACK_COMPLETE`. Store the security group configuration as a secure string in AWS Systems Manager Parameter Store and reference it in the CloudFormation template using a dynamic reference, and then update the stack to apply the database and IAM role changes.

Manually delete the RDS DB instance from the Amazon RDS Console to trigger an automatic stack state change to `DELETE_COMPLETE`. Run `aws cloudformation continue-update-rollback` to complete the stack rollback, and then re-create the RDS DB instance manually and perform a stack update with a new template that references the new database instance ID.

Show answer & explanation

Answer: Execute `aws cloudformation continue-update-rollback` specifying the logical ID of the RDS DB instance in the `--resources-to-skip` parameter to transition the stack to `UPDATE_ROLLBACK_COMPLETE`. Revert the manual security group modifications on the RDS DB instance in the Amazon VPC Console to align the resource's physical state with the template, and then perform a new stack update with the corrected database engine version and the updated IAM role template.

Answer

Execute `aws cloudformation continue-update-rollback` with the `--resources-to-skip` parameter for the RDS DB instance, revert the manual security group modifications in the console, and then perform a new stack update.

The correct sequence begins by executing the `continue-update-rollback` command and specifying the logical ID of the RDS DB instance in the `--resources-to-skip` parameter. This instructs CloudFormation to set the status of the RDS DB instance to update/rollback complete (leaving its physical state unchanged) and proceed with rolling back the rest of the stack, shifting the overall stack status to `UPDATE_ROLLBACK_COMPLETE`. Because skipping the resource leaves it inconsistent with the template, the developer must manually revert the out-of-band security group changes in the VPC Console to match the template. Once reconciled, a new stack update can be run successfully to apply the database upgrade and the new IAM role policies.

Step-by-Step Solution

Invoke the continue-update-rollback command with skipped resources

The command `aws cloudformation continue-update-rollback --stack-name <stack-name> --resources-to-skip <RDS-Logical-ID>` is executed, transitioning the stack to the `UPDATE_ROLLBACK_COMPLETE` state.

When a stack is stuck in `UPDATE_ROLLBACK_FAILED`, you must use `continue-update-rollback`. Specifying the failing resource in `--resources-to-skip` allows CloudFormation to bypass rolling back that specific resource and successfully roll back the rest of the stack (such as the IAM role).

Reconcile resource drift manually

The manual changes made to the RDS DB instance security group are reverted in the AWS Management Console to match the configuration defined in the template.

Skipping a resource leaves its physical state inconsistent with the stack template. To avoid future update failures due to drift, the physical resource must be aligned with the template before launching a new update.

Perform the stack update again

The stack update is executed with the corrected configuration, upgrading the database engine version and applying the new IAM policies.

With the stack in a stable state (`UPDATE_ROLLBACK_COMPLETE`) and the resources reconciled, the update can now be cleanly processed.

Key Concept

Handling AWS CloudFormation UPDATE_ROLLBACK_FAILED states by skipping resources and reconciling out-of-band drift.

Estimated Time:3m 0s

Question 92Question →

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?

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

yaml
option_settings:
aws:elasticbeanstalk:command:
DeploymentPolicy: RollingWithAdditionalBatch

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

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

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

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

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

yaml
option_settings:
aws:elasticbeanstalk:command:
DeploymentPolicy: AllAtOnce

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

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.

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.

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

A developer is writing an AWS CloudFormation template to deploy a web application. The application requires access to a database password that must be rotated automatically every 30 days.

Which approach should the developer use to reference this password in the CloudFormation template while meeting the security requirements?

Retrieve the database password dynamically in the CloudFormation template using a dynamic reference to a secret stored in AWS Secrets Manager.

Retrieve the database password in the template by referencing a standard parameter stored in AWS Systems Manager Parameter Store.

Manually update the database password directly in the database instance and use CloudFormation drift detection to automatically synchronize the template with the new password.

Update the password parameter in the CloudFormation template during a stack update, and if the update fails, allow the stack to remain in the ROLLBACK_IN_PROGRESS state to re-attempt the password rotation.

Show answer & explanation

Answer: Retrieve the database password dynamically in the CloudFormation template using a dynamic reference to a secret stored in AWS Secrets Manager.

Answer

Retrieve the database password dynamically in the CloudFormation template using a dynamic reference to a secret stored in AWS Secrets Manager.

The correct option is to retrieve the database password dynamically in the CloudFormation template using a dynamic reference to a secret stored in AWS Secrets Manager. Secrets Manager is designed specifically to handle sensitive information and provides built-in integration for automatic rotation of credentials. CloudFormation can securely fetch the current version of the secret during deployment using dynamic references.

Step-by-Step Solution

Identify the rotation requirement.

The requirement specifies that the database password must be rotated automatically every 30 days.

AWS Secrets Manager natively supports automatic secrets rotation using AWS Lambda, whereas Systems Manager Parameter Store does not have a native, out-of-the-box automatic rotation feature.

Integrate the secret with CloudFormation.

Configure a dynamic reference pattern like '{{resolve:secretsmanager:secret-id}}' within the CloudFormation resource properties.

This allows CloudFormation to fetch the latest version of the secret at deployment time without hardcoding it or exposing it in plaintext.

Key Concept

AWS CloudFormation Dynamic References with AWS Secrets Manager

Question 94Question →

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

Select all that apply

Create a canary release on the existing API Gateway stage and configure the canary traffic percentage to

15\%

Delete the canary release from the stage to roll back, or promote the canary release to make the new version the active production version.

Configure an Amazon Route 53 weighted routing policy pointing to two different API Gateway stages, one for production (

85\%

) and one for canary (

15\%

Deploy the new API version to a new stage and configure a Lambda function with stage variables to dynamically calculate and split traffic.

Configure an AWS CodeDeploy deployment group with a canary configuration targeting the API Gateway stage.

Show answer & explanation

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

Answer

To meet the requirements, the developer must create a canary release on the API Gateway stage configured to receive 15% of the traffic, and then either delete the canary release to roll back or promote it to replace the production version if successful.

Creating a canary release on the existing stage and specifying

15\%

traffic natively implements the requested traffic split. Once configured, any new deployment to that stage routes the specified portion of traffic to the new code. Deleting the canary from the stage immediately halts the canary traffic routing and serves

100\%

of traffic from the production version, fulfilling the instant rollback requirement. Promoting the canary upgrades the stage's production settings to point to the new deployment.

Step-by-Step Solution

Set up traffic shifting in API Gateway.

By creating a canary release directly on the target deployment stage and configuring it to receive

15\%

of traffic, API Gateway automatically splits incoming traffic between the current production release (

85\%

) and the newly deployed canary release (

15\%

This natively meets the requirement to route a specific percentage of traffic to the new version without using external routing mechanisms.

Manage the lifecycle of the canary deployment.

If errors are detected during testing, deleting the canary release immediately routes

100\%

of traffic back to the production version. If successful, promoting the canary copies the configuration to the stage, making it the new production release.

This provides instant rollback and clean promotion capabilities directly inside the API Gateway stage settings.

Key Concept

Amazon API Gateway stages support native canary releases. Enabling a canary on a stage allows a developer to route a portion of the traffic to a new deployment, test its stability, and either promote it to production or delete the canary to roll back.

Estimated Time:2m 0s

Question 95Question →

A developer is using AWS SAM to deploy a serverless application consisting of an API Gateway endpoint that triggers a Lambda function, which writes data to a DynamoDB table. The template is defined as follows:

yaml
AWSTemplateFormatVersion: '2010-09-09'

Resources:
ProcessTransactionFunction:
Type: 'AWS::Serverless::Function'
Properties:
Handler: index.handler
Runtime: nodejs18.x
CodeUri: ./src
Events:
PostTransaction:
Type: Api
Properties:
Path: /transaction
Method: post
Role: !GetAtt LambdaExecutionRole.Arn

LambdaExecutionRole:
Type: 'AWS::IAM::Role'
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service:
- apigateway.amazonaws.com
Action:
- 'sts:AssumeRole'
Policies:
- PolicyName: DynamoDBWritePolicy
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- 'dynamodb:PutItem'
Resource: !GetAtt TransactionTable.Arn

During the deployment process using the AWS SAM CLI, the deployment fails with a parser error indicating that the resource type `AWS::Serverless::Function` is invalid. Additionally, if the parsing error is resolved, the Lambda function will fail to execute due to execution role issues.

Which two modifications must the developer make to ensure the template parses successfully and the Lambda function can be successfully assumed and executed by the AWS Lambda service?

Select all that apply

Add Transform: AWS::Serverless-2016-10-31 at the root level of the template.

Update the trust policy of LambdaExecutionRole to list lambda.amazonaws.com as the service principal.

Update the execution policy of the IAM role to include the lambda:InvokeFunction action on the ProcessTransactionFunction resource.

Modify the Lambda function handler code to return a raw text response since the default configuration for the SAM Api event source uses custom integration.

Add a default Timeout property set to 900 seconds under the Globals section to prevent execution context reuse timeouts during deployment validation.

Show answer & explanation

Answer: Add Transform: AWS::Serverless-2016-10-31 at the root level of the template.; Update the trust policy of LambdaExecutionRole to list lambda.amazonaws.com as the service principal.

Answer

To resolve the issues, the developer must add the Transform declaration to the root level of the template, and update the execution role trust policy to list the Lambda service principal.

Adding the Transform header enables the CloudFormation service to parse the AWS SAM syntax. Changing the service principal in the trust policy to lambda.amazonaws.com allows the Lambda service to assume the execution role and run the function.

Step-by-Step Solution

Analyze the template syntax error.

Identify that the parser failed on 'AWS::Serverless::Function' because the AWS SAM transform macro statement is missing.

Without the Transform declaration, CloudFormation does not recognize resources in the AWS::Serverless namespace.

Analyze the IAM Role trust policy configuration.

Identify that the trust policy lists 'apigateway.amazonaws.com' as the service principal in the Principal section.

The execution role must be assumed by the Lambda service, meaning the service principal must be lambda.amazonaws.com.

Determine the necessary changes.

Formulate the fixes: insert the Transform line and update the service principal in the trust policy.

These changes address both the parsing failure and the runtime execution permission failure.

Key Concept

AWS SAM templates require the Transform header to compile serverless resources, and Lambda execution roles require the correct trust policy configuration to allow the Lambda service to assume the role.

Question 96Question →

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 $45$ minutes ( $2700$ 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

Create a configuration file inside the `.ebextensions` directory with a `.config` extension, and set the `InactivityTimeout` parameter to

3000

in the `aws:elasticbeanstalk:sqsd` namespace.

Create a configuration file inside the `.ebextensions` directory with a `.config` extension, and set the `VisibilityTimeout` parameter to

3000

in the `aws:elasticbeanstalk:sqsd` namespace.

Create a configuration file inside a folder named `ebextensions` (without a leading dot) at the root of the source bundle, and set the `InactivityTimeout` parameter to

3000

in the `aws:elasticbeanstalk:sqsd` namespace.

Set the `VisibilityTimeout` of the SQS queue to

120

seconds in the Amazon SQS console to ensure that failed processing attempts are quickly retried by other workers.

Configure the environment's deployment policy to Rolling to automatically adjust the Amazon SQS queue's connection pool and visibility timeout during periods of high resource utilization.

Show answer & explanation

Answer: Create a configuration file inside the `.ebextensions` directory with a `.config` extension, and set the `InactivityTimeout` parameter to $3000$ in the `aws:elasticbeanstalk:sqsd` namespace.; Create a configuration file inside the `.ebextensions` directory with a `.config` extension, and set the `VisibilityTimeout` parameter to $3000$ 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

3000

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

3000

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

45

minutes (

2700

seconds), the daemon must wait longer than the default

300

seconds for the HTTP response. Increasing `InactivityTimeout` in the `aws:elasticbeanstalk:sqsd` namespace to

3000

seconds prevents premature HTTP timeouts. Concurrently, increasing the `VisibilityTimeout` in the same namespace to

3000

seconds keeps the message hidden from other instances while the worker processes it, preventing duplicate processing.

Step-by-Step Solution

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

300

seconds.

Since tasks take

45

minutes (

2700

seconds), the daemon's connection will time out unless `InactivityTimeout` is increased.

Analyze message visibility constraints

Identify that the SQS visibility timeout must exceed the task processing time (

2700

seconds) to prevent duplicate processing by other worker instances.

Setting the `VisibilityTimeout` option in the daemon configuration to

3000

seconds prevents the message from returning to the queue during processing.

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

Question 97Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. During the pipeline execution, the pipeline fails at the transition to a deployment stage with an access denied error indicating that the pipeline cannot assume the service role. Which of the following is the most likely cause of this failure?

The IAM service role assigned to the pipeline has a trust policy that does not list codepipeline.amazonaws.com as a trusted entity.

The IAM service role lists codepipeline.amazonaws.com in the identity-based permissions policy rather than in the trust policy.

The pipeline is attempting to retrieve a database connection string from Systems Manager Parameter Store, which fails because Parameter Store cannot rotate credentials.

The pipeline is unable to parse the build configuration because the buildspec.yml file is placed in a subdirectory of the source repository rather than the root directory.

Show answer & explanation

Answer: The IAM service role assigned to the pipeline has a trust policy that does not list codepipeline.amazonaws.com as a trusted entity.

Answer

The IAM service role assigned to the pipeline must have a trust policy that explicitly lists codepipeline.amazonaws.com as a trusted entity.

The correct option is correct because AWS CodePipeline requires an IAM service role to execute pipeline actions on your behalf. The service role's trust policy must declare codepipeline.amazonaws.com as a trusted entity so that the pipeline service can assume the role and obtain temporary credentials.

Step-by-Step Solution

Analyze the error message regarding the pipeline's inability to assume the designated service role.

Identify that the issue is related to IAM role assumption permissions.

The error specifically mentions that CodePipeline is denied access when attempting to assume the service role.

Review the trust policy of the IAM service role assigned to AWS CodePipeline.

Determine if the service principal codepipeline.amazonaws.com is declared as a trusted entity.

Without the correct service principal in the trust policy, the AWS Security Token Service (STS) will block CodePipeline from assuming the role.

Verify that the permissions policy is separate from the trust policy.

Ensure permissions policies define resource access, whereas the trust policy dictates who can assume the role.

Misplacing trust declarations in the permissions policy is a common configuration mistake that results in access denied errors.

Key Concept

AWS CodePipeline Service Roles and IAM Trust Policies

Question 98Question →

A developer is packaging a Node.js web application for deployment to AWS Elastic Beanstalk. The application requires the installation of an external system tool (git) and must define a custom environment variable named APP_STAGE set to production. The developer wants to manage these configurations as code within the application source bundle. Which two actions must the developer take to accomplish this? (Select TWO.)

Select all that apply

Create a directory named .ebextensions at the root of the application source bundle.

Create a configuration file ending with the .config extension inside the .ebextensions directory.

Create a directory named ebextensions (without a leading dot) at the root of the application source bundle.

Create a directory named .ebextensions inside the application source code directory (such as src/ or bin/).

Define the environment variables and system packages in the .elasticbeanstalk/config.yml file.

Show answer & explanation

Answer: Create a directory named .ebextensions at the root of the application source bundle.; Create a configuration file ending with the .config extension inside the .ebextensions directory.

Answer

Create a directory named .ebextensions at the root of the application source bundle, and create a configuration file ending with the .config extension inside that directory.

To customize the AWS Elastic Beanstalk environment (such as installing packages or setting environment variables) using the application source bundle, the configuration files must be stored in a directory named '.ebextensions' located at the root of the application source bundle. These files must have a '.config' extension and contain valid YAML or JSON syntax.

Step-by-Step Solution

Determine the directory structure required for Elastic Beanstalk configuration files.

Identify that a directory named .ebextensions must be created at the root of the application source bundle.

Elastic Beanstalk looks for configuration files specifically in this location at the root level during deployment.

Determine the file naming convention and format for these configurations.

Identify that files must use a .config extension (e.g., setup.config) and contain YAML or JSON formatted configuration blocks such as packages and option_settings.

This is the required format and suffix for Elastic Beanstalk to recognize and parse configurations.

Key Concept

Configuring AWS Elastic Beanstalk environments using .ebextensions configuration files

Question 99Question →

A developer is deploying a containerized microservice to Amazon ECS using the AWS Fargate launch type. The application requires sensitive database credentials to be injected into the container as environment variables at startup from AWS Systems Manager Parameter Store. Additionally, the application must send its container logs to Amazon CloudWatch Logs using the awslogs log driver. Which configuration steps must the developer perform to establish the required IAM roles and permissions for this deployment? (Select TWO.)

Select all that apply

Configure the ECS task execution role with permissions to read the SSM parameters, decrypt the values using AWS KMS, and create/write log streams in CloudWatch Logs.

Configure the trust policy of the ECS task execution role to allow the ecs-tasks.amazonaws.com service principal to assume the role.

Configure the ECS task role with permissions to retrieve the SSM parameters and write logs to CloudWatch Logs.

Configure the trust policy of the ECS task execution role to allow the ec2.amazonaws.com service principal to assume the role.

Initialize the AWS SDK client within the application code using hardcoded IAM access keys to retrieve the database credentials at runtime.

Show answer & explanation

Answer: Configure the ECS task execution role with permissions to read the SSM parameters, decrypt the values using AWS KMS, and create/write log streams in CloudWatch Logs.; Configure the trust policy of the ECS task execution role to allow the ecs-tasks.amazonaws.com service principal to assume the role.

Answer

Configure the ECS task execution role with permissions to read the SSM parameters, decrypt the values using AWS KMS, and create/write log streams in CloudWatch Logs, and configure the trust policy of the ECS task execution role to allow the ecs-tasks.amazonaws.com service principal to assume the role.

The correct options state that the ECS task execution role must be configured with permissions to access SSM Parameter Store, decrypt the secrets using KMS, and write logs to CloudWatch, and that the trust policy must allow ecs-tasks.amazonaws.com to assume the role. The ECS container agent runs outside the application container to set up logs and pull secrets, meaning it relies on the task execution role, which must trust the ECS service principal.

Step-by-Step Solution

Identify the agent responsible for pulling secrets and setting up logging.

The ECS container agent (not the application code) performs these pre-startup actions, which means the ECS task execution role is required instead of the ECS task role.

Correctly segregating container initialization permissions from application runtime permissions is required by ECS.

Grant specific resource access permissions to the task execution role.

The task execution role receives permissions to read SSM parameters, decrypt KMS keys, and create/write logs in CloudWatch.

This enables the ECS agent to retrieve credentials from Parameter Store and direct container logs to CloudWatch.

Configure the trust relationship for the task execution role.

The role's trust policy is updated to allow the ecs-tasks.amazonaws.com service principal to assume the role.

ECS tasks cannot assume IAM roles unless the ECS service principal is explicitly trusted.

Key Concept

Differentiating between the ECS Task Role and the ECS Task Execution Role, and configuring the correct trust relationships and policies.

Estimated Time:1m 30s

Question 100Question →

A developer is deploying a serverless application using a local AWS Serverless Application Model (SAM) template file named `template.yaml`. The template contains the following definition:

yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Resources:
GetProductFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs20.x
CodeUri: ./src
Events:
GetProduct:
Type: Api
Properties:
Path: /products/{id}
Method: get

The developer attempts to deploy the application directly by executing the following AWS CLI command:

`aws cloudformation deploy --template-file template.yaml --stack-name product-service-dev --capabilities CAPABILITY_IAM`

However, the command fails, indicating that the `CodeUri` property of the `AWS::Serverless::Function` resource must point to an Amazon S3 location.

Which of the following statements identifies the root cause of this error and the correct action to resolve it?

The template has the `Transform: AWS::Serverless-2016-10-31` declaration defined at the root level, but this declaration must be moved under the `Metadata` section of the template so that the CloudFormation service can parse and auto-upload local paths.

CloudFormation cannot natively resolve local directory paths like `./src`. The developer must use `sam deploy` (or execute `aws cloudformation package` followed by `aws cloudformation deploy` using the generated packaged template) to zip and upload the local directory to Amazon S3, replacing the local path with an S3 URI.

The execution role associated with the CloudFormation stack deployment is missing a trust policy allowing the `apigateway.amazonaws.com` service principal to assume the role, preventing CloudFormation from reading from the local path.

The API Gateway integration is configured as a proxy integration, which requires the backend Lambda function to return a structured JSON response containing headers, statusCode, and body to authorize local file access.

Show answer & explanation

Answer: CloudFormation cannot natively resolve local directory paths like `./src`. The developer must use `sam deploy` (or execute `aws cloudformation package` followed by `aws cloudformation deploy` using the generated packaged template) to zip and upload the local directory to Amazon S3, replacing the local path with an S3 URI.

Answer

The correct response explains that CloudFormation cannot directly resolve local file paths. Standard CloudFormation deployments require that all Lambda code references (`CodeUri`) point to an S3 object. To resolve this, the developer must package the application using the AWS SAM CLI (`sam deploy`) or the AWS CLI package command (`aws cloudformation package`), which uploads the local zip file to S3 and returns a template with the updated S3 URLs before deploying.

Step-by-Step Solution

Analyze the failed deployment command and the error message.

The developer ran `aws cloudformation deploy` directly on a raw template containing `CodeUri: ./src`, and CloudFormation rejected it because it expects an S3 URL.

CloudFormation runs on AWS servers and has no direct access to the developer's local hard drive to retrieve `./src` during deployment.

Determine how local artifacts are prepared for AWS SAM deployments.

Local code directories must be compressed into a ZIP file, uploaded to an S3 bucket, and the template reference must be replaced with the S3 URI.

This artifact packaging step must occur prior to sending the template to the CloudFormation API.

Select the correct tool or sequence of commands to perform this preparation.

Using the AWS SAM CLI (`sam deploy` or `sam package`) or AWS CLI (`aws cloudformation package`) compiles and uploads local files, producing a deployable template.

These tools automate the packaging workflow and correctly rewrite local paths to S3 references before invoking CloudFormation deploy.

Key Concept

Local Artifact Packaging in AWS Serverless Application Model (SAM) Deployments

Estimated Time:3m 0s

PreviousPage 5 / 19Next

Deployment

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Alternative Method

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution