Deployment

376 questions

All types376 Multiple choice191 Multiple select171 Ordering14

A developer is configuring an AWS CodeDeploy deployment for an AWS Lambda function. The developer needs to define the target Lambda function to deploy and run a validation test before any production traffic shifts to the new version. Which two configurations must the developer include in the AppSpec file to accomplish this? (Select TWO.)

Select all that apply

A resources section that specifies the Lambda function name, alias, current version, and target version

A BeforeAllowTraffic hook under the hooks section that references a validation Lambda function

An ApplicationStart hook under the hooks section to run the validation script

An IAM trust policy definition under a permissions section to grant execution rights to CodeDeploy

A parameters section referencing AWS Systems Manager Parameter Store to retrieve database passwords

Show answer & explanation

Answer: A resources section that specifies the Lambda function name, alias, current version, and target version; A BeforeAllowTraffic hook under the hooks section that references a validation Lambda function

Answer

The developer must include a resources section with the Lambda function details (name, alias, current version, and target version) and define a BeforeAllowTraffic lifecycle hook under the hooks section pointing to a validation Lambda function.

To deploy a Lambda function using AWS CodeDeploy, the AppSpec file must define the target function details under the resources section. To run validation tests before shifting traffic, the developer must use the BeforeAllowTraffic lifecycle hook, which runs a separate validation Lambda function before any production traffic begins routing to the new version.

Step-by-Step Solution

Identify the compute platform for the CodeDeploy deployment.

The compute platform is AWS Lambda.

Different compute platforms (EC2, ECS, Lambda) have distinct AppSpec schema requirements.

Determine how to define the deployment target for AWS Lambda.

Define the function name, alias, current version, and target version in the resources section.

This tells CodeDeploy which function and versions are involved in the deployment.

Determine how to run a validation test before traffic shifting.

Add a BeforeAllowTraffic hook in the hooks section pointing to a validation Lambda function.

This hook executes before traffic shifting begins, allowing tests to run and potentially roll back the deployment if they fail.

Key Concept

AWS CodeDeploy AppSpec file structure and lifecycle hooks for AWS Lambda deployments.

Estimated Time:1m 0s

Question 242Question →

A developer is updating a serverless application hosted on AWS Lambda and wants to roll out a new function version using AWS CodeDeploy. The deployment must route $10\%$ of incoming traffic to the new version initially. After a $10$ -minute observation period, if no errors are detected by Amazon CloudWatch alarms, all remaining traffic ( $90\%$ ) must be routed to the new version. Which AWS CodeDeploy deployment configuration meets these requirements?

CodeDeployDefault.LambdaLinear10PercentEvery10Minutes

CodeDeployDefault.LambdaCanary10Percent10Minutes

CodeDeployDefault.LambdaCanary10Percent5Minutes

CodeDeployDefault.LambdaAllAtOnce

Show answer & explanation

Answer: CodeDeployDefault.LambdaCanary10Percent10Minutes

Answer

CodeDeployDefault.LambdaCanary10Percent10Minutes

The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes shifts

10\%

of the traffic to the new Lambda version initially, waits for a

10

-minute interval to monitor for errors via CloudWatch alarms, and then routes the remaining

90\%

of the traffic to the new version.

Step-by-Step Solution

Analyze the traffic shifting requirement

The requirement specifies routing

10\%

of traffic to the new version initially, waiting

10

minutes, and then shifting all remaining

90\%

of traffic to the new version.

This traffic shifting pattern describes a canary deployment strategy (an initial small slice of traffic followed by a single promotion of all remaining traffic after a specific delay) rather than a linear or all-at-once deployment.

Identify the corresponding AWS CodeDeploy predefined configuration

The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes matches the

10\%

initial traffic split and

10

-minute wait duration.

AWS CodeDeploy provides predefined deployment configurations for Lambda. The Canary configurations specify the percentage to shift and the wait time before shifting the remaining traffic. The configuration CodeDeployDefault.LambdaCanary10Percent10Minutes implements a single

10

-minute step before routing all remaining traffic.

Key Concept

AWS CodeDeploy deployment configurations for AWS Lambda allow developers to gradually shift traffic between versions using Canary or Linear strategies.

Question 243Question →

A developer is deploying a containerized application to an Amazon ECS cluster using the Amazon EC2 launch type. The application, which runs in a container with the `bridge` network mode, is designed to write records to an Amazon DynamoDB table. The developer specifies an IAM role named `DynamoDBWorkerRole` in the `taskRoleArn` parameter of the task definition. This IAM role has a policy that allows `dynamodb:PutItem` on the target table. However, at runtime, the application fails to write to DynamoDB and logs the following error:

`AccessDeniedException: User: arn:aws:sts::123456789012:assumed-role/ECSInstanceRole/i-0abcdef123456789 is not authorized to perform: dynamodb:PutItem on resource`

(Note: ` $123456789012$ ` is the AWS account ID, and `ECSInstanceRole` is the IAM role associated with the EC2 container instances.)

Which of the following actions will resolve this issue?

Attach the DynamoDB permission policy to the ECS Task Execution Role (taskExecutionRoleArn) instead of the Task Role (taskRoleArn).

Modify the application code inside the container to query the EC2 Instance Metadata Service (IMDS) at

169.254.169.254

to retrieve temporary credentials for the DynamoDBWorkerRole.

Update the trust relationship of the DynamoDBWorkerRole to trust the ecs-tasks.amazonaws.com service principal instead of ec2.amazonaws.com.

Store the AWS access key and secret access key for an IAM user with DynamoDB permissions in AWS Secrets Manager, and reference them in the secrets section of the task definition.

Show answer & explanation

Answer: Update the trust relationship of the DynamoDBWorkerRole to trust the ecs-tasks.amazonaws.com service principal instead of ec2.amazonaws.com.

Answer

Update the trust relationship of the DynamoDBWorkerRole to trust the ecs-tasks.amazonaws.com service principal instead of ec2.amazonaws.com.

The application failed to write to DynamoDB because the AWS SDK inside the container could not retrieve task credentials, causing it to fall back to the EC2 instance profile role (`ECSInstanceRole`). This fallback happens because the ECS agent is unable to assume the `DynamoDBWorkerRole` due to a misconfigured trust policy. To resolve this, the role's trust relationship must trust `ecs-tasks.amazonaws.com` instead of `ec2.amazonaws.com`.

Step-by-Step Solution

Analyze the error message to identify which IAM identity is performing the unauthorized request.

The error shows that `ECSInstanceRole` (the role associated with the EC2 container instance profile) is attempting the `dynamodb:PutItem` action, not the specified `DynamoDBWorkerRole`.

This indicates that the AWS SDK inside the container has fallen back to using the host instance's credentials because it could not retrieve container task credentials.

Determine why the task-specific credentials for `DynamoDBWorkerRole` were not provided to the container.

The ECS agent retrieves credentials by assuming the role specified in `taskRoleArn`. If the trust policy of that role does not trust the `ecs-tasks.amazonaws.com` service principal, the ECS agent will fail to assume the role.

ECS tasks require the `ecs-tasks.amazonaws.com` service principal to assume the IAM role defined in the task definition.

Evaluate the correct remediation to enable the ECS agent to assume the task role.

Modify the trust policy of `DynamoDBWorkerRole` to allow the `ecs-tasks.amazonaws.com` service principal to perform the `sts:AssumeRole` action.

This allows the ECS agent to assume the role, generate temporary credentials, and inject them into the container's environment.

Confirm the destination of the policy for application-level actions like DynamoDB operations.

The application permissions must remain attached to the Task Role (`taskRoleArn`), not the Task Execution Role (`taskExecutionRoleArn`).

The Task Execution Role is only used by the ECS container agent for infrastructure tasks such as pulling images and exporting logs.

Key Concept

ECS Task Role trust relationships and credential provider chain fallback behavior

Estimated Time:3m 0s

Question 244Question →

An organization is containerizing a legacy session manager and deploying it as a task on Amazon ECS with the AWS Fargate launch type. The application code requires permissions to write session state directly to an Amazon DynamoDB table. Additionally, the task's container image is hosted within a private Amazon Elastic Container Registry (ECR) repository. The developer needs to establish the correct IAM permissions for both the ECS container agent and the application itself to run successfully.

Which of the following configuration steps must the developer perform? (Select TWO.)

Select all that apply

Configure the ECS Task Role with an IAM policy that allows the `dynamodb:PutItem` action.

Configure the ECS Task Execution Role with an IAM policy that allows the `ecr:GetDownloadUrlForLayer` and `ecr:BatchGetImage` actions.

Configure the ECS Task Execution Role with an IAM policy that allows the `dynamodb:PutItem` action.

Configure the trust policy of the ECS Task Role to allow the Amazon EC2 service (`ec2.amazonaws.com`) to assume the role.

Include static AWS credentials inside the application's environment configuration within the Dockerfile.

Show answer & explanation

Answer: Configure the ECS Task Role with an IAM policy that allows the `dynamodb:PutItem` action.; Configure the ECS Task Execution Role with an IAM policy that allows the `ecr:GetDownloadUrlForLayer` and `ecr:BatchGetImage` actions.

Answer

To configure the task successfully, the ECS Task Role must be configured with permission to write to DynamoDB (`dynamodb:PutItem`), and the ECS Task Execution Role must be configured with permissions to pull the image from ECR (`ecr:GetDownloadUrlForLayer` and `ecr:BatchGetImage`).

The correct configurations are: 1. Setting the ECS Task Role with an IAM policy that allows the application code to write to DynamoDB (`dynamodb:PutItem`). The Task Role is designed specifically to provide permissions to the application running inside the container. 2. Setting the ECS Task Execution Role with an IAM policy that allows the ECS container agent to pull images from ECR (`ecr:GetDownloadUrlForLayer` and `ecr:BatchGetImage`). The Task Execution Role is used by the ECS container agent to perform lifecycle tasks on behalf of the container before the application begins running.

Step-by-Step Solution

Determine which role is used by the ECS container agent to perform infrastructure actions.

The ECS Task Execution Role is identified as the role used by the ECS agent to pull container images from ECR and write logs to CloudWatch.

The ECS container agent runs outside the user container and requires separate credentials to interact with AWS services before the container starts.

Determine which role is used by the application code running inside the container.

The ECS Task Role is identified as the role that provides temporary AWS credentials to the application code container.

The application code uses the AWS SDK to write data to DynamoDB, so the permission must be attached to the Task Role.

Verify the trust policy of both roles to ensure they can be assumed by ECS.

The trust policy for both roles must allow the Amazon ECS Task service (`ecs-tasks.amazonaws.com`) to assume the role.

If the trust policy is misconfigured (e.g., set to EC2 instead of ECS Tasks), ECS will not be able to assume the roles, and the task will fail to launch.

Key Concept

Delineation between the ECS Task Role (granting permissions to the application code inside the container) and the ECS Task Execution Role (granting permissions to the ECS agent/daemon to pull images and push logs).

Question 245Question →

A developer is configuring an in-place deployment in AWS CodeDeploy for an application running on an Auto Scaling group with $10$ Amazon EC2 instances. To prevent performance degradation during peak hours, the application must maintain at least $60\%$ of its capacity ( $6$ instances) to serve traffic at all times during the deployment. The developer also wants to complete the deployment in the shortest time possible. Which deployment configuration should the developer use to meet these requirements?

Create a custom deployment configuration with the minimum healthy hosts set to a fleet percentage of

60\%

Use the predefined CodeDeployDefault.HalfAtATime deployment configuration.

Use the predefined CodeDeployDefault.OneAtATime deployment configuration.

Create a custom deployment configuration with the minimum healthy hosts set to a host count of

4

Show answer & explanation

Answer: Create a custom deployment configuration with the minimum healthy hosts set to a fleet percentage of $60\%$ .

Answer

Create a custom deployment configuration with the minimum healthy hosts set to a fleet percentage of

60\%

The correct option is the custom deployment configuration with the minimum healthy hosts set to a fleet percentage of

60\%

. This ensures that at least

6

instances (which is

60\%

10

instances) remain healthy and serving traffic throughout the deployment. Consequently, CodeDeploy can update up to

4

instances concurrently, minimizing the total deployment duration while satisfying the capacity constraint.

Step-by-Step Solution

Calculate the number of healthy instances required during the deployment.

The application requires at least

60\%

10

instances to be healthy, which equals

10 \times 0.60 = 6

healthy instances.

This establishes the minimum capacity baseline that must be maintained.

Determine the maximum number of instances that can be updated concurrently.

Maximum updating instances = Total instances - Minimum healthy instances =

10 - 6 = 4

instances.

To complete the deployment in the shortest time, we must update the maximum allowable number of instances concurrently.

Evaluate the predefined CodeDeploy configurations against the constraints.

HalfAtATime updates

5

instances (leaving

5

healthy, violating the limit). OneAtATime updates

1

instance (taking too long). AllAtOnce updates all

10

(violating the limit).

Predefined configurations do not optimize for updating exactly

4

instances at a time while keeping

6

healthy.

Define the custom configuration parameters.

A custom configuration with minimum healthy hosts set to a fleet percentage of

60\%

(or a host count of

6

) is required.

Setting the minimum healthy hosts to a fleet percentage of

60\%

ensures exactly

6

instances remain healthy, permitting

4

instances to update concurrently, thus meeting both capacity and speed constraints.

Key Concept

AWS CodeDeploy deployment configurations and minimum healthy hosts parameters.

Question 246Question →

A developer is preparing an AppSpec file for an Amazon ECS deployment using AWS CodeDeploy. The developer needs to define lifecycle hooks to validate the deployment before routing production traffic to the new task set. What target type must the developer specify in the AppSpec file to execute the validation tests?

A shell script path on the container instance

An IAM service role ARN

An AWS Lambda function

An AWS Secrets Manager secret ARN

Show answer & explanation

Answer: An AWS Lambda function

Answer

An AWS Lambda function

For Amazon ECS deployments, CodeDeploy lifecycle hooks (such as BeforeAllowTraffic and AfterAllowTraffic) must target an AWS Lambda function. The Lambda function runs the validation code and calls the CodeDeploy API to report success or failure.

Step-by-Step Solution

Identify the target compute platform for the CodeDeploy deployment.

The target platform is Amazon ECS.

CodeDeploy handles lifecycle hooks differently depending on whether the target platform is EC2/on-premises versus ECS/Lambda.

Determine how validation tests are executed on the Amazon ECS platform.

ECS deployments use AWS Lambda functions to execute validation code for lifecycle hooks.

Because containers in ECS tasks cannot run arbitrary local host scripts during CodeDeploy lifecycle transitions, a Lambda function must be used to perform checks like BeforeAllowTraffic.

Key Concept

AWS CodeDeploy lifecycle hooks for Amazon ECS require AWS Lambda functions to execute validation tests.

Estimated Time:1m 0s

Question 247Question →

An operations team is designing a secure privilege model for a containerized processing job running on Amazon ECS with the AWS Fargate launch type. The task definition specifies a single container built from a private Docker image in Amazon ECR. At launch, the container must have sensitive database credentials injected as environment variables from AWS Systems Manager Parameter Store using the container definition `secrets` parameter. During runtime, the application code inside the container must write processing events to an Amazon DynamoDB table and stream standard output to Amazon CloudWatch Logs. Which configuration will successfully run the container while adhering to the principle of least privilege?

Configure an IAM task execution role with permissions for ECR image pull actions, CloudWatch log streaming actions, and SSM Parameter Store access. Configure a separate IAM task role with permissions for DynamoDB write actions. Set the trust policy of both roles to trust the `ecs-tasks.amazonaws.com` service principal.

Configure an IAM task role with permissions for ECR image pull actions, CloudWatch log streaming actions, SSM Parameter Store access, and DynamoDB write actions. Set the trust policy of this task role to trust the `ecs.amazonaws.com` service principal, and leave the task execution role unassigned.

Configure an IAM task execution role with permissions for DynamoDB write actions, ECR image pull actions, CloudWatch log streaming actions, and SSM Parameter Store access. Do not configure a task role, as the containerized application code automatically inherits the credentials of the task execution role.

Configure an IAM task execution role with permissions for ECR image pull actions, CloudWatch log streaming actions, and SSM Parameter Store access. Embed the AWS Access Key ID and Secret Access Key of a user with DynamoDB write permissions as environment variables in the Dockerfile to authenticate the application client.

Show answer & explanation

Answer: Configure an IAM task execution role with permissions for ECR image pull actions, CloudWatch log streaming actions, and SSM Parameter Store access. Configure a separate IAM task role with permissions for DynamoDB write actions. Set the trust policy of both roles to trust the `ecs-tasks.amazonaws.com` service principal.

Answer

Configure an IAM task execution role with permissions for ECR, CloudWatch, and SSM Parameter Store, and configure an IAM task role with DynamoDB write permissions, ensuring both roles trust the ecs-tasks.amazonaws.com service principal.

The correct configuration assigns the ECS agent startup permissions (pulling the container image, setting up awslogs logging, and fetching secrets from SSM Parameter Store) to the Task Execution Role. The application runtime permissions (writing to DynamoDB) are assigned to the Task Role. Both roles must have a trust policy allowing the `ecs-tasks.amazonaws.com` service principal to assume them.

Step-by-Step Solution

Determine the entity responsible for fetching container dependencies, pulling secrets via container definition properties, and setting up container log configuration.

The ECS host agent manages these lifecycle events before the container launches. Therefore, the ECR, CloudWatch, and Systems Manager Parameter Store permissions must be assigned to the ECS Task Execution Role.

Since AWS Fargate is a serverless host, the ECS agent requires these permissions to retrieve container resources and parameters on behalf of the customer.

Determine the entity responsible for the API calls made directly by the running application code.

The application code interacts with DynamoDB at runtime. These permissions must be assigned to the ECS Task Role.

The Task Role credentials are injected into the container's environment, allowing the AWS SDK inside the container to assume this role for application runtime calls.

Verify the IAM trust policy configuration required for the ECS tasks service.

Both the Task Role and Task Execution Role must trust the `ecs-tasks.amazonaws.com` service principal.

Using the wrong principal (such as `ecs.amazonaws.com`) will result in failures to assume the roles, as that principal belongs to the ECS service scheduler rather than the task execution agent.

Key Concept

Differentiating between the ECS Task Role (application runtime permissions) and the ECS Task Execution Role (ECS agent startup permissions), and configuring their trust policies.

Estimated Time:2m 0s

Question 248Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline that consists of Source, Build, and Deploy stages. The developer needs to configure the pipeline to use a custom build specification file located in a subdirectory (build/buildspec.yml) of the source repository. Additionally, the developer must pass a dynamically generated container image tag from the Build stage (AWS CodeBuild) to the Deploy stage (AWS CloudFormation). Which two actions must the developer perform to meet these requirements?

Select all that apply

Specify the custom buildspec path 'build/buildspec.yml' in the AWS CodeBuild project configuration.

Define a variable namespace in the CodePipeline build action configuration, and reference the output variable in the subsequent deploy stage using the namespace syntax.

Keep the custom buildspec file in the subdirectory without modifying the CodeBuild settings, as CodePipeline recursively searches the source artifact for any buildspec files.

Modify the CodePipeline service role's trust policy to trust the CodeBuild service principal, allowing CodeBuild to directly assume the role and modify the pipeline's environment variables.

Store the custom buildspec file in AWS Secrets Manager and reference the Secrets Manager ARN in the CodePipeline source action configuration parameters.

Show answer & explanation

Answer: Specify the custom buildspec path 'build/buildspec.yml' in the AWS CodeBuild project configuration.; Define a variable namespace in the CodePipeline build action configuration, and reference the output variable in the subsequent deploy stage using the namespace syntax.

Answer

To satisfy the requirements, the developer must specify the custom buildspec path in the CodeBuild project settings and use CodePipeline's native variable namespace feature in the build action configuration to reference output variables in the downstream deployment stage.

Specifying the custom buildspec path in the AWS CodeBuild project configuration is necessary because CodeBuild only looks at the root folder by default. Defining a variable namespace in the CodePipeline build action enables downstream stages to access values like an image tag using variable namespace interpolation.

Step-by-Step Solution

Set the custom buildspec location in AWS CodeBuild.

The developer updates the CodeBuild project configuration so that it looks for the build specification file at 'build/buildspec.yml'.

By default, CodeBuild expects the buildspec.yml file to be located in the root of the source directory. Specifying the custom path prevents build initialization failures.

Export variables from CodeBuild to CodePipeline.

The developer configures the build action in CodePipeline with a namespace, which acts as a container for output variables generated during the build execution.

Assigning a namespace enables downstream deployment actions to consume exported variables using the namespace references.

Key Concept

AWS CodePipeline Variable Namespaces and CodeBuild Configuration

Question 249Question →

A developer is configuring a deployment for an AWS Lambda function using AWS CodeDeploy. The developer needs to define the deployment configuration and ensure CodeDeploy has the necessary permissions.

Which TWO of the following configurations or steps are required to successfully set up this deployment?

Select all that apply

Define the Resources section in the AppSpec file specifying the Lambda function name, alias, current version, and target version.

Create an IAM service role for CodeDeploy with a trust policy that allows the codedeploy.amazonaws.com service to assume the role.

Define the BeforeInstall and AfterInstall hooks in the AppSpec file to run deployment validation scripts.

Configure the trust policy of the CodeDeploy IAM service role to allow the lambda.amazonaws.com service to assume it.

Store the application credentials in Systems Manager Parameter Store with automatic rotation enabled to secure the deployment.

Show answer & explanation

Answer: Define the Resources section in the AppSpec file specifying the Lambda function name, alias, current version, and target version.; Create an IAM service role for CodeDeploy with a trust policy that allows the codedeploy.amazonaws.com service to assume the role.

Answer

To successfully deploy a Lambda function using CodeDeploy, the developer must define the Resources section in the AppSpec file to specify function details, and create an IAM service role for CodeDeploy with a trust policy that permits the codedeploy.amazonaws.com service to assume it.

Defining the Resources section in the AppSpec file is required for Lambda deployments to specify the target function name, alias, and versions. Additionally, CodeDeploy requires an IAM service role with a trust policy allowing the codedeploy.amazonaws.com service to assume it to perform actions on the developer's behalf.

Step-by-Step Solution

Identify the target compute platform and the required AppSpec structure.

Since the target platform is AWS Lambda, the AppSpec file must use the Resources section to specify the function name, alias, current version, and target version.

This tells CodeDeploy which function and versions are involved in the deployment.

Determine the required IAM configuration for the deployment service.

Create an IAM service role that grants CodeDeploy permissions to interact with AWS Lambda, and ensure the trust policy allows codedeploy.amazonaws.com to assume this role.

CodeDeploy requires permission to perform traffic shifting on the Lambda function.

Key Concept

AWS CodeDeploy Lambda deployment configuration requires specifying function resources in the AppSpec file and establishing an IAM service role that trusts the CodeDeploy service.

Question 250Question →

A developer is updating an AWS CloudFormation stack that manages a web application's network infrastructure. The update fails, and the stack begins to roll back. However, the rollback process fails and the stack is left in the UPDATE_ROLLBACK_FAILED state because one of the subnets was previously deleted manually via the AWS Console. How should the developer resolve this issue to return the stack to a stable state?

Run drift detection on the stack, select the deleted subnet from the drift results, and select the console option to import the drift to automatically recreate the resource.

Perform a new stack update with the updated template using the --ignore-rollback-errors CLI flag to force the stack back to UPDATE_COMPLETE.

Use the ContinueUpdateRollback operation and choose to skip the deleted subnet resource during the rollback process, then manually clean up any remaining resources if necessary.

Store the subnet configuration as a SecureString parameter in Systems Manager Parameter Store and trigger a stack update using dynamic references.

Show answer & explanation

Answer: Use the ContinueUpdateRollback operation and choose to skip the deleted subnet resource during the rollback process, then manually clean up any remaining resources if necessary.

Answer

Use the ContinueUpdateRollback operation and choose to skip the deleted subnet resource during the rollback process, then manually clean up any remaining resources if necessary.

The correct approach is to run the ContinueUpdateRollback operation and specify the logical IDs of the resources to skip (in this case, the deleted subnet). CloudFormation will set the state of these resources to UPDATE_ROLLBACK_COMPLETE and continue rolling back the remaining resources in the stack. Once the stack reaches a stable state, the developer can update the template or manually recreate resources to align them.

Step-by-Step Solution

Identify the cause of the rollback failure

Confirm that the stack is in the UPDATE_ROLLBACK_FAILED state due to an out-of-band deletion of the subnet resource.

Before taking corrective action, the developer must verify which resource is blocking the rollback process.

Initiate the ContinueUpdateRollback operation

Start the rollback continuation process using the AWS Console, AWS CLI, or CloudFormation API.

This operation is required to force CloudFormation to attempt to complete the rollback again.

Specify resources to skip during rollback

Select the deleted subnet resource to be skipped.

Skipping the deleted resource allows CloudFormation to set its status to rolled back without attempting to modify the non-existent resource, bringing the stack to the stable UPDATE_ROLLBACK_COMPLETE state.

Key Concept

Handling CloudFormation stack update rollback failures caused by manual out-of-band resource deletion.

Estimated Time:1m 30s

Question 251Question →

A developer is configuring the deployment policy for a web application running on an AWS Elastic Beanstalk environment. The environment currently consists of $8$ Amazon EC2 instances. To meet strict SLA requirements, the deployment must maintain $100\%$ of the current serving capacity ( $8$ instances) at all times during the update. Additionally, the development team wants to minimize the additional infrastructure costs during the deployment process by avoiding the temporary doubling of instances or provisioning a second environment. Which Elastic Beanstalk deployment policy should the developer select?

Rolling

Rolling with additional batch

Immutable

All-at-once

Show answer & explanation

Answer: Rolling with additional batch

Answer

The Rolling with additional batch deployment policy should be selected.

The 'Rolling with additional batch' policy launches a new batch of instances first to maintain

100\%

capacity during the deployment. It then updates the remaining instances in batches. Because it only launches one batch of new instances at a time rather than a full duplicate of the environment, it is more cost-effective than the 'Immutable' policy while still preventing any capacity reduction.

Step-by-Step Solution

Analyze capacity requirements

The deployment must maintain

100\%

capacity (

8

instances) at all times during the deployment process.

To prevent performance degradation and meet SLA requirements during the update.

Evaluate cost and resource constraints

The solution must minimize extra instance costs and avoid doubling the instance count to

16

or setting up a secondary environment.

To satisfy the constraint of minimizing additional infrastructure costs during deployment.

Compare candidate Elastic Beanstalk deployment policies

Rolling reduces capacity. All-at-once causes downtime. Immutable maintains capacity but doubles the instance count. Rolling with additional batch launches only a single additional batch (e.g.,

2

instances for a

25\%

batch size) to maintain capacity, making it the most cost-effective option that meets all constraints.

To select the policy that perfectly aligns with both capacity preservation and cost optimization.

Key Concept

AWS Elastic Beanstalk deployment policies trade-offs between capacity, cost, and rollback capability

Question 252Question →

A developer is preparing to deploy a containerized API service to Amazon ECS using the AWS Fargate launch type. The application is packaged in a Docker image stored in a private Amazon ECR repository. During runtime, the application code must poll an Amazon SQS queue to retrieve incoming messages, and write custom metrics to Amazon CloudWatch. Additionally, the container must use the `awslogs` log driver to send standard output streams to CloudWatch Logs, and retrieve a database password securely from AWS Systems Manager Parameter Store (stored as a `SecureString` parameter) to set a container environment variable at launch. Which combination of configurations must the developer implement to meet these requirements? (Select TWO.)

Select all that apply

Configure an ECS Task Execution Role with permissions for `ecr:BatchGetImage`, `ecr:GetDownloadUrlForLayer`, `logs:PutLogEvents`, and `ssm:GetParameters`.

Configure an ECS Task Role with permissions for `sqs:ReceiveMessage`, `sqs:DeleteMessage`, and `cloudwatch:PutMetricData`.

Configure the ECS Task Role with permissions to read the database password from Parameter Store and write logs via the `awslogs` driver.

Configure the ECS Task Execution Role with permissions to poll the Amazon SQS queue and write custom metrics to CloudWatch.

Configure the trust policy of the ECS Task Execution Role to allow the Amazon EC2 service (`ec2.amazonaws.com`) to assume the role.

Show answer & explanation

Answer: Configure an ECS Task Execution Role with permissions for `ecr:BatchGetImage`, `ecr:GetDownloadUrlForLayer`, `logs:PutLogEvents`, and `ssm:GetParameters`.; Configure an ECS Task Role with permissions for `sqs:ReceiveMessage`, `sqs:DeleteMessage`, and `cloudwatch:PutMetricData`.

Answer

Configure the ECS Task Execution Role with permissions for pulling ECR images, writing logs, and retrieving Parameter Store parameters, and configure the ECS Task Role with permissions for SQS operations and CloudWatch metrics write actions.

The correct configurations properly separate the ECS Task Execution Role (used by the ECS container agent to prepare the container environment, pull the image from Amazon ECR, set up CloudWatch logging, and pull parameters from Systems Manager Parameter Store) and the ECS Task Role (used by the application code running inside the container to interact with AWS services, such as reading from SQS and writing custom metrics to CloudWatch).

Step-by-Step Solution

Identify the entities performing the required actions.

The ECS agent pulls the ECR image, sends logs via the `awslogs` driver, and retrieves the Parameter Store secret. The application code inside the container polls SQS and writes custom metrics.

ECS distinguishes agent-level bootstrapping tasks from container-level application tasks.

Assign agent-level boot permissions.

Define an ECS Task Execution Role with ECR pull, CloudWatch logs write, and Systems Manager Parameter Store get parameter permissions.

The ECS agent needs these permissions before the container starts running.

Assign application-level execution permissions.

Define an ECS Task Role with SQS poll/delete and custom CloudWatch metrics write permissions.

The application code inside the running container assumes the Task Role to interact with other AWS services.

Key Concept

Separation of concerns between the ECS Task Execution Role and the ECS Task Role.

Question 253Question →

An integration specialist is deploying a data ingestion service as a task on Amazon ECS with the EC2 launch type. The application code inside the container must read message payloads from an Amazon SQS queue and write processing logs to Amazon CloudWatch. During deployment, the ECS container agent successfully pulls the image and initializes the container, but the application throws an Access Denied error when attempting to poll the SQS queue. Which action should the developer take to resolve this issue?

Hardcode the AWS credentials of an IAM user with SQS permissions inside the application configuration file within the Docker container.

Attach the SQS permission policy to the ECS Task Role specified by the taskRoleArn parameter, and configure its trust policy to trust ecs-tasks.amazonaws.com.

Attach the SQS permission policy to the ECS Task Execution Role specified by the executionRoleArn parameter in the task definition.

Attach the SQS permission policy to the ECS Task Role, but configure the trust policy of the role to trust ec2.amazonaws.com.

Show answer & explanation

Answer: Attach the SQS permission policy to the ECS Task Role specified by the taskRoleArn parameter, and configure its trust policy to trust ecs-tasks.amazonaws.com.

Answer

Attach the SQS permission policy to the ECS Task Role specified by the taskRoleArn parameter, and configure its trust policy to trust ecs-tasks.amazonaws.com.

The containerized application code running inside the ECS task needs permissions to access SQS. These application-level permissions must be defined in an IAM role assigned as the Task Role (via the taskRoleArn parameter). Additionally, the IAM role must have a trust policy that allows the Amazon ECS tasks service (ecs-tasks.amazonaws.com) to assume the role. This permits the container itself to assume the role and make authorized AWS API calls.

Step-by-Step Solution

Identify which component is failing to perform the action.

The application code inside the container is failing to read from SQS, while the ECS agent is succeeding in pulling the image and sending logs.

This distinguishes between task execution tasks (agent-level) and task execution itself (application-level).

Select the appropriate ECS IAM role for application-level AWS API calls.

The ECS Task Role (taskRoleArn) must be configured with SQS permissions, rather than the Task Execution Role (executionRoleArn).

The Task Role provides credentials directly to the containerized application.

Configure the trust relationship policy for the Task Role.

Add ecs-tasks.amazonaws.com as the trusted entity in the role's trust policy.

This allows the ECS service to assume the role on behalf of the task.

Key Concept

Distinguishing between Amazon ECS Task Role and Task Execution Role configurations

Estimated Time:1m 30s

Question 254Question →

A developer is managing an infrastructure deployment consisting of two separate AWS CloudFormation stacks: a network stack that exports VPC resource identifiers, and an application stack that imports these identifiers using the `Fn::ImportValue` intrinsic function. The developer needs to update the network stack's outputs to support a new subnet configuration. Which of the following are valid constraints or required actions when modifying exported outputs that are referenced by other stacks? (Select TWO.)

Select all that apply

The network stack cannot be deleted, and its exported output values cannot be modified or deleted as long as they are referenced by the application stack.

To modify exported values in the network stack, the developer must first update the importing application stack to remove the references to those exports.

The developer can run drift detection, manually modify the resource values directly in the AWS console, and then trigger a stack sync to update the cross-stack reference.

Sensitive credentials that require automatic rotation should be stored in Systems Manager Parameter Store and shared using cross-stack reference exports.

If the network stack update fails and is stuck in the `UPDATE_ROLLBACK_FAILED` state, the developer must update the referencing application stack to automatically force the network stack to rollback.

Show answer & explanation

Answer: The network stack cannot be deleted, and its exported output values cannot be modified or deleted as long as they are referenced by the application stack.; To modify exported values in the network stack, the developer must first update the importing application stack to remove the references to those exports.

Answer

The network stack cannot be deleted, and its exported output values cannot be modified or deleted as long as they are referenced by the application stack; and to modify exported values in the network stack, the developer must first update the importing application stack to remove the references to those exports.

AWS CloudFormation enforces that you cannot delete a stack if its exported outputs are referenced by another stack, nor can you modify or delete any exported output value that is currently in use. To successfully change an exported value, the importing stack must first be updated to remove the reference to the export. Once the reference is removed, the exporting stack can be updated, and then the importing stack can be updated to reference the new export.

Step-by-Step Solution

Identify the dependency relationship between the two stacks, noting that the application stack imports values exported by the network stack.

Confirm that the network stack is the exporting stack and the application stack is the importing stack.

This establishes that the network stack outputs cannot be modified or deleted directly due to active external references.

Analyze how CloudFormation handles updates to exported values that are currently in use by other stacks.

Determine that CloudFormation will block any updates to the exporting stack that attempt to modify or delete the referenced outputs.

This is a core constraint of cross-stack references in AWS CloudFormation to prevent breaking dependent resources.

Formulate the correct remediation sequence to modify the subnet configuration output.

The developer must first update the application stack to remove the Fn::ImportValue references (e.g., by temporarily hardcoding the values or using another sharing mechanism), then update the network stack's outputs, and finally restore the references in the application stack.

This temporarily breaks the dependency lock, allowing the network stack update to proceed successfully.

Key Concept

AWS CloudFormation cross-stack references enforce strong dependencies, preventing the deletion of exporting stacks or modification of exported values until all referencing stacks remove their imports.

Estimated Time:2m 0s

Question 255Question →

A developer needs to run a database migration script on Amazon EC2 instances before the new application files are copied during an AWS CodeDeploy deployment. Which configuration file and lifecycle hook should the developer use to execute this script?

A buildspec.yml file in the root directory, running the script in the pre_build phase

An appspec.yml file in the root directory, running the script in the BeforeAllowTraffic hook

An appspec.yml file in the root directory, running the script in the BeforeInstall hook

A configuration file in the .ebextensions directory, running the script in container_commands

Show answer & explanation

Answer: An appspec.yml file in the root directory, running the script in the BeforeInstall hook

Answer

An appspec.yml file in the root directory, running the script in the BeforeInstall hook

AWS CodeDeploy manages EC2/On-Premises deployments using the appspec.yml file located in the root of the source directory. In this file, the developer can define hooks to run scripts at specific phases. The BeforeInstall hook is the appropriate hook to execute scripts (such as database migrations or clearing temp folders) before the actual application files are copied to the instance during the installation phase.

Step-by-Step Solution

Identify the service responsible for orchestrating the deployment to Amazon EC2.

The deployment is orchestrated by AWS CodeDeploy.

AWS CodeDeploy requires a configuration file named appspec.yml at the root of the source bundle to define deployment lifecycle hooks.

Determine the correct lifecycle hook for running tasks before files are copied.

The BeforeInstall hook is executed prior to the installation phase where files are copied to the target directory.

For EC2/On-Premises deployments, the AppSpec lifecycle sequence runs ApplicationStop -> BeforeInstall -> Install -> AfterInstall -> ApplicationStart -> ValidateService. Therefore, running a script before files are copied requires using BeforeInstall.

Key Concept

AWS CodeDeploy AppSpec lifecycle hooks for EC2 deployments

Question 256Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline in Account A. The pipeline is designed to deploy a web application to an Amazon ECS cluster located in Account B. The pipeline uses an Amazon S3 bucket in Account A as its artifact store. During the deployment phase, the deployment action in Account B fails with an Access Denied error when attempting to read the build artifact from the S3 bucket in Account A. Which configuration change will resolve this issue?

Configure the S3 bucket in Account A to use a customer managed key (CMK) in AWS KMS, and update both the S3 bucket policy and the KMS key policy to grant the deployment role in Account B access.

Add the CodePipeline service role ARN from Account A to the trust policy of the Account B deployment role so that Account B can assume the role to access the default AWS managed S3 key.

Store the cross-account S3 access keys as a secure string in AWS Systems Manager Parameter Store in Account A, and configure Parameter Store native automatic rotation to dynamically refresh the credentials.

Move the deployment configuration files from the root of the source repository to a nested subdirectory and update the CodePipeline action settings to reference the new path.

Show answer & explanation

Answer: Configure the S3 bucket in Account A to use a customer managed key (CMK) in AWS KMS, and update both the S3 bucket policy and the KMS key policy to grant the deployment role in Account B access.

Answer

Configure the S3 bucket in Account A to use a customer managed key (CMK) in AWS KMS, and update both the S3 bucket policy and the KMS key policy to grant the deployment role in Account B access.

The correct answer is to configure the S3 bucket in Account A with a customer managed key (CMK) and grant read and decrypt access to the Account B role. AWS CodePipeline stores artifacts in S3. For cross-account deployments, the action in the target account must read these artifacts. Since the default S3 KMS key cannot be shared across AWS accounts, the artifact bucket must be encrypted with a Customer Managed Key, and its policy must trust the target account role.

Step-by-Step Solution

Identify the root cause of cross-account artifact decryption failure.

The default AWS managed S3 key (aws/s3) cannot be used for cross-account operations.

AWS managed keys cannot have their key policies modified to grant access to external accounts.

Create and configure a Customer Managed Key (CMK) in AWS KMS within Account A.

A CMK is created with a key policy that explicitly grants decrypt permissions to the deployment IAM role in Account B.

A customer managed key allows external accounts to be granted usage permissions.

Update the S3 bucket policy in Account A.

The bucket policy allows the deployment IAM role in Account B to perform GetObject operations.

Both S3 resource permissions and KMS key permissions must be satisfied for successful retrieval.

Key Concept

Cross-account artifact access in AWS CodePipeline requires using a customer managed key (CMK) in AWS KMS and granting permissions to the target account's deployment role in both the S3 bucket policy and the KMS key policy.

Question 257Question →

An organization is transitioning a containerized API from Amazon EC2 to Amazon ECS and implementing blue/green deployments using AWS CodeDeploy. A developer must configure the deployment to execute an AWS Lambda function named "ValidateDeployment" to run smoke tests on the replacement task set after it is provisioned but before any traffic is routed to it. The validation Lambda function must also retrieve database credentials from AWS Secrets Manager during its run. Which configuration represents the correct setup for the AppSpec file and the required IAM roles to support this deployment?

Use an AppSpec file with lowercase resources and hooks sections, defining the Lambda function ARN under hooks as `- AfterInstall: "arn:aws:lambda:us-east-1:123456789012:function:ValidateDeployment"`. Configure the Amazon ECS Task Execution Role with a trust policy for ecs-tasks.amazonaws.com, and grant it AWS Secrets Manager retrieve permissions.

Use an AppSpec file with capitalized Resources and Hooks sections, defining the Lambda function ARN under Hooks as `- AfterInstall: "arn:aws:lambda:us-east-1:123456789012:function:ValidateDeployment"`. Configure the CodeDeploy service role to trust codedeploy.amazonaws.com. Grant the CodeDeploy service role permissions to retrieve the database credentials from Amazon Systems Manager Parameter Store, as CodeDeploy will retrieve and inject the credentials.

Use an AppSpec file with capitalized Resources and Hooks sections, defining the Lambda function ARN under Hooks as `- AfterInstall: "arn:aws:lambda:us-east-1:123456789012:function:ValidateDeployment"`. Configure the AWS CodeDeploy service role with a trust policy that allows codedeploy.amazonaws.com to assume the role. Grant the validation Lambda function's execution role permission to retrieve the database credentials from AWS Secrets Manager.

Use an AppSpec file with lowercase files and hooks sections, defining a shell script under hooks as `- ApplicationStart: "scripts/validate.sh"`. Configure the Amazon EC2 Instance Profile role to trust codedeploy.amazonaws.com. Grant the EC2 Instance Profile role permission to retrieve the database credentials from AWS Secrets Manager.

Show answer & explanation

Answer: Use an AppSpec file with capitalized Resources and Hooks sections, defining the Lambda function ARN under Hooks as `- AfterInstall: "arn:aws:lambda:us-east-1:123456789012:function:ValidateDeployment"`. Configure the AWS CodeDeploy service role with a trust policy that allows codedeploy.amazonaws.com to assume the role. Grant the validation Lambda function's execution role permission to retrieve the database credentials from AWS Secrets Manager.

Answer

The correct configuration is to use capitalized Resources and Hooks sections in the AppSpec file, define the validation Lambda function under the AfterInstall hook, configure the AWS CodeDeploy service role to trust codedeploy.amazonaws.com, and grant the validation Lambda function's IAM execution role permission to retrieve the credentials from AWS Secrets Manager.

The correct option correctly identifies that for ECS deployments, the AppSpec file must contain capitalized Resources and Hooks sections, and the validation hook must be a Lambda function defined under a valid ECS hook like AfterInstall. It also correctly specifies that the CodeDeploy service role trust policy must trust codedeploy.amazonaws.com, and the validation Lambda function's execution role must be granted Secrets Manager permissions to retrieve database credentials.

Step-by-Step Solution

Identify the AppSpec syntax requirements for ECS deployments.

The AppSpec file must use capitalized Resources and Hooks keys, and the lifecycle hooks must invoke AWS Lambda functions rather than shell scripts.

ECS and Lambda deployments in CodeDeploy utilize a different schema structure than EC2/On-Premises deployments, requiring capitalized keys and Lambda function targets.

Determine the correct CodeDeploy lifecycle hook for validation before traffic routing.

AfterInstall runs after the replacement task set is created but before traffic routing starts.

This ensures validation is completed before the production listener shifts traffic to the new task set.

Identify the required IAM configurations for CodeDeploy and the validation hook.

The CodeDeploy service role must trust codedeploy.amazonaws.com. The validation Lambda function's IAM execution role must have permissions to assume lambda.amazonaws.com and must be granted secretsmanager:GetSecretValue permissions.

CodeDeploy needs to assume its own service role to execute the deployment, and the Lambda function executes under its own role to retrieve the secrets directly.

Key Concept

AWS CodeDeploy AppSpec lifecycle hooks and IAM configuration requirements for Amazon ECS blue/green deployments.

Estimated Time:2m 30s

Question 258Question →

A developer is configuring a rolling update deployment for an application hosted on an Amazon Elastic Container Service (Amazon ECS) cluster using the EC2 launch type. The service runs with a desired task count of $4$ . Due to strict memory constraints on the container instances, the cluster cannot run more than $6$ tasks simultaneously. Additionally, the application must maintain at least $50\%$ of its desired capacity ( $2$ tasks) at all times to handle incoming baseline traffic.

Which two parameters should the developer configure in the ECS service definition to meet these requirements? (Select TWO.)

Select all that apply

Set `minimumHealthyPercent` to

50

Set `maximumPercent` to

150

Set `minimumHealthyPercent` to

100

Set `maximumPercent` to

100

Set `minimumHealthyPercent` to

25

Show answer & explanation

Answer: Set `minimumHealthyPercent` to $50$ .; Set `maximumPercent` to $150$ .

Answer

Setting the minimum healthy percent to

50

and the maximum percent to

150

in the ECS service definition deployment configuration.

To satisfy the requirements, the developer must configure the deployment parameters of the ECS service relative to the desired task count of

4

. The minimum healthy percent represents the lower limit of healthy tasks that must remain running during a deployment, calculated as

\frac{2}{4} \times 100\% = 50\%

. The maximum percent represents the upper limit of tasks that can be running, calculated as

\frac{6}{4} \times 100\% = 150\%

. Together, these parameters allow the ECS service to perform a rolling update by launching up to

2

new tasks before terminating old ones, while never dropping below

2

active tasks or exceeding

6

total tasks.

Step-by-Step Solution

Calculate the required minimum healthy percent from the capacity constraint.

The minimum required active capacity is

2

tasks out of a desired count of

4

. Expressed as a percentage:

\frac{2}{4} \times 100\% = 50\%

. Therefore, the minimum healthy percent must be set to

50

This guarantees that ECS will not terminate tasks below the

50\%

threshold (

2

tasks) during the rolling update.

Calculate the required maximum percent from the resource constraints.

The maximum allowed concurrent capacity is

6

tasks out of a desired count of

4

. Expressed as a percentage:

\frac{6}{4} \times 100\% = 150\%

. Therefore, the maximum percent must be set to

150

This configuration allows ECS to start up to

2

new tasks of the new version before terminating any old tasks, while ensuring the cluster memory limit is not exceeded.

Key Concept

Amazon ECS Rolling Update Deployment Parameters

Estimated Time:1m 30s

Question 259Question →

A company's containerized microservice is being migrated to run on AWS Fargate. During task initialization, the Amazon ECS container agent must retrieve database credentials from AWS Secrets Manager and inject them as environment variables inside the container. The containerized application itself does not make any direct AWS SDK calls. A developer creates a task definition and specifies the Secrets Manager secret ARN in the `secrets` parameter of the container definition. However, when attempting to run the task, it fails to start, showing a `ResourceInitializationError` due to access denied errors while retrieving the secret.

Which configuration change is required to resolve this issue?

Attach an IAM policy with the `secretsmanager:GetSecretValue` permission to the Task Execution Role (`executionRoleArn`), and ensure the role's trust policy allows the `ecs-tasks.amazonaws.com` service principal to assume the role.

Attach an IAM policy with the `secretsmanager:GetSecretValue` permission to the Task Role (`taskRoleArn`), and ensure the role's trust policy allows the `ecs-tasks.amazonaws.com` service principal to assume the role.

Attach an IAM policy with the `secretsmanager:GetSecretValue` permission to the Task Execution Role (`executionRoleArn`), and ensure the role's trust policy allows the `ecs.amazonaws.com` service principal to assume the role.

Remove the `secrets` parameter from the container definition, hardcode the database credentials in the application's SDK client configuration, and retrieve the secret directly from Secrets Manager at runtime.

Show answer & explanation

Answer: Attach an IAM policy with the `secretsmanager:GetSecretValue` permission to the Task Execution Role (`executionRoleArn`), and ensure the role's trust policy allows the `ecs-tasks.amazonaws.com` service principal to assume the role.

Answer

The correct option correctly identifies that the ECS container agent retrieves the secret before container startup, meaning the permission must be on the Task Execution Role (`executionRoleArn`). It also correctly points out that the trust policy must allow the `ecs-tasks.amazonaws.com` service principal.

Step-by-Step Solution

Identify which role is responsible for secret retrieval during container startup.

The Amazon ECS container agent retrieves the secret and injects it as an environment variable before the application starts, which means this action is performed under the context of the Task Execution Role (`executionRoleArn`).

Permissions for operations performed by the ECS agent (such as pulling images or reading secrets for environment variables) belong to the Task Execution Role, while permissions for the application code itself belong to the Task Role.

Determine the required IAM permission and trust policy for the role.

The Task Execution Role must have `secretsmanager:GetSecretValue` permissions, and its trust policy must allow `ecs-tasks.amazonaws.com` to assume the role.

Without the correct trust policy, ECS cannot assume the role to fetch the secret, resulting in a task start failure.

Key Concept

ECS Task Role vs Task Execution Role for secret management

Question 260Question →

A development team is integrating an on-premises security scanning tool as a custom action in AWS CodePipeline. A custom worker application runs on-premises and processes the security scanning tasks.

Arrange the steps in the correct chronological order that the custom action worker must execute to process and complete a job in CodePipeline.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The custom worker must first poll for available jobs, acknowledge the retrieved job, process the job by downloading artifacts and running the scan, and finally report the success status back to CodePipeline.

The correct sequence starts with polling for jobs, followed by acknowledging the job to prevent duplicate executions, then downloading the artifacts and running the scan, and finally reporting the success status back to CodePipeline.

Step-by-Step Solution

Poll for jobs

The worker receives a job token and details from CodePipeline.

Since the worker is on-premises and CodePipeline cannot initiate connection, the worker must poll CodePipeline for new jobs.

Acknowledge the job

The job status is set to in-progress in CodePipeline.

This prevents other worker instances from picking up the same job and verifies that the worker is actively handling it.

Process job workloads

Input artifacts are processed, and the security scan runs.

The worker retrieves input artifacts from S3 using the credentials in the job details, then performs the security scan.

Put job success result

CodePipeline transitions the stage action to succeeded.

CodePipeline requires an explicit API call to mark the action as complete before it can trigger the next stage.

Key Concept

AWS CodePipeline Custom Actions and the Worker Lifecycle

Estimated Time:1m 30s

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