Deployment

376 questions

All types376 Multiple choice191 Multiple select171 Ordering14

A developer is configuring a backend worker application to run on Amazon ECS using the AWS Fargate launch type. The application code running inside the container needs to read and write items in an Amazon DynamoDB table. The container image is hosted in a private Amazon ECR repository located in a separate, central shared AWS account. Additionally, the task definition retrieves sensitive database credentials stored in encrypted AWS Systems Manager Parameter Store parameters and injects them as environment variables at task startup. Which of the following configuration steps are required to successfully deploy the task and run the application? (Select TWO.)

Select all that apply

Assign an IAM role as the Task Role that contains a policy granting dynamodb:GetItem and dynamodb:PutItem permissions on the target DynamoDB table.

Assign an IAM role as the Task Execution Role that contains policies granting ssm:GetParameters and kms:Decrypt permissions, and configure the central ECR repository policy to allow ECR pull actions for this role.

Assign an IAM role as the Task Execution Role that contains a policy granting dynamodb:GetItem and dynamodb:PutItem permissions on the target DynamoDB table.

Attach a policy to the Task Role granting ssm:GetParameters and kms:Decrypt permissions to enable the containerized application to pull the environment variables at launch.

Configure the trust relationship of the Task Execution Role to allow the central ECR repository's service principal ecr.amazonaws.com to assume the role.

Show answer & explanation

Answer: Assign an IAM role as the Task Role that contains a policy granting dynamodb:GetItem and dynamodb:PutItem permissions on the target DynamoDB table.; Assign an IAM role as the Task Execution Role that contains policies granting ssm:GetParameters and kms:Decrypt permissions, and configure the central ECR repository policy to allow ECR pull actions for this role.

Answer

To successfully deploy and run the application, you must assign an IAM role as the Task Role with DynamoDB access policy, and assign another IAM role as the Task Execution Role with SSM Parameter Store and KMS decryption permissions, while updating the central ECR repository policy to allow cross-account pulls.

The correct options are: assigning an IAM role as the Task Role with DynamoDB permissions, and assigning an IAM role as the Task Execution Role with SSM Parameter Store and KMS permissions alongside ECR cross-account repository access. This correctly separates the runtime application permissions (Task Role) from the container startup and orchestration permissions (Task Execution Role).

Step-by-Step Solution

Differentiate application-level and container-level permissions.

Identify that accessing DynamoDB is an application action, which requires permissions on the Task Role. Pulling the Docker image and retrieving configuration secrets at startup are agent-level actions, which require permissions on the Task Execution Role.

ECS separates permissions between what the container agent needs to boot the task (Task Execution Role) and what the running application needs (Task Role).

Configure permissions for accessing DynamoDB.

Create a policy allowing dynamodb:GetItem and dynamodb:PutItem on the target table, and attach it to the Task Role.

The code running inside the container utilizes the credentials provided by the Task Role at runtime.

Configure permissions for pulling the cross-account ECR image.

Update the repository policy in the central AWS account to allow the task execution role of the application account to perform pull actions (ecr:BatchGetImage, ecr:GetDownloadUrlForLayer).

Cross-account ECR pulls require both the puller to have IAM permissions and the ECR repository to explicitly trust the cross-account principal.

Configure permissions for SSM Parameter Store secrets resolution.

Attach policies allowing ssm:GetParameters and kms:Decrypt on the KMS key to the Task Execution Role.

Using the valueFrom syntax in the task definition instructs the ECS agent to fetch and decrypt the parameters at task creation time before launching the container.

Key Concept

Delineating responsibilities and permissions between the ECS Task Role and the ECS Task Execution Role for Fargate deployments.

Question 222Question →

A developer writes an AWS Serverless Application Model (SAM) template to deploy a Lambda function that reads objects from an Amazon S3 bucket. The template is configured as follows:

yaml
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Resources:
ProcessUploadsFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: ./src
Handler: index.handler
Runtime: nodejs18.x
Policies:
- S3ReadPolicy

When executing `sam deploy`, the deployment fails with a CloudFormation template validation or parsing error. Which of the following describes the root cause of this deployment failure and the correct resolution?

The S3ReadPolicy template requires a parameter. The developer must specify the target bucket name by structuring the policy as an object with the BucketName property.

The template lacks the required Transform declaration at the root level, causing CloudFormation to fail to parse serverless resources.

The execution role for the function lacks a trust relationship policy. The developer must manually configure an IAM trust policy to trust the Lambda service.

The function lacks credentials to read from the bucket. The developer must retrieve the credentials using a Systems Manager Parameter Store dynamic reference.

Show answer & explanation

Answer: The S3ReadPolicy template requires a parameter. The developer must specify the target bucket name by structuring the policy as an object with the BucketName property.

Answer

The S3ReadPolicy template requires a parameter, meaning the developer must specify the target bucket name by structuring the policy as an object with the BucketName property.

AWS SAM policy templates allow developers to easily scope permissions for Lambda functions. However, many policy templates (such as `S3ReadPolicy`) require parameters to be explicitly defined. Specifying the policy template name as a string element under the `Policies` list is invalid when parameters are required. The correct approach is to define it as an object with the required parameters (e.g., `S3ReadPolicy` mapped to a nested `BucketName` property).

Step-by-Step Solution

Examine the Policies property configuration in the SAM template.

The template defines the policy as a string element in a list: `- S3ReadPolicy`.

To identify why the validation or parsing error occurred during deployment.

Review the requirements for the AWS SAM S3ReadPolicy template.

The S3ReadPolicy requires the `BucketName` parameter to scope the read permissions to a specific S3 bucket.

To determine whether the policy template requires arguments or can be used as a simple string.

Reformat the policy definition to supply the required parameter.

Change the policy definition to a key-value object containing the policy template name and the bucket reference.

To satisfy the parameter validation requirements of the SAM translator.

Key Concept

AWS SAM Policy Templates Parameter Requirements

Question 223Question →

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

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

Which Elastic Beanstalk deployment strategy satisfies these requirements?

Rolling

Rolling with additional batch

Immutable

All-at-once

Show answer & explanation

Answer: Immutable

Answer

The immutable deployment strategy satisfies the requirements by launching a temporary Auto Scaling group to deploy the new application version, maintaining full capacity of the original environment, and allowing for an immediate, non-disruptive rollback if health checks fail.

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

Step-by-Step Solution

Analyze the capacity requirement.

Since the environment must maintain its full capacity of 8 healthy instances running the current version, any strategy that takes existing instances offline (such as Rolling or All-at-once) is ruled out. This leaves 'Immutable' and 'Rolling with additional batch' as potential options.

To ensure peak performance is not degraded during the deployment.

Evaluate the rollback and active environment constraints.

A rollback must be immediate and must not perform redeployment steps on the existing active instances. 'Rolling with additional batch' updates the existing instances in the active Auto Scaling group; if a failure occurs, it must perform a rollback by redeploying the older version back to the updated instances, which takes time and modifies active instances. 'Immutable' uses a separate temporary Auto Scaling group, so a rollback simply involves terminating that group, leaving the original group completely untouched.

To determine which strategy isolates the rollback impact and provides the fastest recovery time.

Confirm health check validation.

The immutable deployment strategy validates the health of all instances in the temporary Auto Scaling group before cutting over traffic, meeting the validation requirement.

To verify that the chosen strategy aligns with all remaining constraints.

Key Concept

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

Question 224Question →

A developer manages a web application deployed via an AWS CloudFormation stack. The stack contains an Amazon ECS service and an Amazon RDS database instance. During troubleshooting, a team member manually modifies the RDS security group rules in the AWS Management Console to allow temporary access. During a subsequent stack update to deploy a new ECS task definition, the update fails and the stack is left in the UPDATE_ROLLBACK_FAILED state. Additionally, the developer needs to store the database credentials securely and enable automatic rotation. Which approach should the developer take to resolve the stack's state and manage the credentials?

Use the Continue Update Rollback feature in CloudFormation to return the stack to a stable state. Use drift detection to identify the manual security group modifications and update the CloudFormation template to match. Store the credentials in AWS Secrets Manager and reference them using a dynamic reference in the template.

Execute a new stack update immediately using the update-stack CLI command. Store the credentials in Systems Manager Parameter Store, as it natively supports automatic rotation, and let the update overwrite the manual security group changes.

Delete the stack entirely to clear the rollback state, then redeploy it. Continue to manually configure the security groups in the console after deployment. Store the database credentials as secure string parameters in Systems Manager Parameter Store with automatic rotation.

Perform a nested stack update to bypass the rollback block on the main stack. Keep the security group rules manually managed in the console. Store the database credentials in the template's Parameters section with NoEcho set to true.

Show answer & explanation

Answer: Use the Continue Update Rollback feature in CloudFormation to return the stack to a stable state. Use drift detection to identify the manual security group modifications and update the CloudFormation template to match. Store the credentials in AWS Secrets Manager and reference them using a dynamic reference in the template.

Answer

The correct approach involves first resolving the UPDATE_ROLLBACK_FAILED state by invoking the Continue Update Rollback action, which allows the stack to return to a stable ROLLBACK_COMPLETE state. Afterwards, drift detection should be used to identify manual, out-of-band changes (such as the security group modifications) so that the template can be updated to align with the actual infrastructure. For database credentials requiring automatic rotation, AWS Secrets Manager is the appropriate service, and using a dynamic reference in the template ensures secure integration without hardcoding secrets.

Step-by-Step Solution

Resolve the rollback state of the CloudFormation stack.

The stack transitions from UPDATE_ROLLBACK_FAILED to UPDATE_ROLLBACK_COMPLETE.

You cannot perform new updates on a stack stuck in UPDATE_ROLLBACK_FAILED. Continue Update Rollback must be executed to return the stack to a stable state.

Perform drift detection and reconcile out-of-band changes.

Template is updated to align with the manually modified security groups or the resources are reverted to match the template.

Out-of-band changes create drift, causing subsequent stack operations to fail or overwrite configuration unintentionally.

Configure secure credential management with automatic rotation.

Credentials are created in AWS Secrets Manager and referenced dynamically in the template.

AWS Secrets Manager natively supports automatic rotation of database credentials, unlike Systems Manager Parameter Store which only stores static parameters without built-in rotation workflows.

Key Concept

Handling CloudFormation rollback failures, managing resource drift, and using AWS Secrets Manager dynamic references for credentials requiring automatic rotation.

Estimated Time:2m 0s

Question 225Question →

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

Select all that apply

Blue/green deployment

Immutable deployment

Rolling deployment

All-at-once deployment

In-place deployment

Show answer & explanation

Answer: Blue/green deployment; Immutable deployment

Answer

The correct strategies are blue/green deployment and immutable deployment, as both strategies provision entirely new instances for the new application version rather than updating existing instances in-place.

Blue/green deployment and immutable deployment are designed to launch new instances for the new deployment version. Blue/green deployment creates a duplicate environment where the new version is tested before shifting traffic. Immutable deployment replaces the existing instances with new ones by launching a temporary Auto Scaling group, verifying the instances, and terminating the old ones. Both strategies preserve the original instances unchanged during the initial deployment phase, allowing for a fast and clean rollback.

Step-by-Step Solution

Analyze the scenario constraints and requirements.

The target strategy must deploy the application to brand new instances and avoid in-place updates to facilitate a clean separation and quick rollback.

This allows filtering out any deployment strategies that update existing instances directly.

Evaluate the deployment strategies against the requirement of using new instances.

Blue/green deployment creates a separate parallel environment of new instances. Immutable deployment provisions new instances in a separate Auto Scaling group or environment before terminating the old ones.

Both methods fulfill the core requirement of using new instances to avoid configuration drift and allow rapid rollback.

Identify why other options fail.

Rolling, all-at-once, and in-place updates deploy code directly onto the existing virtual machines, meaning they update the instances in-place.

This confirms that only blue/green and immutable deployments meet all constraints.

Key Concept

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

Question 226Question →

A development team is preparing to deploy an application to Amazon ECS using the AWS Fargate launch type. The application container needs to pull its Docker image from a private Amazon ECR repository. Once the container is running, the application code needs to retrieve data from an Amazon S3 bucket.

Which IAM role configuration is required in the task definition to support this deployment?

Assign a single IAM role containing both ECR pull and S3 read permissions to the Task Role, and leave the Task Execution Role empty.

Assign an IAM role with S3 read permissions to the Task Role, and assign an IAM role with ECR pull permissions to the Task Execution Role.

Assign an IAM role with ECR pull permissions to the Task Role, and assign an IAM role with S3 read permissions to the Task Execution Role.

Assign an IAM role with both ECR pull and S3 read permissions to the Task Execution Role, and add a trust relationship allowing the ECS task to assume itself.

Show answer & explanation

Answer: Assign an IAM role with S3 read permissions to the Task Role, and assign an IAM role with ECR pull permissions to the Task Execution Role.

Answer

Assign an IAM role with S3 read permissions to the Task Role, and assign an IAM role with ECR pull permissions to the Task Execution Role.

The correct option correctly maps S3 read permissions to the Task Role and ECR pull permissions to the Task Execution Role. When using AWS Fargate, the ECS container agent runs outside the user container and needs credentials to pull the image from ECR and write logs; these permissions must be in the Task Execution Role. Once the container is running, the application code runs inside the container and requires separate credentials to access AWS resources like Amazon S3; these permissions must be in the Task Role.

Step-by-Step Solution

Identify the entity responsible for pulling the Docker container image from Amazon ECR.

The Amazon ECS container agent is responsible for pulling the image before the container starts.

The container agent runs outside the user's container and requires AWS credentials to pull from a private ECR repository.

Determine which IAM role provides permissions to the ECS container agent.

The Task Execution Role provides these credentials.

AWS Fargate uses the Task Execution Role for actions the ECS agent performs on your behalf (such as pulling ECR images and pushing logs to CloudWatch).

Identify the entity running the application code and the AWS services it needs to access.

The application code runs inside the container and needs to access Amazon S3.

The Task Role supplies temporary AWS credentials directly to the containerized application at runtime.

Key Concept

Distinction between ECS Task Role and ECS Task Execution Role

Question 227Question →

A developer is managing a continuous delivery pipeline in AWS CodePipeline that consists of Source, Build, Test, and Production stages. The developer needs to temporarily stop code changes from being deployed to the Production stage while allowing developers to continue committing code and verifying builds in the Test stage. Additionally, the developer must configure the system to send email alerts to the operations team whenever any stage in the pipeline fails. Which combination of actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Disable the inbound transition on the Production stage in AWS CodePipeline.

Create an Amazon EventBridge rule that filters for CodePipeline stage execution failures and targets an Amazon Simple Notification Service (Amazon SNS) topic subscribed to by the operations team.

Disable the inbound transition on the Test stage in AWS CodePipeline.

Update the trust policy of the CodePipeline service role to allow the sns.amazonaws.com service principal to assume the role.

Store the email notification settings as a SecureString parameter in Systems Manager Parameter Store and configure CodePipeline to retrieve it to publish notifications.

Show answer & explanation

Answer: Disable the inbound transition on the Production stage in AWS CodePipeline.; Create an Amazon EventBridge rule that filters for CodePipeline stage execution failures and targets an Amazon Simple Notification Service (Amazon SNS) topic subscribed to by the operations team.

Answer

Disable the inbound transition on the Production stage in AWS CodePipeline, and create an Amazon EventBridge rule that filters for CodePipeline stage execution failures and targets an Amazon Simple Notification Service (Amazon SNS) topic subscribed to by the operations team.

To satisfy the deployment restriction requirement, disabling the inbound transition on the Production stage ensures that new changes can propagate through Source, Build, and Test but will not enter Production. To satisfy the email alert requirement, creating an EventBridge rule that filters on failed stage executions and targets an SNS topic is the correct and standard integration pattern.

Step-by-Step Solution

Identify the stage transition control mechanism in AWS CodePipeline.

Disabling the transition into the Production stage stops new executions from entering the Production stage while keeping transitions between Source, Build, and Test active.

This satisfies the requirement to allow developers to continue committing code and running tests without deploying to production.

Identify the notification mechanism for pipeline failures.

An Amazon EventBridge rule is created to detect CodePipeline Stage Execution State Changes where the state is FAILED.

EventBridge can trigger an Amazon SNS topic to send emails to the operations team, which is the standard event-driven approach for CodePipeline notifications.

Key Concept

AWS CodePipeline stage transitions and EventBridge notifications integration

Question 228Question →

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

All-at-once

Rolling

Immutable

Rolling with additional batch

Show answer & explanation

Answer: All-at-once

Answer

All-at-once

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

Step-by-Step Solution

Identify the deployment constraints from the scenario

The requirements are: fastest deployment time, acceptance of temporary downtime, and zero budget for additional EC2 instances.

Understanding the constraints is necessary to narrow down the viable deployment strategies.

Evaluate the deployment strategies against the capacity/cost constraint

Strategies that launch additional EC2 instances (Immutable, Rolling with additional batch) are eliminated because there is no budget for extra instances.

This filters out strategies that violate the zero extra cost constraint.

Compare the remaining strategies (All-at-once vs. Rolling) against the speed and downtime constraints

All-at-once is faster than Rolling and takes all instances out of service, which fits the downtime tolerance. Rolling avoids downtime but is slower.

This identifies the option that best matches the speed and downtime requirements.

Key Concept

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

Question 229Question →

A company is deploying a secure microservice to Amazon ECS using the AWS Fargate launch type. The application code inside the container must pull messages from an Amazon SQS queue and write processed records to an Amazon DynamoDB table. Additionally, when the container is initialized, the Amazon ECS agent must retrieve database credentials from AWS Secrets Manager using the container definition secrets parameter and inject them as environment variables. The secret is encrypted using an AWS KMS customer managed key (CMK). During deployment, the tasks fail to transition to the RUNNING state, and the developer receives an error indicating that the container helper was unable to retrieve the Secrets Manager secret. How should the developer configure the IAM roles to resolve this issue and adhere to the principle of least privilege?

Associate an IAM policy granting secretsmanager:GetSecretValue and kms:Decrypt permissions to the ECS Task Execution Role, and associate a separate IAM policy granting SQS and DynamoDB permissions to the ECS Task Role.

Associate an IAM policy granting secretsmanager:GetSecretValue, kms:Decrypt, SQS, and DynamoDB permissions to the ECS Task Role, and leave the ECS Task Execution Role with the default AmazonECSTaskExecutionRolePolicy.

Associate an IAM policy granting secretsmanager:GetSecretValue and kms:Decrypt permissions to the ECS Task Execution Role, and update the trust policy of the ECS Task Execution Role to allow the service principal ecs.amazonaws.com to assume the role.

Associate an IAM policy granting secretsmanager:GetSecretValue and kms:Decrypt permissions to the ECS Task Execution Role, and configure the application code to initialize SDK clients by hardcoding temporary IAM user access keys.

Show answer & explanation

Answer: Associate an IAM policy granting secretsmanager:GetSecretValue and kms:Decrypt permissions to the ECS Task Execution Role, and associate a separate IAM policy granting SQS and DynamoDB permissions to the ECS Task Role.

Answer

The developer should associate an IAM policy with the ECS Task Execution Role that allows secretsmanager:GetSecretValue and kms:Decrypt, and associate another IAM policy with the ECS Task Role that allows Amazon SQS and DynamoDB access.

The correct option correctly separates the responsibilities of the two IAM roles. The ECS Task Execution Role is used by the ECS container agent to perform setup operations, such as pulling container images from ECR and retrieving secrets from Secrets Manager. Because the secret is encrypted with a KMS customer managed key, the execution role also requires kms:Decrypt permissions. The ECS Task Role is assumed by the application container itself at runtime to interact with AWS services like Amazon SQS and DynamoDB.

Step-by-Step Solution

Determine which role is responsible for retrieving secrets during container startup.

The ECS agent retrieves the secrets from Secrets Manager during the task startup phase, which requires permissions to be attached to the ECS Task Execution Role.

The Task Execution Role grants permissions to the ECS container agent, not the application itself.

Determine the required permissions for retrieving and decrypting the secret.

The ECS Task Execution Role must be granted secretsmanager:GetSecretValue and kms:Decrypt permissions because the secret is encrypted with a KMS customer managed key (CMK).

The ECS agent must be authorized to read the secret value and decrypt it using the specific key.

Determine which role is responsible for application-level AWS service access.

The application code runs inside the container and requires access to SQS and DynamoDB, which must be granted to the ECS Task Role.

The Task Role gives temporary credentials directly to the containerized application process.

Ensure the trust policy for both roles is correct.

Verify that both the Task Role and Task Execution Role have a trust relationship allowing the ecs-tasks.amazonaws.com service principal to assume the role.

If the trust relationship is set to ecs.amazonaws.com or another service, the tasks will fail to assume the roles during launch.

Key Concept

Understanding the separation of concerns between the ECS Task Role (application runtime permissions) and the ECS Task Execution Role (agent orchestration and startup permissions), and configuring necessary KMS decryption policies.

Estimated Time:3m 0s

Question 230Question →

A developer is deploying a microservices application to Amazon ECS using the AWS Fargate launch type in AWS Account A. The container image is stored in a private Amazon Elastic Container Registry (Amazon ECR) repository located in AWS Account B. During deployment, the ECS tasks fail to transition to the RUNNING state, and the task status shows an error indicating that the container image cannot be pulled from the remote registry. Which combination of steps should the developer perform to resolve this authentication and access issue? (Select TWO.)

Select all that apply

Configure the ECS task execution role in Account A with an IAM policy that allows the ecr:GetAuthorizationToken action on all resources, and the ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, and ecr:BatchGetImage actions on the Account B repository.

Configure the ECR repository policy in Account B to grant read-only access for the ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, and ecr:BatchGetImage actions to the ECS task execution role ARN from Account A.

Configure the ECS task role in Account A with an IAM policy that allows ECR API calls, and attach it to the container definition under the taskRoleArn parameter.

Modify the trust policy of the ECS task execution role in Account A to allow the ecr.amazonaws.com service principal to assume the role.

Create a secret in AWS Secrets Manager in Account A containing cross-account ECR registry credentials, and reference the secret in the container definition's repositoryCredentials parameter.

Show answer & explanation

Answer: Configure the ECS task execution role in Account A with an IAM policy that allows the ecr:GetAuthorizationToken action on all resources, and the ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, and ecr:BatchGetImage actions on the Account B repository.; Configure the ECR repository policy in Account B to grant read-only access for the ecr:BatchCheckLayerAvailability, ecr:GetDownloadUrlForLayer, and ecr:BatchGetImage actions to the ECS task execution role ARN from Account A.

Answer

Configure the ECS task execution role in Account A with permissions to pull the ECR image, and configure the ECR repository policy in Account B to grant access to Account A's task execution role.

To pull private ECR images cross-account, the ECS task execution role in Account A needs permissions to retrieve the authorization token and access the repository layers. Simultaneously, the repository policy in Account B must allow access from the Account A task execution role principal.

Step-by-Step Solution

Ensure the ECS Task Execution Role in Account A has permissions to authenticate and pull from ECR.

The ECS agent can invoke ecr:GetAuthorizationToken (on resource '*') to authenticate and has read permissions on the target repository.

The task execution role provides the ECS agent with the required credentials to pull images and push logs before the container code executes.

Update the ECR Repository Policy in Account B to trust the Task Execution Role from Account A.

Cross-account access is authorized on the repository level.

By default, AWS resources are isolated across accounts. The ECR repository policy must explicitly allow the Task Execution Role ARN from Account A to read image layers.

Key Concept

Configuring cross-account private ECR repository access for Amazon ECS tasks by separating Task Execution Role from Task Role permissions.

Question 231Question →

A developer is writing an appspec.yaml file to deploy updates to an AWS Lambda function using AWS CodeDeploy. Which of the following sections or hooks are valid for an AWS Lambda deployment? (Select TWO.)

Select all that apply

The resources section, which specifies the Lambda function name, alias, current version, and target version.

The AfterAllowTraffic hook, which is used to run validation tasks after traffic has shifted to the new version.

The files section, which lists the source file paths and destination directories on the target system.

The BeforeInstall hook, which runs scripts before any files are copied to the instances.

The ApplicationStart hook, which executes scripts to start services after the installation completes.

Show answer & explanation

Answer: The resources section, which specifies the Lambda function name, alias, current version, and target version.; The AfterAllowTraffic hook, which is used to run validation tasks after traffic has shifted to the new version.

Answer

The valid sections or hooks for an AWS Lambda CodeDeploy deployment are the resources section and the AfterAllowTraffic hook.

In AWS CodeDeploy, the AppSpec file structure depends on the compute platform. For an AWS Lambda deployment, the resources section must be defined to specify the Lambda function name, alias, and versions. Additionally, only two lifecycle hooks are supported: BeforeAllowTraffic and AfterAllowTraffic. The correct choices represent these valid components.

Step-by-Step Solution

Identify the target compute platform for the CodeDeploy deployment.

The target compute platform is AWS Lambda.

AppSpec file schemas and valid hooks differ significantly between AWS Lambda, Amazon ECS, and EC2/On-Premises.

Filter out sections and hooks that are specific to EC2/On-Premises deployments.

The files section, BeforeInstall hook, and ApplicationStart hook are identified as EC2/On-Premises specific.

EC2 deployments copy files to instances and manage local service lifecycles, which does not apply to serverless Lambda functions.

Select the valid Lambda-specific configuration elements from the remaining options.

The resources section (used to define the function metadata) and the AfterAllowTraffic hook (used to run post-deployment validation Lambda functions) are chosen.

AWS Lambda AppSpec files strictly require the resources section and only support BeforeAllowTraffic and AfterAllowTraffic lifecycle hooks.

Key Concept

AWS CodeDeploy AppSpec file structure for AWS Lambda compute platform

Estimated Time:1m 0s

Question 232Question →

A developer is configuring an AWS CodeBuild project that runs inside a private subnet of a VPC to perform integration tests against an internal Amazon RDS database. The build process must retrieve a database password stored as a SecureString parameter in Systems Manager Parameter Store. The developer stores the build commands in a custom file named `build_config.yml` inside a subdirectory named `specs/` in the source repository.

During the initial run, the build fails with an error indicating that the build specification cannot be found.

Which combination of actions will resolve the buildspec finding error and allow the build to retrieve the parameter?

Update the Buildspec path to `specs/build_config.yml` in the CodeBuild project settings. Additionally, ensure the VPC has either a NAT Gateway or a VPC interface endpoint for Systems Manager configured.

Move the `build_config.yml` file to the root of the repository and rename it to `buildspec.yml`. In the CodeBuild project settings, configure the Buildspec path to point to the `specs/` directory. Ensure that the CodeBuild service role has the `ssm:GetParameters` permission.

Modify the trust policy of the CodeBuild service role to allow the `ssm.amazonaws.com` service principal to assume the role. In the `build_config.yml` file, define a custom `run-as` parameter under the `pre_build` phase pointing to the CodeBuild service role.

In the CodeBuild project settings, change the environment variable type from Parameter Store to Secrets Manager. In the `build_config.yml` file, change the `env.parameter-store` block to `env.secrets-manager` and migrate the credential to AWS Secrets Manager, as Systems Manager Parameter Store is not supported in VPC-enabled builds.

Show answer & explanation

Answer: Update the Buildspec path to `specs/build_config.yml` in the CodeBuild project settings. Additionally, ensure the VPC has either a NAT Gateway or a VPC interface endpoint for Systems Manager configured.

Answer

The correct answer resolves the buildspec finding failure by specifying the custom path in the CodeBuild project configuration. It also addresses the connectivity issue by establishing a valid network path from the private VPC subnet to the public Systems Manager API.

Step-by-Step Solution

Address the buildspec location error.

By default, AWS CodeBuild looks for a file named `buildspec.yml` at the root of the source directory. Since the developer used a custom filename and path, the CodeBuild project's Buildspec setting must be updated to match this path.

This resolves the initial phase failure where CodeBuild cannot find the build specification.

Analyze VPC network requirements for accessing public AWS services.

CodeBuild containers running inside a private subnet of a VPC do not have direct internet access. To interact with public AWS services like Systems Manager Parameter Store, they need a route to the internet or private VPC endpoints.

Without this routing configuration, the build container will time out or fail when attempting to fetch parameters from Systems Manager.

Key Concept

AWS CodeBuild custom buildspec paths and VPC network access to AWS services

Estimated Time:2m 0s

Question 233Question →

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

Select all that apply

Blue/Green deployment

Immutable deployment

All-at-once deployment

Rolling deployment

Rolling with additional batch deployment

Show answer & explanation

Answer: Blue/Green deployment; Immutable deployment

Answer

Blue/Green deployment and Immutable deployment

Blue/Green and Immutable deployments satisfy all requirements. A Blue/Green deployment swaps DNS/CNAME records between two separate environments, maintaining

100\%

capacity and allowing an instant rollback. An Immutable deployment creates a temporary Auto Scaling group with the new version, ensuring

100\%

capacity is maintained and allowing a rapid rollback by simply deleting the new group.

Step-by-Step Solution

Identify the constraints specified in the deployment scenario.

The key constraints are: zero downtime,

100\%

capacity maintained, rapid rollback capabilities, and no budget constraints.

This sets up the criteria used to evaluate each Elastic Beanstalk deployment option.

Evaluate the impact of each deployment strategy on application capacity and downtime.

All-at-once causes downtime. Rolling reduces capacity during the update. Rolling with additional batch, Immutable, and Blue/Green all maintain

100\%

capacity and have no downtime.

This narrows the candidate list to strategies that maintain full application availability.

Assess the rollback speed of the remaining strategy options.

Rolling with additional batch requires a slow rolling deployment of the older version to roll back. Blue/Green (CNAME swap) and Immutable (terminating the new Auto Scaling group) both support near-instantaneous rollbacks.

This identifies the final two strategies that satisfy the rapid rollback constraint.

Key Concept

AWS Elastic Beanstalk deployment strategies differ in their impact on environment capacity, downtime, and rollback time.

Estimated Time:1m 0s

Question 234Question →

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

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

Select all that apply

CodeDeployDefault.OneAtATime

CodeDeployDefault.HalfAtATime

CodeDeployDefault.AllAtOnce

A CodeDeploy Blue/Green deployment

CodeDeployDefault.ECSLinear10PercentEvery1Minute

Show answer & explanation

Answer: CodeDeployDefault.OneAtATime; CodeDeployDefault.HalfAtATime

Answer

The correct configurations are CodeDeployDefault.OneAtATime and CodeDeployDefault.HalfAtATime.

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

Step-by-Step Solution

Analyze the deployment platform and constraints.

The platform is Amazon EC2. The constraints are zero downtime (at least one instance must remain online) and zero additional instances (the update must be in-place).

This establishes that we must use an in-place deployment strategy for EC2 that does not deploy to all instances simultaneously.

Evaluate CodeDeploy default in-place configurations.

CodeDeployDefault.OneAtATime deploys to 1 of 4 instances (leaving 3 healthy). CodeDeployDefault.HalfAtATime deploys to 2 of 4 instances (leaving 2 healthy). CodeDeployDefault.AllAtOnce deploys to 4 of 4 instances (leaving 0 healthy).

Both OneAtATime and HalfAtATime maintain application availability during the in-place update process.

Filter out configurations that violate the constraints.

AllAtOnce causes downtime. Blue/Green requires provisioning a replacement Auto Scaling group (incurring extra instance costs). ECSLinear10PercentEvery1Minute is incompatible with EC2 deployments.

This confirms that only the two selected in-place configurations meet both the availability and budget requirements.

Key Concept

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

Question 235Question →

A developer is deploying a serverless application using the AWS Serverless Application Model (SAM). The template defines an AWS::Serverless::Api resource with an OpenAPI specification in the DefinitionBody property. The template also defines an AWS::Serverless::Function resource.

Within the OpenAPI specification, the developer configures the integration for a POST route as follows:

yaml
paths:
/orders:
post:
x-amazon-apigateway-integration:
type: "aws"
httpMethod: "POST"
uri:
Fn::Sub: "arn:aws:apigateway: ${AWS::Region}:lambda:path/2015-03-31/functions/$ {OrderFunction.Arn}/invocations"

The Lambda function handler is implemented to return the following structure:

{
"statusCode": 201,
"body": "{\"message\": \"Order created successfully\"}",
"headers": {
"Content-Type": "application/json"
}
}

When the client sends a POST request to /orders, it receives an HTTP status code of 200 OK with the following response body:

{
"statusCode": 201,
"body": "{\"message\": \"Order created successfully\"}",
"headers": {
"Content-Type": "application/json"
}
}

Which configuration change should the developer make to ensure the client receives an HTTP status code of 201 Created with the message body '{"message": "Order created successfully"}'?

Modify the Lambda function handler to return only the JSON string '{"message": "Order created successfully"}' directly as the payload.

Change the integration type to 'aws_proxy' in the x-amazon-apigateway-integration extension inside the OpenAPI specification.

Update the Lambda function's execution role to define the 'apigateway.amazonaws.com' service principal as a trusted entity in the trust policy.

Remove the 'Transform: AWS::Serverless-2016-10-31' line from the top of the template and deploy the stack.

Show answer & explanation

Answer: Change the integration type to 'aws_proxy' in the x-amazon-apigateway-integration extension inside the OpenAPI specification.

Answer

The correct answer is to change the integration type to 'aws_proxy' in the x-amazon-apigateway-integration extension inside the OpenAPI specification.

Changing the integration type to 'aws_proxy' enables the Lambda proxy integration. With proxy integration, API Gateway automatically parses the JSON response returned by the Lambda function, setting the HTTP status code, response headers, and response body matching the keys 'statusCode', 'headers', and 'body' in the returned object. This ensures the client receives the status code 201 instead of 200 with the raw JSON payload.

Step-by-Step Solution

Analyze the current client response and the integration configuration in the template.

The client receives a 200 OK HTTP status code containing the raw JSON output of the Lambda function. The template uses a custom integration ('type: "aws"').

In custom integrations, API Gateway does not parse the status code or body from the Lambda response payload by default; it simply forwards the raw output with a default 200 OK status.

Identify the correct integration type required to automatically parse the Lambda proxy response structure.

Lambda proxy integration ('type: "aws_proxy"') is required.

When using 'aws_proxy', API Gateway automatically maps the 'statusCode', 'headers', and 'body' fields returned by the Lambda function to the final HTTP response.

Select the option that configures the Lambda proxy integration in the template.

Change 'type: "aws"' to 'type: "aws_proxy"' under x-amazon-apigateway-integration.

This correctly switches the API Gateway integration type to Lambda proxy integration, enabling the desired response mapping behavior.

Key Concept

API Gateway Integration Types in AWS SAM

Question 236Question →

A developer is configuring the AppSpec file for an AWS CodeDeploy deployment to Amazon ECS. The developer wants to run a validation test before production traffic is routed to the newly deployed task set. Which lifecycle hook should the developer use in the AppSpec file?

BeforeAllowTraffic

ApplicationStart

ValidateService

ApplicationStop

Show answer & explanation

Answer: BeforeAllowTraffic

Answer

BeforeAllowTraffic

The lifecycle hook designed for Amazon ECS deployments to run tasks before traffic shifts to the new task set is BeforeAllowTraffic. This hook allows developers to invoke a Lambda function to validate the new task set prior to routing live traffic.

Step-by-Step Solution

Identify the target compute platform for the CodeDeploy deployment.

The target platform is Amazon ECS.

ECS deployments use a specific, limited set of lifecycle hooks compared to EC2/On-premises deployments.

Determine the timing requirement for running the validation test.

The test must run after containers are deployed but before production traffic is shifted.

This corresponds to the phase before allowing traffic to the replacement task set.

Select the correct Amazon ECS lifecycle hook that executes before traffic shifting.

BeforeAllowTraffic is the correct hook.

This allows running Lambda functions to validate the deployment before any users access it.

Key Concept

AWS CodeDeploy AppSpec lifecycle hooks vary by compute platform. Amazon ECS deployments support BeforeAllowTraffic and AfterAllowTraffic to validate deployments before and after traffic shifting, while EC2 deployments support hooks like ApplicationStart and ValidateService.

Question 237Question →

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

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

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

Select all that apply

Configure the deployment settings in the deployment group to use the Canary10Percent15Minutes deployment configuration.

Configure the deployment group's blue/green deployment settings to wait 60 minutes before terminating the original task set.

Configure the deployment settings in the deployment group to use the Linear10Percent15Minutes deployment configuration.

Configure the deployment settings in the deployment group to use the Canary10Percent5Minutes deployment configuration.

Add an ApplicationStop lifecycle hook in the AppSpec file with a script that pauses execution for 3600 seconds.

Show answer & explanation

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

Answer

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

To shift

10\%

of traffic immediately and the remaining

90\%

after a

15

-minute evaluation period, the Canary10Percent15Minutes configuration is required. To retain the original task set for

1

hour after traffic shifting completes, the developer must specify a termination wait time of

60

minutes in the deployment group settings.

Step-by-Step Solution

Analyze traffic shifting requirements to choose the correct CodeDeploy configuration.

The requirement calls for shifting

10\%

of traffic immediately and the remaining

90\%

after a

15

-minute window. This represents a canary deployment pattern with a

15

-minute evaluation interval, pointing to Canary10Percent15Minutes.

Linear configurations shift traffic incrementally over multiple steps (e.g.,

10\%

every

15

minutes), which does not match the two-increment canary requirement.

Determine the proper mechanism for delaying the termination of the old task set.

Identify that the CodeDeploy deployment group settings contain a specific configuration for specifying the termination wait time of the original (blue) task set.

Configuring this to

60

minutes allows the old task set to remain active for exactly

1

hour after traffic is fully shifted, facilitating manual rollback if needed.

Evaluate AppSpec lifecycle hooks to identify incorrect configuration options.

Verify that ECS deployments support specific hooks (such as BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, and AfterAllowTraffic) but do not support EC2 hooks like ApplicationStop.

Attempting to use ApplicationStop in an ECS AppSpec file will cause deployment validation errors.

Key Concept

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

Question 238Question →

A software engineer is configuring an Amazon ECS task definition to deploy a containerized application to AWS Fargate. To simplify log management, the engineer configures the container to use the `awslogs` log driver and sets the `awslogs-create-group` option to `true` in the log configuration. The task definition specifies a custom IAM role for the task execution role. When the engineer attempts to launch the task, the task fails to start and remains in the `STOPPED` state, citing an authorization error related to CloudWatch Logs.

Which configuration change will resolve this deployment issue?

Add the `logs:CreateLogGroup` permission to the custom IAM role assigned as the ECS task role.

Update the ECS task execution role trust policy to allow the `logs.amazonaws.com` service principal to assume the role.

Add the `logs:CreateLogGroup` permission to the custom IAM role assigned as the task execution role.

Configure the application code inside the Docker container to use the AWS SDK to verify and create the CloudWatch log group at startup.

Show answer & explanation

Answer: Add the `logs:CreateLogGroup` permission to the custom IAM role assigned as the task execution role.

Answer

Add the `logs:CreateLogGroup` permission to the custom IAM role assigned as the task execution role.

The correct answer is to add the `logs:CreateLogGroup` permission to the task execution role. When the `awslogs` log driver is configured with `awslogs-create-group` set to `true`, the Amazon ECS container agent automatically attempts to create the specified log group in CloudWatch. Because the agent performs this infrastructure setup action, it requires authorization via the task execution role. The default managed policy `AmazonECSTaskExecutionRolePolicy` only provides permissions to create log streams and put log events, meaning that `logs:CreateLogGroup` must be explicitly added to a custom policy attached to the task execution role.

Step-by-Step Solution

Differentiate between the roles: Identify that the ECS agent is responsible for creating the log group during container startup, which requires permissions in the Task Execution Role.

The Task Execution Role is selected as the target for IAM policy modification instead of the Task Role.

The Task Execution Role is used by the ECS agent for lifecycle tasks like pulling ECR images and writing logs, whereas the Task Role is for application-level AWS API calls.

Analyze the policy permissions: Review the managed policy `AmazonECSTaskExecutionRolePolicy` and notice it only grants `logs:CreateLogStream` and `logs:PutLogEvents`.

Confirm that `logs:CreateLogGroup` is missing from the default policies when configuring `awslogs-create-group` to `true`.

If `awslogs-create-group` is set to `true`, the agent needs to explicitly create the log group, which requires a custom inline or managed policy with the `logs:CreateLogGroup` action.

Apply the IAM policy updates: Attach a policy containing `logs:CreateLogGroup` to the ECS Task Execution Role.

The ECS task successfully creates the log group and transitions to the `RUNNING` state.

Providing the necessary action to the Task Execution Role grants the ECS agent the authorization it needs to complete task provisioning.

Key Concept

Understanding the division of responsibilities and IAM permissions between the Amazon ECS Task Execution Role and the Task Role when configuring logging.

Question 239Question →

A developer is configuring a custom stage action in AWS CodePipeline that invokes an AWS Lambda function to perform integration testing. Arrange the following events in the correct chronological order, from the moment the Lambda action is initiated by the pipeline to the transition of the pipeline to the next stage.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The correct order starts with CodePipeline transitioning the action to In Progress and generating a Job ID, followed by CodePipeline invoking the Lambda function with the payload. Next, the Lambda function executes and retrieves the Job ID, then calls PutJobSuccessResult with the Job ID, and finally, CodePipeline receives the result and transitions the action status to Succeeded.

The correct chronological order starts with CodePipeline generating the Job ID and transitioning the action to In Progress. Next, CodePipeline invokes the Lambda function, passing the Job ID in the event payload. The Lambda function then runs its code, retrieves the Job ID from the event payload, and finishes its tasks. Finally, the function calls the PutJobSuccessResult API with the Job ID, allowing CodePipeline to mark the action as Succeeded and proceed.

Step-by-Step Solution

Initiate the action in the pipeline

CodePipeline transitions the Lambda action to In Progress and generates a unique Job ID containing execution details.

AWS CodePipeline manages the lifecycle of the action and creates a tracking Job ID for the execution.

Invoke the Lambda function

CodePipeline invokes the Lambda function asynchronously, passing the job event as the JSON payload.

This transfers execution control to the Lambda function and provides the necessary context, including the Job ID.

Process the custom logic and parse the event payload

The Lambda function runs its code and extracts the Job ID from the input event object.

The function must have the Job ID in memory to report the outcome back to CodePipeline.

Submit the success callback

The Lambda function calls the PutJobSuccessResult API operation using the AWS SDK, referencing the Job ID.

CodePipeline requires an explicit API call (PutJobSuccessResult or PutJobFailureResult) to update the status of the action; otherwise, the stage will hang and eventually time out.

Complete the stage transition

CodePipeline transitions the action status to Succeeded and proceeds to the next stage or action.

The received API call confirms the successful completion of the custom action.

Key Concept

AWS CodePipeline integration with AWS Lambda requires the Lambda function to explicitly return a success or failure status by calling the PutJobSuccessResult or PutJobFailureResult API operation using the Job ID provided in the invocation event payload.

Question 240Question →

A developer is writing an AWS CloudFormation template to deploy an Amazon EC2 instance that runs a web application. The developer uses the AWS::CloudFormation::Init metadata key to install several software packages and configure application files during startup. However, when deploying the stack, CloudFormation marks the EC2 instance status as CREATE_COMPLETE immediately after the instance is provisioned, but before the software installation and configuration tasks have finished running. Which configuration should the developer implement to ensure the stack creation waits until the software setup on the instance is fully complete?

Manually log into the EC2 instance via SSH to run the software installation scripts, and then use the AWS Management Console to update the stack parameters to force a manual synchronization.

Configure the EC2 instance's UserData to write a completion status to AWS Secrets Manager, and use an AWS Systems Manager Parameter Store dynamic reference in the EC2 instance properties to poll for this secret during stack creation.

Add a CreationPolicy attribute to the EC2 instance resource in the template, and execute the cfn-signal helper script at the end of the UserData property after the cfn-init execution.

Run a script that detects if the stack enters the ROLLBACK_IN_PROGRESS state, and execute the cfn-signal script locally from the developer's command line to override the rollback process and force the stack to CREATE_COMPLETE.

Show answer & explanation

Answer: Add a CreationPolicy attribute to the EC2 instance resource in the template, and execute the cfn-signal helper script at the end of the UserData property after the cfn-init execution.

Answer

Add a CreationPolicy attribute to the EC2 instance resource in the template, and execute the cfn-signal helper script at the end of the UserData property after the cfn-init execution.

The correct configuration is to add a CreationPolicy attribute to the EC2 instance resource and call the cfn-signal script at the end of UserData. This instructs CloudFormation to pause the status of the resource in CREATE_IN_PROGRESS until it receives the required number of signals or the timeout duration is reached.

Step-by-Step Solution

Define the application metadata and configuration script on the EC2 resource using the AWS::CloudFormation::Init key.

The instance metadata contains the configuration details, which will be processed by cfn-init.

This allows CloudFormation to manage packages, files, and services systematically on the EC2 instance.

Add a CreationPolicy attribute with a ResourceSignal count of 1 and a timeout configuration to the EC2 resource.

CloudFormation is instructed to pause resource creation and wait for a success signal before marking the instance as CREATE_COMPLETE.

This prevents CloudFormation from prematurely finishing stack creation before the software is operational.

Execute the cfn-signal helper script at the very end of the instance's UserData property, immediately after invoking cfn-init.

A success signal is sent to the CloudFormation endpoint once all setup steps successfully run.

This signals CloudFormation that the instance setup is successful, causing the resource status to transition to CREATE_COMPLETE.

Key Concept

Using CreationPolicy and helper scripts (cfn-init, cfn-signal) to synchronize resource provisioning inside AWS CloudFormation.

Estimated Time:1m 30s

PreviousPage 12 / 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