Deployment

376 questions

All types376 Multiple choice191 Multiple select171 Ordering14

A developer needs to deploy a new version of a Java application to an AWS Elastic Beanstalk environment. The deployment must install a security patch on the host operating system using an environment configuration file named `security.config`. The application requires zero downtime during deployment, and the developer must ensure that if the deployment fails, the running production instances remain completely unaffected and do not require a manual recovery process. Which configuration and deployment setup meets these requirements?

Use the Rolling deployment policy, and place `security.config` in the `.ebextensions/` directory at the root of the application source bundle.

Use the Immutable deployment policy, and place `security.config` in the `.ebextensions/` directory at the root of the application source bundle.

Use the Immutable deployment policy, and place `security.config` in the `ebextensions/` directory at the root of the application source bundle.

Use the All at once deployment policy, and place `security.config` in the `.ebextensions/` directory at the root of the application source bundle.

Show answer & explanation

Answer: Use the Immutable deployment policy, and place `security.config` in the `.ebextensions/` directory at the root of the application source bundle.

Answer

Use the Immutable deployment policy, and place the configuration file in the `.ebextensions/` directory at the root of the application source bundle.

The correct answer proposes using the Immutable deployment policy and placing the configuration file in the `.ebextensions/` directory. The Immutable deployment policy performs an update by launching a second Auto Scaling group with instances running the new version. If these new instances fail health checks, Elastic Beanstalk terminates them, leaving the original environment and instances completely untouched. This satisfies the requirement that production instances remain unaffected in case of failure. Placing the configuration file in the `.ebextensions/` directory at the root of the source bundle ensures that Elastic Beanstalk successfully parses and applies the custom configuration.

Step-by-Step Solution

Analyze the deployment downtime and rollback requirements from the scenario.

The application requires zero downtime and must guarantee that a failed deployment leaves running production instances completely unaffected.

These constraints eliminate the All at once policy (which causes downtime) and the Rolling policy (which modifies existing instances, risking inconsistent states if a failure occurs).

Select the deployment policy that isolates changes and guarantees safe rollback.

The Immutable deployment policy is selected because it deploys the new version to a temporary Auto Scaling group, ensuring the existing instances are untouched until the new version is healthy.

Immutable updates provide zero downtime and the cleanest rollback path by terminating the temporary instances upon failure.

Determine the correct directory structure for Elastic Beanstalk configuration files.

The configuration file must be placed in a directory named `.ebextensions/` at the root of the source bundle.

Elastic Beanstalk requires the leading dot in `.ebextensions/` to recognize and apply the configuration files during provisioning; a folder named `ebextensions/` without the dot is ignored.

Key Concept

AWS Elastic Beanstalk Immutable deployments and `.ebextensions` configuration directory naming.

Question 182Question →

A cloud engineering team is migrating a legacy payment service to a serverless architecture on AWS. To ensure safe deployments, they intend to implement a canary rollout where $10\%$ of traffic is shifted to the new version for $10$ minutes before the remaining traffic is cut over. They write the following AWS SAM template:

yaml
Transform: AWS::Serverless-2016-10-31

Resources:
ProcessPaymentFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs18.x
CodeUri: ./payment
DeploymentPreference:
Type: Canary10Percent10Minutes

After deploying the template, the team observes that the application traffic shifts to the new function version immediately, completely bypassing the $10$ -minute canary phase.

What is the root cause of this behavior?

The AutoPublishAlias property is omitted from the function properties, preventing AWS SAM from generating the Lambda alias and CodeDeploy resources required for traffic shifting.

The IAM role assigned to the function lacks a trust relationship allowing the AWS CodeDeploy service principal to assume it.

The execution timeout of the function is set to a value shorter than the

10

-minute canary window, causing the deployment to fail back to All-at-Once routing.

The Canary10Percent10Minutes deployment configuration is exclusive to Amazon ECS task sets and cannot be applied to serverless functions.

Show answer & explanation

Answer: The AutoPublishAlias property is omitted from the function properties, preventing AWS SAM from generating the Lambda alias and CodeDeploy resources required for traffic shifting.

Answer

The AutoPublishAlias property is omitted from the function properties, which prevents AWS SAM from generating the Lambda alias and AWS CodeDeploy resources required for gradual traffic shifting.

The correct answer is correct because AWS SAM requires the AutoPublishAlias property to be defined in order to set up gradual deployments. AutoPublishAlias instructs SAM to publish new versions of the function and create a Lambda alias pointing to them. CodeDeploy shifts traffic between these versions on the alias. If AutoPublishAlias is omitted, SAM will update the function directly, resulting in an immediate traffic shift.

Step-by-Step Solution

Analyze how AWS SAM implements gradual deployment preferences using AWS CodeDeploy under the hood.

Identified that AWS CodeDeploy requires a specific target Lambda alias to shift traffic between two underlying Lambda function versions.

Traffic routing cannot occur directly on the function's static ARN or the $LATEST version.

Examine the provided template properties for the AWS::Serverless::Function resource.

Observed that the template defines DeploymentPreference but lacks the AutoPublishAlias property under Properties.

Checking if all required properties are declared to allow SAM to synthesize the CodeDeploy resources.

Determine the outcome of omitting AutoPublishAlias during the CloudFormation transformation phase.

Without AutoPublishAlias, AWS SAM does not generate the Lambda alias resource or the CodeDeploy deployment group, leading to direct updates on $LATEST and causing traffic to shift immediately.

Explaining the root cause of the immediate traffic cutover.

Key Concept

AWS SAM Gradual Lambda Deployments with CodeDeploy and AutoPublishAlias

Estimated Time:2m 0s

Question 183Question →

A developer is preparing to update an AWS CloudFormation stack that manages a production backend application. The update involves introducing a new external service API key that must be stored securely with support for automatic rotation. Additionally, the developer must ensure that any manual, out-of-band changes previously made to the stack's resources are identified and resolved before the update is performed to prevent deployment failures.

Which combination of actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Store the API key in AWS Secrets Manager, and reference it in the CloudFormation template using a dynamic reference.

Run drift detection on the CloudFormation stack, identify any drifted resources, and update the template or import resources to resolve the differences before updating the stack.

Store the API key in Systems Manager Parameter Store as a Standard parameter, and reference it in the CloudFormation template using a Systems Manager dynamic reference.

Modify the drifted resources manually in the AWS Management Console to match the updated template configurations, then apply the stack update.

Initiate the stack update directly, and if a failure occurs, manually delete the resource that caused the rollback while the stack is in the ROLLBACK_IN_PROGRESS state.

Show answer & explanation

Answer: Store the API key in AWS Secrets Manager, and reference it in the CloudFormation template using a dynamic reference.; Run drift detection on the CloudFormation stack, identify any drifted resources, and update the template or import resources to resolve the differences before updating the stack.

Answer

Storing the API key in AWS Secrets Manager and referencing it via a dynamic reference, and running drift detection to identify and resolve drifted resources before updating the stack.

Storing the API key in AWS Secrets Manager satisfies the requirements for secure storage and automatic rotation, and referencing it via a dynamic reference ensures security. Running drift detection identifies any out-of-band changes that would cause the stack update to fail, allowing the developer to synchronize the template and actual resource configurations before deploying the update.

Step-by-Step Solution

Select the appropriate storage service for the API key.

AWS Secrets Manager is chosen because it supports automatic rotation and secure credential storage.

Systems Manager Parameter Store does not offer native automatic rotation for secrets, whereas Secrets Manager does.

Integrate the secret securely in the CloudFormation template.

Reference the secret using the Secrets Manager dynamic reference format in the template.

This prevents hardcoding sensitive credentials in the template and allows retrieval at deployment time.

Identify out-of-band resource modifications.

Execute drift detection on the CloudFormation stack.

Drift detection reveals which resources have been modified outside of CloudFormation control.

Resolve resource drift before deploying the update.

Update the template to match the drifted state or import/re-import resources as necessary.

This ensures the stack state is synchronized with the template, preventing deployment conflicts and rollback failures.

Key Concept

CloudFormation update mechanics, drift detection, and secure parameter retrieval.

Question 184Question →

A developer is using AWS CodeDeploy to deploy an update to an in-place application running on a fleet of Amazon EC2 instances. To minimize the risk of application failure, the developer wants to ensure that the update is applied to only a single Amazon EC2 instance at a time, keeping the rest of the fleet online and healthy. Which default CodeDeploy deployment configuration should the developer select?

CodeDeployDefault.HalfAtATime

CodeDeployDefault.AllAtOnce

CodeDeployDefault.OneAtATime

CodeDeployDefault.LambdaCanary10Percent5Minutes

Show answer & explanation

Answer: CodeDeployDefault.OneAtATime

Answer

CodeDeployDefault.OneAtATime

The default configuration for one at a time deploys the update to a single instance at a time. The deployment succeeds only if each instance is updated successfully, ensuring minimal impact if a deployment fails.

Step-by-Step Solution

Identify the deployment platform and type.

The platform is Amazon EC2 and the deployment type is in-place.

This determines which default deployment configurations are compatible.

Evaluate the deployment constraints.

The constraint requires deploying to only one instance at a time to minimize risk and maintain maximum availability.

This specifies the target configuration behavior.

Match the behavior to the default CodeDeploy configurations for EC2.

The configuration that targets exactly one instance at a time is the one at a time configuration.

This identifies the correct API configuration name.

Key Concept

AWS CodeDeploy deployment configurations define how deployments progress across instances in a deployment group.

Estimated Time:45s

Question 185Question →

An application running inside a Docker container on Amazon ECS needs to query an Amazon DynamoDB table. Which configuration should the developer specify in the task definition to grant the containerized application permissions to access DynamoDB?

Define the permissions in the taskRoleArn parameter of the task definition

Define the permissions in the executionRoleArn parameter of the task definition

Store IAM access keys in the application code and configure the default credential chain

Configure the ECS service-linked role with policies for DynamoDB

Show answer & explanation

Answer: Define the permissions in the taskRoleArn parameter of the task definition

Answer

Define the permissions in the taskRoleArn parameter of the task definition

The correct option is to define the permissions in the taskRoleArn parameter of the task definition. This assigns an IAM Task Role to the container, which is used by the application inside the container to authorize its calls to services like Amazon DynamoDB using the AWS SDK.

Step-by-Step Solution

Determine which component needs to access the Amazon DynamoDB table.

The application code running inside the container needs the access.

This helps distinguish between application-level requirements and container-orchestration-level requirements.

Identify the correct parameter in the ECS task definition designed for container application permissions.

The taskRoleArn parameter represents the ECS Task Role.

The Task Role credentials are automatically injected into the container environment for the SDK to use.

Key Concept

ECS Task Role vs Task Execution Role

Question 186Question →

A developer is configuring a cross-account continuous delivery pipeline in AWS CodePipeline. The pipeline resides in Account A and must deploy an application to Account B. The pipeline uses an Amazon S3 bucket in Account A to store deployable artifacts, which must be encrypted using a customer managed key in AWS KMS. Arrange the steps in the correct sequence to configure the cross-account pipeline and its security components so that the deploy action in Account B can successfully access and decrypt the artifacts.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct sequence of steps to configure the cross-account pipeline is: first, create the customer managed KMS key in Account A; second, create the IAM deployment role in Account B; third, update the S3 artifact bucket policy in Account A to grant access to the Account B role; and finally, update the pipeline JSON definition in Account A to reference these resources.

The correct sequence begins with creating the KMS key in Account A to establish cross-account encryption permissions. Next, the IAM deployment role must be created in Account B so that its ARN exists. With the role created, the S3 bucket policy in Account A can then be updated to reference the role's ARN without causing validation errors. Finally, the pipeline definition is updated to tie the KMS key and the deployment role ARN into the pipeline configuration.

Step-by-Step Solution

Create the customer managed KMS key in Account A.

A KMS key is generated, and its policy is updated to grant cross-account permissions to Account B.

This establishes the cryptographic foundation required for securing cross-account artifact sharing, allowing Account B to decrypt pipeline artifacts.

Create the IAM deployment role in Account B.

An IAM role is created with a trust policy allowing the Account A pipeline execution role to assume it.

This role is required to perform the deployment in Account B and must be created first so its ARN exists for references in other policies.

Update the S3 artifact bucket policy in Account A.

The S3 bucket policy is modified to allow the Account B deployment role access to the artifacts.

AWS S3 validates the existence of IAM principal ARNs when saving bucket policies. The role in Account B must already exist to prevent a validation error.

Update the pipeline JSON definition in Account A.

The pipeline is updated with the KMS key associated with the artifact store and the deployment role ARN specified in the deploy action.

This binds the cross-account deployment configuration together, allowing CodePipeline to assume the Account B role during the deployment stage.

Key Concept

Cross-account AWS CodePipeline deployments require a specific ordering of resource creation because IAM role ARNs are validated during the saving of resource-based policies (like S3 bucket policies), and customer managed KMS keys are required for cross-account artifact encryption.

Question 187Question →

A developer creates a new AWS CodeBuild project and configures a custom IAM role for the build environment. However, when attempting to run the build, the execution fails immediately before starting any phases with an error indicating that CodeBuild is unable to assume the configured service role. Which of the following is the most likely cause of this failure?

The buildspec.yml file has been placed in a subdirectory of the source code repository instead of the root directory.

The permissions policy attached to the custom IAM role is missing the sts:AssumeRole permission for the CodeBuild service.

The trust policy of the custom IAM role does not grant the codebuild.amazonaws.com service principal permission to assume the role.

The credentials required for the build environment were stored as Systems Manager Parameter Store String parameters instead of SecureString parameters.

Show answer & explanation

Answer: The trust policy of the custom IAM role does not grant the codebuild.amazonaws.com service principal permission to assume the role.

Answer

The trust policy of the custom IAM role does not grant the codebuild.amazonaws.com service principal permission to assume the role.

For AWS CodeBuild to execute a build project, it must assume the specified IAM service role. This requires the IAM role's trust policy (trust relationship) to explicitly list the CodeBuild service principal (codebuild.amazonaws.com) in the Principal block and allow the sts:AssumeRole action. If the trust policy is missing or misconfigured, CodeBuild will fail to assume the role and the build cannot start.

Step-by-Step Solution

Analyze the error message regarding the inability to assume the service role.

Identify that the issue is related to the relationship between the service (AWS CodeBuild) and the IAM role.

Before any build phases can run, CodeBuild must assume the service role to obtain temporary security credentials.

Verify where service trust is established in AWS IAM.

Recognize that service trust is defined in the trust policy (or trust relationship) of the role, rather than its permissions policy.

The trust policy determines which entities (users, accounts, or services) are allowed to assume the role.

Identify the correct service principal for AWS CodeBuild.

Ensure that the principal 'codebuild.amazonaws.com' is configured to allow 'sts:AssumeRole'.

If this configuration is missing, IAM blocks CodeBuild from assuming the role, resulting in an immediate failure.

Key Concept

AWS CodeBuild IAM service role trust relationship

Question 188Question →

A developer is creating an AWS Serverless Application Model (SAM) template to deploy a Lambda function that is triggered by an API Gateway endpoint. Which two template configurations or declarations are required to successfully define the serverless function and its API Gateway trigger?

Select all that apply

Include the `Transform: AWS::Serverless-2016-10-31` declaration at the root of the template

Define an `Events` property of type `Api` under the `AWS::Serverless::Function` resource

Declare `AWS::Serverless-2016-10-31` as the value for the `AWSTemplateFormatVersion` property

Configure a custom integration mapping template to manually structure the HTTP request payload for the API Gateway endpoint

Configure the trust policy of the Lambda execution role to allow the API Gateway principal (`apigateway.amazonaws.com`) to assume the role

Show answer & explanation

Answer: Include the `Transform: AWS::Serverless-2016-10-31` declaration at the root of the template; Define an `Events` property of type `Api` under the `AWS::Serverless::Function` resource

Answer

To configure the serverless function and its API Gateway trigger, the developer must include the `Transform: AWS::Serverless-2016-10-31` declaration at the root of the template and define an `Events` property of type `Api` under the `AWS::Serverless::Function` resource.

The correct configurations are including the `Transform: AWS::Serverless-2016-10-31` declaration at the root of the template to instruct CloudFormation to evaluate the SAM syntax, and defining an `Events` property of type `Api` under the `AWS::Serverless::Function` resource to set up the API Gateway trigger.

Step-by-Step Solution

Identify the required header declaration for AWS SAM templates.

Adding `Transform: AWS::Serverless-2016-10-31` instructs CloudFormation to parse the template using the SAM engine.

Without the Transform declaration, CloudFormation fails to recognize shorthand SAM resource types like AWS::Serverless::Function.

Configure the event source to trigger the Lambda function.

Adding an `Events` property with an `Api` type under the function resource establishes the API Gateway connection.

This automatically creates and links the API Gateway resource to the function with sensible default proxy configurations.

Key Concept

AWS Serverless Application Model (SAM) Template Structure

Question 189Question →

A developer is configuring a deployment pipeline using AWS CodeDeploy to update an AWS Lambda function. The deployment uses the `CodeDeployDefault.LambdaCanary10Percent10Minutes` configuration, which shifts $10\%$ of the traffic to the new version for a duration of $10\text{ minutes}$ . The traffic is routed through a Lambda alias named `live`. The developer wants to ensure the deployment automatically rolls back if the new function version introduces errors, while preventing false rollbacks caused by test executions on the `$LATEST` version or activity on other development aliases of the function. Which configuration should the developer implement to meet these requirements?

Create a CloudWatch Alarm for the Lambda `Errors` metric using the `FunctionName` and `Resource` dimensions, with the `Resource` dimension set to `my-function:live`. Associate this alarm with the CodeDeploy deployment group's rollback configuration.

Create a CloudWatch Alarm for the Lambda `Errors` metric using only the `FunctionName` dimension. Associate this alarm with the CodeDeploy deployment group's rollback configuration.

Create a CloudWatch Alarm for the Lambda `Errors` metric using the `Resource` dimension set to `my-function:$LATEST`. Associate this alarm with the CodeDeploy deployment group's rollback configuration.

Create a CloudWatch Alarm for the Lambda `Errors` metric using a dynamic `Resource` dimension set to the newly created version number. Use a CodeDeploy `BeforeAllowTraffic` lifecycle hook to update the deployment group with this alarm before traffic shifting starts.

Show answer & explanation

Answer: Create a CloudWatch Alarm for the Lambda `Errors` metric using the `FunctionName` and `Resource` dimensions, with the `Resource` dimension set to `my-function:live`. Associate this alarm with the CodeDeploy deployment group's rollback configuration.

Answer

Create a CloudWatch Alarm for the Lambda Errors metric using the FunctionName and Resource dimensions, with the Resource dimension set to the function name and the live alias. Associate this alarm with the CodeDeploy deployment group's rollback configuration.

The correct answer configuration monitors the specific Lambda alias (live) that is undergoing traffic shifting. Lambda publishes metrics under the Resource dimension in the format of FunctionName:AliasName. Monitoring this specific resource isolates the traffic routed to the production environment, ensuring that errors on other versions or aliases do not cause false alarms, and that any issues introduced by the new canary version are correctly detected.

Step-by-Step Solution

Identify how Lambda metrics are published to CloudWatch.

Recall that Lambda emits metrics with dimensions FunctionName (aggregating all traffic) and Resource (tracking a specific version or alias, formatted as FunctionName:Alias or FunctionName:Version).

To monitor the specific deployment's health, we need to know how to filter the metrics.

Evaluate which dimension isolates the deployment traffic.

The alias live is being updated by CodeDeploy. Thus, monitoring the Resource dimension with my-function:live isolates all traffic routed to the alias during the deployment, capturing errors from both the new and old versions.

This allows the alarm to trigger a rollback if the new version introduces errors, without being affected by testing on other aliases or $LATEST.

Assess the distractors against the requirements.

Distractors using only FunctionName monitor other environments. Distractors using $LATEST miss the canary traffic. Dynamic version monitoring is not supported.

To confirm that the chosen configuration is the only viable option.

Key Concept

AWS CodeDeploy automates Lambda traffic shifting using aliases. Monitoring for automatic rollbacks must use the specific alias Resource dimension to isolate deployment-related errors and avoid false rollbacks from unrelated invocations.

Estimated Time:2m 0s

Question 190Question →

A developer is configuring an Amazon ECS task definition to run a microservice on AWS Fargate. The containerized application must retrieve database credentials stored as SecureString parameters in Systems Manager Parameter Store and inject them as environment variables during container startup. Additionally, the application code inside the container needs to read and write items in an Amazon DynamoDB table at runtime. Which configuration of IAM roles should the developer specify in the task definition to satisfy these requirements?

Specify a Task Execution Role containing permissions to retrieve the Parameter Store parameters, and a Task Role containing permissions to access the DynamoDB table, but configure the trust policy of the Task Role to trust the DynamoDB service.

Specify a Task Execution Role containing permissions to retrieve the Parameter Store parameters, and a Task Role containing permissions to access the DynamoDB table.

Specify a Task Role containing permissions to both retrieve the Parameter Store parameters and access the DynamoDB table, leaving the Task Execution Role empty.

Specify a Task Execution Role containing permissions to both retrieve the Parameter Store parameters and access the DynamoDB table, leaving the Task Role empty.

Show answer & explanation

Answer: Specify a Task Execution Role containing permissions to retrieve the Parameter Store parameters, and a Task Role containing permissions to access the DynamoDB table.

Answer

Specify a Task Execution Role containing permissions to retrieve the Parameter Store parameters, and a Task Role containing permissions to access the DynamoDB table.

The correct answer properly separates the concerns of task bootstrapping and container runtime execution. The Task Execution Role is utilized by the Amazon ECS container agent to pull secrets from Systems Manager Parameter Store and inject them into the container's environment variables before startup. The Task Role is assumed by the application code running inside the container to make AWS SDK calls to Amazon DynamoDB at runtime. Both roles must trust the ECS tasks service principal to be assumed correctly.

Step-by-Step Solution

Identify the agent-level requirements during container bootstrap.

The ECS agent needs to fetch SSM Parameter Store secure parameters to inject them as environment variables before the container starts, which requires the ECS Task Execution Role.

The Task Execution Role grants the ECS container agent permissions to make AWS API calls on your behalf (such as pulling container images and pulling secrets).

Identify the application-level requirements at runtime.

The application code running inside the container needs to read/write to the DynamoDB table, which requires the ECS Task Role.

The Task Role grants the containerized application itself permissions to call AWS APIs at runtime.

Verify trust policy configurations.

Both roles must have a trust policy allowing the ecs-tasks.amazonaws.com service principal to assume the role.

Trust policies determine which entities (in this case, ECS tasks) are permitted to assume the IAM roles.

Key Concept

Distinction between ECS Task Role and ECS Task Execution Role

Estimated Time:1m 30s

Question 191Question →

A developer is deploying a web application using AWS CloudFormation. The template configures an Amazon EC2 Auto Scaling group behind an Application Load Balancer. The EC2 instances must install application software packages and retrieve a database password from parameter storage during startup. The database password must be rotated automatically every 30 days. Currently, the stack deployment finishes and is marked complete before the application initialization script finishes on the EC2 instances, causing the application to fail to connect to the database. How should the developer configure the CloudFormation template and startup scripts to resolve these issues in a secure and reliable manner?

Configure the launch template's UserData to run the initialization. If the configuration fails and the stack transitions to the ROLLBACK_IN_PROGRESS state, use the UpdateStack API with the ContinueUpdateRollback parameter to force the instances to retry the setup script without deleting the stack resources.

Configure a CreationPolicy on the Auto Scaling group resource. Store the database password in AWS Systems Manager Parameter Store as a Standard Parameter to reduce costs, and use the ssm dynamic reference in the launch template's UserData to inject the password. Execute cfn-signal at the start of the UserData script before the application installation begins.

Configure a CreationPolicy on the Auto Scaling group resource. Store the database password in AWS Secrets Manager to support automatic rotation, and configure the EC2 instances to retrieve the password at runtime using the AWS SDK. In the launch template's UserData script, execute the software installation, retrieve the database password, and invoke the cfn-signal helper script only after the initialization is fully complete.

Manually log in to each EC2 instance after CloudFormation completes the stack deployment to install the software packages and configure the database connection. Run CloudFormation drift detection on the Auto Scaling group to ensure that the manual changes do not cause the stack to drift from its template definition.

Show answer & explanation

Answer: Configure a CreationPolicy on the Auto Scaling group resource. Store the database password in AWS Secrets Manager to support automatic rotation, and configure the EC2 instances to retrieve the password at runtime using the AWS SDK. In the launch template's UserData script, execute the software installation, retrieve the database password, and invoke the cfn-signal helper script only after the initialization is fully complete.

Answer

The correct solution uses a CreationPolicy on the Auto Scaling group resource to halt the stack creation progress until a success signal is received. By placing the cfn-signal command at the end of the UserData script, the developer ensures that the signal is only sent after the software packages are fully installed and configured. Furthermore, AWS Secrets Manager is used because it natively supports the required 30-day automatic rotation, and retrieving the secret at runtime using the AWS SDK is a secure practice.

Step-by-Step Solution

Configure a CreationPolicy on the Auto Scaling group resource in the CloudFormation template.

CloudFormation will pause the resource creation process and wait for a specified number of success signals before transitioning the Auto Scaling group to CREATE_COMPLETE.

This prevents CloudFormation from marking the stack creation as successful before the instances are actually ready.

Store the database password in AWS Secrets Manager and enable automatic rotation.

The password is secure, and Secrets Manager automatically rotates it every 30 days without manual intervention.

Systems Manager Parameter Store does not natively support automatic rotation of secrets, making Secrets Manager the correct choice for this requirement.

Modify the instance launch template's UserData to install the application, retrieve the password via AWS SDK, and invoke cfn-signal at the end of the script.

The instances configure themselves on startup and signal CloudFormation of success only after all initialization steps are complete.

Signaling only at the end of the script ensures the instance is fully operational before the stack transitions to success.

Key Concept

CloudFormation CreationPolicy, helper scripts (cfn-signal), and Secrets Manager integration

Estimated Time:2m 30s

Question 192Question →

A developer is managing a production web application deployed via an AWS CloudFormation stack. The stack includes an Amazon RDS database and an Amazon ECS service. The database credentials must be rotated automatically every 30 days. To troubleshoot an urgent connectivity issue, a system administrator manually modified the database security group rules and the database master password directly in the AWS Management Console. When the developer subsequently attempts to update the stack to deploy a new ECS task definition, the stack update fails.

Which two actions should the developer take to resolve the update failure and align the infrastructure with AWS security best practices? (Select TWO.)

Select all that apply

Run drift detection on the stack to identify the out-of-band changes, and update the CloudFormation template to match the current database security group configuration.

Store the database credentials in AWS Secrets Manager, and reference them in the CloudFormation template using dynamic references to support automatic rotation.

Store the database credentials in Systems Manager Parameter Store as String parameters, and enable the native Parameter Store rotation schedule.

Revert the manual security group modifications using the AWS Management Console, and use the `cfn-init` helper script within the ECS container definition to dynamically retrieve the new credentials during container startup.

Manually change the stack status to `ROLLBACK_COMPLETE` in the CloudFormation console to bypass the failed update, then proceed with the task definition deployment.

Show answer & explanation

Answer: Run drift detection on the stack to identify the out-of-band changes, and update the CloudFormation template to match the current database security group configuration.; Store the database credentials in AWS Secrets Manager, and reference them in the CloudFormation template using dynamic references to support automatic rotation.

Answer

Run drift detection on the stack to identify the out-of-band changes, update the CloudFormation template to match the current database security group configuration, store the database credentials in AWS Secrets Manager, and reference them in the template using dynamic references.

To resolve the CloudFormation update failure due to manual out-of-band modifications, the developer should run drift detection to identify the changes and update the template configuration to match the current physical state. To securely manage the database password and satisfy the rotation requirement, the developer should store the credentials in AWS Secrets Manager, which natively supports automatic rotation, and reference them in the CloudFormation template using dynamic references.

Step-by-Step Solution

Detect drift to identify out-of-band changes.

The differences between the expected template configuration and the actual physical resource configuration of the security groups are identified.

This determines exactly what has changed manually so the template can be synchronized without overwriting intended configuration changes.

Update the template to match the drifted state.

The template definition of the security groups is updated to match the manually modified rules.

Aligning the template with the drifted state ensures subsequent CloudFormation updates do not fail due to configuration mismatch or attempt to overwrite the database's network access settings.

Migrate credentials to AWS Secrets Manager and configure dynamic references.

The database credentials are secured in Secrets Manager with automatic rotation enabled, and the template references them dynamically.

Secrets Manager provides secure storage and automatic rotation of credentials, which are referenced at runtime without hardcoding in the CloudFormation template or application configuration.

Key Concept

Handling resource drift and managing secrets securely in AWS CloudFormation.

Question 193Question →

A developer is selecting deployment strategies for a production web application. The application has two strict requirements: there must be zero downtime during the deployment process, and the application must be able to roll back to the previous version immediately if a failure is detected. Which of the following deployment strategies satisfy both of these requirements? (Select TWO.)

Select all that apply

Blue/Green deployment

Canary deployment

All-at-once deployment

Rolling deployment

In-place deployment

Show answer & explanation

Answer: Blue/Green deployment; Canary deployment

Answer

Blue/Green deployment and Canary deployment satisfy the requirements because they both allow traffic to be shifted between environments or versions with zero downtime, and can immediately route traffic back to the stable version if a failure occurs.

The correct strategies are Blue/Green deployment and Canary deployment. In a Blue/Green deployment, a separate environment is created, and traffic is cut over, allowing an immediate rollback by shifting traffic back if an error occurs. In a Canary deployment, traffic is shifted incrementally, and if alarms fire, traffic is immediately routed back to the old version. Both methods guarantee zero downtime and immediate rollback.

Step-by-Step Solution

Identify the downtime requirements of the candidate deployment strategies.

Blue/Green and Canary strategies support zero downtime by keeping both versions of the application active. All-at-once and standard In-place strategies incur downtime.

To filter out strategies that cause application offline states.

Analyze the rollback capabilities of the remaining strategies.

Blue/Green and Canary strategies can roll back immediately by shifting traffic back to the original version. Rolling and All-at-once strategies require a redeployment of the previous version to roll back.

To identify which strategies meet the immediate rollback constraint.

Key Concept

Downtime and rollback trade-offs of AWS deployment strategies.

Estimated Time:45s

Question 194Question →

A developer is deploying a serverless application using AWS SAM. During the deployment process, AWS CloudFormation returns a validation error stating that the resource type 'AWS::Serverless::Function' could not be found or is invalid. Which of the following is the most likely cause of this error?

The template is missing the required Transform declaration specifying the AWS::Serverless-2016-10-31 transform.

The Lambda function's execution role has a misconfigured trust policy that prevents AWS CloudFormation from assuming the role.

The Lambda function is configured with a timeout value that exceeds the maximum limit allowed for serverless function resources.

The template specifies a Lambda proxy integration when it should be configured as a Lambda custom integration.

Show answer & explanation

Answer: The template is missing the required Transform declaration specifying the AWS::Serverless-2016-10-31 transform.

Answer

The template is missing the required Transform declaration specifying the AWS::Serverless-2016-10-31 transform.

The correct answer is correct because AWS SAM is an extension of AWS CloudFormation. In order for CloudFormation to recognize and parse SAM-specific resource types like AWS::Serverless::Function, the template must include the 'Transform: AWS::Serverless-2016-10-31' declaration. This declaration tells CloudFormation to run the macro that translates the SAM template into standard CloudFormation resources.

Step-by-Step Solution

Analyze the CloudFormation error message.

The error indicates that the resource type 'AWS::Serverless::Function' is unrecognized or invalid.

This error occurs because CloudFormation does not natively support the AWS::Serverless namespace without a translator.

Identify the mechanism that enables CloudFormation to parse SAM resources.

The template must contain the 'Transform: AWS::Serverless-2016-10-31' declaration.

The Transform declaration instructs CloudFormation to invoke the SAM transform macro, which translates SAM-specific resources into standard CloudFormation resources during deployment.

Key Concept

AWS SAM templates must include the Transform declaration to translate serverless resources into standard CloudFormation resources.

Question 195Question →

A company's CI/CD pipeline uses AWS CodeBuild to compile a web application. The build process requires the main application source code from a primary AWS CodeCommit repository, as well as a common stylesheet template from a secondary AWS CodeCommit repository. The developer configures the CodeBuild project with multiple input sources, setting the secondary source identifier to CommonStyles. During the build, the buildspec must copy the stylesheet from the secondary source directory to the main application's public assets folder. How should the developer reference the file path of the secondary source inside the buildspec.yml file to perform this copy operation?

Reference the directory path using the `$CODEBUILD_SRC_DIR_CommonStyles` environment variable.

Reference the directory path using a relative path from the primary source directory, such as `../CommonStyles`.

Reference the directory path as a subdirectory of the primary working directory, such as `$CODEBUILD_SRC_DIR/CommonStyles`.

Store the repository URL in AWS Systems Manager Parameter Store and resolve it using the `parameters` section of the buildspec.

Show answer & explanation

Answer: Reference the directory path using the `$CODEBUILD_SRC_DIR_CommonStyles` environment variable.

Answer

Reference the directory path using the `$CODEBUILD_SRC_DIR_CommonStyles` environment variable.

When configured with multiple input sources, AWS CodeBuild downloads the primary source to the default build directory referenced by `

CODEBUILD_SRC_DIR`. For each secondary source, CodeBuild creates a separate directory and generates a dedicated environment variable named `

CODEBUILD_SRC_DIR_source_identifier` where `source_identifier` is the unique identifier specified in the project configuration. Therefore, referencing `$CODEBUILD_SRC_DIR_CommonStyles` provides the correct path to the secondary source repository's files.

Step-by-Step Solution

Identify how AWS CodeBuild handles multiple input sources during a build execution.

The primary source is downloaded to the directory referenced by `$CODEBUILD_SRC_DIR`, while secondary sources are downloaded to separate locations.

Understanding the isolation of source directories prevents incorrect assumptions about directory nesting or relative paths.

Determine how CodeBuild exposes the paths of secondary sources to the build environment.

CodeBuild dynamically generates environment variables for each secondary source matching the pattern `$CODEBUILD_SRC_DIR_source_identifier`.

This allows buildspec shell commands to programmatically locate and reference files across different repositories.

Select the specific environment variable matching the configured source identifier CommonStyles.

The correct environment variable is `$CODEBUILD_SRC_DIR_CommonStyles`.

This environment variable contains the absolute path to the directory containing the common stylesheet template.

Key Concept

AWS CodeBuild Multiple Source Inputs

Question 196Question →

A developer is setting up a release pipeline in AWS CodePipeline that consists of a Source stage, a Build stage using AWS CodeBuild, and a Deploy stage. The developer needs to pass the build output files from the Build stage to the Deploy stage. Which configuration must the developer specify in the pipeline definition to transfer these files?

Configure the build action to upload the zip archive to a custom Amazon S3 bucket, and modify the Deploy stage's IAM role trust policy to trust the CodeBuild service role directly.

Configure the build action to produce an output artifact, and configure the deploy action to accept that artifact as an input artifact.

Save the binary payload of the build output directly inside AWS Systems Manager Parameter Store as a SecureString parameter, then configure the deploy action to retrieve it.

Define the artifact paths within a custom buildspec.yml file located in a /config subdirectory of the source repository, and reference the paths as environment variables in the deploy stage.

Show answer & explanation

Answer: Configure the build action to produce an output artifact, and configure the deploy action to accept that artifact as an input artifact.

Answer

Configure the build action to produce an output artifact, and configure the deploy action to accept that artifact as an input artifact.

In AWS CodePipeline, files are passed between stages using input and output artifacts. The developer defines an output artifact for the CodeBuild action and references it as an input artifact in the deployment action. CodePipeline automatically manages the storage of these files in an Amazon S3 artifact bucket associated with the pipeline.

Step-by-Step Solution

Identify the AWS CodePipeline mechanism for passing files between stages.

CodePipeline uses InputArtifacts and OutputArtifacts to move files between actions.

This is the native, secure, and automated way to manage flow of files in CodePipeline.

Assign the output artifact name in the Build stage.

The Build stage action produces an output artifact named (e.g.) BuildArtifact.

This registers the build output in CodePipeline's artifact store.

Reference the same artifact name as the input artifact in the Deploy stage.

The Deploy stage action consumes BuildArtifact as its input.

This tells CodePipeline to feed the build output files into the deployment step.

Key Concept

CodePipeline Artifacts

Estimated Time:1m 30s

Question 197Question →

A developer is using AWS Serverless Application Model (SAM) to deploy updates to a critical Lambda function. The deployment must satisfy the following constraints:
- Traffic must be shifted from the old version to the new version gradually, in increments of 10% every 2 minutes.
- The deployment must automatically roll back if the execution error rate or latency metrics exceed predefined thresholds.
- Integration test suites must run before traffic starts shifting, and a cleanup script must run after all traffic has shifted to the new version.

Which TWO configurations must the developer specify in the AWS SAM template to satisfy these requirements?

Select all that apply

Configure the AutoPublishAlias property under the Serverless Function resource to define the alias that will receive the shifted traffic.

Under DeploymentPreference, set the Type to Linear10PercentEvery2Minutes, list the rollback alarms under Alarms, and define the PreTraffic and PostTraffic lifecycle hooks.

Under DeploymentPreference, set the Type to Canary10PercentEvery2Minutes and define the hooks under BeforeAllowTraffic and AfterAllowTraffic.

Define a custom CodeDeploy deployment configuration named CodeDeployDefault.LambdaLinear10PercentEvery2Minutes in the Resources section of the template.

Under DeploymentPreference, set the Type to AllAtOnce and configure a custom AWS CodePipeline action to rollback the stack if the CloudWatch alarms transition to the ALARM state.

Show answer & explanation

Answer: Configure the AutoPublishAlias property under the Serverless Function resource to define the alias that will receive the shifted traffic.; Under DeploymentPreference, set the Type to Linear10PercentEvery2Minutes, list the rollback alarms under Alarms, and define the PreTraffic and PostTraffic lifecycle hooks.

Answer

The developer must specify the AutoPublishAlias property under the Serverless Function resource to define the alias for traffic routing, and configure the DeploymentPreference section with Type: Linear10PercentEvery2Minutes along with the rollback alarms and the PreTraffic and PostTraffic hooks.

To perform gradual traffic shifting with AWS SAM, the function must have AutoPublishAlias enabled. In addition, the deployment strategy must be specified via DeploymentPreference with Type: Linear10PercentEvery2Minutes to shift traffic by 10% every 2 minutes. The template must also reference CloudWatch alarms for automated rollback and specify PreTraffic and PostTraffic hooks to execute validation tests and cleanup operations.

Step-by-Step Solution

Enable traffic shifting support by defining an alias configuration.

Define the AutoPublishAlias property under the AWS::Serverless::Function resource.

AWS SAM cannot perform gradual deployment unless a function alias is defined to shift traffic between the old and new versions.

Select the correct linear deployment type configuration.

Set the Type under DeploymentPreference to Linear10PercentEvery2Minutes.

This built-in configuration matches the requirement of shifting 10% of the traffic every 2 minutes.

Link safety controls and lifecycle hooks for validation.

Reference the CloudWatch alarms under Alarms and the Lambda validation functions under the PreTraffic and PostTraffic hook properties.

Alarms trigger automatic rollback during the deployment, and hooks run integration tests before traffic shifting starts and cleanup after traffic shifting completes.

Key Concept

Configuring AWS SAM safe deployments (DeploymentPreference) using built-in CodeDeploy types, aliases, alarms, and lifecycle hooks.

Estimated Time:2m 30s

Question 198Question →

A developer is setting up an AWS CodeBuild project to compile a simple web application. The developer needs to define the build commands and pull database connection configurations securely during the build execution.

Which TWO configurations are required to support this setup? (Select TWO.)

Select all that apply

Place the buildspec.yml file at the root of the source directory to define the build phases.

Reference sensitive database configurations from AWS Systems Manager Parameter Store or AWS Secrets Manager in the env section of the buildspec file.

Save the buildspec.yml file within a custom .codebuild/ subfolder at the top level of the repository without specifying a custom path in the project configuration.

Store non-sensitive configuration parameters in AWS Secrets Manager rather than AWS Systems Manager Parameter Store to optimize cost.

Edit the IAM permission policy attached to the CodeBuild service role to allow the CodeBuild service to assume the role.

Show answer & explanation

Answer: Place the buildspec.yml file at the root of the source directory to define the build phases.; Reference sensitive database configurations from AWS Systems Manager Parameter Store or AWS Secrets Manager in the env section of the buildspec file.

Answer

Placing the buildspec.yml file at the root of the source directory and referencing database configurations from Parameter Store or Secrets Manager in the env section of the buildspec file.

The correct options are placing the buildspec.yml file at the root of the source directory, which CodeBuild automatically locates, and referencing sensitive database configurations from Parameter Store or Secrets Manager in the env section of the buildspec to securely retrieve secrets.

Step-by-Step Solution

Determine the default buildspec file placement.

CodeBuild expects the buildspec.yml file at the root of the source repository unless a custom path is specified in the build project settings.

This allows the build runner to find and execute the build steps automatically.

Determine the secure configuration retrieval method.

Map database configurations dynamically inside the env parameter block of the buildspec using Parameter Store or Secrets Manager.

This avoids hardcoding sensitive information in the source code.

Key Concept

AWS CodeBuild buildspec configuration and secret retrieval

Question 199Question →

A developer is writing an AWS CloudFormation template to deploy a web application. The application requires two configurations:
1. A database connection password that must be rotated automatically every 30 days.
2. A database connection port number, which is a non-sensitive configuration parameter.

To optimize operational efficiency, security, and cost, how should the developer store and reference these configurations in the CloudFormation template?

Store both the database password and the port number in AWS Secrets Manager, and reference both in the template using Secrets Manager dynamic references.

Store the database password in Systems Manager Parameter Store as a SecureString parameter with automatic rotation enabled, and store the port number in AWS Secrets Manager.

Store the database password in AWS Secrets Manager and reference it using a Secrets Manager dynamic reference in the template. Store the port number in Systems Manager Parameter Store and reference it using an SSM dynamic reference.

Store the database password as a standard CloudFormation Parameter with NoEcho set to true, and manually update the stack parameters whenever the password is rotated.

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and reference it using a Secrets Manager dynamic reference in the template. Store the port number in Systems Manager Parameter Store and reference it using an SSM dynamic reference.

Answer

The correct approach is to store the sensitive database password in AWS Secrets Manager because it supports native automatic rotation every 30 days. To optimize costs, the non-sensitive port number should be stored in Systems Manager Parameter Store as it is free for standard parameters. Both can be securely referenced in the CloudFormation template using dynamic references without exposing plaintext values.

Step-by-Step Solution

Analyze the security and rotation requirements for the database password.

Identify that AWS Secrets Manager is required because it natively supports automatic rotation (every 30 days) and secure storage of sensitive credentials.

To meet the security and compliance requirement of automated rotation.

Analyze the requirements for the database port number.

Identify that the port number is non-sensitive and does not require rotation or high-cost storage, making AWS Systems Manager Parameter Store the most cost-effective service.

To optimize costs and distinguish between sensitive and non-sensitive configurations.

Determine how to reference both configurations in the CloudFormation template securely.

Use CloudFormation dynamic references to retrieve the values at runtime without hardcoding them in the template.

To maintain infrastructure-as-code best practices and avoid credential exposure in version control.

Key Concept

AWS CloudFormation Dynamic References

Question 200Question →

An operations engineer is establishing a continuous deployment workflow for a critical microservice. The pipeline is designed to fetch code from a repository, package the application using AWS CodeBuild, create an AWS CloudFormation change set, require manual intervention for approval, and finally execute the change set.

In what chronological order do these events occur during a successful pipeline execution?

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The pipeline execution begins with the Source action detecting a commit and uploading the source ZIP file to S3. Next, the Build action downloads this source archive, runs the buildspec, and uploads the compiled package back to S3. Following the build, the first deployment action uses AWS CloudFormation to create a change set. The pipeline then pauses at the Manual Approval action to await user consent. Once approved, the final deployment action executes the CloudFormation change set to update the infrastructure.

The correct chronological sequence starts with the source action retrieving the codebase, followed by CodeBuild compiling and packaging the app. Once packaged, CloudFormation creates a change set so that the proposed infrastructure changes are calculated. The pipeline then pauses at the manual approval stage for verification. Finally, after approval, CloudFormation executes the change set to deploy the resources.

Step-by-Step Solution

Trigger pipeline and output source artifact

The Source stage runs, fetching code from the repository and storing it in the Amazon S3 artifact bucket.

AWS CodePipeline requires a source action to pull the source code and produce an input artifact for subsequent stages.

Compile and package the application

AWS CodeBuild runs the build stage, compiling code and outputting a packaged application template artifact to S3.

The build stage consumes the source artifact and produces the deployment package required by the deployment actions.

Generate the infrastructure change proposal

AWS CloudFormation creates a change set showing what resources will be created, modified, or deleted.

Creating a change set allows developers to review the proposed modifications before they are applied to the live environment.

Pause pipeline for manual approval

The pipeline halts transition to the next action, publishes a notification to an SNS topic, and waits for an approval decision.

This manual approval action is configured between the change set creation and execution to enforce gates and human validation.

Apply the infrastructure changes

AWS CloudFormation executes the previously created change set, deploying the updates to the stack.

After the manual approval action is approved, the execution resumes and applies the change set.

Key Concept

AWS CodePipeline execution flow, artifact transition, and integration of CloudFormation change sets with manual approvals.

PreviousPage 10 / 19Next

Deployment

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

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept