All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

A developer has configured a CI/CD pipeline using AWS CodePipeline. The pipeline has a deploy stage that uses AWS CloudFormation to update a production stack. During a recent deployment, the stack update failed due to an error in a custom resource, and the subsequent rollback attempt also failed, leaving the stack in the UPDATE_ROLLBACK_FAILED state. The developer has resolved the root cause of the custom resource failure in the CloudFormation template and committed the changes to the source repository. However, the pipeline is now failing at the CloudFormation deploy stage with an error stating that the stack cannot be updated in its current state. Which two actions should the developer take to resolve the deployment failure and successfully apply the changes? (Select TWO.)

Select all that apply

Execute the continue-update-rollback command via the AWS CLI or CloudFormation console to resume the rollback process and bring the stack to the UPDATE_ROLLBACK_COMPLETE state.

After the stack reaches a stable state, trigger the pipeline again to apply the updated template containing the fix.

Run the update-stack CLI command directly with the --force flag while the stack is in the UPDATE_ROLLBACK_FAILED state to override the state validation.

Delete the stack using the delete-stack CLI command, then trigger the pipeline to perform a fresh stack creation.

Modify the CloudFormation service role's trust policy to allow the CodePipeline service role to assume it with the sts:AssumeRole action.

Show answer & explanation

Answer: Execute the continue-update-rollback command via the AWS CLI or CloudFormation console to resume the rollback process and bring the stack to the UPDATE_ROLLBACK_COMPLETE state.; After the stack reaches a stable state, trigger the pipeline again to apply the updated template containing the fix.

Answer

Execute the continue-update-rollback command via the AWS CLI or CloudFormation console to resume the rollback process and bring the stack to the UPDATE_ROLLBACK_COMPLETE state, and after the stack reaches a stable state, trigger the pipeline again to apply the updated template containing the fix.

The correct approach is to first return the CloudFormation stack to a stable state. This is achieved by executing the continue-update-rollback action, which moves the stack to UPDATE_ROLLBACK_COMPLETE. Once the stack is stable, the pipeline can be executed again to safely apply the corrected template configuration from the repository.

Step-by-Step Solution

Diagnose the current state of the AWS CloudFormation stack.

The stack is confirmed to be in the UPDATE_ROLLBACK_FAILED state, meaning that the update failed and the subsequent rollback attempt also failed.

You must identify the stack state to determine the appropriate recovery API call, as CloudFormation prevents updates on stacks that are not in a stable state.

Resume the rollback using AWS CloudFormation CLI or Console.

By executing 'aws cloudformation continue-update-rollback', CloudFormation attempts to roll back the remaining resources. If specific resources continue to fail, they can be skipped during this process.

This action moves the stack from the unstable UPDATE_ROLLBACK_FAILED state to the stable UPDATE_ROLLBACK_COMPLETE state.

Redeploy the corrected template by triggering the CI/CD pipeline.

The pipeline runs successfully, executing the CloudFormation update stage to apply the bug fix to the resources.

Once the stack is stable in the UPDATE_ROLLBACK_COMPLETE state, it can accept new update commands to apply the corrected template configuration.

Key Concept

Handling AWS CloudFormation stack update rollback failures by resuming the rollback process to reach a stable state before applying further updates.

Question 142Question →

A developer is building a student portal for a Learning Management System (LMS) hosted on an Auto Scaling group of Amazon EC2 instances. The application has two primary requirements:

1. It must cache the course catalog metadata, which is read frequently but updated only once a week.
2. It must store active student quiz session states. These session states are updated frequently with every answered question and must persist even if individual EC2 instances or cache nodes fail.

Which TWO options represent the most suitable AWS services and configurations to meet these requirements?

Select all that apply

Use Amazon ElastiCache for Redis to store the active student quiz session states.

Use Amazon ElastiCache for Memcached to cache the course catalog metadata.

Use Amazon ElastiCache for Memcached to store the active student quiz session states.

Use Amazon DynamoDB with a Scan operation to retrieve the course catalog metadata on every request.

Use Amazon Systems Manager Parameter Store to cache the weekly course catalog metadata.

Show answer & explanation

Answer: Use Amazon ElastiCache for Redis to store the active student quiz session states.; Use Amazon ElastiCache for Memcached to cache the course catalog metadata.

Answer

To store active student quiz sessions with durability, use Amazon ElastiCache for Redis. To cache the static course catalog metadata where persistence is not required, use Amazon ElastiCache for Memcached.

Using Amazon ElastiCache for Redis to store active student quiz session states is correct because Redis provides persistence, replication, and multi-AZ support, ensuring data is not lost if a node fails. Using Amazon ElastiCache for Memcached to cache the course catalog metadata is correct because Memcached is a high-performance, multi-threaded cache engine designed for simple key-value lookups where persistence is not necessary.

Step-by-Step Solution

Identify the durability and replication requirements for the active student quiz session states.

Since session data must survive instance or cache node failures, a cache engine supporting replication and persistence (like Redis) is required.

To prevent loss of quiz state during node failure.

Identify the caching requirements for the infrequently updated course catalog.

Since the data is read-heavy but updated infrequently and does not require persistence, a simple key-value cache (like Memcached) is appropriate.

To reduce database load and latency efficiently.

Key Concept

ElastiCache engines (Redis vs Memcached) and session state durability requirements.

Estimated Time:1m 30s

Question 143Question →

A developer is troubleshooting a multi-account deployment pipeline in AWS CodePipeline. During the execution, the AWS CodeBuild stage fails with an AccessDenied error when attempting to assume a deployment role in a target AWS account. Additionally, a separate AWS CloudFormation deploy stage fails with an error indicating that the target stack is in the ROLLBACK_COMPLETE state from a previous failed creation. Which two actions must the developer take to resolve these failures? (Select TWO.)

Select all that apply

Delete the CloudFormation stack in the ROLLBACK_COMPLETE state before running the deployment pipeline again.

Update the trust policy of the target deployment role to allow the AssumeRole action from the CodeBuild service role principal.

Execute the continue-update-rollback command using the AWS CLI to transition the CloudFormation stack out of the ROLLBACK_COMPLETE state.

Update the pipeline's CloudFormation deployment stage configuration to disable rollback on resource creation failure.

Add the target deployment role's ARN to the trust policy of the CodeBuild service role in the source account.

Show answer & explanation

Answer: Delete the CloudFormation stack in the ROLLBACK_COMPLETE state before running the deployment pipeline again.; Update the trust policy of the target deployment role to allow the AssumeRole action from the CodeBuild service role principal.

Answer

Delete the CloudFormation stack in the ROLLBACK_COMPLETE state before running the deployment pipeline again, and update the trust policy of the target deployment role to allow the AssumeRole action from the CodeBuild service role principal.

To resolve the deployment issues, the developer must delete the stack in the ROLLBACK_COMPLETE state because CloudFormation does not support updating a stack that failed during its initial creation. Additionally, to resolve the cross-account AccessDenied error, the developer must update the trust policy of the target role to trust the CodeBuild service role as a principal, permitting the sts:AssumeRole action.

Step-by-Step Solution

Identify the cause of the CloudFormation stage failure.

The target stack is determined to be in the ROLLBACK_COMPLETE state, indicating a failed initial creation.

CloudFormation does not allow updating a stack that failed during its initial creation and rolled back to ROLLBACK_COMPLETE. The stack must be deleted before a new creation attempt can succeed.

Address the ROLLBACK_COMPLETE state.

The stack is deleted.

Deleting the stack removes the blocked state, allowing the pipeline to create the stack from scratch on the next execution.

Identify the cause of the CodeBuild assume-role failure.

The CodeBuild service role in the source account cannot assume the target deployment role due to missing trust permissions.

Cross-account role assumption requires the target role's trust policy to explicitly grant the assuming principal permission to assume it.

Update the trust policy of the target deployment role.

The trust policy is updated to include the CodeBuild service role ARN as a trusted principal with the sts:AssumeRole action.

This establishes the trust relationship, allowing STS to successfully issue temporary credentials to CodeBuild to perform the deployment.

Key Concept

Cross-account IAM delegation and CloudFormation initial creation rollback handling

Question 144Question →

A financial technology application uses an Amazon DynamoDB table to retrieve real-time stock price data. During periods of high market activity, the application experiences increased read latency due to a massive spike in repeat query requests for popular stock symbols, leading to Read Capacity Unit (RCU) throttling on the table. A developer decides to deploy an Amazon DynamoDB Accelerator (DAX) cluster to resolve this issue. Which two of the following benefits does deploying a DAX cluster provide to resolve this throughput and latency bottleneck? (Select two.)

Select all that apply

It provides sub-millisecond response times for cached read requests.

It reduces the read load on the DynamoDB table by serving repeat read requests from the cache.

It automatically increases the provisioned read capacity units (RCUs) of the table to handle hot partition keys.

It converts DynamoDB Query operations into Scan operations to pre-populate the cache.

It serves as a secure store to cache database access credentials and rotate them automatically.

Show answer & explanation

Answer: It provides sub-millisecond response times for cached read requests.; It reduces the read load on the DynamoDB table by serving repeat read requests from the cache.

Answer

Deploying a DAX cluster provides sub-millisecond response times for cached read requests and reduces the read load on the DynamoDB table by serving repeat read requests from the cache.

Deploying a DAX cluster acts as an in-memory cache that serves repeat read requests with sub-millisecond latency. Since these cached reads are resolved within the DAX cluster, they do not consume the underlying table's provisioned Read Capacity Units (RCUs), resolving the throttling bottleneck.

Step-by-Step Solution

Identify the performance bottleneck in the DynamoDB table.

The bottleneck is caused by a massive spike in repeat query requests, leading to RCU throttling and latency.

Understanding the nature of the bottleneck is necessary to choose the correct optimization approach.

Evaluate the capabilities of Amazon DynamoDB Accelerator (DAX) to resolve read latency and capacity bottlenecks.

DAX provides an API-compatible, in-memory caching layer that serves repeat read requests with sub-millisecond latency and offloads read traffic from the database table.

This confirms that DAX directly mitigates both the read latency and RCU throttling issues.

Key Concept

Using Amazon DynamoDB Accelerator (DAX) to cache read requests, reducing latency and table read throughput load.

Estimated Time:1m 0s

Question 145Question →

A developer is deploying a Node.js web application to AWS Elastic Beanstalk. The application reads and writes data to an Amazon DynamoDB table using the AWS SDK for JavaScript. The developer wants to use AWS X-Ray to perform distributed tracing of incoming HTTP requests and downstream DynamoDB calls. Currently, the application is running, but no trace data is visible in the AWS X-Ray console.

Which two actions should the developer take to instrument the application and enable distributed tracing? (Select two.)

Select all that apply

Create a configuration file in the `.ebextensions` directory at the root of the application source bundle to set `XRayEnabled` to `true` under the `aws:elasticbeanstalk:xray` namespace.

Use the AWS X-Ray SDK in the application code to wrap the DynamoDB client and capture trace context for downstream calls.

Create a configuration file in a folder named `ebextensions` (without the leading dot) at the root of the application source bundle to enable X-Ray.

Initialize the AWS X-Ray SDK by hardcoding the AWS access key and secret access key of an IAM user directly in the application code.

Increase the Amazon SQS visibility timeout to allow the X-Ray daemon sufficient time to process and upload trace data.

Show answer & explanation

Answer: Create a configuration file in the `.ebextensions` directory at the root of the application source bundle to set `XRayEnabled` to `true` under the `aws:elasticbeanstalk:xray` namespace.; Use the AWS X-Ray SDK in the application code to wrap the DynamoDB client and capture trace context for downstream calls.

Answer

Enable X-Ray tracing in the Elastic Beanstalk environment using a configuration file in the `.ebextensions` directory, and instrument the DynamoDB client in the application code using the AWS X-Ray SDK.

To trace incoming requests and downstream database calls on AWS Elastic Beanstalk, you must enable the X-Ray daemon on the hosting instances and instrument the database client. Creating a configuration file in the `.ebextensions` directory at the root of the source bundle with `XRayEnabled: true` ensures that the platform automatically installs, runs, and updates the X-Ray daemon. Additionally, wrapping the DynamoDB client with the AWS X-Ray SDK enables the capture of downstream calls as subsegments under the active trace context.

Step-by-Step Solution

Enable the AWS X-Ray daemon in the Elastic Beanstalk environment.

The X-Ray daemon is installed and started on the Elastic Beanstalk EC2 instances, listening on local UDP port 2000.

Elastic Beanstalk does not run the X-Ray daemon by default. Creating a configuration file in the `.ebextensions` folder with the `XRayEnabled` option set to `true` instructs Elastic Beanstalk to configure and run the daemon process.

Instrument the downstream AWS SDK DynamoDB client using the AWS X-Ray SDK in the application code.

The application wraps the DynamoDB client, allowing the X-Ray SDK to record and inject trace propagation headers into outgoing requests.

Simply enabling the daemon only collects EC2 instance metadata and application container level data. To trace specific downstream calls (like DynamoDB queries), the AWS SDK client must be explicitly instrumented by the X-Ray SDK.

Key Concept

Instrumenting Elastic Beanstalk applications with the AWS X-Ray daemon and capturing downstream AWS SDK client calls.

Estimated Time:2m 0s

Question 146Question →

A developer is using AWS CodeDeploy to perform an in-place deployment of a new application revision to an Amazon EC2 Auto Scaling group that currently contains $6$ running instances. The deployment must satisfy the following constraints:

* A minimum of $3$ instances must remain healthy and serve traffic at all times during the deployment process.
* The deployment must complete as quickly as possible while adhering to the healthy host constraint.

Which two CodeDeploy configurations can the developer use to meet these requirements?

Select all that apply

The default deployment configuration CodeDeployDefault.HalfAtATime

A custom deployment configuration with the minimumHealthyHosts parameter set to a type of FLEET_PERCENT and a value of

50

The default deployment configuration CodeDeployDefault.OneAtATime

The default deployment configuration CodeDeployDefault.AllAtOnce

A custom deployment configuration with the minimumHealthyHosts parameter set to a type of HOST_COUNT and a value of

50

Show answer & explanation

Answer: The default deployment configuration CodeDeployDefault.HalfAtATime; A custom deployment configuration with the minimumHealthyHosts parameter set to a type of FLEET_PERCENT and a value of $50$

Answer

The developer can use the default deployment configuration CodeDeployDefault.HalfAtATime or a custom deployment configuration with the minimumHealthyHosts parameter set to a type of FLEET_PERCENT and a value of

50

The correct options are the default configuration that updates half of the instances at a time, and a custom configuration specifying a minimum of

50\%

fleet health. For a fleet of

6

instances, keeping a minimum of

3

healthy instances requires maintaining at least

50\%

health. The default configuration that accomplishes this in the fewest steps is the one that updates half the fleet at a time, completing in two batches. Alternatively, a custom configuration using a fleet percentage of

50

achieves the exact same balance of speed and availability.

Step-by-Step Solution

Determine the minimum healthy host percentage and count required.

The target is

3

healthy instances out of

6

, which represents exactly

50\%

of the fleet.

This establishes the boundary conditions for the deployment configurations.

Evaluate the default configuration options against speed and capacity constraints.

CodeDeployDefault.HalfAtATime meets the requirement by updating

3

instances at a time (

2

steps total). CodeDeployDefault.OneAtATime is too slow (

6

steps), and CodeDeployDefault.AllAtOnce violates the healthy instances constraint.

To select the correct predefined deployment configuration.

Evaluate custom configuration parameters to match the target threshold.

A custom configuration with minimumHealthyHosts of type FLEET_PERCENT set to

50

will correctly keep

3

instances healthy. Using HOST_COUNT with a value of

50

expects

50

physical hosts, which exceeds the fleet size.

To identify the correct custom deployment configuration settings.

Key Concept

AWS CodeDeploy deployment configurations allow developers to specify the number or percentage of instances that must remain healthy during an in-place deployment to balance availability and speed.

Question 147Question →

A mobile application sends a `POST` request to an Amazon API Gateway REST API. The API is configured with a Lambda proxy integration to retrieve user profiles. The developer recently migrated the integration from a Lambda custom integration to a Lambda proxy integration. Following the migration, client requests fail with a `502 Bad Gateway` status code and a CORS error in the browser console. The Lambda function execution logs show that the function completes successfully and returns the user profile data. Which two actions should the developer take to resolve this issue?

Select all that apply

Modify the backend Lambda function to return a JSON object containing `statusCode`, a headers map, and a stringified JSON `body`.

Include the `Access-Control-Allow-Origin` header inside the `headers` object of the Lambda function's return payload.

Configure an integration response mapping template in API Gateway to map the Lambda output to the client-facing format.

Enable CORS on the API Gateway resource and rely on API Gateway to automatically inject CORS headers into the integration response.

Configure a CORS origin policy on the Amazon S3 bucket that hosts the static assets of the mobile application.

Show answer & explanation

Answer: Modify the backend Lambda function to return a JSON object containing `statusCode`, a headers map, and a stringified JSON `body`.; Include the `Access-Control-Allow-Origin` header inside the `headers` object of the Lambda function's return payload.

Answer

To resolve the 502 Bad Gateway and CORS errors, the developer must format the Lambda function's output as a JSON object containing statusCode, a headers map, and a stringified body, and explicitly include the Access-Control-Allow-Origin header inside the headers map.

Under a Lambda proxy integration, API Gateway expects the backend Lambda function to structure its response as a JSON object with the keys: `statusCode`, `headers`, and `body` (as a string). Returning unformatted output causes API Gateway to fail parsing the integration response, throwing a 502 Bad Gateway error. Because the request never successfully completes with valid response headers, the browser console also reports a CORS error. Furthermore, API Gateway does not inject CORS headers automatically into proxy integration responses, meaning the Lambda function itself must return the `Access-Control-Allow-Origin` header in its response payload.

Step-by-Step Solution

Inspect the Lambda function response format.

The Lambda function returns raw user profile data, which is incompatible with Lambda proxy integration requirements.

Lambda proxy integrations require a structured response containing statusCode, headers, and body.

Modify the response structure returned by the Lambda function.

The function returns a JSON object with 'statusCode': 200, a 'headers' map, and 'body': JSON.stringify(profileData).

This matches the expected schema for API Gateway to successfully parse the integration response and avoid the 502 Bad Gateway error.

Add the Access-Control-Allow-Origin header to the Lambda response.

The headers map contains 'Access-Control-Allow-Origin': '*'.

Since proxy integrations bypass API Gateway integration response formatting, the backend Lambda must explicitly supply the CORS headers to prevent browser blocks.

Key Concept

Lambda Proxy Integration Response Format and CORS Requirements

Question 148Question →

A developer is configuring an Amazon CloudWatch Logs metric filter to monitor HTTP 500 status codes for a legacy web application. The application logs events to a CloudWatch log group in space-delimited Common Log Format (CLF). The developer observes the following sample log event:

`192.0.2.10 - - [14/Jul/2026:12:00:00 +0000] "POST /submit HTTP/1.1" 500 324`

The developer sets up the metric filter with the following pattern:

`[ip, client, user, timestamp, request, status_code = 500, size]`

However, the metric does not record any data points even when the log group receives events containing HTTP 500 errors. What is the reason for this behavior?

The metric filter parser splits the log line strictly by spaces, ignoring brackets and quotes. This causes the timestamp and HTTP request to be parsed into multiple fields, shifting the status code to the ninth position.

The metric filter pattern syntax requires double equal signs for comparison operators in space-delimited logs, meaning the pattern should be updated to status_code == 500.

The metric filter must use JSON syntax to query the log event properties because the web server logs are structured, which requires changing the pattern to a JSON path query.

The timestamp and request fields in the pattern must be enclosed in single quotes to instruct the parser to treat them as single entities, rather than splitting them on spaces.

Show answer & explanation

Answer: The metric filter parser splits the log line strictly by spaces, ignoring brackets and quotes. This causes the timestamp and HTTP request to be parsed into multiple fields, shifting the status code to the ninth position.

Answer

The correct answer explains that CloudWatch Logs parses space-delimited log events strictly by spaces, ignoring enclosing brackets (like those on timestamps) or quotes (like those around requests). Consequently, the log line is split into ten fields instead of seven, shifting the status code to the ninth position. To fix the issue, the metric filter pattern must declare fields up to the ninth position, such as: `[ip, client, user, timestamp_date, timestamp_zone, method, path, protocol, status_code = 500, size]`.

Step-by-Step Solution

Analyze the raw log line to identify space boundaries.

The log line has space-delimited tokens: 192.0.2.10 (1), - (2), - (3), [14/Jul/2026:12:00:00 (4), +0000] (5), "POST (6), /submit (7), HTTP/1.1" (8), 500 (9), 324 (10).

CloudWatch Logs space-delimited metric filter parser does not respect quotes or brackets for grouping; it separates tokens strictly by spaces.

Determine the position of the target metric field.

The HTTP status code '500' is at the 9th position in the sequence of space-separated values.

Knowing the correct position allows us to align the metric filter fields with the actual log format structure.

Evaluate the metric filter pattern defined by the developer.

The pattern specifies only 7 fields, mapping 'status_code' to the 6th field (which parses to '"POST'), causing the comparison 'status_code = 500' to fail.

This shows why the existing metric filter fails to capture any matches.

Key Concept

CloudWatch Logs space-delimited metric filters parse raw log entries strictly by space boundaries without respecting quotes or brackets for grouping.

Estimated Time:1m 30s

Question 149Question →

A developer is configuring AWS CodeDeploy to deploy a Python web application to a fleet of Amazon EC2 instances. The deployment process must retrieve database credentials securely from AWS Systems Manager Parameter Store (stored as a `SecureString` parameter) and execute a database migration script before the application starts and begins accepting traffic.

Which two actions must the developer perform to meet these requirements?

Select all that apply

Grant the Amazon EC2 instance profile IAM role the `ssm:GetParameters` and `kms:Decrypt` permissions.

Execute the database migration script during the `AfterInstall` lifecycle hook in the `appspec.yml` file.

Execute the database migration script during the `BeforeAllowTraffic` lifecycle hook in the `appspec.yml` file.

Grant the AWS CodeDeploy service role the `ssm:GetParameters` and `kms:Decrypt` permissions.

Define the Parameter Store parameters in the `resources` section of the `appspec.yml` file to inject them as environment variables.

Show answer & explanation

Answer: Grant the Amazon EC2 instance profile IAM role the `ssm:GetParameters` and `kms:Decrypt` permissions.; Execute the database migration script during the `AfterInstall` lifecycle hook in the `appspec.yml` file.

Answer

Granting the Amazon EC2 instance profile IAM role the necessary decrypt permissions and executing the migration script during the AfterInstall lifecycle hook in the appspec.yml file.

To successfully run the database migration before the application starts, the script must execute during a valid EC2 lifecycle hook like `AfterInstall`. Since the script runs on the EC2 instances, the instance profile IAM role must have permissions to retrieve the SecureString parameter and decrypt it using the associated KMS key.

Step-by-Step Solution

Identify the entity executing the deployment scripts.

The CodeDeploy agent runs on the EC2 instances and executes the AppSpec lifecycle hook scripts.

This determines that permissions to fetch parameters must be assigned to the EC2 instance profile role, not the CodeDeploy service role.

Select the correct CodeDeploy lifecycle hook for EC2.

The `AfterInstall` hook runs on EC2 instances before the application starts.

This ensures the schema migration is completed before the web server begins running.

Grant the EC2 instance profile access to Systems Manager Parameter Store and AWS KMS.

Add `ssm:GetParameters` and `kms:Decrypt` to the instance profile role's policy.

The script running on the instance must be authorized to pull and decrypt the database credentials.

Key Concept

AWS CodeDeploy EC2 deployments rely on the CodeDeploy agent running under the instance profile's IAM permissions and execute scripts within EC2-specific lifecycle hooks such as AfterInstall.

Estimated Time:2m 0s

Question 150Question →

A developer is setting up an application on an on-premises server that must archive daily transaction logs to a private Amazon S3 bucket. To implement this securely without storing long-term credentials on the server, the developer creates an IAM User named `archive-agent` in the AWS account `111122223333` and an IAM Role named `S3UploaderRole` that has permissions to write to the S3 bucket. The application will authenticate as `archive-agent` using short-term configurations and then assume `S3UploaderRole` to perform the S3 uploads.

Which two configuration policies are required to establish this role-assumption trust relationship and grant the necessary permissions? (Select two.)

Select all that apply

A trust policy attached to S3UploaderRole that allows the archive-agent user to assume the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/archive-agent"
},
"Action": "sts:AssumeRole"
}
]
}

A permissions policy attached to the archive-agent user that permits calling sts:AssumeRole on the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/S3UploaderRole"
}
]
}

A trust policy attached to S3UploaderRole containing S3 permissions directly:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/archive-agent"
},
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::company-logs-bucket/*"
}
]
}

A permissions policy attached to S3UploaderRole that references the user as a resource:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:user/archive-agent"
}
]
}

A local credentials file containing static credentials for the AWS Account Root User to bypass role assumption:

{
"aws_access_key_id": "AKIAIOSFODNN7EXAMPLE",
"aws_secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}

Show answer & explanation

Answer: A trust policy attached to S3UploaderRole that allows the archive-agent user to assume the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:user/archive-agent"
},
"Action": "sts:AssumeRole"
}
]
}
; A permissions policy attached to the archive-agent user that permits calling sts:AssumeRole on the role:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::111122223333:role/S3UploaderRole"
}
]
}

Answer

To establish the trust relationship and grant permissions, the developer must attach a trust policy to the S3UploaderRole that lists the archive-agent user as the trusted principal allowed to perform the sts:AssumeRole action, and attach an IAM permissions policy to the archive-agent user that permits calling sts:AssumeRole on the role's Amazon Resource Name (ARN).

Role assumption is a two-way handshake. The trust policy attached to the S3UploaderRole must declare the archive-agent IAM User as a trusted principal that is permitted to execute the sts:AssumeRole action. Simultaneously, the archive-agent user must possess a permissions policy that explicitly permits it to perform the sts:AssumeRole action against the target role's ARN. This combination ensures that the user is authorized to request the role and the role is authorized to trust the user.

Step-by-Step Solution

Configure the trust policy on the destination IAM Role.

The target role (S3UploaderRole) allows sts:AssumeRole requests originating from the archive-agent IAM User principal.

An IAM Role's trust policy establishes which trusted identities (principals) are authorized to assume it.

Configure the permissions policy on the source IAM User.

The archive-agent user has explicit permission to call sts:AssumeRole on the ARN of the S3UploaderRole.

By default, IAM users do not have permissions to call STS AssumeRole; this must be explicitly granted in their permissions policy.

Key Concept

Role assumption requires permissions configured on both sides: a trust policy on the role defining who can assume it, and an identity permissions policy on the user permitting the assume role action.

Question 151Question →

A developer is using AWS Serverless Application Model (SAM) to deploy a serverless API. The application uses a Lambda function triggered by an API Gateway API (defined as an `Api` event source) to retrieve records from a database. During testing, the API Gateway endpoint returns a 502 Bad Gateway error. The Lambda function logs indicate that it executed successfully and returned the database records, but the integration failed. Additionally, the developer needs to store the database credentials securely and ensure they are rotated automatically.

Which of the following actions should the developer take to resolve the integration error and meet the security requirements? (Select TWO.)

Select all that apply

Format the Lambda function's return payload to include the statusCode, headers, and body fields.

Store the database credentials in AWS Secrets Manager and configure automatic rotation for the secret.

Modify the API Gateway integration in the template to use a custom integration, and configure the Lambda function handler to parse the request mapping templates.

Store the database credentials in AWS Systems Manager Parameter Store as a SecureString, and enable the built-in Parameter Store automatic rotation feature.

Update the trust policy of the Lambda execution role to allow the API Gateway service principal (apigateway.amazonaws.com) to assume the role.

Show answer & explanation

Answer: Format the Lambda function's return payload to include the statusCode, headers, and body fields.; Store the database credentials in AWS Secrets Manager and configure automatic rotation for the secret.

Answer

Format the Lambda function's return payload to include the statusCode, headers, and body fields, and store the database credentials in AWS Secrets Manager and configure automatic rotation for the secret.

The correct options are to format the Lambda function's return payload with status code, headers, and body fields, and to store the credentials in AWS Secrets Manager with automatic rotation. Because the default SAM Api event source deploys API Gateway with Lambda proxy integration, the Lambda response must adhere to a specific structure. Additionally, Secrets Manager is the correct service to use because it supports native automated credential rotation, whereas Systems Manager Parameter Store does not.

Step-by-Step Solution

Analyze the 502 Bad Gateway integration error.

The Lambda function executes successfully but the integration fails. Since AWS SAM's default Api event source configures API Gateway Lambda proxy integration, the Lambda function must return the response in a structured format containing the status code, headers, and body.

This determines how to format the Lambda function's response to satisfy API Gateway's proxy integration requirements.

Evaluate the database credential rotation requirement.

AWS Secrets Manager is selected because it natively supports automatic rotation of credentials, unlike AWS Systems Manager Parameter Store which requires custom implementations to achieve rotation.

This identifies the correct AWS service to store and rotate credentials securely.

Key Concept

AWS SAM templates default to API Gateway Lambda proxy integrations, requiring structured JSON responses from the backend Lambda function, and security credentials requiring rotation should be managed by AWS Secrets Manager.

Question 152Question →

A developer is configuring the deployment settings for a production web application hosted on AWS Elastic Beanstalk. The deployment process must satisfy the following requirements:

1. The new application version must be deployed to a completely separate, temporary Auto Scaling group and pass health checks before serving any production traffic.
2. If health checks fail, the rollback must be automatic, immediate, and leave the existing active instances completely untouched.
3. The deployment must avoid any DNS-level routing changes, such as swapping environment URLs.

Which Elastic Beanstalk deployment policy should the developer select?

Immutable

Rolling with additional batch

Traffic splitting

All at once

Show answer & explanation

Answer: Immutable

Answer

Immutable

The correct option is Immutable because it is the only Elastic Beanstalk deployment policy that satisfies all constraints. It deploys the new version to a separate temporary Auto Scaling group under the same environment and load balancer. It validates the new version's health before directing any production traffic to it. If the health checks fail, the rollback is clean and instant since Elastic Beanstalk simply terminates the temporary Auto Scaling group, leaving the original instances untouched. Furthermore, since it uses the same load balancer, it does not require DNS CNAME swaps.

Step-by-Step Solution

Analyze the requirement for deploying to a separate, temporary Auto Scaling group with zero pre-traffic production exposure.

This eliminates Rolling and Rolling with Additional Batch, which update instances within the existing Auto Scaling group.

To ensure the active production instances remain completely untouched until health checks pass, the new version must be isolated initially.

Evaluate the requirement for avoiding DNS-level changes.

This eliminates Blue/Green deployments that rely on swapping CNAME URLs at the Route 53 or Elastic Beanstalk environment level.

The deployment must occur within the same Elastic Beanstalk environment under the same load balancer without changing CNAME records.

Compare Immutable vs Traffic Splitting and All at Once policies.

All at Once causes downtime. Traffic Splitting immediately routes production traffic to the new version before final promotion. Only Immutable meets all constraints by using a temporary Auto Scaling group under the same load balancer, running health checks, and offering clean rollback by simply terminating the temporary group.

Immutable is the only native Elastic Beanstalk policy that provides zero-downtime, separate temporary ASG testing, and clean rollback without DNS changes.

Key Concept

AWS Elastic Beanstalk Deployment Policies

Question 153Question →

A developer is hosting a client-side web application on `https://console.inventoryhub.net`. The application makes an HTTP `DELETE` request to an Amazon API Gateway REST API that uses a Lambda proxy integration to remove items from a database. When a user attempts to delete an item, the browser blocks the request and displays a CORS preflight error in the console. Additionally, when testing the endpoint directly using a custom HTTP client, the API returns a `502 Bad Gateway` error. Which two actions should the developer take to resolve these issues? (Select TWO.)

Select all that apply

Configure a MOCK integration for the OPTIONS method on the API Gateway resource to return the CORS headers Access-Control-Allow-Origin and Access-Control-Allow-Methods.

Update the backend Lambda function to return a JSON response containing the statusCode, body, and headers fields, including the Access-Control-Allow-Origin header.

Add a CORS configuration policy to the Amazon S3 bucket where the web app is hosted to allow HTTP DELETE requests from the API Gateway domain.

In the API Gateway console under the DELETE method, use Integration Responses to map the Access-Control-Allow-Origin header from the Lambda function's return value.

Associate an Amazon Cognito User Pool authorizer with the OPTIONS method to authenticate the preflight requests before forwarding them.

Show answer & explanation

Answer: Configure a MOCK integration for the OPTIONS method on the API Gateway resource to return the CORS headers Access-Control-Allow-Origin and Access-Control-Allow-Methods.; Update the backend Lambda function to return a JSON response containing the statusCode, body, and headers fields, including the Access-Control-Allow-Origin header.

Answer

Configure a MOCK integration for the OPTIONS method on the API Gateway resource to return the CORS headers, and update the backend Lambda function to return a JSON response containing the statusCode, body, and headers fields including the Access-Control-Allow-Origin header.

The browser blocks the request because the API Gateway does not respond to the preflight OPTIONS request with the required CORS headers, which is fixed by configuring a MOCK integration for OPTIONS. Furthermore, the 502 Bad Gateway error indicates that the Lambda function's response violates the required format for proxy integrations. Correcting the Lambda output to include statusCode, body, and headers (with Access-Control-Allow-Origin) resolves both the 502 error and allows the browser to accept the actual DELETE request response.

Step-by-Step Solution

Enable CORS on the API Gateway resource for the OPTIONS method.

This creates an OPTIONS method with a MOCK integration that returns the Access-Control-Allow-Origin and Access-Control-Allow-Methods headers to satisfy the browser's preflight request.

Browsers send a preflight OPTIONS request before cross-origin non-simple requests (like DELETE). The API must respond to OPTIONS without authentication and with the appropriate CORS headers.

Ensure the Lambda function returns a correctly structured JSON object containing statusCode, body, and headers.

This resolves the 502 Bad Gateway error caused by the malformed response format under Lambda proxy integration.

Under Lambda proxy integration, API Gateway expects a specific return JSON structure. If the Lambda returns a raw string or missing fields, API Gateway cannot parse it and returns a 502 Bad Gateway error.

Include the Access-Control-Allow-Origin header within the Lambda function's returned headers dictionary.

The browser successfully receives the Access-Control-Allow-Origin header on the actual DELETE response and permits the client-side application to read the response.

For Lambda proxy integrations, CORS headers for the actual request (DELETE) must be returned by the backend Lambda function itself, not just the OPTIONS preflight method.

Key Concept

CORS preflight requests require a MOCK OPTIONS endpoint returning CORS headers, and Lambda proxy integrations require the backend Lambda function to format its response with statusCode, body, and headers, including Access-Control-Allow-Origin.

Question 154Question →

A developer is writing an AWS Lambda function in AWS Account A ( $111111111111$ ) that needs to retrieve files from an Amazon S3 bucket located in AWS Account B ( $222222222222$ ). The developer has attached an IAM policy to the Lambda function's execution role in Account A that grants `s3:GetObject` permissions on the S3 bucket in Account B. However, when the Lambda function runs, it receives an Access Denied error (HTTP $403$ ) from Amazon S3. Which of the following actions will resolve this authorization failure?

Add a bucket policy to the S3 bucket in Account B that explicitly grants the Lambda execution role ARN in Account A permission to perform the s3:GetObject action.

Update the trust policy of the Lambda execution role in Account A to allow the S3 service in Account B to assume the role.

Initialize the Amazon S3 client in the Lambda function using hardcoded AWS access keys from an IAM user in Account B who has access to the bucket.

Create an Amazon Cognito Identity Pool in Account B, configure it to authenticate the Lambda function, and use the retrieved temporary credentials to access the bucket.

Show answer & explanation

Answer: Add a bucket policy to the S3 bucket in Account B that explicitly grants the Lambda execution role ARN in Account A permission to perform the s3:GetObject action.

Answer

Add a bucket policy to the S3 bucket in Account B that explicitly grants the Lambda execution role ARN in Account A permission to perform the s3:GetObject action.

For cross-account access to Amazon S3, both the identity-based policy in the source account (Account A) and the resource-based policy (bucket policy) in the destination account (Account B) must explicitly grant permission. Adding a bucket policy in the destination account that allows the source account's Lambda execution role to perform the object retrieval action satisfies the second requirement.

Step-by-Step Solution

Identify the authorization boundary for cross-account S3 access.

Determine that the request crosses AWS accounts, requiring authorization from both the source (Account A) and destination (Account B).

Unlike same-account S3 access, cross-account access requires permissions to be granted explicitly on both the identity-based policy and the resource-based policy.

Evaluate the existing configuration.

Confirm that the identity-based policy on the Lambda execution role in Account A already allows s3:GetObject on the target resource.

Since the IAM role is configured correctly, the authorization failure points to a missing resource-based permission on the destination bucket.

Configure the destination S3 bucket policy.

Add an S3 bucket policy in Account B designating the Lambda execution role from Account A as the Principal, and allowing the s3:GetObject action.

This establishes the necessary trust relationship at the resource level, enabling the Lambda function to retrieve the objects successfully.

Key Concept

Cross-Account IAM Delegation and Resource-Based Policies

Question 155Question →

A developer is deploying a microservices application to AWS App Runner. The application needs to retrieve two configuration settings:

1. Database credentials for an Amazon Aurora PostgreSQL database that must be rotated automatically every 30 days.
2. A public API endpoint URL for an external service that is non-sensitive and frequently accessed.

Which combination of actions should the developer perform to manage and retrieve these configurations securely and cost-effectively? (Select TWO.)

Select all that apply

Store the database credentials in AWS Systems Manager Parameter Store as a SecureString parameter and enable native scheduled rotation.

Store the external service endpoint URL in AWS Secrets Manager to keep all external references in a single service.

Store the database credentials in AWS Secrets Manager and configure automatic rotation using the built-in AWS Lambda rotation function.

Store the external service endpoint URL in AWS Systems Manager Parameter Store as a String parameter.

Embed the database credentials directly in the application code as environment variables within the Dockerfile.

Show answer & explanation

Answer: Store the database credentials in AWS Secrets Manager and configure automatic rotation using the built-in AWS Lambda rotation function.; Store the external service endpoint URL in AWS Systems Manager Parameter Store as a String parameter.

Answer

The developer should store the database credentials in AWS Secrets Manager and configure automatic rotation, and store the non-sensitive external service endpoint URL in AWS Systems Manager Parameter Store as a String parameter.

AWS Secrets Manager is designed for storing database credentials securely and provides native support for RDS/Aurora automatic rotation via Lambda. AWS Systems Manager Parameter Store is the most cost-effective storage for non-sensitive configuration data like API endpoints, as standard parameters are free.

Step-by-Step Solution

Determine the appropriate storage service for the database credentials.

Identify AWS Secrets Manager as the best choice because it offers native integration with Amazon Aurora and built-in automatic credential rotation.

AWS Secrets Manager is specifically built for secrets requiring lifecycle management and rotation, reducing custom scripting effort.

Determine the appropriate storage service for the public API endpoint URL.

Identify AWS Systems Manager Parameter Store as the correct choice since the configuration is non-sensitive and does not require rotation.

Parameter Store standard parameters are free and ideal for non-sensitive application settings, optimizing costs.

Key Concept

Selecting between AWS Secrets Manager and Systems Manager Parameter Store based on security features (like automatic rotation) and cost-efficiency.

Question 156Question →

A developer has configured an AWS Lambda function in Account A to write data to an Amazon DynamoDB table in Account B. To achieve this, the Lambda function code uses the AWS SDK to call `sts:AssumeRole` on an IAM role in Account B named `DynamoDBWriteRole`. The Lambda function's execution role in Account A has a policy allowing `sts:AssumeRole` on the ARN of `DynamoDBWriteRole`. However, the function execution fails with an `AccessDenied` error during the STS assume role operation. The developer examines the trust policy of `DynamoDBWriteRole` in Account B:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "lambda.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

Which of the following actions will resolve this authorization failure?

Add a Principal block specifying lambda.amazonaws.com directly to the identity-based permission policy attached to the Lambda execution role in Account A.

Modify the Lambda function code to initialize the DynamoDB client by passing hardcoded IAM Access Key IDs and Secret Access Keys from the Lambda execution role.

Update the trust policy of DynamoDBWriteRole in Account B to specify the ARN of the Lambda execution role from Account A in the Principal block instead of the Lambda service principal.

Configure a Cognito Identity Pool in Account B to authenticate the Lambda function and obtain temporary AWS credentials for DynamoDB.

Show answer & explanation

Answer: Update the trust policy of DynamoDBWriteRole in Account B to specify the ARN of the Lambda execution role from Account A in the Principal block instead of the Lambda service principal.

Answer

Updating the trust policy of DynamoDBWriteRole in Account B to specify the ARN of the Lambda execution role from Account A in the Principal block instead of the Lambda service principal.

The correct action is to modify the trust policy of the target role in Account B so that it trusts the ARN of the Lambda execution role in Account A. When a Lambda function runs and utilizes the AWS SDK to call `AssumeRole`, the call is initiated under the identity of the Lambda execution role, not the Lambda service principal. Therefore, the destination role's trust policy must explicitly allow the execution role's ARN (or Account A) as the trusted Principal.

Step-by-Step Solution

Identify the identity making the role assumption request.

The Lambda function's execution role in Account A is the calling identity that invokes `sts:AssumeRole`.

When code running inside a Lambda function uses the AWS SDK to assume a role, the request is authenticated via the function's execution role credentials.

Analyze the destination role's trust policy in Account B.

The current trust policy grants permissions only to the AWS service principal `lambda.amazonaws.com`.

The service principal `lambda.amazonaws.com` is used to allow the Lambda service to assume a role to execute a function, not to allow programmatic SDK calls made by an IAM role.

Modify the trust policy of the destination role in Account B.

Replace the service principal in the Principal block with the ARN of the Lambda execution role from Account A.

This establishes the necessary cross-account trust relation allowing the specific IAM identity from Account A to call `sts:AssumeRole` on the role in Account B.

Key Concept

Understanding and resolving IAM trust policy misconfigurations in cross-account delegation.

Estimated Time:1m 30s

Question 157Question →

A developer is attempting to deploy an AWS Serverless Application Model (SAM) template using the AWS CLI in an AWS Organizations member account. The developer is assuming an IAM role named `DeploymentRole` which has the `AdministratorAccess` managed policy attached. During the deployment, the CloudFormation stack creation fails with the following error:

`API: lambda:CreateFunction User: arn:aws:iam::123456789012:assumed-role/DeploymentRole/AWSCloudFormation is not authorized to perform: lambda:CreateFunction on resource: arn:aws:lambda:us-east-1:123456789012:function:MySampleFunction`

Which of the following actions should the developer take to resolve this authorization failure? (Select TWO.)

Select all that apply

Ensure that the IAM permissions boundary attached to the `DeploymentRole` includes permissions for the `lambda:CreateFunction` action.

Verify that no Service Control Policy (SCP) in AWS Organizations is denying the `lambda:CreateFunction` action on the member account.

Modify the trust policy of the `DeploymentRole` to allow the Lambda service principal (`lambda.amazonaws.com`) to assume the role.

Configure an Amazon Cognito Identity Pool to federate the developer's credentials and grant temporary permissions for the Lambda creation.

Create an API Gateway custom Lambda authorizer to authenticate the deployment requests sent by the AWS CLI.

Show answer & explanation

Answer: Ensure that the IAM permissions boundary attached to the `DeploymentRole` includes permissions for the `lambda:CreateFunction` action.; Verify that no Service Control Policy (SCP) in AWS Organizations is denying the `lambda:CreateFunction` action on the member account.

Answer

Ensure that the IAM permissions boundary attached to the DeploymentRole includes permissions for the lambda:CreateFunction action, and verify that no Service Control Policy (SCP) in AWS Organizations is denying the lambda:CreateFunction action on the member account.

The correct options are to ensure that the IAM permissions boundary attached to the DeploymentRole includes permissions for the lambda:CreateFunction action, and to verify that no Service Control Policy (SCP) in AWS Organizations is denying the action on the member account. In AWS IAM policy evaluation, even if an identity-based policy (such as AdministratorAccess) allows an action, it will be denied if it is not allowed by an active permissions boundary or if it is denied by an SCP, as both function as policy filters that set the maximum allowable permissions.

Step-by-Step Solution

Analyze the error message and the current permission configuration.

The deployment role has the AdministratorAccess policy but is still unauthorized to perform the lambda:CreateFunction action.

Since the identity-based policy grants full access, the restriction must originate from a policy type that acts as a guardrail, such as a permissions boundary or a Service Control Policy (SCP).

Check the IAM permissions boundary on the DeploymentRole.

Confirm whether a permissions boundary is attached to the role, and verify if it includes permissions for the lambda:CreateFunction action.

Permissions boundaries define the maximum permissions that an IAM entity can have. If the boundary does not allow the action, the action is denied even if AdministratorAccess is attached.

Check AWS Organizations Service Control Policies (SCPs) applied to the account.

Verify that no SCP at the Root, OU, or account level denies the lambda:CreateFunction action.

SCPs restrict permissions in member accounts. Any explicit deny in an SCP overrides account-level administrator permissions, causing authorization failures.

Key Concept

Understanding how policy evaluation logic handles administrator permissions when constrained by IAM permissions boundaries and AWS Organizations SCPs.

Question 158Question →

A developer is building a mobile application that authenticates users through an Amazon Cognito User Pool. The application then exchanges the user's JSON Web Token (JWT) for temporary AWS credentials using an Amazon Cognito Identity Pool. These credentials are used to sign requests to an Amazon API Gateway REST API using AWS Signature Version 4 (SigV4). However, the API Gateway method is configured with a Cognito User Pool Authorizer, and all signed requests are failing with a 401 Unauthorized error. How should the developer resolve this authorization failure?

Modify the API Gateway method's authorization type to AWS_IAM to allow authorization of requests signed with temporary IAM credentials.

Replace the Cognito User Pool Authorizer with a custom Lambda authorizer to parse and validate the AWS Signature Version 4 signature manually.

Configure the client application to send the Cognito Identity Pool ID directly in the Authorization header as a bearer token instead of using Signature Version 4 signing.

Initialize the API Gateway client in the mobile application by hardcoding the IAM role's permanent access key and secret key.

Show answer & explanation

Answer: Modify the API Gateway method's authorization type to AWS_IAM to allow authorization of requests signed with temporary IAM credentials.

Answer

Modify the API Gateway method's authorization type to AWS_IAM to allow authorization of requests signed with temporary IAM credentials.

Changing the API Gateway authorization type to AWS_IAM allows API Gateway to natively validate the Signature Version 4 (SigV4) headers. Since Cognito Identity Pools issue temporary IAM credentials associated with an IAM role (either authenticated or unauthenticated), the API Gateway method must be configured to use AWS_IAM authorization to allow access based on these IAM permissions.

Step-by-Step Solution

Analyze the request signing mechanism used by the client application.

The application uses temporary credentials from a Cognito Identity Pool to sign requests with AWS Signature Version 4 (SigV4).

Understanding how the request is signed helps determine which authorization type API Gateway expects.

Identify the authorization type currently configured on the API Gateway method.

The method is configured with a Cognito User Pool Authorizer.

A Cognito User Pool Authorizer expects a raw JWT (ID token or access token) from the User Pool in the headers, not a SigV4 signed request.

Update the API Gateway method authorization to match the client's credential type.

Change the authorization type to AWS_IAM.

AWS_IAM authorization allows API Gateway to natively process and authorize SigV4 signed requests using the IAM permissions of the assumed Cognito role.

Key Concept

Resolving Cognito User Pool vs. Identity Pool API Gateway Authorization failures by switching to AWS_IAM authorization for SigV4 signed requests.

Estimated Time:1m 30s

Question 159Question →

A client-side web application hosted on `https://portal.member-services.org` makes an HTTP `PUT` request to an Amazon API Gateway REST API. The API is integrated with a backend AWS Lambda function using Lambda Proxy integration. Users report that the updates fail. Inspecting the browser console reveals a CORS error stating that the `Access-Control-Allow-Origin` header is missing, while the API Gateway execution logs show a `502 Bad Gateway` error due to a malformed Lambda response. Which two actions should the developer take to resolve these errors?

Select all that apply

Configure the API Gateway resource to support CORS by enabling the OPTIONS method and returning the required CORS headers for preflight requests.

Update the backend Lambda function response payload to return a JSON object containing a statusCode, a body, and a headers map that includes the Access-Control-Allow-Origin header.

Add a CORS configuration policy containing the Access-Control-Allow-Origin header to the Amazon S3 bucket that hosts the client-side web application.

Configure the API Gateway Integration Request settings for the PUT method to inject the Access-Control-Allow-Origin header into the incoming request headers.

Switch the integration type to Lambda Custom Integration and configure a Gateway Response mapping template to format the string returned by the Lambda function.

Show answer & explanation

Answer: Configure the API Gateway resource to support CORS by enabling the OPTIONS method and returning the required CORS headers for preflight requests.; Update the backend Lambda function response payload to return a JSON object containing a statusCode, a body, and a headers map that includes the Access-Control-Allow-Origin header.

Answer

Configure the API Gateway resource to support CORS by enabling the OPTIONS method, and update the backend Lambda function response payload to return a JSON object containing a statusCode, a body, and a headers map that includes the Access-Control-Allow-Origin header.

The correct options are to configure the OPTIONS preflight method in API Gateway and update the backend Lambda function to return a structured JSON response containing the Access-Control-Allow-Origin header in its headers map. The preflight OPTIONS method handles the browser's initial handshake. Since Lambda Proxy integration is used, API Gateway passes the response directly from the Lambda function, requiring the function itself to return the necessary CORS headers and a valid format (statusCode, headers, and body) to avoid a 502 Bad Gateway error.

Step-by-Step Solution

Configure the preflight CORS OPTIONS method in API Gateway.

Allows browsers to complete the CORS preflight handshake before sending the actual PUT request.

Web browsers send a preflight OPTIONS request before non-simple requests like PUT to verify if the server permits cross-origin requests.

Modify the Lambda function response format to match Lambda Proxy requirements.

Ensures API Gateway can parse the Lambda response successfully and does not return a 502 Bad Gateway error.

In Lambda Proxy integrations, the Lambda function must return a JSON response with specific keys (statusCode, headers, and body). Returning a raw string or incorrect format causes a 502 error.

Include the Access-Control-Allow-Origin header in the Lambda function's response headers map.

Sends the CORS header back to the browser in the actual PUT response, satisfying the browser's CORS policy check.

With Lambda Proxy integrations, API Gateway passes the headers returned by the Lambda function directly to the client. The backend function is responsible for including the CORS headers in its response.

Key Concept

CORS troubleshooting and Lambda Proxy response formatting in Amazon API Gateway.

Question 160Question →

A developer is implementing a backend service integration for automated partner applications. The partner applications must programmatically upload raw telemetry data directly to an Amazon S3 bucket. The partners authenticate using their own enterprise OpenID Connect (OIDC) identity provider. The developer must ensure that these external applications obtain temporary AWS credentials with permission to write only to a specific folder in the S3 bucket without requiring long-lived IAM user credentials. Which TWO configuration steps should the developer perform to meet these requirements?

Select all that apply

Create and configure an Amazon Cognito identity pool, specifying the partner's OIDC provider as an authentication provider.

Associate an IAM role containing the required folder-level S3 write permissions with the authenticated identity role of the Cognito identity pool.

Create an Amazon Cognito user pool, register the OIDC provider, and use user pool groups to grant direct access to the S3 bucket.

Implement an Amazon API Gateway Lambda authorizer that generates temporary IAM credentials using AWS STS and returns them in the context object.

Generate long-lived IAM access keys for a partner service account and configure the partner applications to use these keys in their SDK calls.

Show answer & explanation

Answer: Create and configure an Amazon Cognito identity pool, specifying the partner's OIDC provider as an authentication provider.; Associate an IAM role containing the required folder-level S3 write permissions with the authenticated identity role of the Cognito identity pool.

Answer

Create and configure an Amazon Cognito identity pool with the external OIDC provider as an authentication provider, and associate an IAM role containing the required folder-level S3 write permissions with the authenticated identity role of the identity pool.

To access AWS resources directly from an external identity provider (such as an OIDC provider), Amazon Cognito identity pools are used to vend temporary AWS credentials. The client first authenticates with the OIDC provider, passes the token to the identity pool, and receives temporary AWS credentials mapped to an IAM role. This role must have a trust policy allowing the identity pool to assume it and an IAM policy with the necessary S3 folder permissions.

Step-by-Step Solution

Select Cognito Identity Pools instead of User Pools for AWS resource authorization.

Allows external users to exchange credentials.

Identity pools are designed specifically to vend temporary AWS credentials for direct resource access.

Configure the OIDC provider in the identity pool authentication settings.

Enables trust relationship between external OIDC token and AWS STS.

Allows AWS Cognito to validate identity tokens presented by the partner applications.

Define an IAM policy with targeted S3 write access and bind it to the IAM role mapped for authenticated users.

Enforces least-privilege folder-level access for the partner applications.

Ensures that the vended temporary credentials only permit uploading to the designated S3 folder.

Key Concept

Amazon Cognito Identity Pools (Federated Identities) for vending temporary AWS credentials to external OIDC-authenticated users.

Estimated Time:2m 0s

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