All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

A developer is deploying an application on an Amazon EC2 instance. The application is designed to read messages from an Amazon SQS queue named `orders-queue` and write the processed items to an Amazon DynamoDB table named `orders-table`. The developer wants to configure the necessary permissions by following security best practices and avoiding hardcoded credentials. Which two configurations are required to meet these requirements? (Select TWO.)

Select all that apply

Create an IAM role with a permissions policy that allows the `sqs:ReceiveMessage` and `sqs:DeleteMessage` actions on the queue ARN, and the `dynamodb:PutItem` action on the table ARN.

Associate the IAM role with an IAM instance profile, and attach the instance profile to the EC2 instance.

Configure the IAM role's trust policy to trust `sqs.amazonaws.com` and `dynamodb.amazonaws.com` as the principal services.

Store AWS Access Key ID and Secret Access Key in a local application configuration file on the EC2 instance to initialize the SDK client.

Add a statement to the IAM role's trust policy that allows the IAM instance profile ARN to assume the role.

Show answer & explanation

Answer: Create an IAM role with a permissions policy that allows the `sqs:ReceiveMessage` and `sqs:DeleteMessage` actions on the queue ARN, and the `dynamodb:PutItem` action on the table ARN.; Associate the IAM role with an IAM instance profile, and attach the instance profile to the EC2 instance.

Answer

Create an IAM role with a permissions policy that allows SQS and DynamoDB actions, and associate the IAM role with an IAM instance profile attached to the EC2 instance.

To grant the EC2 instance access to SQS and DynamoDB without hardcoding credentials, the developer must create an IAM role with a permissions policy allowing SQS and DynamoDB actions, and associate the role with an IAM instance profile attached to the EC2 instance. This allows the application to retrieve temporary credentials automatically via the instance metadata service.

Step-by-Step Solution

Define permissions in an IAM policy.

An IAM permissions policy is created that allows `sqs:ReceiveMessage` and `sqs:DeleteMessage` on the SQS queue, and `dynamodb:PutItem` on the DynamoDB table.

This grants the application the minimum permissions required to interact with SQS and DynamoDB.

Create an IAM role and configure its trust policy.

An IAM role is created with a trust policy that allows the Amazon EC2 service (`ec2.amazonaws.com`) to assume the role via `sts:AssumeRole`.

The EC2 service needs permission to assume the role on behalf of the application running on the instance.

Attach the role to the EC2 instance using an instance profile.

An IAM instance profile is created, the IAM role is added to it, and the instance profile is attached to the EC2 instance.

This allows the application code to automatically retrieve temporary security credentials from the EC2 instance metadata service.

Key Concept

To securely grant applications running on EC2 instances access to AWS resources, create an IAM role with the required permissions, configure its trust policy to trust the EC2 service, and associate the role with the instance using an IAM instance profile.

Question 1382Question →

An application running in Amazon ECS container tasks writes structured JSON logs to Amazon CloudWatch Logs. A sample log event is:

{
"eventType": "DatabaseError",
"details": {
"duration": 4500,
"status": "failed"
}
}

A developer wants to create a CloudWatch Metric Filter to monitor events where the event type is "DatabaseError" and the nested query duration is greater than $4000$ milliseconds. The developer initially configures a metric filter with the pattern `[eventType = "DatabaseError", details.duration > 4000]`, but notices that the metric is not being published and no matches are found. Which of the following actions must the developer take to resolve this issue and successfully monitor the database errors? (Select TWO.)

Select all that apply

Update the filter pattern to use curly braces and JSON path notation: `{

.eventType = "DatabaseError" &&

.details.duration > 4000 }`

Specify a metric name, a metric namespace, and a metric value of

1

in the metric filter configuration.

Update the filter pattern to use double equals for the string comparison: `{

.eventType == "DatabaseError" &&

.details.duration > 4000 }`

Attach an IAM policy to the ECS Task Role that grants the `cloudwatch:PutMetricData` permission to allow the container to publish the filtered metrics.

Configure a CloudWatch subscription filter to route the logs to an Amazon Kinesis Data Firehose delivery stream, as standard metric filters cannot inspect nested JSON structures.

Show answer & explanation

Answer: Update the filter pattern to use curly braces and JSON path notation: `{ $.eventType = "DatabaseError" &&$ .details.duration > 4000 }`; Specify a metric name, a metric namespace, and a metric value of $1$ in the metric filter configuration.

Answer

Update the filter pattern to use curly braces and JSON path notation, and specify a metric name, a metric namespace, and a metric value of 1 in the metric filter configuration.

To successfully capture and record metrics from the JSON logs, two actions are required. First, the filter pattern must match the structured JSON schema. This is achieved by enclosing the expression in curly braces and using JSON path notation with a single equals sign for string comparison. Second, the metric filter must be configured with a metric namespace, metric name, and a metric value to indicate how CloudWatch should generate the data point when a log matches the pattern.

Step-by-Step Solution

Correct the log format interpretation in the filter pattern.

Change the pattern from space-delimited text syntax `[eventType = "DatabaseError", details.duration > 4000]` to JSON syntax `{

.eventType = "DatabaseError" &&

.details.duration > 4000 }`.

CloudWatch Logs requires curly braces `{}` and the `$.` prefix to query nested properties in JSON log events.

Map the filter matches to a target metric.

Define the target metric's namespace, name, and increment value (

1

A metric filter must specify how matching log events translate into custom metric data points in Amazon CloudWatch.

Key Concept

CloudWatch Logs Metric Filter JSON Syntax and Lifecycle

Estimated Time:2m 0s

Question 1383Question →

A developer is implementing fine-grained access control for a mobile application. Users authenticate via an Amazon Cognito User Pool, and the application needs to write user-specific profile data to an Amazon DynamoDB table named `UserProfiles`. The table's partition key is `UserId` (String). The developer created an Amazon Cognito Identity Pool to provide temporary AWS credentials to authenticated users and attached an IAM policy to the authenticated role that uses the `dynamodb:LeadingKeys` condition. However, when the application attempts to write data to the DynamoDB table, the API calls fail with an `AccessDeniedException` error. Which two actions must the developer take to resolve these authorization failures?

Select all that apply

Configure the application to exchange the Cognito User Pool tokens for temporary AWS credentials from the Cognito Identity Pool, and use these credentials to sign the DynamoDB requests.

Ensure that the partition key `UserId` value in the DynamoDB write request is set to the user's Cognito Identity ID.

Modify the trust policy of the authenticated IAM role to restrict the `dynamodb:LeadingKeys` condition to the Cognito identity provider.

Associate the IAM permission policy allowing `dynamodb:PutItem` directly to the Cognito User Pool's App Client configuration.

Embed static IAM credentials directly into the application's SDK client configuration to bypass the Cognito Identity Pool exchange.

Show answer & explanation

Answer: Configure the application to exchange the Cognito User Pool tokens for temporary AWS credentials from the Cognito Identity Pool, and use these credentials to sign the DynamoDB requests.; Ensure that the partition key `UserId` value in the DynamoDB write request is set to the user's Cognito Identity ID.

Answer

To resolve the authorization failures, the application must exchange the Cognito User Pool tokens for temporary AWS credentials from the Cognito Identity Pool and use those credentials to sign the requests. Additionally, the partition key value in the DynamoDB write request must match the user's Cognito Identity ID.

To resolve the authorization failure, the developer must ensure that the mobile application properly coordinates authentication and authorization. First, the application must exchange the Cognito User Pool token for temporary AWS credentials using the Cognito Identity Pool, as the User Pool token alone does not grant direct AWS service access. Second, the write request to DynamoDB must use the user's Cognito Identity ID as the partition key value to satisfy the `dynamodb:LeadingKeys` condition in the IAM permissions policy.

Step-by-Step Solution

Acquire temporary AWS credentials

The application authenticates against the Cognito User Pool, obtains an ID token, passes it to the Cognito Identity Pool using the `GetCredentialsForIdentity` API, and receives temporary AWS credentials associated with the authenticated IAM role.

DynamoDB requests must be signed with AWS credentials that map to the authorized IAM role, which is managed by the Identity Pool rather than the User Pool.

Align request partition key with IAM policy condition

The application sets the `UserId` partition key attribute of the write payload to the user's unique Cognito Identity ID.

The IAM policy uses `dynamodb:LeadingKeys` with `${cognito-identity.amazonaws.com:sub}`, meaning DynamoDB will reject any write request where the partition key does not match the requester's Cognito Identity ID.

Key Concept

Using Amazon Cognito Identity Pools and DynamoDB Fine-Grained Access Control (FGAC) to securely authorize mobile applications to access AWS services.

Estimated Time:1m 30s

Question 1384Question →

A developer uses AWS SAM to deploy a serverless application. The template defines an `AWS::Serverless::Function` triggered by an API Gateway HTTP API event source, and a custom `AWS::IAM::Role` for the execution role. The deployment completes successfully. However, when the API is invoked, the client receives a ` $502$ Bad Gateway` error. The CloudWatch logs show that the Lambda service is unable to assume the configured execution role, and the function is not executed.

Here is a portion of the template:

yaml
Resources:
ProcessOrderFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: src/
Handler: index.handler
Runtime: nodejs18.x
Role: !GetAtt ExecutionRole.Arn
Events:
CreateOrder:
Type: Api
Properties:
Path: /orders
Method: post

ExecutionRole:
Type: AWS::IAM::Role
Properties:
AssumeRolePolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Principal:
Service: apigateway.amazonaws.com
Action: sts:AssumeRole
Policies:
- PolicyName: WriteLogs
PolicyDocument:
Version: '2012-10-17'
Statement:
- Effect: Allow
Action:
- logs:CreateLogGroup
- logs:CreateLogStream
- logs:PutLogEvents
Resource: '*'

The handler code in `src/index.js` is defined as:

javascript
exports.handler = async (event) => {
return "Order successfully processed!";
};

Which TWO modifications are required to resolve both the execution role assumption issue and the ` $502$ Bad Gateway` error? (Select TWO.)

Select all that apply

Change the service principal in the AssumeRolePolicyDocument of ExecutionRole to lambda.amazonaws.com

Modify the handler code in src/index.js to return a JSON object containing statusCode and body keys

Change the service principal in the AssumeRolePolicyDocument of ExecutionRole to sts.amazonaws.com

Configure an API Gateway integration mapping template in the SAM template to parse the raw string return value

Increase the Timeout property of the Lambda function in the template to

30

seconds to bypass proxy response validation

Show answer & explanation

Answer: Change the service principal in the AssumeRolePolicyDocument of ExecutionRole to lambda.amazonaws.com; Modify the handler code in src/index.js to return a JSON object containing statusCode and body keys

Answer

To resolve these errors, change the execution role's trust policy service principal to lambda.amazonaws.com, and update the Lambda function handler to return a structured JSON object containing statusCode and body properties.

The trust policy must authorize the AWS Lambda service principal (lambda.amazonaws.com) to assume the role. The default Lambda Proxy Integration requires the response payload to be formatted with statusCode and body keys; otherwise, API Gateway returns a 502 Bad Gateway error.

Step-by-Step Solution

Analyze the IAM trust configuration for ExecutionRole in the template.

The principal service is set to apigateway.amazonaws.com, which grants API Gateway trust to assume the role instead of granting it to the Lambda execution service.

AWS Lambda must be explicitly trusted in the role's AssumeRolePolicyDocument to run the function code.

Analyze the API response model requirements for SAM Api events.

The Api event source implicitly sets up a Lambda Proxy Integration, which requires the handler to return a JSON object with statusCode and body properties.

Returning a raw string causes API Gateway to fail parsing the response, leading to a HTTP 502 Bad Gateway response.

Update the IAM service principal to lambda.amazonaws.com and refactor the handler return statement.

The execution role can now be assumed by Lambda, and the handler output conforms to the required proxy integration format.

These changes address both the execution permissions and the API response structure validation rules.

Key Concept

AWS SAM Integration Mechanics and IAM Service Trust Principles

Estimated Time:1m 30s

Question 1385Question →

A developer needs to deploy a new version of a critical web application. The deployment must satisfy the following constraints:
- The application must maintain $100\%$ of its serving capacity throughout the deployment.
- The deployment must have zero downtime.
- The deployment must not modify the existing production instances until the new version is fully verified.
- Rollbacks must be fast and have minimal impact on the active production environment if the new version fails verification.

Which two deployment strategies will satisfy these requirements? (Select two.)

Select all that apply

Blue/Green deployment

Immutable deployment

Rolling deployment

Rolling with additional batch deployment

All-at-once deployment

Show answer & explanation

Answer: Blue/Green deployment; Immutable deployment

Answer

The correct strategies are Blue/Green deployment and Immutable deployment.

The correct strategies are Blue/Green deployment and Immutable deployment. Both strategies deploy the new version of the application to new resources that are separate from the active production environment. This ensures that the active environment is not modified during the deployment,

100\%

capacity is maintained using the old version, and rollbacks are fast and simple (either by swapping DNS/traffic back or by terminating the temporary instances) if the verification fails.

Step-by-Step Solution

Analyze the capacity requirement

Strategies like Rolling or All-at-once, which temporarily take existing instances out of service, are eliminated because they reduce capacity below

100\%

The requirement states that

100\%

capacity must be maintained at all times.

Analyze the requirement to not modify existing instances until verified

Strategies like Rolling with additional batch are eliminated because they perform in-place updates on existing production instances during the rollout.

The system must keep the existing production environment untouched during the verification phase of the new version.

Evaluate Blue/Green and Immutable strategies

Both Blue/Green and Immutable deployments provision new resources separately from the active production fleet, keep the active environment intact until fully verified, support zero downtime, and can roll back instantly by redirecting traffic or terminating the new temporary resource group.

These strategies align perfectly with the need for zero downtime, full capacity, isolated verification, and rapid rollback.

Key Concept

Deployment strategies vary in how they handle capacity, resource overhead, in-place modifications, and rollback speed. Blue/Green and Immutable deployments prevent modification of existing production resources during validation, while Rolling and All-at-once modify them in-place.

Estimated Time:2m 0s

Question 1386Question →

An organization is transitioning their microservices to Amazon ECS and plans to use AWS CodeDeploy for automated blue/green deployments. To ensure zero downtime, the deployment workflow must execute validation tests against the replacement task set on a secondary port before shifting any production traffic. Furthermore, AWS CodeDeploy must be authorized to interact with the ECS cluster and load balancer during the deployment execution.

Which TWO configuration actions should the developer perform to support this deployment flow?

Select all that apply

Define the validation test under the AfterAllowTestTraffic lifecycle hook in the AppSpec file to trigger a validation AWS Lambda function.

Configure a trust policy on the CodeDeploy service role that allows the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action.

Define the validation test under the BeforeAllowTraffic lifecycle hook in the AppSpec file to execute a shell script that runs integration tests directly on the container.

Define the validation test under the AfterAllowTraffic lifecycle hook in the AppSpec file to verify the health of the replacement task set.

Configure the trust policy on the Amazon ECS task execution role to trust the codedeploy.amazonaws.com service principal.

Show answer & explanation

Answer: Define the validation test under the AfterAllowTestTraffic lifecycle hook in the AppSpec file to trigger a validation AWS Lambda function.; Configure a trust policy on the CodeDeploy service role that allows the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action.

Answer

To support this deployment flow, the developer must configure the validation tests under the AfterAllowTestTraffic lifecycle hook in the AppSpec file to trigger a validation AWS Lambda function, and configure a trust policy on the CodeDeploy service role to allow the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action.

To run validation tests on a test listener before production traffic shifts, the AfterAllowTestTraffic hook must be used to trigger a validation Lambda function. Additionally, CodeDeploy requires a service role with a trust policy that allows codedeploy.amazonaws.com to assume the role via sts:AssumeRole so it has the permissions to execute the deployment.

Step-by-Step Solution

Determine the deployment platform and validation timing requirement.

The target platform is Amazon ECS, and validation must occur on a test port before production traffic shifts.

This determines which AppSpec hooks and execution environments are valid.

Select the correct AppSpec hook and execution format for ECS.

The AfterAllowTestTraffic hook must be configured with a Lambda function reference. Script execution is not supported for ECS.

Only Lambda hooks are supported for ECS, and AfterAllowTestTraffic runs after the test listener routes traffic but before the production listener shifts.

Identify the service authorization mechanism.

CodeDeploy itself needs permissions, which requires a CodeDeploy service role with a trust policy for codedeploy.amazonaws.com.

This enables CodeDeploy to call ECS and Elastic Load Balancing APIs to execute the deployment.

Key Concept

AWS CodeDeploy ECS Deployment Validation and IAM Authorization

Question 1387Question →

A developer is troubleshooting an application that writes space-delimited log events to an Amazon CloudWatch Logs log group. A sample log event is:

`2026-07-14T12:00:00Z INFO 192.168.1.50 GET /index.html 200 125`

The fields in the log event represent the timestamp, severity, client IP address, HTTP method, resource path, status code, and response time in milliseconds, in that order.

The developer wants to create a CloudWatch Logs metric filter that counts all requests where either the status code is $500$ or the response time is greater than $500\text{ ms}$ .

Which of the following filter patterns must the developer use to correctly implement this metric filter?

[timestamp, severity, client_ip, method, resource, status_code = 500 OR response_time_ms > 500]

{

.status_code = 500 ||

.response_time_ms > 500 }

[timestamp, severity, client_ip, method, resource, status_code = 500 || response_time_ms > 500]

fields status_code, response_time_ms | filter status_code = 500 or response_time_ms > 500

Show answer & explanation

Answer: [timestamp, severity, client_ip, method, resource, status_code = 500 || response_time_ms > 500]

Answer

The filter pattern starting with square brackets and using the double pipe operator '||' to combine the field conditions.

The correct answer defines the space-delimited fields sequentially inside square brackets, assigning names to each position. It uses the correct logical OR operator '||' to combine the conditions for the status code and response time fields.

Step-by-Step Solution

Identify the format of the log events in the log group.

The log events are space-delimited text, not JSON-formatted.

Knowing the log format determines whether to use bracket syntax `[...]` for space-delimited logs or curly brace syntax `{...}` for JSON logs.

Map the log fields to their corresponding positions inside the brackets.

The fields must be defined in the correct order: `timestamp`, `severity`, `client_ip`, `method`, `resource`, `status_code`, and `response_time_ms`.

Space-delimited log patterns match fields by position from left to right.

Construct the logical condition with the correct filter syntax.

The condition uses the `=` and `>` operators, combined with the logical OR operator `||` inside the brackets.

CloudWatch Logs metric filters require the logical operators `||` (OR) and `&&` (AND) for multiple conditions, and do not accept SQL keywords like 'OR'.

Key Concept

CloudWatch Logs metric filter pattern syntax for space-delimited logs.

Estimated Time:1m 30s

Question 1388Question →

An organization hosts a web application on an AWS Elastic Beanstalk environment. The operations team needs to deploy a minor software update. Due to strict AWS account limits, the environment cannot launch any additional Amazon EC2 instances during the deployment. The application must remain online and accessible to users, but it can tolerate running at a minimum of $50\%$ of its total instance capacity during the deployment. Which Elastic Beanstalk deployment policy should the developer configure to meet these requirements?

Rolling

Rolling with additional batch

Immutable

All at once

Show answer & explanation

Answer: Rolling

Answer

Rolling

The Rolling deployment strategy updates the application in batches on the existing instances. This ensures that no new EC2 instances are provisioned during the process, adhering to the strict service limits. Because it updates one batch at a time, the application remains online, satisfying the availability requirement while running at the tolerated reduced capacity.

Step-by-Step Solution

Evaluate the capacity constraints and compute the allowed additional resources.

Zero new Amazon EC2 instances can be launched due to strict AWS account limits.

This rules out deployment strategies that require provisioning new instances, such as Immutable or Rolling with additional batch.

Analyze the availability requirement for the web application.

The application must remain online and accessible to users.

This rules out the All at once deployment strategy, which takes all instances out of service simultaneously.

Evaluate the remaining candidate strategies against the performance threshold.

The Rolling policy is selected because it updates instances in batches without creating new instances, while maintaining application availability at a reduced capacity of at least

50\%

Rolling updates satisfy the zero-new-instance limit and the online requirement by using existing instances in batches.

Key Concept

AWS Elastic Beanstalk deployment policies and their resource/capacity trade-offs

Estimated Time:1m 30s

Question 1389Question →

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

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

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

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

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

A developer is building a mobile health-tracking application. Users will log in using an external OpenID Connect (OIDC) compliant identity provider. After logging in, the mobile application must upload raw telemetry log files directly to a private Amazon S3 bucket, and invoke a private REST API hosted on Amazon API Gateway to fetch user profile data. Which TWO Amazon Cognito configurations are required to support this architecture?

Select all that apply

A Cognito User Pool federated with the OIDC identity provider to handle user authentication and issue identity and access tokens.

A Cognito Identity Pool configured to accept the OIDC-federated tokens and assume an IAM role for temporary AWS credentials to upload files to Amazon S3.

A Cognito User Pool group with an attached IAM role configured to directly authorize the client application to put objects into the S3 bucket.

An API Gateway Lambda Authorizer configured to validate the OIDC tokens and generate temporary AWS credentials for the S3 bucket access.

An API Gateway Cognito Authorizer configured to validate the OIDC tokens and return temporary AWS credentials to the mobile client.

Show answer & explanation

Answer: A Cognito User Pool federated with the OIDC identity provider to handle user authentication and issue identity and access tokens.; A Cognito Identity Pool configured to accept the OIDC-federated tokens and assume an IAM role for temporary AWS credentials to upload files to Amazon S3.

Answer

To support this architecture, the developer must configure a Cognito User Pool federated with the OIDC identity provider to handle user authentication, and a Cognito Identity Pool to exchange the OIDC tokens for temporary AWS credentials to write to the Amazon S3 bucket.

To authenticate users through an external OIDC identity provider and obtain user directory tokens (such as identity or access tokens), a Cognito User Pool must be configured with federation. To allow the mobile application to upload files directly to a private S3 bucket without routing through a server, a Cognito Identity Pool is required to exchange the OIDC-federated tokens for temporary, limited-privilege AWS credentials.

Step-by-Step Solution

Configure a Cognito User Pool with the OIDC identity provider as an external identity provider.

The User Pool validates OIDC authentication and issues identity, access, and refresh tokens to the mobile application.

A User Pool acts as the user directory and manages federation for user sign-in.

Configure a Cognito Identity Pool (Federated Identities) with the Cognito User Pool as an authentication provider.

The Identity Pool exchanges the OIDC-federated tokens for temporary, limited-privilege AWS credentials.

An Identity Pool is required to translate external identity tokens into IAM roles and temporary credentials for direct access to AWS resources like S3.

Key Concept

Distinction and integration between Amazon Cognito User Pools (authentication) and Cognito Identity Pools (authorization for AWS resources).

Question 1395Question →

A sports streaming application named FanStream logs viewer chat messages during live events. The chat messages are written to an Amazon DynamoDB table with EventID as the partition key and Timestamp as the sort key. During highly anticipated matches, the application experiences frequent ProvisionedThroughputExceededException errors on write operations, even though the total consumed write throughput is well below the table's provisioned capacity. Which of the following actions should the developer take to resolve this issue? (Select TWO.)

Select all that apply

Append a random suffix to the EventID partition key value before writing the items to distribute the write requests across multiple physical partitions.

Configure the AWS SDK client to utilize exponential backoff and jitter when retrying throttled requests.

Increase the visibility timeout of the upstream Amazon SQS queue that processes the incoming write requests.

Retrieve records using a Scan operation with a filter expression instead of using a Query.

Hardcode permanent AWS access keys directly in the application configuration to eliminate IAM metadata service query latency.

Show answer & explanation

Answer: Append a random suffix to the EventID partition key value before writing the items to distribute the write requests across multiple physical partitions.; Configure the AWS SDK client to utilize exponential backoff and jitter when retrying throttled requests.

Answer

To resolve the write throttling and key distribution issues, the developer should append a random suffix to the partition key (EventID) to distribute writes across partitions, and configure the AWS SDK client to use exponential backoff and jitter for retrying failed requests.

The correct options involve appending a random suffix to the partition key (which shards the hot partition key to distribute write traffic across physical partitions) and configuring the AWS SDK with exponential backoff and jitter (which prevents retry storms by spacing out requests and handling transient throttling gracefully).

Step-by-Step Solution

Analyze the table key design and throttling error.

Identify that the partition key (EventID) has high write concurrency during matches, concentrating all writes onto a single logical partition (a hot key scenario), causing ProvisionedThroughputExceededException.

DynamoDB allocates capacity across physical partitions based on partition keys. Concentrating traffic on a single key leads to throttling even if the total provisioned throughput is not exceeded.

Select a strategy to distribute the write load.

Append a random suffix (e.g., EventID_1, EventID_2) to the partition key to split the writes across multiple logical partitions.

This key sharding strategy ensures write operations are evenly distributed, avoiding the limits of a single partition.

Implement a retry policy to handle transient spikes.

Configure the AWS SDK with exponential backoff and jitter.

This mitigates temporary spikes by spacing out retry attempts, avoiding a thundering herd problem where all retries hit the table at the same time.

Key Concept

Resolving hot partitions and throttling in DynamoDB

Question 1396Question →

An e-commerce application deployed on Amazon ECS writes structured JSON logs to Amazon CloudWatch Logs. A developer needs to create a CloudWatch metric filter to count the occurrences of HTTP 504 Gateway Timeout errors. A sample log event is:

{
"request": {
"path": "/checkout",
"responseCode": 504
}
}

Which filter pattern must the developer use to correctly match this log event?

{ $.request.responseCode = 504 }

{ $.request.responseCode == 504 }

{ request.responseCode = 504 }

[request.responseCode = 504]

Show answer & explanation

Answer: { $.request.responseCode = 504 }

Answer

The pattern `{ $.request.responseCode = 504 }` is the correct filter pattern.

The correct pattern is `{

.request.responseCode = 504 }`. In CloudWatch Logs filter pattern syntax, JSON log events are matched using curly braces `{ }`. The root of the JSON document is represented by `

`, and nested properties are traversed using dot notation (e.g., `$.request.responseCode`). Additionally, equality comparison in CloudWatch filter patterns is performed using a single equals sign (`=`).

Step-by-Step Solution

Identify the log format

The log format is structured JSON, which requires curly braces `{ }` for the CloudWatch metric filter pattern.

CloudWatch Logs parses JSON objects only if the filter pattern is enclosed in curly braces.

Determine the path to the target field

The target field `responseCode` is nested under `request`. In CloudWatch Logs filter syntax, the root of the JSON object is represented by `

`, and nested fields are referenced using dot notation: `

.request.responseCode`.

Correct path syntax is necessary to address nested JSON properties.

Specify the comparison operator

CloudWatch Logs metric filter syntax uses a single equals sign `=` to evaluate equality.

Using operators like `==` will result in a syntax mismatch and zero metrics reported.

Key Concept

CloudWatch Logs Metric Filter JSON Syntax

Question 1397Question →

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

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

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

A developer is deploying a containerized application on Amazon ECS (Fargate). The application needs to read messages from an Amazon SQS queue and write items to an Amazon DynamoDB table. During deployment, the developer notices that the container starts up successfully but fails with an AccessDenied error when attempting to write to the DynamoDB table. Which of the following configurations will resolve this authorization issue while following the principle of least privilege?

Attach an IAM policy with permissions for sqs:ReceiveMessage and dynamodb:PutItem to an IAM role, configure this role as the taskRoleArn in the ECS task definition, and ensure the role's trust policy allows the ecs-tasks.amazonaws.com service principal to assume the role.

Attach an IAM policy with permissions for sqs:ReceiveMessage and dynamodb:PutItem to the ECS Task Execution Role (executionRoleArn) so that the container agent can pass these permissions to the application at runtime.

Generate long-term IAM access keys with SQS and DynamoDB permissions, store them in the application's environment variables, and configure the application code to explicitly initialize the AWS SDK client with these credentials.

Attach an IAM policy with permissions for sqs:ReceiveMessage and dynamodb:PutItem to an IAM role, configure this role as the taskRoleArn in the ECS task definition, and ensure the role's trust policy allows the ecs.amazonaws.com service principal to assume the role.

Show answer & explanation

Answer: Attach an IAM policy with permissions for sqs:ReceiveMessage and dynamodb:PutItem to an IAM role, configure this role as the taskRoleArn in the ECS task definition, and ensure the role's trust policy allows the ecs-tasks.amazonaws.com service principal to assume the role.

Answer

The correct configuration is to create an IAM role for the task itself (ECS Task Role) and attach the necessary application permissions (sqs:ReceiveMessage and dynamodb:PutItem). The trust policy of this IAM role must allow the 'ecs-tasks.amazonaws.com' service principal to assume the role. This permits the containerized application to automatically fetch temporary security credentials using the AWS SDK.

Step-by-Step Solution

Differentiate between the ECS Task Role and the ECS Task Execution Role.

Identify that permissions required by the application code itself (like DynamoDB and SQS access) must be granted via the Task Role (taskRoleArn), while permissions required by the ECS agent (like ECR image pulls) use the Task Execution Role.

This ensures the application container obtains the necessary credentials at runtime.

Configure the IAM role trust policy.

Verify that the trust relationship of the Task Role is configured to allow the service principal 'ecs-tasks.amazonaws.com' to call 'sts:AssumeRole'.

Without this trust relationship, ECS cannot assign the role to the running task, resulting in authorization errors.

Attach a least-privilege IAM policy to the Task Role.

Create and attach an IAM policy that allows only the required actions ('sqs:ReceiveMessage' and 'dynamodb:PutItem') on the specific SQS queue and DynamoDB table resources.

This fulfills the authorization requirement while adhering to the security principle of least privilege.

Key Concept

ECS Task Role vs. ECS Task Execution Role and IAM Trust Policies

PreviousPage 70 / 78Next

All practice questions

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