All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

A developer is implementing authentication and authorization for a mobile retail shopping application. The application needs to allow users to sign up and sign in, make authorized calls to a backend order processing API hosted on Amazon API Gateway, and upload scan logs directly to a private Amazon S3 bucket. Which architecture meets these requirements with the least operational overhead?

Configure a Cognito User Pool to handle user registration and login. Set up a Cognito Authorizer on Amazon API Gateway to validate the tokens generated by the User Pool. Configure a Cognito Identity Pool to exchange the User Pool tokens for temporary AWS IAM credentials to authorize direct S3 uploads.

Configure a Cognito Identity Pool to manage user registration and authentication. Set up a custom Lambda Authorizer on Amazon API Gateway to validate the session state, and use Cognito User Pool groups to authorize direct S3 uploads.

Configure a Cognito User Pool to handle user registration and login. Create a custom API Gateway Lambda Authorizer that parses the user identity from the User Pool, generates temporary IAM credentials, and returns them to the client to authorize S3 uploads and API calls.

Configure a Cognito User Pool to handle user registration. Write a custom IAM trust policy on the Amazon S3 bucket that allows direct write access based on the User Pool client ID, and use an API Gateway resource policy to authenticate API requests.

Show answer & explanation

Answer: Configure a Cognito User Pool to handle user registration and login. Set up a Cognito Authorizer on Amazon API Gateway to validate the tokens generated by the User Pool. Configure a Cognito Identity Pool to exchange the User Pool tokens for temporary AWS IAM credentials to authorize direct S3 uploads.

Answer

The correct solution leverages Cognito User Pools to authenticate users and generate JSON Web Tokens (JWTs). These tokens are verified directly by API Gateway using a built-in Cognito Authorizer, which requires no custom coding. To allow the mobile application to upload files directly to Amazon S3 without exposing static credentials or passing data through a backend, a Cognito Identity Pool is used to exchange the User Pool tokens for temporary, short-lived AWS IAM credentials.

Step-by-Step Solution

Select Amazon Cognito User Pools for authentication.

Enables user signup, signin, and directory management, producing JSON Web Tokens (JWTs) upon successful authentication.

User Pools are built specifically for identity management and authentication.

Configure API Gateway with a native Cognito Authorizer.

Enables API Gateway to validate User Pool tokens automatically without custom code or running a Lambda function.

Minimizes operational overhead and cost compared to custom Lambda authorizers.

Configure a Cognito Identity Pool (Federated Identities).

Allows authenticated User Pool users to exchange their tokens for temporary AWS credentials mapped to an IAM role with S3 write permissions.

Identity Pools are the standard AWS mechanism to authorize users for direct access to AWS resources like Amazon S3.

Key Concept

Cognito User Pools handle authentication (identity directory), while Cognito Identity Pools handle authorization (temporary AWS credentials for direct resource access). API Gateway Cognito Authorizers natively validate User Pool tokens.

Question 1402Question →

A developer is troubleshooting an application named PagePublish that stores metadata for online articles in an Amazon DynamoDB table. The table is configured with provisioned read capacity and uses ArticleStatus (such as DRAFT or PUBLISHED) as the partition key. During peak traffic hours, users experience high latency, and the application logs show numerous ProvisionedThroughputExceededException errors. Upon reviewing CloudWatch metrics, the developer notes that the read capacity is heavily consumed on a single partition, while other partitions remain idle. Which of the following is the most effective way to resolve this issue and prevent future throttling?

Increase the provisioned Read Capacity Units (RCUs) for the table to handle the traffic spikes during peak hours.

Modify the application to perform a Scan operation instead of a Query, and apply a filter expression on the client side to retrieve the articles.

Redesign the table schema to use a more granular attribute, such as ArticleID, as the partition key.

Increase the visibility timeout of the Amazon SQS queue that processes retrieval requests to give the table more time to process requests.

Show answer & explanation

Answer: Redesign the table schema to use a more granular attribute, such as ArticleID, as the partition key.

Answer

Redesign the table schema to use a more granular attribute, such as ArticleID, as the partition key.

Redesigning the table schema to use a more granular attribute like ArticleID ensures that write and read requests are evenly distributed across multiple physical partitions. Since DynamoDB allocates partition capacity based on the partition key value, high-cardinality keys prevent hot partitions and eliminate ProvisionedThroughputExceededException errors caused by uneven traffic distribution.

Step-by-Step Solution

Analyze the CloudWatch metrics and the exception logs.

Identify that the ProvisionedThroughputExceededException is occurring on a specific partition key value (ArticleStatus), indicating a hot partition issue.

Before applying a fix, the developer must determine if the throttling is due to overall capacity exhaustion or uneven key distribution.

Evaluate the cardinality of the partition key attribute.

Recognize that 'ArticleStatus' has very low cardinality (few distinct values like DRAFT or PUBLISHED), causing almost all requests to hit the same partition.

Understanding the key distribution characteristics is necessary to design a schema that distributes the workload evenly.

Select a partition key with high cardinality and modify the schema.

Choose a high-cardinality attribute like 'ArticleID' as the new partition key, which distributes read and write requests uniformly across partitions.

A high-cardinality partition key allows DynamoDB to partition the data across multiple physical SSDs, utilizing the provisioned throughput efficiently.

Key Concept

Resolving DynamoDB hot partitions by using a high-cardinality partition key design.

Estimated Time:1m 30s

Question 1403Question →

A developer is building a client proofing portal for a photography studio. The portal must authenticate clients using email and password, allow them to upload selection feedback files directly to a secure Amazon S3 bucket, and access private backend APIs on Amazon API Gateway. Which TWO actions must the developer take to configure the authentication and authorization flow?

Select all that apply

Set up a Cognito User Pool to handle user registration and sign-in, and configure a Cognito User Pool Authorizer on API Gateway to secure the APIs.

Set up a Cognito Identity Pool that uses the User Pool as an identity provider to obtain temporary AWS credentials for S3 bucket uploads.

Set up a Cognito User Pool to generate temporary AWS credentials for S3 uploads using Cognito Sync.

Create a custom API Gateway Lambda Authorizer that decodes and validates the Cognito User Pool identity tokens to authorize API calls.

Create a Cognito Identity Pool to store user profiles and authenticate users directly via email and password.

Show answer & explanation

Answer: Set up a Cognito User Pool to handle user registration and sign-in, and configure a Cognito User Pool Authorizer on API Gateway to secure the APIs.; Set up a Cognito Identity Pool that uses the User Pool as an identity provider to obtain temporary AWS credentials for S3 bucket uploads.

Answer

To configure the authentication and authorization flow, the developer must set up a Cognito User Pool to manage authentication and secure the API Gateway using a Cognito User Pool Authorizer, and set up a Cognito Identity Pool referencing the User Pool to obtain temporary AWS credentials for S3 uploads.

The system requires a Cognito User Pool to handle user directory registration, login, and token generation. The backend APIs are secured with minimal complexity by using the native Cognito User Pool Authorizer on API Gateway. Direct uploads to Amazon S3 are enabled by exchanging the user token for temporary AWS credentials via a Cognito Identity Pool, which assumes an authenticated IAM role with the necessary S3 permissions.

Step-by-Step Solution

Configure a Cognito User Pool.

Establishes a user directory for client registration and authentication, issuing identity and access tokens (JWTs) upon successful login.

A User Pool is required to manage credentials and handle user sign-in.

Create a Cognito User Pool Authorizer on Amazon API Gateway.

API Gateway validates the token automatically for incoming requests without requiring custom code.

Using the native Cognito Authorizer reduces operational overhead and simplifies API security.

Create a Cognito Identity Pool and link it to the User Pool.

The client application can exchange User Pool tokens for temporary AWS credentials mapped to an IAM role with S3 write permissions.

An Identity Pool is necessary to delegate temporary AWS access for direct interaction with S3.

Key Concept

Amazon Cognito User Pools vs. Identity Pools and API Gateway Authorization

Question 1404Question →

A developer is deploying a Go-based web application to Amazon EC2 instances. The application logs HTTP requests in a custom space-delimited format to /var/log/app/web.log. The fields in each log entry are: IP, client, user, datetime, request_path, response_status, and response_time_ms. The developer wants to use the unified CloudWatch agent to publish these logs to CloudWatch Logs and then create a metric filter to track only requests that returned an HTTP 404 response status. Which two configuration steps must the developer perform to meet these requirements?

Select all that apply

In the CloudWatch agent configuration file, specify the log file path under the logs.logs_collected.files section and define a target log group.

Create a CloudWatch Logs metric filter on the target log group using the pattern [ip, client, user, datetime, request_path, response_status = 404, response_time_ms].

Create a CloudWatch Logs metric filter on the target log group using the pattern { $.response_status = 404 }.

Create a CloudWatch Logs metric filter on the target log group using the pattern [response_status = 404].

In the CloudWatch agent configuration file, specify the log file path under the metrics.metrics_collected section to enable log streaming.

Show answer & explanation

Answer: In the CloudWatch agent configuration file, specify the log file path under the logs.logs_collected.files section and define a target log group.; Create a CloudWatch Logs metric filter on the target log group using the pattern [ip, client, user, datetime, request_path, response_status = 404, response_time_ms].

Answer

To monitor the space-delimited log file, the developer must configure the log file path under the logs.logs_collected.files section of the unified CloudWatch agent configuration file, and create a CloudWatch Logs metric filter with the pattern [ip, client, user, datetime, request_path, response_status = 404, response_time_ms].

To stream local log files to CloudWatch Logs, the unified CloudWatch agent must be configured with the file path in the logs.logs_collected.files section. To create a metric filter for space-delimited logs, the filter pattern must list all fields in order, enclosed in brackets, and use the assignment operator to filter on the specific HTTP status code.

Step-by-Step Solution

Configure the CloudWatch agent to collect the log file.

The file path /var/log/app/web.log and log_group_name are added to the logs.logs_collected.files section.

This informs the agent daemon to track the target log file and stream its content to CloudWatch Logs.

Create the metric filter for space-delimited events.

The metric filter is created on the target log group using the positional bracketed syntax [ip, client, user, datetime, request_path, response_status = 404, response_time_ms].

Because the logs are space-delimited rather than JSON, CloudWatch Logs maps fields positionally. Specifying the preceding fields is necessary for the filter to target the sixth field, response_status.

Key Concept

Configuring log collection with the unified CloudWatch agent and applying space-delimited metric filter patterns.

Question 1405Question →

An order ingestion application named OrderSync processes real-time transaction updates and writes them to an Amazon DynamoDB table. The table is configured with provisioned write capacity. During high-traffic flash sales, the application experiences a high rate of ProvisionedThroughputExceededException errors. CloudWatch metrics indicate that the overall write capacity consumption is well below the table's provisioned limit, but the write operations are concentrated on a small number of partition keys representing trending items.

Which TWO actions should the developer take to resolve these throttling issues? (Select TWO.)

Select all that apply

Modify the application's write logic to append a random numeric suffix to the partition key for high-volume items to distribute writes across multiple partitions.

Implement exponential backoff and jitter in the application's SDK client retry configuration to handle transient throttling errors.

Change the database read operations to use Scan instead of Query to bypass partition throughput limits.

Increase the visibility timeout of the SQS queue that feeds the application to give DynamoDB partitions more time to complete write operations.

Hardcode the access keys of an IAM user with administrator permissions in the AWS SDK client to bypass provisioning limits.

Show answer & explanation

Answer: Modify the application's write logic to append a random numeric suffix to the partition key for high-volume items to distribute writes across multiple partitions.; Implement exponential backoff and jitter in the application's SDK client retry configuration to handle transient throttling errors.

Answer

Modify the application's write logic to append a random numeric suffix to the partition key for high-volume items, and implement exponential backoff and jitter in the application's SDK client retry configuration.

The correct options are to append a random numeric suffix to the partition key (which spreads the write requests across multiple physical partitions, preventing individual partition limit exhaustion) and to configure the AWS SDK with exponential backoff and jitter (which handles temporary spikes in write requests without failing the transactions outright).

Step-by-Step Solution

Analyze the CloudWatch metrics and throttling errors.

Identified that the ProvisionedThroughputExceededException is caused by a hot partition key issue where writes are concentrated on a few trending items.

Before applying a fix, the developer must confirm whether the throttling is due to overall capacity exhaustion or uneven key distribution.

Apply write sharding using a random suffix.

The write requests are distributed across multiple partitions by appending a suffix, preventing a single partition from bearing the entire load.

DynamoDB partitions have a hard limit of 1000 WCU and 3000 RCU per partition. Distributing hot keys via sharding avoids hitting individual partition limits.

Configure the SDK retry policy with exponential backoff and jitter.

Transient throttling spikes are handled gracefully by retrying requests at randomized intervals.

Jitter prevents a 'thundering herd' problem where retried requests arrive simultaneously, causing repeated throttling.

Key Concept

Resolving DynamoDB throttling issues by avoiding hot partitions through partition key sharding and handling transient failures using backoff and jitter.

Question 1406Question →

A developer is troubleshooting a serverless application where an AWS Lambda function has a configured timeout of 15 seconds. The function is designed to write a custom JSON log entry to Amazon CloudWatch Logs at the end of its execution, structured as { "requestID": "123-456", "status": "COMPLETED", "executionTimeMs": 1250 }. If a database delay occurs, the function catches it and logs { "requestID": "123-456", "status": "ERROR", "errorType": "DatabaseTimeout" }. To track performance issues and failures, the developer configures a CloudWatch Metric Filter with the pattern { ( $.status = "ERROR") || ($ .executionTimeMs > 15000) }. During testing, several invocations time out, but the metric filter does not register any data points. Why is the metric filter failing to capture these timeout events?

The metric filter pattern is invalid because CloudWatch Logs JSON filter expressions require the double equality operator '==' rather than a single '=' for string equality evaluations.

When a Lambda function times out, the execution is abruptly terminated by the Lambda runtime, preventing the custom log statement from being written. The metric filter must instead match the platform-generated log string 'Task timed out'.

Lambda execution environments run in isolated sandboxes that prevent CloudWatch metric filters from reading log streams until the sandbox is completely recycled.

The metric filter is failing because JSON property names containing mixed case characters, such as 'executionTimeMs', must be converted to uppercase within the filter pattern expression.

Show answer & explanation

Answer: When a Lambda function times out, the execution is abruptly terminated by the Lambda runtime, preventing the custom log statement from being written. The metric filter must instead match the platform-generated log string 'Task timed out'.

Answer

The correct answer is correct because AWS Lambda enforces execution timeouts at the platform level. If the function times out, the execution container is terminated immediately, preventing any application-level catch blocks or log statements from executing. As a result, the custom JSON log containing the execution time is never written. The developer must instead match the platform-generated log line which contains the phrase 'Task timed out'.

Step-by-Step Solution

Analyze how AWS Lambda handles timeouts at the runtime level.

When the timeout threshold (15 seconds) is reached, the Lambda service immediately halts container execution.

This prevents any subsequent application-level code (including catch blocks or logging libraries) from running.

Determine where the log entries originate when a timeout occurs.

The application's custom JSON logs are not written. Instead, the AWS Lambda service writes a standard platform message containing the string 'Task timed out after 15.00 seconds'.

Since the application did not write the log, the metric filter looking for custom JSON properties like status or executionTimeMs will find nothing.

Formulate a metric filter pattern to capture these timeout events.

Create a metric filter that matches the string 'Task timed out' in the log group.

This platform-generated string is guaranteed to be logged by the Lambda service when a timeout occurs.

Key Concept

CloudWatch Logs filters and Lambda timeout log generation

Question 1407Question →

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

A developer is building a personal finance application. Users must be able to sign up, sign in, and access secured REST API endpoints on Amazon API Gateway. Additionally, users must be able to upload scanned monthly statements directly to a private Amazon S3 bucket. Which architecture meets these requirements with the least operational overhead?

Use an Amazon Cognito User Pool for user registration and authentication, configure an API Gateway Cognito user pool authorizer to secure the API endpoints, and use an Amazon Cognito Identity Pool to grant authenticated users temporary AWS credentials for the Amazon S3 uploads.

Use an Amazon Cognito Identity Pool for user registration and authentication, configure an API Gateway Cognito user pool authorizer to secure the API endpoints, and use an Amazon Cognito User Pool to grant authenticated users temporary AWS credentials for the Amazon S3 uploads.

Use an Amazon Cognito User Pool for user registration and authentication, write a custom Lambda authorizer to manually parse and validate the Cognito JSON Web Tokens (JWT) for the API endpoints, and use an Amazon Cognito Identity Pool to grant authenticated users temporary AWS credentials for the Amazon S3 uploads.

Use an Amazon Cognito User Pool for user registration and authentication, configure an API Gateway Cognito user pool authorizer to secure the API endpoints, and configure the application client with an IAM user's long-term access keys to handle the Amazon S3 uploads.

Show answer & explanation

Answer: Use an Amazon Cognito User Pool for user registration and authentication, configure an API Gateway Cognito user pool authorizer to secure the API endpoints, and use an Amazon Cognito Identity Pool to grant authenticated users temporary AWS credentials for the Amazon S3 uploads.

Answer

The correct architecture uses a Cognito User Pool to handle user registration and login, an API Gateway Cognito user pool authorizer to secure REST API endpoints with no coding effort, and a Cognito Identity Pool to dynamically exchange user pool tokens for temporary IAM credentials that authorize the client application to upload files directly to S3.

Step-by-Step Solution

Set up user authentication and directory services.

Create an Amazon Cognito User Pool to manage user registration, sign-in, and user attributes.

A User Pool serves as a user directory and issues JSON Web Tokens (JWT) upon successful authentication.

Protect the REST API endpoints in API Gateway.

Create a built-in Cognito User Pool authorizer in API Gateway and configure the API methods to require this authorizer.

Using the built-in Cognito authorizer allows API Gateway to natively validate the user's ID or access tokens without requiring custom Lambda code, minimizing operational overhead.

Configure secure access to Amazon S3.

Create an Amazon Cognito Identity Pool, specify the User Pool as the authentication provider, and map authenticated users to an IAM role with write permissions to the destination S3 bucket.

Cognito Identity Pools authorize access to AWS resources by exchanging external authentication tokens for scoped, temporary AWS credentials.

Key Concept

Distinction between Amazon Cognito User Pools (authentication) and Cognito Identity Pools (authorization to access AWS resources), alongside native API Gateway Cognito authorizer integration.

Estimated Time:2m 0s

Question 1409Question →

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

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

A developer is building a serverless web application for a fitness tracking portal. The application must allow users to log in using their existing Google or Facebook accounts. Once authenticated, the application must allow users to retrieve their profile data from an Amazon API Gateway REST API and upload workout videos directly to a private Amazon S3 bucket. Which TWO configuration steps should the developer perform to implement this authentication and authorization workflow with the least operational overhead?

Select all that apply

Configure a Cognito User Pool with Google and Facebook social identity providers, and configure a Cognito Authorizer on the API Gateway REST API.

Configure a Cognito Identity Pool, set the Cognito User Pool as an authentication provider, and assign an authenticated IAM role with write permissions for the S3 bucket.

Configure a Cognito User Pool with Google and Facebook, and associate an IAM role with the User Pool to generate temporary credentials for writing directly to the S3 bucket.

Configure a custom API Gateway Lambda Authorizer to validate the social identity provider tokens, and have it return temporary AWS credentials to the client for the S3 uploads.

Configure a custom API Gateway Lambda Authorizer to validate the Cognito Identity Pool token for the REST API endpoint.

Show answer & explanation

Answer: Configure a Cognito User Pool with Google and Facebook social identity providers, and configure a Cognito Authorizer on the API Gateway REST API.; Configure a Cognito Identity Pool, set the Cognito User Pool as an authentication provider, and assign an authenticated IAM role with write permissions for the S3 bucket.

Answer

Configure a Cognito User Pool with Google and Facebook social identity providers, configure a Cognito Authorizer on the API Gateway REST API, configure a Cognito Identity Pool using the User Pool as an authentication provider, and assign an authenticated IAM role with write permissions for the S3 bucket.

To implement authentication with Google and Facebook and access both API Gateway and S3 with the least operational overhead, the developer should combine a Cognito User Pool with a Cognito Identity Pool. The Cognito User Pool authenticates the federated social users and provides tokens. These tokens are natively validated by the API Gateway Cognito Authorizer to secure REST API endpoints without custom code. To allow direct upload to a private S3 bucket, the application must exchange the User Pool tokens for temporary AWS credentials using a Cognito Identity Pool, which maps the authenticated session to an IAM role with S3 write permissions.

Step-by-Step Solution

Set up User Directory and Social Federation

Configure an Amazon Cognito User Pool with Google and Facebook as identity providers to handle user registration, login, and identity token issuance.

A User Pool acts as the user directory and manages federation, allowing the application to authenticate users and receive JSON Web Tokens (JWTs) representing their identity.

Authorize API Access

Configure a Cognito Authorizer on the Amazon API Gateway REST API endpoints.

The Cognito Authorizer natively validates the identity tokens (JWTs) passed in the authorization header of incoming API requests, securing the backend with zero custom code.

Enable S3 Write Permissions

Create an Amazon Cognito Identity Pool, configure the User Pool as the authentication provider, and associate the authenticated IAM role with S3 write permissions.

An Identity Pool (Federated Identities) is required to exchange the authenticated User Pool token for temporary, short-lived AWS credentials, enabling the client application to directly upload video files to S3 without using a proxy backend.

Key Concept

Amazon Cognito Authentication and Authorization

Question 1412Question →

A developer is configuring an AWS Lambda function in Account A ( $111111111111$ ) that needs to write items to an Amazon DynamoDB table in Account B ( $222222222222$ ). The developer wants to use cross-account IAM roles to implement secure access following the principle of least privilege. An IAM role named `CrossAccountDynamoDBWriter` has been created in Account B with the necessary permission policy to write to the DynamoDB table.

Which two configuration steps must the developer perform to enable the Lambda function to access the DynamoDB table?

Select all that apply

In Account B, configure the trust policy of the `CrossAccountDynamoDBWriter` role to allow the Lambda function's execution role in Account A to assume the role.

In Account A, attach an identity-based policy to the Lambda function's execution role that grants the `sts:AssumeRole` permission on the ARN of the `CrossAccountDynamoDBWriter` role in Account B.

In Account A, configure the trust policy of the Lambda function's execution role to trust the `CrossAccountDynamoDBWriter` role in Account B.

In Account A, configure the Lambda function to use hardcoded access keys of an IAM user from Account B that has write access to the DynamoDB table.

In Account A, configure the Lambda function to assume the `CrossAccountDynamoDBWriter` role by adding a resource-based policy directly to the Lambda function.

Show answer & explanation

Answer: In Account B, configure the trust policy of the `CrossAccountDynamoDBWriter` role to allow the Lambda function's execution role in Account A to assume the role.; In Account A, attach an identity-based policy to the Lambda function's execution role that grants the `sts:AssumeRole` permission on the ARN of the `CrossAccountDynamoDBWriter` role in Account B.

Answer

In Account B, configure the trust policy of the role to allow the Lambda function's execution role in Account A to assume the role, and in Account A, attach an identity-based policy to the Lambda function's execution role that grants the `sts:AssumeRole` permission on the ARN of the role in Account B.

For cross-account access, a two-way permission handshake is required. The role in the trusting account (Account B) must have a trust policy allowing the trusted identity (Account A's Lambda execution role) to assume it. Concurrently, the trusted identity in Account A must have an identity-based policy allowing it to call `sts:AssumeRole` on the target role in Account B.

Step-by-Step Solution

Configure the trust relationship on the target role in Account B.

The `CrossAccountDynamoDBWriter` role in Account B trusts the Lambda function's execution role in Account A.

A role must explicitly declare which identities are trusted to assume it via its trust policy.

Grant permission to the Lambda execution role in Account A to perform the assume role action.

The Lambda execution role in Account A is authorized to perform `sts:AssumeRole` on the target role's ARN.

An IAM identity must be explicitly granted permission to perform the `sts:AssumeRole` API call on a target resource.

Key Concept

Cross-account IAM role access requires configuring both a trust policy on the resource role and an identity-based permission policy on the calling principal.

Estimated Time:2m 0s

Question 1413Question →

A fleet management system stores real-time diagnostics for $50,000$ delivery vehicles in an Amazon DynamoDB table. To minimize read latency and prevent database load, a developer deploys a DynamoDB Accelerator (DAX) cluster. The developer implements a background process that runs periodic Scan operations via the DAX client to pre-warm the cache. However, when the dashboard application performs GetItem calls to retrieve individual vehicle details, it continues to experience high read latency and triggers ProvisionedThroughputExceededException errors on the DynamoDB table. Which action should the developer take to resolve the performance bottleneck and utilize the DAX cache effectively?

Modify the background process to perform individual GetItem or BatchGetItem calls for the vehicle records instead of Scan operations, allowing DAX to populate its item cache.

Increase the table's provisioned Read Capacity Units (RCUs) to handle the dashboard traffic and run the background Scan operations during off-peak hours.

Change the table's partition key to a low-entropy attribute like vehicle status and increase the read capacity units to resolve the throttling errors.

Replace the DAX cluster with an Amazon ElastiCache for Redis cluster, and configure the application to run nightly Scan operations to load the vehicle diagnostics into the Redis cache.

Show answer & explanation

Answer: Modify the background process to perform individual GetItem or BatchGetItem calls for the vehicle records instead of Scan operations, allowing DAX to populate its item cache.

Answer

Modify the background process to perform individual GetItem or BatchGetItem calls for the vehicle records instead of Scan operations, allowing DAX to populate its item cache.

The correct answer is to modify the background process to perform individual GetItem or BatchGetItem calls. Amazon DynamoDB Accelerator (DAX) utilizes two separate caches: the item cache and the query cache. GetItem and BatchGetItem operations check and populate the item cache. Scan and Query operations check and populate the query cache. Because the background process was using Scan, it only populated the query cache. Subsequent GetItem requests from the dashboard resulted in item cache misses and went directly to DynamoDB, causing latency and throttling. Warming the item cache using GetItem or BatchGetItem resolves this issue.

Step-by-Step Solution

Analyze how DAX handles cache population for different API calls.

DAX maintains an item cache (populated by GetItem, BatchGetItem, etc.) and a query cache (populated by Query and Scan).

Understanding the difference between DAX's item cache and query cache is necessary to diagnose why GetItem calls are bypassing the cache.

Identify the cause of the cache misses and read throttling.

The background process uses Scan, which only populates the query cache. Subsequent GetItem calls search the item cache, result in cache misses, and hit the DynamoDB table directly.

This explains why the table is receiving ProvisionedThroughputExceededException errors despite the DAX cluster.

Apply the appropriate caching strategy to resolve the bottleneck.

Changing the background warming process to use GetItem or BatchGetItem calls ensures that the individual vehicle items are cached in the DAX item cache.

This allows subsequent GetItem calls from the dashboard to be served directly from the DAX item cache, eliminating database load and reducing latency.

Key Concept

DAX Caching Behavior (Item Cache vs. Query Cache)

Question 1414Question →

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

A document collaboration platform named DocuCollab tracks real-time document editing events and writes them to an Amazon DynamoDB table. The table is configured with provisioned write capacity and uses the DocumentId as the partition key. During peak hours, a small number of extremely popular shared documents experience heavy, concurrent editing activity. This results in ProvisionedThroughputExceededException errors and writes are dropped, even though the total consumed write capacity is well below the table's provisioned limit.

Which combination of actions will resolve this issue? (Select TWO.)

Select all that apply

Append a random numeric suffix to the partition key value before writing the items to distribute the write load.

Configure the application SDK client to implement exponential backoff with jitter for retrying failed requests.

Increase the provisioned Write Capacity Units (WCUs) on the DynamoDB table to distribute the capacity across all partition keys.

Increase the visibility timeout of the Amazon SQS queue that buffers the writes to allow the consumer more time to retry without message duplication.

Initialize the DynamoDB SDK client using static credentials with administrative privileges to bypass partition write limits.

Show answer & explanation

Answer: Append a random numeric suffix to the partition key value before writing the items to distribute the write load.; Configure the application SDK client to implement exponential backoff with jitter for retrying failed requests.

Answer

To resolve the throttling issues, the developer should append a random numeric suffix to the partition key value before writing the items, and configure the application SDK client to implement exponential backoff with jitter for retrying failed requests.

The correct actions are appending a random numeric suffix to the partition key (sharding) and configuring the SDK to use exponential backoff with jitter. Appending a random suffix distributes the concurrent writes for a single popular document across multiple physical partitions, which prevents exceeding the 1,000 WCU physical partition limit. Implementing exponential backoff with jitter ensures that when throttling does occur, the application retries the requests at progressively longer, randomized intervals, preventing retry storms and allowing the writes to succeed without being dropped.

Step-by-Step Solution

Analyze the DynamoDB ProvisionedThroughputExceededException and partition key design to identify if the workload is unevenly distributed.

Discovered that a few popular documents (hot partition keys) are exceeding the single physical partition throughput limit of 1,000 WCUs, even though the total table WCU consumption is low.

This step is necessary to pinpoint that the problem is a hot partition issue rather than a table-wide capacity limitation.

Redesign the partition key strategy by appending a random numeric suffix (e.g., a hash or random number from 1 to N) to the DocumentId before writing.

Writes for a single popular document are distributed across N different partition keys, spreading the throughput load across multiple physical partitions.

This step is required to scale the throughput of a single logical key beyond the 1,000 WCU physical partition limit.

Configure the application SDK client to implement exponential backoff with randomized jitter for request retries.

Throttled requests are retried with spacing in time, preventing collision patterns (retry storms) and allowing temporary spikes to resolve successfully.

This step is necessary to ensure that the application handles transient throttling gracefully without immediately dropping write requests.

Key Concept

Resolving DynamoDB throttling issues by redesigning partition keys (sharding) and configuring SDK retry policies with backoff and jitter.

Estimated Time:2m 0s

Question 1416Question →

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

An enterprise web application needs to allow employees to sign in using their corporate Identity Provider (IdP) via SAML 2.0. Once authenticated, the application must allow users to upload files directly to a user-specific folder in an Amazon S3 bucket. The architecture must minimize operational overhead and avoid storing long-term credentials on the client. Which solution meets these requirements with the least operational overhead?

Configure an Amazon Cognito User Pool integrated with the SAML IdP. Retrieve the ID token upon successful authentication and pass it directly to the Amazon S3 API headers to authorize direct client-side uploads.

Configure an Amazon API Gateway endpoint with a custom Lambda Authorizer that validates the SAML assertions, creates a Cognito User Pool user on the fly, and uses the API Gateway service integration to upload files directly to S3.

Configure an Amazon Cognito User Pool integrated with the SAML IdP, and associate it with an Amazon Cognito Identity Pool. Use the Identity Pool to map the federated users to an IAM role that grants access to the user-specific S3 folder using the cognito-identity.amazonaws.com:sub variable.

Configure an Amazon Cognito User Pool integrated with the SAML IdP. Set up an API Gateway endpoint backed by a Lambda function that contains hardcoded IAM access keys to upload files to the S3 bucket on behalf of the user.

Show answer & explanation

Answer: Configure an Amazon Cognito User Pool integrated with the SAML IdP, and associate it with an Amazon Cognito Identity Pool. Use the Identity Pool to map the federated users to an IAM role that grants access to the user-specific S3 folder using the cognito-identity.amazonaws.com:sub variable.

Answer

The correct solution leverages Amazon Cognito User Pools to manage authentication with the corporate SAML Identity Provider, and Amazon Cognito Identity Pools to exchange the authentication tokens for temporary AWS IAM credentials. The IAM policy attached to the authenticated role uses the cognito-identity.amazonaws.com:sub policy variable to dynamically restrict access to the user's specific folder in the S3 bucket, ensuring security with minimal operational overhead.

Step-by-Step Solution

Configure SAML federation with the corporate Identity Provider within an Amazon Cognito User Pool.

Users can authenticate against their corporate IdP and receive Cognito User Pool tokens.

This establishes user authentication without managing passwords locally or creating custom SAML validation logic.

Link the Cognito User Pool as an authentication provider in an Amazon Cognito Identity Pool.

The Identity Pool can verify the Cognito User Pool tokens and exchange them for temporary AWS credentials.

Cognito Identity Pools are designed to authorize users and provide temporary AWS IAM credentials.

Create an IAM role for authenticated users with a policy permitting S3 PutObject actions restricted to user-specific prefixes using the cognito-identity.amazonaws.com:sub variable, and associate it with the Identity Pool.

Authenticated users receive dynamic, scope-limited temporary credentials to upload directly to their own S3 folder.

This implements secure, direct client-to-S3 uploads with minimal latency, avoiding the need for an intermediary backend server or hardcoded credentials.

Key Concept

Amazon Cognito Identity Pools are used to federate identities and obtain temporary AWS credentials for accessing AWS resources like Amazon S3, whereas Cognito User Pools handle user directory management and authentication.

Estimated Time:2m 0s

Question 1418Question →

An e-commerce checkout application named CartCheckout records transaction logs in Amazon DynamoDB. The table uses CheckoutDate (formatted as YYYY-MM-DD) as the partition key and TransactionID as the sort key. During a flash sale event, the application experiences multiple ProvisionedThroughputExceededException errors when writing to the table, even though the total consumed Write Capacity Units (WCUs) are well below the table's total provisioned limits. Which action should the developer take to resolve the write throttling and optimize the table's write performance?

Redesign the partition key schema to use the high-entropy TransactionID as the partition key, or append a random suffix to the CheckoutDate, to distribute writes evenly across partitions.

Increase the overall provisioned Write Capacity Units (WCUs) of the DynamoDB table to handle the high volume of write traffic during the flash sale.

Place an Amazon SQS queue in front of the DynamoDB table and configure a longer queue visibility timeout to prevent write failures.

Configure the application SDK client initialization by hardcoding AWS IAM access keys with higher write privileges to prevent API rate limiting.

Show answer & explanation

Answer: Redesign the partition key schema to use the high-entropy TransactionID as the partition key, or append a random suffix to the CheckoutDate, to distribute writes evenly across partitions.

Answer

Redesign the partition key schema to use the high-entropy TransactionID as the partition key, or append a random suffix to the CheckoutDate, to distribute writes evenly across partitions.

The correct answer is correct because replacing the partition key with a high-entropy key (like TransactionID) or adding a random suffix to the date distributes the data and request load evenly across all available physical partitions. This avoids hot partition bottlenecks where a single partition key receives all writes.

Step-by-Step Solution

Analyze the error message and table configuration to determine the root cause of throttling.

The ProvisionedThroughputExceededException combined with low overall table throughput indicates a hot partition issue due to poor partition key distribution.

Since the partition key is CheckoutDate (YYYY-MM-DD), all transaction writes on the day of the flash sale target the same partition, exceeding the throughput limit of a single physical partition.

Evaluate remediation strategies to distribute the write load more evenly across partitions.

A high-entropy attribute like TransactionID should be selected as the partition key, or write sharding (appending a random suffix) should be implemented on the CheckoutDate.

This spreads writes across multiple partition keys and therefore multiple physical partitions, utilizing the table's provisioned capacity effectively.

Key Concept

Identifying and resolving hot partitions in Amazon DynamoDB by designing high-entropy partition keys or implementing write sharding.

Question 1419Question →

A smart home telemetry application stores real-time ambient device statuses in an Amazon DynamoDB table. Users retrieve the status of specific devices through a mobile app dashboard, which performs frequent key-value read requests by device ID. During peak usage hours, users experience high read latency, and the dashboard receives ProvisionedThroughputExceededException errors. CloudWatch metrics indicate that the table's total read capacity is not exceeded, but a small subset of highly active device IDs is causing hot partitions. The developer wants to deploy Amazon DynamoDB Accelerator (DAX) to resolve the latency and throttling issues. Which two actions must the developer take to achieve this objective?

Select all that apply

Deploy a DAX cluster and replace the standard DynamoDB client with the DAX client SDK in the application code.

Configure the read requests from the mobile application to use eventually consistent reads.

Modify the application code to perform Scan operations instead of GetItem operations to populate the cache.

Increase the provisioned Read Capacity Units (RCUs) on the DynamoDB table to absorb the spikes in read traffic.

Initialize the DAX client in the application code by hardcoding the AWS IAM access keys and secret keys.

Show answer & explanation

Answer: Deploy a DAX cluster and replace the standard DynamoDB client with the DAX client SDK in the application code.; Configure the read requests from the mobile application to use eventually consistent reads.

Answer

To resolve the throttling and latency issues using DAX, the developer must deploy the DAX cluster, use the DAX client SDK to point the application to the cache, and ensure read requests use eventually consistent reads so they can be cached.

To leverage DAX for sub-millisecond read latency and prevent hot partition throttling, the application must use the DAX client SDK to route reads through the cache. Additionally, the read operations must be configured as eventually consistent, because DAX does not cache strongly consistent reads in its Item Cache.

Step-by-Step Solution

Replace the standard DynamoDB client SDK with the DAX client SDK.

The application routes its API calls to the DAX cluster instead of directly to DynamoDB.

DAX requires a specialized client SDK that is API-compatible with DynamoDB to intercept and cache the requests.

Configure read requests to use eventually consistent reads.

DAX intercepts the GetItem and Query calls and saves the result in the Item Cache.

Strongly consistent reads bypass the DAX cache and hit the database directly, which would not resolve the hot partition throttling.

Key Concept

Integrating DAX requires utilizing the DAX client SDK and configuring reads to be eventually consistent to leverage the DAX Item Cache.

Question 1420Question →

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.

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

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

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Answer

Step-by-Step Solution