Deployment

376 questions

All types376 Multiple choice191 Multiple select171 Ordering14

A developer is configuring a rolling update deployment for an Amazon ECS service. The service has a desired task count of 12. To ensure high availability and prevent performance degradation under peak load, the service must maintain 100% of its desired capacity at all times during the deployment. Furthermore, due to CPU and memory constraints on the underlying container instances, the deployment can run at most 3 additional tasks concurrently. Which parameters for minimum healthy percent and maximum percent should the developer configure for the ECS service?

Minimum healthy percent of 100% and maximum percent of 125%

Minimum healthy percent of 75% and maximum percent of 125%

Minimum healthy percent of 100% and maximum percent of 100%

Minimum healthy percent of 75% and maximum percent of 100%

Show answer & explanation

Answer: Minimum healthy percent of 100% and maximum percent of 125%

Answer

Minimum healthy percent of 100% and maximum percent of 125%

The correct configuration is to set the minimum healthy percent to 100% and the maximum percent to 125%. The minimum healthy percent of 100% ensures that the ECS service always has at least 12 healthy tasks running (100% of the desired count of 12). The maximum percent of 125% allows the service to temporarily scale up to 15 tasks (125% of 12) during the deployment, representing the 3 additional tasks permitted by the resource constraints.

Step-by-Step Solution

Calculate the minimum number of running tasks required based on the capacity constraint.

The minimum number of running tasks must be 12 (100% of the desired count of 12 tasks). Therefore, the minimum healthy percent is 100%.

The requirement states that the service must maintain 100% of its desired capacity at all times during the deployment.

Calculate the maximum number of running tasks allowed based on container instance resources.

The maximum number of running tasks allowed is 15 tasks (12 desired + 3 additional tasks).

The requirement states that the deployment can run at most 3 additional tasks concurrently.

Convert the maximum task count into a percentage of the desired count.

Maximum percent = (15 / 12) * 100 = 125%.

ECS service definitions express the maximum task limit during deployment as a percentage of the desired task count.

Key Concept

Amazon ECS rolling update deployment configuration parameters (minimumHealthyPercent and maximumPercent)

Question 362Question →

A developer is writing an AWS SAM template for a serverless application. The application contains a Lambda function (`ProcessOrdersFunction`) that must execute with a custom IAM role to comply with strict organizational security requirements. The developer defines the custom role and the function in the SAM template as follows:

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

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

ProcessOrdersFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: src/
Handler: index.handler
Runtime: nodejs18.x
Role: !GetAtt LambdaExecutionRole.Arn

OrdersTable:
Type: AWS::Serverless::SimpleTable

During deployment, the stack is created successfully. However, when the client application triggers the Lambda function, the function fails to execute, and the logs indicate that the execution role cannot be assumed. What is the root cause of this execution failure?

The template is missing the required AWS CloudFormation Transform declaration, which prevents AWS SAM from correctly compiling the custom IAM role.

The function does not define a custom execution timeout, causing AWS Lambda to reject the role assumption request.

The trust policy on the custom role specifies the service principal for API Gateway (apigateway.amazonaws.com) rather than AWS Lambda (lambda.amazonaws.com).

The API Gateway Lambda Proxy integration requires the execution role's trust policy to authorize the API Gateway service instead of the Lambda service.

Show answer & explanation

Answer: The trust policy on the custom role specifies the service principal for API Gateway (apigateway.amazonaws.com) rather than AWS Lambda (lambda.amazonaws.com).

Answer

The trust policy on the custom role incorrectly specifies the service principal for API Gateway rather than AWS Lambda, preventing AWS Lambda from assuming the execution role at runtime.

The correct answer is the option stating that the trust policy on the custom role specifies the service principal for API Gateway rather than AWS Lambda. For AWS Lambda to successfully execute a function, the function's execution role must contain a trust policy (AssumeRolePolicyDocument) that allows the AWS Lambda service principal ('lambda.amazonaws.com') to assume the role via the 'sts:AssumeRole' action. In this template, the service principal is set to 'apigateway.amazonaws.com', which prevents the Lambda service from assuming the role.

Step-by-Step Solution

Analyze the error context and deployment logs.

The stack deployed successfully, meaning the template structure and SAM transforms are valid. However, a runtime error occurs stating that the execution role cannot be assumed.

This isolates the issue to IAM role trust relationships rather than template parsing or CloudFormation syntax errors.

Examine the configuration of the custom IAM role in the SAM template.

The AssumeRolePolicyDocument allows the principal 'apigateway.amazonaws.com' to call 'sts:AssumeRole'.

The trust policy defines which AWS service or identity is trusted to assume the role. AWS Lambda requires the role to trust its own service principal.

Identify the correct service principal for AWS Lambda.

The service principal must be changed to 'lambda.amazonaws.com'.

Without trusting 'lambda.amazonaws.com', the AWS Lambda service cannot assume the role to run the function code under that identity, causing a runtime execution failure.

Key Concept

AWS Lambda Execution Role Trust Policy Configuration

Question 363Question →

A developer is configuring an AWS CodeDeploy deployment group to perform a blue/green deployment for an Amazon ECS service. The developer wants to run validation tests against the replacement task set using a test listener before routing production traffic. The deployment fails during the validation phase. Upon reviewing the logs, the developer discovers that the AppSpec file specifies an invalid lifecycle hook for the ECS compute platform, and CodeDeploy is unable to invoke the validation Lambda function due to incorrect IAM permissions. Which combination of configurations will correctly resolve these issues?

Change the AppSpec lifecycle hook to AfterAllowTestTraffic and ensure that the CodeDeploy service role is granted lambda:InvokeFunction permissions.

Change the AppSpec lifecycle hook to ValidateService and ensure that the CodeDeploy service role is granted lambda:InvokeFunction permissions.

Change the AppSpec lifecycle hook to AfterAllowTestTraffic and add codedeploy.amazonaws.com to the trust policy of the validation Lambda function's IAM execution role.

Change the AppSpec lifecycle hook to AfterAllowTestTraffic and store the Lambda function's database credentials in AWS Systems Manager Parameter Store with automatic rotation enabled.

Show answer & explanation

Answer: Change the AppSpec lifecycle hook to AfterAllowTestTraffic and ensure that the CodeDeploy service role is granted lambda:InvokeFunction permissions.

Answer

Change the AppSpec lifecycle hook to AfterAllowTestTraffic and ensure that the CodeDeploy service role is granted lambda:InvokeFunction permissions.

The correct option is the one that changes the AppSpec lifecycle hook to AfterAllowTestTraffic and ensures that the CodeDeploy service role is granted lambda:InvokeFunction permissions. In an Amazon ECS blue/green deployment, the AfterAllowTestTraffic hook runs validation tests after test traffic is routed to the replacement task set. Additionally, the CodeDeploy service role requires permission to invoke the validation Lambda function.

Step-by-Step Solution

Identify the correct AWS CodeDeploy lifecycle hook for Amazon ECS.

Amazon ECS deployments support specific hooks such as BeforeInstall, AfterInstall, AfterAllowTestTraffic, BeforeAllowTraffic, and AfterAllowTraffic. The ValidateService hook is only for EC2/on-premises deployments.

Choosing the correct hook ensures CodeDeploy runs the validation tests at the correct phase of the blue/green deployment.

Determine the necessary IAM configuration to allow CodeDeploy to invoke the validation Lambda function.

The CodeDeploy service role requires the lambda:InvokeFunction permission. The Lambda function's execution role does not need its trust policy updated to trust CodeDeploy because CodeDeploy does not assume the Lambda role to invoke it.

Granting direct invocation permissions to the CodeDeploy service role allows it to trigger the validation Lambda function.

Key Concept

AWS CodeDeploy ECS blue/green deployment lifecycle hooks and IAM permissions

Question 364Question →

An operations team is migrating a legacy provisioning stack to a serverless model. A team member creates a new template file containing an `AWS::Serverless::Function` resource:

yaml
AWSTemplateFormatVersion: '2010-09-09'

Resources:
RetrieveInventoryFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs20.x
CodeUri: ./src
Environment:
Variables:
DB_PASSWORD: '{{resolve:ssm-secure:InventoryDBPassword}}'

The database password requires automated rotation every 30 days. When attempting to create the stack, AWS CloudFormation fails with a validation error stating that the `AWS::Serverless::Function` resource type is unrecognized.

Which TWO actions should the team take to successfully deploy the template and retrieve the database credentials securely?

Select all that apply

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

Store the database password in AWS Secrets Manager and reference it using `{{resolve:secretsmanager:InventoryDBPassword}}` in the environment variables.

Add `Transform: AWS::Serverless-2010-09-09` at the root of the template file.

Keep the password in Systems Manager Parameter Store and write a custom script using AWS EventBridge to rotate the parameter.

Set the `Timeout` property of the `AWS::Serverless::Function` resource to `0` to ensure retrieval requests never time out.

Show answer & explanation

Answer: Add `Transform: AWS::Serverless-2016-10-31` at the root of the template file.; Store the database password in AWS Secrets Manager and reference it using `{{resolve:secretsmanager:InventoryDBPassword}}` in the environment variables.

Answer

Add the AWS SAM transform header `Transform: AWS::Serverless-2016-10-31` to the template, and store the password in AWS Secrets Manager, referencing it via the secretsmanager dynamic reference.

To fix the unrecognized resource error, the template must include the `Transform: AWS::Serverless-2016-10-31` declaration. Additionally, credentials requiring automated rotation should be stored in AWS Secrets Manager and referenced using the `secretsmanager` dynamic reference syntax.

Step-by-Step Solution

Add the SAM transform declaration to the template.

The resource `AWS::Serverless::Function` is recognized and compiled correctly by AWS CloudFormation.

The SAM transform tells CloudFormation to translate serverless resource definitions into standard CloudFormation resources during deployment.

Change the credential store from Systems Manager Parameter Store to AWS Secrets Manager.

The password is stored in a service that natively supports automated rotation every 30 days.

Parameter Store does not natively support automated scheduled rotation of credentials, which is a key requirement of Secrets Manager.

Update the reference in the template's environment variables to use `{{resolve:secretsmanager:InventoryDBPassword}}`.

The database password is dynamically retrieved securely at runtime.

Using the secretsmanager dynamic reference ensures the password is not hardcoded in the template while meeting security standards.

Key Concept

AWS SAM Template Anatomy & Credentials Rotation

Estimated Time:1m 30s

Question 365Question →

A developer is designing a deployment pipeline for a critical microservice on AWS. The deployment process must ensure zero downtime, allow testing of the new application version with a small fraction of production traffic before shifting all traffic, and support automatic rollback if CloudWatch alarms detect errors.

Which two deployment strategies or configurations will satisfy these requirements?

Select all that apply

An AWS CodeDeploy Canary deployment for an AWS Lambda function

An AWS CodeDeploy Linear deployment for an Amazon ECS service

An AWS Elastic Beanstalk All-at-Once deployment

An Amazon ECS Rolling Update with a minimum healthy percent of 100% and a maximum percent of 200%

An AWS Elastic Beanstalk Rolling deployment

Show answer & explanation

Answer: An AWS CodeDeploy Canary deployment for an AWS Lambda function; An AWS CodeDeploy Linear deployment for an Amazon ECS service

Answer

The deployment configurations that satisfy the requirements are the AWS CodeDeploy Canary deployment for an AWS Lambda function and the AWS CodeDeploy Linear deployment for an Amazon ECS service.

The correct strategies are the AWS CodeDeploy Canary deployment for an AWS Lambda function and the AWS CodeDeploy Linear deployment for an Amazon ECS service. Both configurations leverage traffic shifting (either at the Lambda alias level or via an Application Load Balancer target group for ECS) to route a small percentage of production traffic to the new version. Additionally, CodeDeploy monitors CloudWatch alarms during the deployment and can trigger an automatic, near-instantaneous rollback if errors are detected.

Step-by-Step Solution

Analyze the requirement for gradual traffic shifting to test the new version with a small fraction of production traffic.

Identify that AWS CodeDeploy Canary and Linear configurations support routing a small percentage of traffic (e.g., 10%) initially.

This isolates the test traffic and minimizes blast radius.

Evaluate the rollback requirements under failure conditions.

Identify that AWS CodeDeploy integrates with CloudWatch alarms to monitor the deployment and automatically roll back if errors occur.

This satisfies the automatic rollback requirement without manual intervention.

Verify if the remaining options satisfy the constraints.

Eliminate Elastic Beanstalk All-at-Once (downtime), ECS Rolling Update (no dedicated canary traffic shifting or automated alarm integration), and Elastic Beanstalk Rolling (no fine-grained traffic routing and automated rollback).

These strategies fail to meet either the zero-downtime, traffic-routing, or automatic rollback constraints.

Key Concept

Gradual traffic shifting and automated rollback using AWS CodeDeploy configurations for Lambda and ECS.

Estimated Time:2m 0s

Question 366Question →

A developer is configuring the `appspec.yml` file for an AWS Lambda deployment using AWS CodeDeploy. The deployment needs to shift traffic to a new version of a function. The developer wants to run validation tests before the traffic shift starts, and a notification function after all traffic has successfully shifted. The developer begins drafting the AppSpec file as follows:

yaml
version: 0.0
Resources:
- MyLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Name: "MyLambdaFunction"
Alias: "live"
CurrentVersion: "1"
TargetVersion: "2"
Hooks:
- Hook_1: "ValidationLambdaFunction"
- Hook_2: "NotificationLambdaFunction"

Which of the following lifecycle hooks are valid replacements for `Hook_1` and `Hook_2` to meet these requirements? (Select TWO.)

Select all that apply

BeforeAllowTraffic

AfterAllowTraffic

ValidateService

BeforeInstall

AfterInstall

Show answer & explanation

Answer: BeforeAllowTraffic; AfterAllowTraffic

Answer

BeforeAllowTraffic and AfterAllowTraffic

For AWS Lambda deployments, AWS CodeDeploy supports only two lifecycle hooks: BeforeAllowTraffic and AfterAllowTraffic. The hook BeforeAllowTraffic executes validation tasks before any traffic starts shifting, and AfterAllowTraffic executes tasks after all traffic has shifted to the new version.

Step-by-Step Solution

Identify the target compute platform for the CodeDeploy deployment based on the AppSpec schema.

The platform is AWS Lambda, indicated by the 'AWS::Lambda::Function' type under 'Resources'.

AWS CodeDeploy supports different lifecycle hooks depending on whether the target is EC2/On-premises, ECS, or Lambda.

Determine the supported lifecycle hooks for AWS Lambda deployments.

Only BeforeAllowTraffic and AfterAllowTraffic are valid lifecycle hooks for AWS Lambda in CodeDeploy.

Unlike EC2 or ECS, Lambda deployments only support hooks that run immediately before traffic shifting begins and immediately after traffic shifting completes.

Map the requirements (validation before shifting and notifications after shifting) to the corresponding hooks.

Hook_1 (validation before shifting) maps to BeforeAllowTraffic, and Hook_2 (notification after shifting) maps to AfterAllowTraffic.

BeforeAllowTraffic executes tasks before the first increment of traffic shifts to the new version, while AfterAllowTraffic runs after the final increment has shifted.

Key Concept

AWS CodeDeploy lifecycle hooks for AWS Lambda deployments

Estimated Time:1m 30s

Question 367Question →

A developer uses AWS SAM to build and deploy a serverless microservice. The SAM template defines a Lambda function triggered by an API Gateway event using the following template definition:

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

Resources:
SubmitFeedbackFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: src/
Handler: app.handler
Runtime: nodejs18.x
Events:
PostFeedback:
Type: Api
Properties:
Path: /feedback
Method: post

The Lambda function's handler code is implemented as follows:

javascript
exports.handler = async (event) => {
const feedbackText = event.feedback;
return {
message: `Feedback received: ${feedbackText}`
};
};

When clients send a POST request with the JSON payload `{"feedback": "Great service!"}`, the response from the API is ` $502$ Bad Gateway` and the Lambda logs show that `feedbackText` is undefined.

Which explanation best identifies the root cause of this failure, and how should it be resolved?

The API event source in AWS SAM defaults to API Gateway Lambda Proxy Integration, which passes the request payload as a serialized string in the body property of the event object. The handler must parse the body property to access the feedback value and must return a structured JSON response containing statusCode and body fields.

The AWS SAM template is missing the required global transform declaration at the resource level, preventing API Gateway from matching the route to the target Lambda function.

The Lambda function is timing out because its execution context is reused across requests, causing the default

3

-second runtime limit to be exceeded when processing the API payload.

The auto-generated IAM role for the function is missing a trust policy allowing the API Gateway service principal to assume the role, preventing API Gateway from invoking the function.

Show answer & explanation

Answer: The API event source in AWS SAM defaults to API Gateway Lambda Proxy Integration, which passes the request payload as a serialized string in the body property of the event object. The handler must parse the body property to access the feedback value and must return a structured JSON response containing statusCode and body fields.

Answer

The API event source in AWS SAM defaults to API Gateway Lambda Proxy Integration. In a proxy integration, the request payload is passed directly as a serialized JSON string under the body property of the event parameter. The handler code must parse this string (e.g., using JSON.parse(event.body)) to access nested properties. Additionally, the Lambda function must return a structured JSON response containing the statusCode integer and a stringified body to satisfy the API Gateway proxy format. Returning a custom object without these properties causes API Gateway to fail to parse the backend response, returning a

502

Bad Gateway error.

Step-by-Step Solution

Analyze the event source definition in the AWS SAM template.

The event named PostFeedback uses the Api type, which translates to an Amazon API Gateway REST API configured with Lambda Proxy Integration by default.

Determining the integration type is essential to understand the structure of the incoming event object and the required response format.

Examine the Lambda handler code and the log output.

The handler attempts to access event.feedback directly, but under Lambda Proxy Integration, the payload is serialized as a string in event.body. Therefore, event.feedback is undefined.

This explains why the variable evaluates to undefined during execution.

Analyze the

502

Bad Gateway error returned to clients.

In a proxy integration, API Gateway expects the Lambda function to return a structured JSON response containing key-value pairs for statusCode and body. Returning a plain object without these keys causes a parsing failure in API Gateway, resulting in a

502

error.

This identifies the structural requirements of the return payload to resolve the gateway integration error.

Key Concept

AWS SAM API Event Source and Lambda Proxy Integration Response Requirements

Question 368Question →

A developer is updating a critical AWS Lambda function using AWS CodeDeploy. The deployment must route $10\%$ of the production traffic to the new version of the function first. The deployment must then automatically shift the remaining $90\%$ of the traffic to the new version after exactly $15$ minutes, provided that no CloudWatch alarms are triggered during this window.

Which AWS CodeDeploy deployment configuration should the developer choose to satisfy these requirements?

CodeDeployDefault.LambdaCanary10Percent15Minutes

CodeDeployDefault.LambdaLinear10PercentEvery10Minutes

CodeDeployDefault.LambdaCanary10Percent10Minutes

CodeDeployDefault.LambdaLinear10PercentEvery15Minutes

Show answer & explanation

Answer: CodeDeployDefault.LambdaCanary10Percent15Minutes

Answer

CodeDeployDefault.LambdaCanary10Percent15Minutes

The correct configuration is the canary deployment option that specifies a

10\%

initial traffic shift followed by a

15

-minute monitoring interval before the remaining

90\%

is shifted. This matches the configuration named CodeDeployDefault.LambdaCanary10Percent15Minutes.

Step-by-Step Solution

Identify the deployment strategy type from the requirements.

The requirements describe a canary deployment strategy because traffic is shifted in two stages: an initial minor shift (

10\%

) and a final complete shift (

90\%

) after a specific wait period (

15

minutes).

Determining the correct class of deployment configuration narrows down the options between canary and linear.

Extract the specific percentage and time parameters.

The initial percentage is

10\%

, and the wait time is

15

minutes.

These parameters map directly to the names of the predefined deployment configurations in CodeDeploy.

Select the built-in configuration that matches these parameters.

The built-in configuration that routes

10\%

first and waits

15

minutes is CodeDeployDefault.LambdaCanary10Percent15Minutes.

This configuration satisfies all the criteria of the scenario.

Key Concept

AWS CodeDeploy deployment configurations for AWS Lambda functions

Estimated Time:1m 30s

Question 369Question →

A developer is managing an application deployed on a fleet of 10 Amazon EC2 instances using AWS CodeDeploy. The application must maintain a minimum of 8 healthy instances at all times during a deployment to handle peak traffic loads. To minimize the overall deployment duration as much as possible while strictly adhering to this capacity constraint, which CodeDeploy deployment configuration should the developer choose?

A custom deployment configuration with the minimum healthy hosts set to 80%.

The default CodeDeployDefault.OneAtATime deployment configuration.

The default CodeDeployDefault.HalfAtATime deployment configuration.

The default CodeDeployDefault.AllAtOnce deployment configuration.

Show answer & explanation

Answer: A custom deployment configuration with the minimum healthy hosts set to 80%.

Answer

A custom deployment configuration with the minimum healthy hosts set to 80%.

A custom deployment configuration specifying a minimum of 80% healthy hosts allows CodeDeploy to update 2 instances in parallel. This is the fastest way to deploy the update because it maximizes the number of parallel updates (2 instances) while guaranteeing that the remaining 8 instances (80%) stay online and healthy, satisfying the customer constraint.

Step-by-Step Solution

Identify the minimum capacity requirement from the scenario constraints.

The application runs on 10 EC2 instances and requires at least 8 instances to remain healthy, which equates to

8/10 = 80\%

minimum healthy capacity.

This determines the lower bound of healthy resources required during the update process.

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

Subtracting the required healthy instances from the total fleet size (

10 - 8 = 2

), we find that a maximum of 2 instances can be offline/updating at any given time.

To minimize deployment duration, we must maximize parallel updates without dropping below the capacity floor.

Evaluate the default CodeDeploy deployment configurations against the constraints.

CodeDeployDefault.OneAtATime updates 1 instance at a time (slower). CodeDeployDefault.HalfAtATime updates 5 instances at a time (violates the healthy host constraint). CodeDeployDefault.AllAtOnce updates 10 instances at a time (causes complete downtime).

To verify if any built-in default configurations can optimize the deployment time while maintaining safety.

Select the optimal configuration that meets all criteria.

A custom deployment configuration with minimum healthy hosts set to 80% (or 8 hosts) is selected as it allows 2 parallel updates, making it faster than the OneAtATime configuration.

Custom configurations are necessary when default configurations either violate safety constraints or perform suboptimally.

Key Concept

AWS CodeDeploy deployment configurations and capacity management

Estimated Time:1m 30s

Question 370Question →

A developer is deploying a serverless application using AWS SAM. The template contains a custom IAM role and a Lambda function configured as follows:

yaml
Transform: AWS::Serverless-2016-10-31
Resources:
ProcessDataFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs18.x
CodeUri: ./src
Role: !GetAtt CustomExecutionRole.Arn

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

During deployment, the CloudFormation stack creation fails with an error indicating that the Lambda function could not be created because AWS Lambda was unable to assume the configured role.

Which configuration change will resolve this deployment failure?

Remove the Transform: AWS::Serverless-2016-10-31 line from the template, as this declaration prevents CloudFormation from deploying standard AWS::IAM::Role resources.

Modify the Lambda function's properties to use a custom integration rather than a proxy integration to allow the role context to pass through API Gateway.

Modify the trust policy of CustomExecutionRole to specify lambda.amazonaws.com as the service principal in the Principal block.

Increase the Timeout property of the ProcessDataFunction to ensure the Lambda execution environment has enough time to assume the IAM role during container initialization.

Show answer & explanation

Answer: Modify the trust policy of CustomExecutionRole to specify lambda.amazonaws.com as the service principal in the Principal block.

Answer

Modify the trust policy of the custom execution role to specify the Lambda service principal, allowing AWS Lambda to assume the execution role.

The trust policy of an IAM role determines which entities are trusted to assume the role. For a Lambda function execution role, the trust policy must explicitly allow the AWS Lambda service principal (lambda.amazonaws.com) to assume the role. Because the template erroneously trusts API Gateway (apigateway.amazonaws.com) instead, the Lambda service is unauthorized to assume the role during deployment, leading to a creation failure.

Step-by-Step Solution

Identify the resource type and configuration in the AWS SAM template.

The template uses AWS::Serverless::Function and references a custom IAM execution role named CustomExecutionRole.

Understanding the relationship between the Lambda function and its execution role is necessary to trace role assumption issues.

Inspect the trust policy document configuration for the custom execution role.

The trust policy principal is set to apigateway.amazonaws.com instead of lambda.amazonaws.com.

The trust policy controls which AWS services are allowed to assume the role. If the wrong service principal is specified, the target service will be blocked from assuming the role.

Update the trust policy's principal to trust the Lambda service.

Changing the service principal to lambda.amazonaws.com permits the Lambda service to assume the role during initialization.

This resolves the deployment failure by granting AWS Lambda the required permissions to assume the configured role.

Key Concept

AWS SAM Lambda execution role configurations require a trust policy allowing lambda.amazonaws.com to assume the role.

Estimated Time:1m 30s

Question 371Question →

A developer is configuring AWS CodeDeploy to perform in-place deployments of a web application to a fleet of Amazon EC2 instances. The deployment group is configured, but the deployments fail immediately at the start with an error indicating that CodeDeploy does not have permission to access the target instances. The developer needs to ensure that the CodeDeploy service has the necessary permissions to perform the deployment.

Which configuration change will resolve this issue?

Add ECS-specific lifecycle hooks such as BeforeAllowTraffic and AfterAllowTraffic to the appspec.yml file to allow traffic routing.

Update the trust policy of the CodeDeploy IAM service role to allow the codedeploy.amazonaws.com service principal to assume the role.

Update the trust policy of the EC2 instance profile role to allow the ec2.amazonaws.com service principal to assume the role.

Store the CodeDeploy service role credentials as a secure string in AWS Systems Manager Parameter Store and retrieve them using an instance bootstrap script.

Show answer & explanation

Answer: Update the trust policy of the CodeDeploy IAM service role to allow the codedeploy.amazonaws.com service principal to assume the role.

Answer

Updating the trust policy of the CodeDeploy IAM service role to trust the CodeDeploy service principal.

Updating the trust policy of the CodeDeploy IAM service role to allow the codedeploy.amazonaws.com service principal to assume the role is correct. CodeDeploy requires a service role with permissions to access EC2 instances and ECS services on your behalf, and this role must trust the CodeDeploy service principal so that AWS CodeDeploy can assume it using AWS Security Token Service (STS).

Step-by-Step Solution

Identify the service role configured for the CodeDeploy deployment group.

The specific IAM role used by CodeDeploy is identified.

Deployments require a service role with appropriate permissions to execute actions.

Verify the trust relationship of the identified IAM service role in the IAM console.

The trust policy is found to be missing or misconfigured for the CodeDeploy service principal.

To assume a service role, AWS CodeDeploy must be allowed in the trust policy.

Modify the trust policy of the IAM service role to allow the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action.

The role's trust policy is successfully updated, allowing CodeDeploy to assume it.

This resolves the authorization failure and allows CodeDeploy to manage the deployment.

Key Concept

IAM service roles and trust policies for AWS CodeDeploy

Estimated Time:2m 0s

Question 372Question →

A development team is setting up a continuous delivery pipeline using AWS CodeDeploy for a microservice hosted on Amazon Elastic Container Service (Amazon ECS). The team wants to ensure that a validation test suite is executed immediately after the new container tasks are registered and test traffic is routed to them, but before any production traffic is shifted. Additionally, they want to execute a notification task once the production traffic has been completely transitioned.

Which actions must the developer take to achieve this deployment workflow? (Select TWO.)

Select all that apply

Define the AfterAllowTestTraffic hook in the appspec.yaml file to invoke a Lambda function that executes the validation tests.

Define the AfterAllowTraffic hook in the appspec.yaml file to invoke a Lambda function that executes the notification task.

Define the ApplicationStart and ApplicationStop hooks in the appspec.yaml file to run the validation tests and the notification task.

Update the trust policy of the Amazon ECS task execution role to trust the codedeploy.amazonaws.com service principal.

Store the notification service credentials in AWS Systems Manager Parameter Store as a Standard Parameter with a String data type for retrieval by the validation script.

Show answer & explanation

Answer: Define the AfterAllowTestTraffic hook in the appspec.yaml file to invoke a Lambda function that executes the validation tests.; Define the AfterAllowTraffic hook in the appspec.yaml file to invoke a Lambda function that executes the notification task.

Answer

To configure this ECS deployment workflow, the developer must define the AfterAllowTestTraffic hook in the appspec.yaml file to execute the validation tests, and define the AfterAllowTraffic hook to run the post-traffic routing notification task.

For an Amazon ECS deployment, CodeDeploy uses a specific set of hooks. The 'AfterAllowTestTraffic' hook runs after the replacement tasks are created and test traffic is routed to them, making it the ideal stage for running integration/validation tests. The 'AfterAllowTraffic' hook runs after all production traffic is shifted to the new task set, which is the correct moment to trigger a notification task confirming completion.

Step-by-Step Solution

Identify the target compute platform and its specific lifecycle hooks.

The platform is Amazon ECS. ECS-specific hooks must be used rather than EC2-specific ones.

AWS CodeDeploy uses distinct lifecycle hooks depending on the target compute platform.

Determine the correct lifecycle hook for the validation tests.

Validation tests must run after test traffic is active but before production traffic starts shifting, which matches the AfterAllowTestTraffic hook.

This hook fires as soon as the test port is serving traffic to the new task set.

Determine the correct lifecycle hook for post-deployment notification.

The notification must run after the shift of production traffic is completed, which corresponds to the AfterAllowTraffic hook.

This hook fires immediately after the production traffic routing is successfully fully swapped.

Key Concept

AWS CodeDeploy Lifecycle Hooks for ECS

Alternative Method

Instead of executing tests strictly in AfterAllowTestTraffic, you can also use AfterInstall to perform tests if you do not have a separate test port configured, though AfterAllowTestTraffic is the standard best practice when test traffic routing is configured.

Estimated Time:1m 30s

Question 373Question →

A developer has a production API hosted on Amazon API Gateway and wants to introduce a new API version. To minimize risk, the developer needs to route $5\%$ of the API traffic to the new version using the same endpoint, while the remaining $95\%$ continues to go to the current version. The developer wants to monitor the performance of the new version and must be able to immediately roll back all traffic to the current version if any anomalies are detected. Which deployment approach should the developer use to meet these requirements?

Deploy the new API version to a new stage, configure a Route 53 weighted routing policy with a

5\%

weight pointing to the new stage's endpoint, and decrease the TTL to zero for immediate rollback.

Deploy the new API version to a new stage, configure an Application Load Balancer with weighted target groups routing

5\%

of traffic to the new stage, and modify the target group weights to

0\%

to roll back.

Enable canary settings on the existing API Gateway stage, set the canary traffic percentage to

5\%

, and delete the canary deployment if any anomalies are detected.

Create a Route 53 failover routing policy that designates the current stage as primary and the new stage as secondary, and configure a CloudWatch alarm to trigger the failover.

Show answer & explanation

Answer: Enable canary settings on the existing API Gateway stage, set the canary traffic percentage to $5\%$ , and delete the canary deployment if any anomalies are detected.

Answer

Enable canary settings on the existing API Gateway stage, set the canary traffic percentage to

5\%

, and delete the canary deployment if any anomalies are detected.

Enabling canary settings on an existing API Gateway stage allows a developer to route a small percentage of traffic (such as

5\%

) to a new deployment using the same endpoint. If anomalies occur, deleting the canary deployment immediately routes all traffic back to the stable production version, satisfying the rollback requirement.

Step-by-Step Solution

Identify the requirement for percentage-based traffic routing on a single API endpoint.

The solution must support shifting

5\%

of traffic to the new version and

95\%

to the current version under the same stage endpoint.

Clients must access the API using the existing configuration without needing distinct URLs.

Evaluate the native deployment capabilities of Amazon API Gateway.

API Gateway offers stage-level canary settings, allowing traffic to be split between a production deployment and a canary deployment on the same stage.

This avoids external routing layers and provides native support for canary testing.

Determine the optimal rollback mechanism.

If anomalies occur, deleting the canary settings or deployment on the stage immediately redirects all traffic back to the primary production deployment.

This ensures the rollback is instantaneous, meeting the requirement without suffering from DNS propagation delays.

Key Concept

API Gateway Canary Deployments

Estimated Time:1m 15s

Question 374Question →

A developer is preparing to deploy updates to an AWS Lambda function using AWS CodeDeploy. The deployment must use a canary strategy (Canary10Percent5Minutes). The developer wants to execute a validation Lambda function to perform integration tests on the new version of the function before any production traffic is shifted to it. The deployment must also use a service role that grants CodeDeploy the necessary permissions to perform the deployment.

Which two actions should the developer take to configure this deployment? (Select TWO.)

Select all that apply

Define the validation Lambda function under the BeforeAllowTraffic hook in the hooks section of the AppSpec file.

Attach a trust policy to the CodeDeploy service role that allows the codedeploy.amazonaws.com service principal to assume the role.

Define the validation Lambda function under the AfterAllowTestTraffic hook in the hooks section of the AppSpec file.

Configure the trust policy of the Lambda function's execution role to allow the codedeploy.amazonaws.com service principal to assume it.

Store the database credentials used by the validation Lambda function in AWS Systems Manager Parameter Store and enable automatic rotation.

Show answer & explanation

Answer: Define the validation Lambda function under the BeforeAllowTraffic hook in the hooks section of the AppSpec file.; Attach a trust policy to the CodeDeploy service role that allows the codedeploy.amazonaws.com service principal to assume the role.

Answer

Define the validation Lambda function under the BeforeAllowTraffic hook in the hooks section of the AppSpec file, and attach a trust policy to the CodeDeploy service role that allows the codedeploy.amazonaws.com service principal to assume the role.

The correct options are to define the validation function in the BeforeAllowTraffic hook and configure the CodeDeploy service role trust policy. The BeforeAllowTraffic hook runs before any traffic is shifted to the new version, which allows the developer to run verification tests. The CodeDeploy service role must have a trust policy that allows codedeploy.amazonaws.com to assume the role in order to perform deployment tasks.

Step-by-Step Solution

Determine the correct CodeDeploy lifecycle hook for validating an AWS Lambda function before traffic starts routing to the new version.

Identify the BeforeAllowTraffic lifecycle hook as the appropriate hook.

AWS Lambda deployments support only BeforeAllowTraffic and AfterAllowTraffic hooks. BeforeAllowTraffic executes prior to any traffic shifting, which meets the requirement of verifying the function before production traffic is routed.

Establish the correct trust policy for the IAM service role used by CodeDeploy.

Ensure the trust policy allows the codedeploy.amazonaws.com service principal to assume the role.

AWS CodeDeploy requires permissions to interact with AWS Lambda and other services during deployment. This requires a dedicated CodeDeploy service role that explicitly trusts the CodeDeploy service principal.

Key Concept

Configuring AWS CodeDeploy for Lambda deployments using AppSpec lifecycle hooks and establishing the correct trust policy for the service role.

Question 375Question →

A developer is configuring an AppSpec file in YAML format for an AWS CodeDeploy deployment targeting Amazon ECS. The developer needs to run a validation Lambda function immediately after the replacement task set is created, but before any traffic shifts to the new version. Which of the following configurations correctly implements this requirement?

Under the hooks section, define the AfterInstall lifecycle event and specify the ARN of the validation Lambda function.

Under the hooks section, define the ValidateService lifecycle event and specify the file path of a shell script to run the tests.

Under the files section, map the source file path to the ECS container path, and specify the ApplicationStart hook to trigger the Lambda function.

Under the hooks section, define the AfterInstall lifecycle event and use AWS Systems Manager Parameter Store to reference and execute the test script.

Show answer & explanation

Answer: Under the hooks section, define the AfterInstall lifecycle event and specify the ARN of the validation Lambda function.

Answer

Under the hooks section, define the AfterInstall lifecycle event and specify the ARN of the validation Lambda function.

For an Amazon ECS deployment using AWS CodeDeploy, the AppSpec file defines lifecycle hooks under the hooks section that trigger AWS Lambda functions. The AfterInstall hook is executed after the replacement task set is created but before any traffic is routed to it. This makes it the correct place to run validation tests.

Step-by-Step Solution

Identify the target compute platform for the CodeDeploy deployment.

The target platform is Amazon ECS, which uses an AppSpec file containing Resources and Hooks sections.

AppSpec file structures and valid lifecycle hooks differ significantly between Amazon ECS, AWS Lambda, and EC2/on-premises compute platforms.

Determine the correct lifecycle hook for the validation timing requirement.

The requirement is to validate after the replacement task set is created but before any traffic shifts. The AfterInstall hook corresponds to this stage.

In ECS deployments, AfterInstall is the hook that runs immediately after the new task set is provisioned.

Identify how validation tasks are executed on Amazon ECS.

Validation tasks are executed by specifying a Lambda function ARN under the target lifecycle hook.

Unlike EC2 deployments which run shell scripts, ECS deployments use Lambda functions to execute validation checks.

Key Concept

AWS CodeDeploy AppSpec lifecycle hooks for Amazon ECS

Question 376Question →

A company runs a critical web application on AWS Elastic Beanstalk. The application must maintain $100\%$ of its capacity to handle peak traffic during updates. Additionally, if the new version fails post-deployment, the developer must be able to roll back to the previous version immediately with minimal service impact and without triggering a new application deployment.

Which two Elastic Beanstalk deployment strategies meet these requirements? (Select TWO).

Select all that apply

Blue/Green deployment

Immutable deployment

Rolling with additional batch deployment

Rolling deployment

All-at-once deployment

Show answer & explanation

Answer: Blue/Green deployment; Immutable deployment

Answer

Blue/Green deployment and Immutable deployment

Blue/Green deployment and Immutable deployment are correct because both strategies keep the original, healthy application instances running at

100\%

capacity while the new version is deployed and verified. In Blue/Green, a CNAME swap directs traffic to the new environment, and rolling back is as simple as swapping CNAMEs back. In Immutable, a temporary Auto Scaling group is created, and if the deployment fails, the temporary instances are terminated, instantly reverting traffic to the original instances without needing a new deployment.

Step-by-Step Solution

Analyze the capacity requirement.

Since the application must maintain

100\%

capacity, strategies that take existing instances offline without first adding capacity (such as Rolling and All-at-once) are ruled out.

To identify strategies that prevent latency spikes under peak load.

Analyze the rollback requirement.

The requirement specifies rollback without triggering a new deployment. In-place strategies (like Rolling with additional batch) require deploying the old version package again. Only strategies that keep the old environment/instances completely intact (Blue/Green and Immutable) support immediate rollback by swapping CNAMEs or terminating the new Auto Scaling group.

To identify strategies that avoid the overhead and time of redeploying the previous version in a failure scenario.

Key Concept

Elastic Beanstalk deployment strategies and their trade-offs regarding capacity and rollback mechanics.

Estimated Time:1m 30s

PreviousPage 19 / 19

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

Alternative Method

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution

Key Concept

Common Mistakes