All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

A developer is configuring a deployment to shift traffic to a new version of an AWS Lambda function using AWS CodeDeploy. The deployment group is configured with an IAM service role. When the deployment is initiated, the developer encounters an error during the initial validation of the AppSpec file, and the deployment is aborted. The AppSpec file is configured as follows:

yaml
version: 0.0
Resources:
- MyLambdaFunction:
Type: AWS::Lambda::Function
Properties:
Name: "MyServiceFunction"
Alias: "live"
CurrentVersion: "1"
TargetVersion: "2"
Hooks:
- BeforeInstall: "ValidationFunction"

What is the reason for this deployment failure?

The AppSpec file specifies 'BeforeInstall' under the 'Hooks' section, which is a lifecycle hook reserved for EC2/on-premises and ECS deployments and is invalid for AWS Lambda deployments.

The service role configured for the CodeDeploy deployment group has a trust policy that allows the assume role action for the Lambda service instead of the CodeDeploy service.

The validation Lambda function's IAM execution role contains a trust policy that trusts the CodeDeploy service instead of the Lambda service.

The validation function attempts to retrieve configurations from Systems Manager Parameter Store using a standard parameter instead of Secrets Manager, violating CodeDeploy's encryption policies.

Show answer & explanation

Answer: The AppSpec file specifies 'BeforeInstall' under the 'Hooks' section, which is a lifecycle hook reserved for EC2/on-premises and ECS deployments and is invalid for AWS Lambda deployments.

Answer

The AppSpec file specifies 'BeforeInstall' under the 'Hooks' section, which is a lifecycle hook reserved for EC2/on-premises and ECS deployments and is invalid for AWS Lambda deployments.

The correct option is correct because AWS CodeDeploy deployments for the Lambda compute platform only support the 'BeforeAllowTraffic' and 'AfterAllowTraffic' lifecycle hooks. Hook names such as 'BeforeInstall', 'AfterInstall', and 'AfterAllowTestTraffic' are invalid for Lambda deployments (though they are valid for ECS or EC2/on-premises deployments). Specifying an invalid hook causes the AppSpec validation to fail before the deployment can proceed.

Step-by-Step Solution

Inspect the resources and hooks sections of the AppSpec file.

Identify that the resource type is 'AWS::Lambda::Function' and the hook is 'BeforeInstall'.

AWS CodeDeploy supports different hooks depending on the target compute platform.

Recall the valid lifecycle hooks for AWS Lambda deployments in AWS CodeDeploy.

Lambda deployments only support 'BeforeAllowTraffic' and 'AfterAllowTraffic'.

Other hooks like 'BeforeInstall' are only applicable to EC2/on-premises or ECS platforms.

Identify why the validation failed based on the hook mismatch.

The presence of 'BeforeInstall' causes the AppSpec validation to fail immediately.

CodeDeploy rejects AppSpec files containing invalid hooks for the specified resource type.

Key Concept

AWS CodeDeploy AppSpec lifecycle hooks for AWS Lambda deployments

Question 1102Question →

A developer has a Java-based microservice running on Amazon ECS on AWS Fargate. The microservice reads messages from an Amazon SQS queue, processes them, and writes results to an Amazon DynamoDB table. The developer needs to instrument the application with AWS X-Ray to trace the processing from the SQS queue to the DynamoDB calls. The X-Ray daemon is deployed as a sidecar container in the same task definition. Which two actions should the developer take to configure AWS X-Ray tracing and resolve the missing downstream segments?

Select all that apply

Add the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Role used by the ECS container.

Configure the AWS SDK for Java client with the TracingInterceptor to intercept and trace calls to DynamoDB.

Add the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Execution Role.

Rely on the Amazon SQS queue to automatically propagate the trace context to DynamoDB without instrumenting the AWS SDK client inside the Java application.

Initialize the DynamoDB client inside the application code by hardcoding temporary IAM user access keys that have X-Ray write permissions.

Show answer & explanation

Answer: Add the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Role used by the ECS container.; Configure the AWS SDK for Java client with the TracingInterceptor to intercept and trace calls to DynamoDB.

Answer

To configure AWS X-Ray tracing for this application, the developer must attach the AWSXRayDaemonWriteAccess policy to the IAM ECS Task Role used by the ECS container, and configure the AWS SDK for Java client with the TracingInterceptor to intercept and trace calls to DynamoDB.

To trace downstream requests to DynamoDB, the developer must instrument the AWS SDK client inside the Java microservice using the AWS X-Ray SDK (for example, by adding TracingInterceptor). In addition, since the X-Ray daemon runs in a sidecar container, it needs permissions to upload segment data to the AWS X-Ray service. These permissions must be attached to the ECS Task Role.

Step-by-Step Solution

Configure permissions for the X-Ray daemon container to upload traces.

The AWSXRayDaemonWriteAccess policy is attached to the ECS Task Role, allowing the sidecar daemon to communicate with the AWS X-Ray service.

The running container requires runtime permissions to write trace segments.

Instrument the application's AWS SDK clients.

The AWS SDK for Java client is configured with TracingInterceptor.

This allows the application to capture calls to downstream services such as DynamoDB as subsegments in the trace context.

Key Concept

Instrumenting microservices running on ECS with AWS X-Ray requires both configuring the container's IAM Task Role for write permissions and instrumenting the application's SDK client to record downstream calls.

Question 1103Question →

A developer is building a high-throughput microservice that must encrypt data payloads (each approximately $2\text{ MB}$ in size) locally before storing them in an database. To implement envelope encryption efficiently and minimize network latency, the service needs to obtain a new symmetric key that contains both a plaintext version for immediate encryption and an encrypted version for storage alongside the data. Which AWS KMS API operation should the service call to receive both versions in a single request?

GenerateDataKey

GenerateDataKeyWithoutPlaintext

Encrypt

GenerateRandom

Show answer & explanation

Answer: GenerateDataKey

Answer

GenerateDataKey

The GenerateDataKey operation is designed for envelope encryption. It generates a unique data key and returns both a plaintext copy and an encrypted copy in a single response, matching the requirement to minimize network latency.

Step-by-Step Solution

Analyze the requirement to perform local envelope encryption on payloads of size

2\text{ MB}

while minimizing network calls.

Determine that the application needs both a plaintext key to encrypt the payload locally and an encrypted version of that key to store with the data.

Since KMS cannot directly encrypt payloads larger than

4\text{ KB}

, envelope encryption is required.

Evaluate the AWS KMS APIs for generating data keys.

Identify that GenerateDataKey returns both plaintext and ciphertext key representations, whereas GenerateDataKeyWithoutPlaintext returns only the ciphertext representation.

Choosing the correct API prevents unnecessary network roundtrips to decrypt the key.

Key Concept

AWS KMS Envelope Encryption Key Generation

Question 1104Question →

A developer is building a fitness tracking web application that retrieves user statistics by calling a REST API. The API is hosted on Amazon API Gateway and uses a Lambda Proxy integration. During testing, the web browser console displays a CORS error indicating that the 'Access-Control-Allow-Origin' header is missing. The developer has already enabled CORS on the API Gateway resources using the AWS Management Console, but the error remains. Which of the following is the correct action to resolve this issue?

Modify the backend Lambda function to return the Access-Control-Allow-Origin header in its response JSON.

Configure a CORS policy on the Amazon S3 bucket hosting the web application to allow requests from the API Gateway URL.

Add the Access-Control-Allow-Origin header to the API Gateway Method Response configuration and redeploy the API.

Create an IAM role that allows the API Gateway execution role to trust the Amazon S3 bucket hosting the application.

Show answer & explanation

Answer: Modify the backend Lambda function to return the Access-Control-Allow-Origin header in its response JSON.

Answer

Modify the backend Lambda function to return the Access-Control-Allow-Origin header in its response JSON.

Under a Lambda Proxy integration, Amazon API Gateway passes the backend response directly to the client without modifying the headers. Therefore, enabling CORS on the API Gateway resource only sets up the preflight OPTIONS endpoint. The developer must update the Lambda function code to return the Access-Control-Allow-Origin header in the headers key of the response JSON payload.

Step-by-Step Solution

Determine the integration type of the API Gateway resource.

The resource is configured with Lambda Proxy integration.

Integration type dictates how requests and responses are mapped between API Gateway and the backend.

Understand how headers are managed in Lambda Proxy integration.

API Gateway does not modify or inject response headers for proxy integrations.

The backend Lambda function has full control over the response structure, including HTTP headers.

Add the required CORS header to the Lambda function's response payload.

The Lambda function returns a JSON response containing 'Access-Control-Allow-Origin' under the 'headers' key.

This satisfies the browser's origin-check validation for the client request.

Key Concept

CORS handling in API Gateway Lambda Proxy integrations

Estimated Time:1m 0s

Question 1105Question →

A developer is designing a web application deployed on Amazon ECS. The application requires an external session state store to manage user shopping carts. The session data must be retrieved with sub-millisecond response times, support nested JSON structures, and remain highly available even in the event of an infrastructure failure. Which architecture should the developer implement to meet these requirements?

Store the session data in an Amazon DynamoDB table and retrieve the shopping cart items using Scan operations with a filter expression on the user session ID.

Save the shopping cart details as configuration parameters in AWS Systems Manager Parameter Store, updating them using the parameter history.

Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ replication enabled to store the session data.

Store the session data in an Amazon DynamoDB table with a partition key based on the user's country code, and use DynamoDB Accelerator (DAX) to cache all updates.

Show answer & explanation

Answer: Deploy an Amazon ElastiCache for Redis cluster with Multi-AZ replication enabled to store the session data.

Answer

Deploying an Amazon ElastiCache for Redis cluster with Multi-AZ replication enabled to store the session data.

Deploying an Amazon ElastiCache for Redis cluster with Multi-AZ replication meets all requirements. Redis is an in-memory data store that achieves sub-millisecond latencies and natively supports complex data types (such as hashes, lists, and sets) which are ideal for nested JSON shopping cart data. Enabling Multi-AZ replication ensures automatic failover and high availability if the primary node encounters issues.

Step-by-Step Solution

Analyze the requirements for the session store: sub-millisecond retrieval latency, support for nested JSON structures, high availability during failures, and dynamic scaling.

The requirements point to an in-memory caching or NoSQL database solution that supports replication, failover, and complex data formats.

Establishing the functional and non-functional requirements filters out unsuitable AWS services.

Evaluate Amazon ElastiCache for Redis against the requirements.

ElastiCache for Redis provides sub-millisecond response times, supports complex data structures (like hashes and lists for nested JSON), and offers Multi-AZ replication for auto-failover.

Redis is designed specifically for fast in-memory key-value caching with persistence and high availability.

Compare against alternatives such as DynamoDB with DAX, SSM Parameter Store, and DynamoDB with Scan operations.

DynamoDB Scan operations are too slow and expensive. Systems Manager Parameter Store is not designed for fast transactional session states. Using a low-entropy partition key (like country code) in DynamoDB will create hot partition issues that DAX cannot resolve on writes.

Ruling out distractors validates that the chosen solution is the most architecturally sound option.

Key Concept

Selecting the appropriate in-memory caching engine (ElastiCache for Redis vs Memcached) and avoiding database bottlenecks for session state storage.

Estimated Time:1m 30s

Question 1106Question →

A developer is containerizing a Java application that uses the AWS SDK for Java v2 to read objects from an Amazon S3 bucket. Access to the bucket requires assuming an IAM role. The developer has configured the local development host's `~/.aws/config` file with a profile named `dev-role` that specifies a `role_arn` and a `source_profile`. Running the AWS CLI command `aws s3 ls --profile dev-role` on the host machine successfully lists the bucket contents. However, when the Java application is run inside a local Docker container using the environment variable `AWS_PROFILE=dev-role`, the application fails with a `SdkClientException` indicating that credentials cannot be loaded.

Which two actions should the developer take to resolve this issue? (Choose two.)

Select all that apply

Mount the host's `~/.aws` directory to the home directory of the user running the application inside the container.

Add the `software.amazon.awssdk:sts` dependency to the application's build file (e.g., `pom.xml`).

Hardcode the AWS Access Key ID and Secret Access Key associated with the target IAM role in the S3 client initialization code.

Modify the IAM trust policy of the target IAM role to trust the private IP address of the local Docker container.

Configure the application to bootstrap credentials from AWS Systems Manager Parameter Store by configuring a custom credential provider.

Show answer & explanation

Answer: Mount the host's `~/.aws` directory to the home directory of the user running the application inside the container.; Add the `software.amazon.awssdk:sts` dependency to the application's build file (e.g., `pom.xml`).

Answer

Mount the host's `~/.aws` directory to the container user's home directory and add the `software.amazon.awssdk:sts` dependency to the application's build file.

The containerized application needs access to the host's AWS credentials configuration, which can be achieved by mounting the host's `~/.aws` directory to the container. Additionally, the AWS SDK for Java v2 requires the `software.amazon.awssdk:sts` dependency to assume the IAM role defined in the profile configuration. Together, these two steps satisfy the credentials requirement without violating security best practices.

Step-by-Step Solution

Diagnose container isolation.

Identify that the local container has an independent filesystem and cannot read the host's `~/.aws/config` or `~/.aws/credentials` files.

Resolving the profile depends on accessing these configuration files from within the container's execution context.

Mount the credentials directory.

Map the host's `~/.aws` directory to the container user's home directory.

This allows the default credentials provider chain inside the container to read the configuration profiles.

Check SDK classpath dependencies.

Identify that the Java SDK v2 requires the STS module to perform the `AssumeRole` call specified in the profile.

Without the STS library, the SDK fails to instantiate the provider needed to assume the role defined by `role_arn`.

Key Concept

AWS SDK credentials resolution, credential file mounting in Docker, and the STS dependency requirement in the AWS SDK for Java v2.

Estimated Time:2m 0s

Question 1107Question →

An IoT telemetry ingestion application uses an AWS Lambda function to process device log files uploaded to an Amazon S3 bucket. The function parses the logs and sends alerts to an external monitoring API on the public internet. To securely query an Amazon ElastiCache Redis cluster, the Lambda function is configured to run inside private subnets of a VPC. The developer notices that the function successfully queries Redis but fails to send alerts to the external monitoring API, resulting in connection timeouts. Furthermore, under peak load, some executions are terminated prematurely before completion.

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

Select all that apply

Configure a NAT gateway in a public subnet of the VPC, and update the route table of the Lambda function's private subnets to route 0.0.0.0/0 to the NAT gateway.

Increase the function's execution timeout setting in the AWS Lambda configuration.

Enable the public IP assignment setting in the VPC configuration of the Lambda function.

Attach an Internet Gateway directly to the private subnets and update their route tables to direct 0.0.0.0/0 traffic to it.

Move the Redis connection initialization inside the Lambda handler function to prevent the execution context from reusing stale connections that cause timeouts.

Show answer & explanation

Answer: Configure a NAT gateway in a public subnet of the VPC, and update the route table of the Lambda function's private subnets to route 0.0.0.0/0 to the NAT gateway.; Increase the function's execution timeout setting in the AWS Lambda configuration.

Answer

The developer should configure a NAT gateway in a public subnet with a route in the private subnets' route table, and increase the execution timeout in the Lambda function's configuration.

To resolve the network connectivity issue, a NAT gateway must be set up in a public subnet, and the route table for the private subnets (where the Lambda function runs) must route outbound traffic (0.0.0.0/0) to the NAT gateway. To resolve the premature termination issue under peak load, the Lambda function's timeout configuration must be increased to allow enough time for processing larger logs.

Step-by-Step Solution

Diagnose the connection timeouts to the external API.

Identify that the Lambda function is in private subnets and lacks internet access because it does not have a route to a NAT gateway.

Lambda functions in a VPC require a NAT gateway or NAT instance to route traffic to the public internet.

Configure outbound internet access for the VPC private subnets.

Provision a NAT gateway in a public subnet and update the private subnets' route tables to send all 0.0.0.0/0 traffic to the NAT gateway.

This allows the Lambda function in the private subnets to send requests to the external monitoring API while retaining internal access to the ElastiCache cluster.

Diagnose the premature termination of Lambda executions under peak load.

Recognize that the execution time is exceeding the configured Lambda timeout limit.

Heavier payloads or peak traffic require longer processing times, so the Lambda execution timeout configuration must be increased.

Key Concept

Configuring VPC networking for Lambda internet access and managing Lambda execution timeouts

Question 1108Question →

A developer is preparing to deploy a containerized backend application to Amazon ECS using the AWS Fargate launch type. The application must process incoming requests and write transaction records directly to an Amazon DynamoDB table. The container image is stored in a private Amazon Elastic Container Registry (Amazon ECR) repository. Additionally, the task definition is configured to use the awslogs log driver to stream container logs to Amazon CloudWatch Logs. Which configuration steps must the developer perform to ensure that the task has the minimum required permissions to initialize and run successfully? (Select TWO.)

Select all that apply

Configure an IAM role (Task Role) that grants permissions for dynamodb:PutItem and dynamodb:UpdateItem, specify ecs-tasks.amazonaws.com as the trusted entity in its trust policy, and assign it to the taskRoleArn parameter in the task definition.

Configure an IAM role (Task Execution Role) that grants permissions for ecr:BatchGetImage, ecr:GetDownloadUrlForLayer, logs:CreateLogStream, and logs:PutLogEvents, specify ecs-tasks.amazonaws.com as the trusted entity in its trust policy, and assign it to the executionRoleArn parameter in the task definition.

Configure an IAM role with permissions for dynamodb:PutItem and assign it to the executionRoleArn parameter in the task definition.

Configure an IAM role with permissions for ecr:BatchGetImage and logs:CreateLogStream and assign it to the taskRoleArn parameter in the task definition.

Modify the trust policy of both the Task Role and Task Execution Role to allow the Amazon EC2 service principal (ec2.amazonaws.com) to assume the roles.

Show answer & explanation

Answer: Configure an IAM role (Task Role) that grants permissions for dynamodb:PutItem and dynamodb:UpdateItem, specify ecs-tasks.amazonaws.com as the trusted entity in its trust policy, and assign it to the taskRoleArn parameter in the task definition.; Configure an IAM role (Task Execution Role) that grants permissions for ecr:BatchGetImage, ecr:GetDownloadUrlForLayer, logs:CreateLogStream, and logs:PutLogEvents, specify ecs-tasks.amazonaws.com as the trusted entity in its trust policy, and assign it to the executionRoleArn parameter in the task definition.

Answer

The developer must configure a Task Role with DynamoDB permissions and assign it to taskRoleArn, and configure a Task Execution Role with ECR and CloudWatch Logs permissions and assign it to executionRoleArn.

The correct options properly separate application-level permissions (assigned to the Task Role via taskRoleArn) from infrastructure/agent-level permissions (assigned to the Task Execution Role via executionRoleArn). Under the Fargate launch type, both roles must trust the ecs-tasks.amazonaws.com service principal.

Step-by-Step Solution

Determine application code requirements.

The application code running inside the container needs to write to Amazon DynamoDB, requiring dynamodb:PutItem and dynamodb:UpdateItem permissions.

Application-level permissions must be defined in the Task Role (taskRoleArn).

Determine container orchestration requirements.

The ECS container agent needs to pull the image from a private Amazon ECR repository and send logs to CloudWatch Logs, requiring ECR pull permissions and CloudWatch logs permission.

Agent-level and launch-level permissions must be defined in the Task Execution Role (executionRoleArn).

Verify trust policy for ECS Fargate.

Both IAM roles must trust the ecs-tasks.amazonaws.com service principal.

AWS Fargate is a serverless execution environment where tasks are managed directly by ECS, meaning the roles must trust the ECS tasks principal rather than the EC2 instance principal.

Key Concept

ECS Task Role vs Task Execution Role

Question 1109Question →

A developer is troubleshooting a local C# application that uses the AWS SDK for .NET to publish messages to an Amazon SNS topic. During local testing, the application publishes messages to the production AWS account instead of the development AWS account.

The developer has set the AWS_PROFILE environment variable to development-profile in the active terminal session. The local ~/.aws/credentials file is configured as follows:

ini
[default]
aws_access_key_id = AKIA_PROD_KEY
aws_secret_access_key = PROD_SECRET

[development-profile]
aws_access_key_id = AKIA_DEV_KEY
aws_secret_access_key = DEV_SECRET

Upon investigation, the developer discovers that the environment variables AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are also set to the production keys within the same terminal session.

Why is the application using the production credentials, and how should the developer resolve this issue?

The AWS SDK loads credentials from the global configuration file before evaluating environment variables. To resolve this, the developer must modify the ~/.aws/config file to set profile_precedence = development-profile.

The AWS SDK default credential provider chain evaluates environment variables before looking up profiles in the shared credentials file. To resolve this, the developer must unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal session.

The AWS SDK cannot parse the credentials file because the local developer's IAM user lacks a trust policy mapping. To resolve this, the developer must update the development IAM trust policy to allow the local machine to assume the role.

The AWS SDK retrieves the production credentials from AWS Systems Manager Parameter Store, which overrides local configuration settings. To resolve this, the developer must delete the production credentials parameters from the Parameter Store.

Show answer & explanation

Answer: The AWS SDK default credential provider chain evaluates environment variables before looking up profiles in the shared credentials file. To resolve this, the developer must unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal session.

Answer

The AWS SDK default credential provider chain evaluates environment variables before looking up profiles in the shared credentials file. To resolve the issue, the developer must unset the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables in the terminal session.

The default credential provider chain in the AWS SDK resolves credentials in a specific order of precedence. Environment variables (such as AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY) are checked first. If they are present, the SDK uses them and stops looking. Shared credentials profiles (configured via AWS_PROFILE and ~/.aws/credentials) are evaluated later in the chain. Therefore, because the production keys were set in the environment variables, they took precedence over the AWS_PROFILE environment variable. Unsetting AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY from the environment allows the SDK to fall back to the credentials file and correctly use the profile specified by AWS_PROFILE.

Step-by-Step Solution

Analyze the active terminal environment variables and identify configured AWS credentials.

Discovered that the terminal has AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY set to production keys, alongside AWS_PROFILE set to the development profile.

The AWS SDK relies on the default credential provider chain, which checks environment variables first.

Evaluate the order of precedence in the AWS SDK default credential provider chain.

Identified that environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) take precedence over the shared credentials file and the AWS_PROFILE setting.

Since environment variables are found first, the SDK uses them directly and ignores the AWS_PROFILE setting.

Unset the production credential environment variables in the terminal.

Executing 'unset AWS_ACCESS_KEY_ID' and 'unset AWS_SECRET_ACCESS_KEY' removes the environment-level overrides.

Removing these variables forces the AWS SDK to fall back to the next level in the provider chain, which is the shared credentials file, allowing it to correctly load the profile specified by AWS_PROFILE.

Key Concept

AWS SDK Default Credential Provider Chain Order of Precedence

Question 1110Question →

A developer is troubleshooting a serverless application where an AWS Lambda function is triggered by an Amazon SQS queue. The Lambda function processes incoming messages, invokes a downstream third-party REST API using the Python `requests` library, and records metrics. During testing under high load, the developer notices two main issues:

1. Downstream third-party REST API calls do not appear as subsegments in the AWS X-Ray service map.
2. Many messages are being processed multiple times by the Lambda function, resulting in duplicate API calls and redundant traces.

Which two actions must the developer take to resolve these issues?

Select all that apply

Use the AWS X-Ray SDK for Python to patch the requests library at the start of the Lambda function code.

Increase the visibility timeout of the SQS queue to be at least

6

times the execution timeout of the Lambda function.

Reconfigure the Lambda integration in Amazon API Gateway from proxy integration to custom integration and manually map the HTTP headers in the integration request template.

Hardcode temporary AWS IAM credentials retrieved from AWS STS inside the Lambda function initialization code to authorize the X-Ray recorder client.

Increase the Lambda function's execution timeout to match the SQS queue's message retention period to prevent trace context loss during execution context reuse.

Show answer & explanation

Answer: Use the AWS X-Ray SDK for Python to patch the requests library at the start of the Lambda function code.; Increase the visibility timeout of the SQS queue to be at least $6$ times the execution timeout of the Lambda function.

Answer

To resolve these issues, the developer must patch the requests library using the AWS X-Ray SDK for Python and increase the SQS queue's visibility timeout to be at least

6

times the Lambda function's execution timeout.

To trace downstream HTTP calls made via the Python requests library, the developer must patch the library using the AWS X-Ray SDK for Python. This dynamically instruments HTTP client libraries to generate tracing subsegments for outgoing HTTP requests. Additionally, under high load, if the SQS queue's visibility timeout is too close to the Lambda function's execution timeout, messages may return to the queue and be processed by other concurrent invocations before the original execution finishes. Setting the SQS visibility timeout to at least

6

times the Lambda execution timeout prevents these duplicate invocations and the resulting redundant traces.

Step-by-Step Solution

Analyze downstream HTTP tracing requirement.

Identify that third-party HTTP libraries like Python requests are not automatically instrumented by X-Ray unless they are patched using the AWS X-Ray SDK.

Patching ensures that the HTTP client library intercepts outgoing calls and generates the appropriate subsegments in the trace.

Diagnose duplicate message processing under load.

Recognize that messages processed multiple times usually indicate that the SQS visibility timeout is shorter than the time Lambda takes to process and delete the message.

If the visibility timeout is too short, other Lambda invocations poll the same message before the original execution finishes, leading to duplicate executions.

Determine the correct configuration adjustments.

Patch the requests library using the SDK, and set the SQS queue's visibility timeout to at least

6

times the Lambda timeout.

This implements the recommended AWS best practice for SQS-Lambda integrations to prevent duplicate processing, and successfully captures downstream API tracing details.

Key Concept

Instrumenting HTTP libraries with AWS X-Ray SDK and configuring SQS visibility timeouts for Lambda integration.

Estimated Time:2m 30s

Question 1111Question →

A developer is building a single-page web application (SPA) that will allow users to authenticate using Amazon Cognito User Pools and access backend services through Amazon API Gateway. Since the SPA runs entirely in the user's browser, the client credentials cannot be kept secure. The developer wants to implement a secure authentication flow using the authorization code grant with Proof Key for Code Exchange (PKCE) and validate access at the API Gateway layer. Which TWO steps should the developer take to implement this architecture?

Select all that apply

Configure the Amazon Cognito User Pool app client with client secret generation disabled, and enable the Authorization Code Grant OAuth flow.

Configure the Amazon Cognito User Pool app client with client secret generation enabled, and retrieve the secret at runtime using AWS Secrets Manager inside the browser.

Create an Amazon API Gateway Cognito User Pool authorizer to validate the signature and expiration of the identity or access tokens passed in the Request header.

Create an API Gateway custom Lambda Authorizer that performs an HTTPS POST request to the Cognito token endpoint to validate the token on every incoming request.

Configure an Amazon Cognito Identity Pool to exchange the authorization code directly for temporary AWS credentials, and configure IAM authorization on API Gateway.

Show answer & explanation

Answer: Configure the Amazon Cognito User Pool app client with client secret generation disabled, and enable the Authorization Code Grant OAuth flow.; Create an Amazon API Gateway Cognito User Pool authorizer to validate the signature and expiration of the identity or access tokens passed in the Request header.

Answer

The correct steps are to configure the user pool app client without a client secret while enabling the authorization code grant flow, and to create an API Gateway Cognito User Pool authorizer to validate incoming tokens.

The correct options state that the Cognito User Pool app client must be configured with client secret generation disabled while enabling the authorization code grant flow, and that a built-in API Gateway Cognito User Pool authorizer should be created to validate the tokens. For public clients like single-page applications running in the browser, exposing a client secret is a security risk. Therefore, client secret generation is disabled, and PKCE is utilized to secure the authorization code grant. API Gateway's native Cognito authorizer can automatically validate the JWT signature, issuer, and expiration locally using public keys from the User Pool's JSON Web Key Set (JWKS), minimizing overhead.

Step-by-Step Solution

Disable client secret generation for the app client.

The client application (SPA) can safely initiate the authentication flow without needing to store or protect a secret.

Single-page applications run entirely in the browser, making it impossible to protect client secrets. Using the authorization code grant with PKCE mitigates the need for a client secret.

Enable the Authorization Code Grant flow in the Cognito app client settings.

Cognito is configured to exchange authorization codes for access and identity tokens securely.

This OAuth grant type, combined with PKCE, is the industry standard for securing public web applications.

Configure an Amazon API Gateway Cognito User Pool authorizer.

API Gateway automatically intercepts requests, validates the signature and expiration of the JWTs, and permits or denies access.

This native integration validates JSON Web Tokens (JWTs) locally using Cognito's public key set, removing the need for a custom Lambda authorizer and reducing latency.

Key Concept

Securing public clients and verifying tokens using Amazon Cognito User Pools and API Gateway native authorizers.

Question 1112Question →

A developer is implementing a mobile application that uses an Amazon Cognito identity pool to grant users temporary AWS credentials for uploading files to an Amazon S3 bucket. The developer has created an IAM role for authenticated users, but when the mobile application attempts to exchange the Cognito identity token for temporary credentials, the request fails with an access denied error. The developer reviews the trust policy currently attached to the IAM role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "cognito-identity.amazonaws.com"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"cognito-identity.amazonaws.com:aud": "us-east-1:12345678-1234-1234-1234-1234567890ab"
},
"ForAnyValue:StringLike": {
"cognito-identity.amazonaws.com:amr": "authenticated"
}
}
}
]
}

Which modification to the trust policy will resolve this issue?

Change the Action to sts:AssumeRoleWithWebIdentity, but leave the Principal as a Service principal.

Change the Principal key to Federated with the value set to cognito-identity.amazonaws.com, but leave the Action as sts:AssumeRole.

Change the Principal key to Federated and set its value to cognito-identity.amazonaws.com, and change the Action to sts:AssumeRoleWithWebIdentity.

Remove the trust policy from the role and configure the mobile application SDK with the hardcoded Access Key ID and Secret Access Key of a dedicated IAM user.

Show answer & explanation

Answer: Change the Principal key to Federated and set its value to cognito-identity.amazonaws.com, and change the Action to sts:AssumeRoleWithWebIdentity.

Answer

Change the Principal key to Federated and set its value to cognito-identity.amazonaws.com, and change the Action to sts:AssumeRoleWithWebIdentity.

The correct option correctly adjusts both the Principal to Federated and the Action to sts:AssumeRoleWithWebIdentity. Amazon Cognito Identity Pools act as a web identity federation provider. Therefore, any IAM role intended for authentication via Cognito must allow the federated identity 'cognito-identity.amazonaws.com' as the Principal, and it must permit the 'sts:AssumeRoleWithWebIdentity' API action to facilitate exchanging the Cognito token for temporary AWS credentials.

Step-by-Step Solution

Identify the authentication source in the scenario.

Amazon Cognito Identity Pools acts as an external federated OpenID Connect (OIDC) provider, not a native internal AWS service.

Understanding the source dictates which Principal type and STS action are required in the trust policy.

Correct the Principal definition in the trust policy.

Change 'Service' to 'Federated' with the value 'cognito-identity.amazonaws.com'.

Federated identity providers require the Federated key rather than the Service key in IAM trust policy statements.

Correct the permitted Action in the trust policy.

Change the Action from 'sts:AssumeRole' to 'sts:AssumeRoleWithWebIdentity'.

Exchanging OIDC or web identity federation tokens for temporary AWS credentials requires authorization for the AssumeRoleWithWebIdentity API call.

Key Concept

IAM Trust Policies for Web Identity Federation

Question 1113Question →

A developer has enabled active tracing on an AWS Lambda function that uses the AWS SDK for Python (boto3) to write data to an Amazon DynamoDB table. Although the Lambda function's execution is traced, the downstream calls to DynamoDB are missing from the AWS X-Ray service map. Which action must the developer take to include the DynamoDB calls in the X-Ray trace?

Instrument the AWS SDK by using the patch_all or patch function from the X-Ray SDK in the Lambda function code.

Increase the Lambda function's timeout configuration to allow the service execution context to persist longer.

Configure the API Gateway integration type to use Lambda Custom integration to pass raw request payloads.

Increase the Amazon SQS visibility timeout to prevent messages from returning to the queue during tracing.

Show answer & explanation

Answer: Instrument the AWS SDK by using the patch_all or patch function from the X-Ray SDK in the Lambda function code.

Answer

Instrument the AWS SDK by using the patch_all or patch function from the X-Ray SDK in the Lambda function code.

The correct answer is to instrument the AWS SDK by using the patch_all or patch function from the X-Ray SDK in the Lambda function code. While enabling active tracing on the Lambda function configuration creates the parent trace segment, the AWS SDK client inside the code must be instrumented using the X-Ray SDK so that outgoing API calls to services like DynamoDB are recorded as subsegments.

Step-by-Step Solution

Analyze the tracing configuration.

Active tracing is enabled on the Lambda function, which creates the main segment, but downstream AWS SDK calls are not being intercepted.

By default, enabling active tracing on Lambda only traces the function's entry, initialization, and execution. Outgoing calls via the AWS SDK require explicit library instrumentation.

Identify the mechanism for SDK instrumentation.

The AWS SDK client needs to be wrapped or patched by the AWS X-Ray SDK.

Instrumenting the SDK allows the X-Ray library to automatically capture subsegments for downstream AWS API requests (like DynamoDB) and link them to the parent segment.

Select the correct SDK function.

In Python, the developer should use the patch or patch_all function from the X-Ray SDK.

Calling patch_all() dynamically patches supported libraries, including boto3, ensuring all outgoing calls to DynamoDB are traced.

Key Concept

AWS X-Ray SDK Instrumentation

Estimated Time:45s

Question 1114Question →

A client-side web application hosted on `https://portal.example.com` attempts to send a `DELETE` request to a resource on a REST API hosted on Amazon API Gateway. The API utilizes a Lambda Proxy Integration. The browser console displays an error stating that the request has been blocked by CORS policy because no 'Access-Control-Allow-Origin' header is present on the requested resource.

Which TWO actions must the developer take to resolve this issue?

Select all that apply

Enable CORS on the resource in the Amazon API Gateway console to configure the OPTIONS method.

Update the backend Lambda function response to include the Access-Control-Allow-Origin header.

Configure a CORS configuration rule on the Amazon S3 bucket hosting the web application to allow requests from the API Gateway domain.

Configure the API Gateway integration to return a raw text response rather than a structured JSON payload.

Create an API Gateway custom Lambda Authorizer that intercepts the preflight request and returns a policy allowing the origin.

Show answer & explanation

Answer: Enable CORS on the resource in the Amazon API Gateway console to configure the OPTIONS method.; Update the backend Lambda function response to include the Access-Control-Allow-Origin header.

Answer

Enable CORS on the resource in the Amazon API Gateway console to configure the OPTIONS method, and update the backend Lambda function response to include the Access-Control-Allow-Origin header.

Resolving a CORS issue for a DELETE request requires two configuration steps. First, configuring the OPTIONS preflight method in API Gateway ensures that preflight CORS verification passes. Second, because Lambda Proxy Integration is utilized, the Lambda function itself must return the Access-Control-Allow-Origin header in its response envelope.

Step-by-Step Solution

Configure the preflight response in API Gateway.

The OPTIONS method is enabled for the resource, returning the CORS headers needed to pass the initial preflight check.

Before sending a DELETE request, the browser performs a preflight OPTIONS check to verify if the destination server allows cross-origin requests.

Inject CORS headers in the Lambda proxy response.

The Lambda function returns a JSON response containing 'headers': {'Access-Control-Allow-Origin': 'https://portal.example.com'}.

Under Lambda Proxy Integration, API Gateway does not alter the backend response to add CORS headers, so the Lambda function must return them explicitly.

Key Concept

Handling CORS with Lambda Proxy Integrations requires configuring both the preflight OPTIONS method in API Gateway and the custom response headers inside the backend Lambda code.

Estimated Time:1m 30s

Question 1115Question →

A developer is creating an IAM role that will be used by an AWS Lambda function to access other AWS resources. The developer needs to ensure that the AWS Lambda service itself is authorized to assume this role. Which type of policy must the developer configure to define which service principal can assume the role?

An IAM trust policy

An identity-based permissions policy

A resource-based policy on the Lambda function

An IAM permissions boundary

Show answer & explanation

Answer: An IAM trust policy

Answer

An IAM trust policy

An IAM trust policy (also known as an assume role policy document) defines the trust relationship for an IAM role. It is a resource-based policy attached to the role itself that specifies which security principals (such as the AWS Lambda service principal, 'lambda.amazonaws.com') are allowed to assume the role using the STS AssumeRole API.

Step-by-Step Solution

Identify the goal: granting permission for a service principal (AWS Lambda) to assume an IAM role.

The configuration required is a delegation of trust to a service.

Before a service can act on behalf of a user, it must be trusted to assume the execution role.

Differentiate between policy types: trust policies versus permissions policies.

Trust policies specify the principal (who can assume the role), while permissions policies specify the actions and resources (what the role can do).

An IAM role contains both a trust policy and permissions policies.

Select the policy type that governs the assume role action.

The trust policy contains the 'AssumeRole' action and designates 'lambda.amazonaws.com' as the trusted principal.

This configuration allows AWS Lambda to assume the execution role and obtain temporary security credentials.

Key Concept

IAM Trust Policies vs. Permissions Policies

Question 1116Question →

A developer has deployed a Python-based AWS Lambda function that synchronizes real-time multiplayer game leaderboards with an external third-party API and retrieves player metadata from an Amazon ElastiCache (Memcached) cluster located in a private VPC subnet. The Lambda function is configured to run inside the VPC and is associated with the private subnet containing the ElastiCache cluster. During load testing, the developer observes two symptoms: 1. The function is able to connect to the ElastiCache cluster, but all requests to the external third-party leaderboard API fail with a connection timeout error. 2. Under sustained high concurrent load, subsequent invocations of the Lambda function occasionally process stale player metadata that was cached during earlier invocations of the same execution context. Which two actions should the developer take to resolve these issues? (Select TWO.)

Select all that apply

Configure the Lambda function to run in private subnets that have a route pointing to a NAT Gateway located in a public subnet of the VPC.

Modify the function code to clear or reinitialize global/module-level variables holding the cached player metadata at the start of each handler invocation.

Associate the Lambda function with a public subnet of the VPC and enable auto-assign public IP on the network interface to establish direct outbound routing.

Increase the Lambda function's timeout configuration to allow the global execution context to automatically refresh and purge its in-memory state between consecutive invocations.

Configure the Lambda execution role to allow the 'ec2:CreateNetworkInterface' and 'ec2:DescribeNetworkInterfaces' actions on the public subnets to bridge the external route.

Show answer & explanation

Answer: Configure the Lambda function to run in private subnets that have a route pointing to a NAT Gateway located in a public subnet of the VPC.; Modify the function code to clear or reinitialize global/module-level variables holding the cached player metadata at the start of each handler invocation.

Answer

Configure the Lambda function to run in private subnets that have a route pointing to a NAT Gateway located in a public subnet of the VPC, and modify the function code to clear or reinitialize global/module-level variables holding the cached player metadata at the start of each handler invocation.

The correct solution involves routing outbound traffic through a NAT Gateway for internet access (resolving the timeout to the external API) and reinitializing global variables within the handler (resolving the stale data issue caused by context reuse).

Step-by-Step Solution

Analyze the networking issue (Symptom 1)

Identify that the Lambda function is running in a private VPC subnet without outbound internet access, causing connections to the external API to time out.

VPC-connected Lambda functions require a NAT Gateway or VPC endpoints to access external endpoints.

Determine the required VPC networking configuration

Ensure the Lambda function is placed in private subnets whose route tables direct traffic to a NAT Gateway in a public subnet.

This establishes outbound internet connectivity while keeping the function securely isolated.

Analyze the state/cache issue (Symptom 2)

Identify that global variables are retaining player metadata across reused execution contexts.

AWS Lambda reuses containers (execution contexts) for performance, carrying over state declared outside the handler.

Implement the code fix for execution context reuse

Update the Lambda code to clear or reinitialize global metadata caches inside the handler method at the beginning of each execution.

This guarantees that each new request processes fresh data regardless of whether the execution context is new or reused.

Key Concept

AWS Lambda VPC networking outbound routing and execution context variable persistence.

Question 1117Question →

A developer is configuring a continuous delivery pipeline in AWS CodePipeline. The pipeline builds a database migration package in AWS CodeBuild and then runs a post-migration check using an AWS Lambda function. The CodeBuild project must retrieve a database password stored as a SecureString in AWS Systems Manager Parameter Store. The Lambda function must report its execution status back to CodePipeline.

Arrange the execution steps in the correct chronological order from start to finish to ensure the pipeline runs successfully without permission or credential failures.

Drag items to arrange them in the correct order

Show answer & explanation

Answer

The pipeline first pulls the source code, then CodeBuild retrieves and decrypts the database password from Parameter Store, next the Lambda service assumes the Lambda execution role to run, and finally the Lambda function invokes PutJobSuccessResult to notify CodePipeline of completion.

The correct order requires pulling the source code first, then allowing CodeBuild to assume its service role and decrypt the SecureString from Parameter Store using AWS KMS. After CodeBuild completes, CodePipeline invokes the Lambda function. The Lambda service assumes the execution role (which requires a trust relationship with lambda.amazonaws.com), and once the code runs, the function must explicitly report success to CodePipeline using PutJobSuccessResult.

Step-by-Step Solution

Source artifact generation

Source code is successfully fetched and packaged.

AWS CodePipeline requires a source artifact to trigger downstream stages.

CodeBuild retrieves secure credentials

The decrypted database password is loaded into CodeBuild's environment.

CodeBuild needs credentials to run the migration; the CodeBuild service role must have permissions to decrypt the KMS key used by the SecureString parameter.

Lambda function execution

The Lambda service assumes the execution role and runs the verification code.

The Lambda execution role must trust the lambda.amazonaws.com service principal to execute the code.

CodePipeline status notification

CodePipeline receives a success result and completes the action.

Asynchronous Lambda actions in CodePipeline do not auto-complete; they require a PutJobSuccessResult call to advance the pipeline.

Key Concept

AWS CodePipeline execution flow, secure parameter retrieval, and service role trust configurations.

Estimated Time:1m 30s

Question 1118Question →

A developer is configuring a containerized application running on Amazon ECS that needs to access two settings: a public API endpoint URL (non-sensitive configuration) and a database password for an Amazon RDS database. The database password must be rotated automatically every 30 days. To ensure the design is both secure and cost-effective, which configuration should the developer implement?

Store the public API endpoint URL as a String parameter in AWS Systems Manager Parameter Store. Store the database password in AWS Secrets Manager and configure automatic rotation using the built-in RDS rotation template.

Store both the public API endpoint URL and the database password in AWS Secrets Manager, and enable automatic rotation for both parameters.

Store both the public API endpoint URL and the database password as SecureString parameters in AWS Systems Manager Parameter Store, and write a scheduled AWS Lambda function to rotate the password in the database.

Store the public API endpoint URL in Systems Manager Parameter Store, and define the database password as a plaintext environment variable in the ECS task definition.

Show answer & explanation

Answer: Store the public API endpoint URL as a String parameter in AWS Systems Manager Parameter Store. Store the database password in AWS Secrets Manager and configure automatic rotation using the built-in RDS rotation template.

Answer

The correct configuration uses AWS Systems Manager Parameter Store for non-sensitive parameters like the API endpoint URL, which minimizes costs. It uses AWS Secrets Manager for the database password because Secrets Manager supports native integration with Amazon RDS to automatically rotate the password, fulfilling the security requirement without requiring custom rotation logic.

Step-by-Step Solution

Analyze the sensitivity and lifecycle requirements of both configuration settings.

The API endpoint URL is non-sensitive, static configuration, while the database password is highly sensitive and requires automated rotation every 30 days.

This determines which AWS service is best suited for each parameter to optimize for cost and operational efficiency.

Select the appropriate storage service for the non-sensitive configuration.

AWS Systems Manager Parameter Store (String parameter) is selected.

Parameter Store standard parameters are free and ideal for non-sensitive configurations, making this the most cost-effective choice.

Select the appropriate storage service and rotation mechanism for the database password.

AWS Secrets Manager is selected, configured with the built-in RDS automatic rotation.

Secrets Manager provides native, out-of-the-box integration with Amazon RDS for automated password rotation, meeting the security and rotation requirements with minimal operational overhead.

Key Concept

Choosing between AWS Secrets Manager and Systems Manager Parameter Store based on sensitivity, automatic rotation requirements, and cost-effectiveness.

Question 1119Question →

A developer is building a sensitive medical telemetry ingestion application. The application receives health records (each approximately $120\text{ KB}$ in size) that must be encrypted client-side using envelope encryption before being stored in Amazon DynamoDB. The developer needs to implement this workflow using the AWS SDK and a customer managed key in AWS KMS.

Which two steps must the developer perform to encrypt and store each health record? (Select TWO.)

Select all that apply

Call the AWS KMS GenerateDataKey API using the customer managed key to receive both a plaintext data key and an encrypted data key.

Call the AWS KMS Encrypt API directly to encrypt each

120\text{ KB}

health record, then store the resulting ciphertext in DynamoDB.

Call the AWS KMS GenerateDataKeyWithoutPlaintext API to retrieve an encrypted data key, then decrypt this key locally using a local private key.

Encrypt the health record payload locally using the plaintext data key, erase the plaintext key from memory, and store the encrypted payload along with the encrypted data key in DynamoDB.

Store the generated plaintext data key in AWS Systems Manager Parameter Store as a SecureString parameter to share it with other application components.

Show answer & explanation

Answer: Call the AWS KMS GenerateDataKey API using the customer managed key to receive both a plaintext data key and an encrypted data key.; Encrypt the health record payload locally using the plaintext data key, erase the plaintext key from memory, and store the encrypted payload along with the encrypted data key in DynamoDB.

Answer

To secure the payloads, the developer must call the GenerateDataKey API to obtain both a plaintext data key and an encrypted data key. The plaintext key is used to encrypt the health record locally, and then it is discarded from memory. The encrypted payload and the encrypted data key are then stored together in DynamoDB.

The correct workflow for client-side envelope encryption requires obtaining both a plaintext key and an encrypted key via the GenerateDataKey API. The plaintext key is used to perform the local encryption of the health record, and then it is immediately discarded from memory to prevent exposure. The encrypted data key and the encrypted payload are stored together in the database, allowing authorized users to decrypt the payload by first decrypting the key via KMS.

Step-by-Step Solution

Request a data key from AWS KMS.

The GenerateDataKey API returns a plaintext data key and an encrypted data key (ciphertext).

The plaintext key is required for local encryption, while the encrypted key is stored alongside the encrypted data for future decryption.

Encrypt the payload locally and clean up memory.

The

120\text{ KB}

payload is encrypted using the plaintext data key, and the plaintext key is deleted from the application's memory.

This implements client-side envelope encryption and ensures that plaintext keys do not persist in memory, minimizing exposure risk.

Save the encrypted assets to Amazon DynamoDB.

The ciphertext payload and the encrypted data key are written to the database.

During decryption, the encrypted data key can be sent back to AWS KMS to retrieve the plaintext key needed to decrypt the payload.

Key Concept

AWS KMS Envelope Encryption

Estimated Time:1m 30s

Question 1120Question →

A developer manages a CI/CD pipeline in AWS CodePipeline. The pipeline has an AWS CodeBuild project that packages an application and an AWS CloudFormation deploy stage that performs a stack update. During a execution, the pipeline fails with two errors:

1. The CodeBuild project fails during the pre-build phase with the error: 'An error occurred (AccessDenied) when calling the AssumeRole operation: Role: arn:aws:iam::111122223333:role/CrossAccountDeployRole is not authorized to perform: sts:AssumeRole'.
2. The CloudFormation deployment fails immediately because the target stack is stuck in the UPDATE_ROLLBACK_FAILED state due to a resource that failed to clean up during a previous rollback.

Which of the following actions should the developer take to resolve these deployment pipeline failures? (Select TWO.)

Select all that apply

Update the trust policy of the CrossAccountDeployRole in account 111122223333 to allow the CodeBuild service role in the source account to perform the sts:AssumeRole action.

Run the continue-update-rollback command on the CloudFormation stack, optionally specifying the failing resource to be skipped, to return the stack to a stable UPDATE_ROLLBACK_COMPLETE state.

Attach an identity-based permission policy to the CodeBuild service role that grants sts:AssumeRole on the CrossAccountDeployRole, without modifying the destination role's trust policy.

Perform a stack update directly on the CloudFormation stack using a modified template that excludes the failing resource to override the UPDATE_ROLLBACK_FAILED state.

Update the permissions policy of the CrossAccountDeployRole to allow the sts:AssumeRole action on the CodeBuild service role ARN.

Show answer & explanation

Answer: Update the trust policy of the CrossAccountDeployRole in account 111122223333 to allow the CodeBuild service role in the source account to perform the sts:AssumeRole action.; Run the continue-update-rollback command on the CloudFormation stack, optionally specifying the failing resource to be skipped, to return the stack to a stable UPDATE_ROLLBACK_COMPLETE state.

Answer

To resolve the failures, the developer must update the trust policy of the CrossAccountDeployRole to trust the CodeBuild service role, and run the continue-update-rollback command on the CloudFormation stack to bring it back to a stable UPDATE_ROLLBACK_COMPLETE state.

The correct options are to update the trust policy of the CrossAccountDeployRole to trust the CodeBuild service role, and to run the continue-update-rollback command to return the locked CloudFormation stack to the stable UPDATE_ROLLBACK_COMPLETE state. Updating the trust policy is required because cross-account access relies on the trusting resource granting permission to the external identity. Running the continue-update-rollback command is the only valid way to transition a stack out of the UPDATE_ROLLBACK_FAILED state so it can accept updates again.

Step-by-Step Solution

Diagnose the cross-account AccessDenied error during role assumption.

Identify that the CodeBuild service role is attempting to assume CrossAccountDeployRole but lacks authorization.

For cross-account role assumption, the target role must have a trust policy (trust relationship) that explicitly trusts the principal of the calling role.

Update the trust policy of the target role (CrossAccountDeployRole).

The target role now allows sts:AssumeRole calls from the CodeBuild service role principal.

This establishes trust between the two AWS accounts, allowing CodeBuild to successfully assume the role to perform cross-account actions.

Diagnose the CloudFormation deployment block in the UPDATE_ROLLBACK_FAILED state.

Recognize that the stack is locked in a failed rollback state and cannot accept update commands.

When a resource fails to clean up during a rollback, CloudFormation stops the rollback and sets the stack state to UPDATE_ROLLBACK_FAILED. The stack remains locked until the rollback is addressed.

Execute the continue-update-rollback action on the CloudFormation stack.

The rollback resumes, optionally skipping the problematic resource, and finishes with a status of UPDATE_ROLLBACK_COMPLETE.

This operation unlocks the stack and returns it to a stable state, allowing the pipeline to deploy subsequent stack updates successfully.

Key Concept

Troubleshooting cross-account IAM role delegation and resolving locked CloudFormation rollback states.

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