All practice questions

1542 questions

All types1,542 Multiple choice782 Multiple select746 Ordering14

A developer is building a document processing application that runs on an Amazon EC2 instance. The application needs to encrypt scanned PDF documents (each averaging $15\text{ MB}$ in size) before sending them to a third-party storage system. Security policy requires that the files be encrypted using client-side envelope encryption with an AWS KMS customer managed key.

Which TWO steps should the developer take to implement this encryption workflow?

Select all that apply

Call the GenerateDataKey API operation against the customer managed key to retrieve a plaintext data key and an encrypted data key.

Encrypt the PDF document locally using the plaintext data key, and then immediately remove the plaintext data key from memory.

Send the PDF documents directly to the AWS KMS Encrypt API operation to perform server-side encryption.

Call the GenerateDataKeyWithoutPlaintext API operation to obtain the encrypted key, and decrypt it locally using a public key pair.

Store the generated plaintext data key in AWS Systems Manager Parameter Store as a SecureString parameter for later decryption.

Show answer & explanation

Answer: Call the GenerateDataKey API operation against the customer managed key to retrieve a plaintext data key and an encrypted data key.; Encrypt the PDF document locally using the plaintext data key, and then immediately remove the plaintext data key from memory.

Answer

To implement client-side envelope encryption for files larger than

4\text{ KB}

, the developer should call GenerateDataKey to obtain a plaintext and encrypted data key, encrypt the file locally using the plaintext key, and then immediately destroy the plaintext key from memory. The encrypted data key is stored alongside the encrypted data.

The correct strategy involves calling the GenerateDataKey API operation to retrieve both a plaintext and an encrypted data key. The plaintext key is used to encrypt the

15\text{ MB}

document locally, and is then immediately deleted from memory to minimize exposure. The encrypted data key is stored with the ciphertext.

Step-by-Step Solution

Generate the data keys using AWS KMS.

The application calls the GenerateDataKey API operation, specifying the Customer Managed Key (CMK) ID, and receives a plaintext data key and an encrypted version of the data key.

This is required to obtain a unique key for symmetric local encryption while keeping the master CMK secure inside KMS.

Perform local client-side encryption.

The application uses the plaintext data key to encrypt the PDF document locally using a symmetric algorithm such as AES-256.

Because the PDF size (

15\text{ MB}

) exceeds the

4\text{ KB}

limit of direct KMS Encrypt API, the encryption must be performed client-side.

Secure memory and store the ciphertexts.

The plaintext data key is purged from memory, and the encrypted PDF document is stored alongside the encrypted data key.

This prevents memory exposure of the plaintext key and ensures the key can be recovered later by sending the encrypted data key back to KMS Decrypt.

Key Concept

AWS KMS client-side envelope encryption workflow

Question 1082Question →

A developer is optimizing a mobile news reader application that retrieves article metadata from an Amazon RDS MySQL database. When breaking news occurs, read traffic to the database spikes dramatically, causing latency issues. The article metadata is write-once and read-heavy. The developer wants to implement a caching solution using Amazon ElastiCache to mitigate database load, minimize memory usage by caching only the requested articles, and prevent the cache from running out of space.

Which TWO actions should the developer take to meet these requirements? (Select TWO.)

Select all that apply

Implement a lazy-loading (cache-aside) strategy where the application queries the cache first, and writes to the cache only after a database query on a cache miss.

Configure a Time to Live (TTL) on the cached keys and use a Least Recently Used (LRU) eviction policy.

Implement a write-through caching strategy that automatically writes all new articles to the cache whenever they are added to the database.

Store the query results in Systems Manager Parameter Store and enable automatic rotation of the cached values.

Deploy Amazon DynamoDB Accelerator (DAX) to cache the SQL query results and automatically evict cold data.

Show answer & explanation

Answer: Implement a lazy-loading (cache-aside) strategy where the application queries the cache first, and writes to the cache only after a database query on a cache miss.; Configure a Time to Live (TTL) on the cached keys and use a Least Recently Used (LRU) eviction policy.

Answer

To optimize the database queries while minimizing cache memory, the developer must implement a lazy-loading (cache-aside) caching strategy and configure a Time to Live (TTL) along with an LRU eviction policy.

Implementing a lazy-loading caching strategy is the best choice because the cache is only populated on demand (after a cache miss), which minimizes memory usage. Additionally, configuring a Time to Live (TTL) prevents stale metadata from being served, and using a Least Recently Used (LRU) eviction policy ensures that the least requested items are removed when cache capacity is reached, preventing out-of-memory issues.

Step-by-Step Solution

Analyze how cache population affects memory usage.

Lazy loading (cache-aside) is selected because it only populates the cache with articles that are actually requested by users, satisfying the memory optimization requirement.

This prevents unread articles from consuming memory space.

Address data expiration and capacity management.

Define a Time to Live (TTL) to allow stale news data to expire, and configure a Least Recently Used (LRU) eviction policy so the cache automatically discards the least accessed keys if memory capacity is reached.

This prevents the cache from running out of space under high load.

Identify and reject incompatible AWS services proposed in distractors.

Reject Systems Manager Parameter Store since it is a configuration and secret storage service rather than a caching engine. Reject DynamoDB Accelerator (DAX) because it only works with Amazon DynamoDB and cannot front Amazon RDS.

This guarantees that all architectural selections are technically compatible with RDS MySQL.

Key Concept

Selecting and configuring cache strategies (lazy-loading), TTL, and eviction policies using Amazon ElastiCache to reduce relational database load.

Estimated Time:2m 0s

Question 1083Question →

A developer wants to create an Amazon CloudWatch metric filter to count occurrences of the term 'AccessDenied' in a plain text log group. The developer attempts to use the following CloudWatch Logs Insights query syntax as the metric filter pattern:

`fields @message | filter @message like /AccessDenied/`

However, the metric is not being incremented even when 'AccessDenied' appears in the logs.

Which of the following is the correct explanation and resolution for this issue?

Metric filters do not support CloudWatch Logs Insights query syntax. The filter pattern should be changed to the literal string 'AccessDenied'.

Metric filters can only parse JSON-formatted logs. The developer must convert the application's logging library output to JSON format to use metric filters.

The metric filter pattern is correct, but the metric does not increment because the IAM execution role of the application generating the logs lacks the 'logs:StartQuery' permission.

The metric filter failed to process the logs because the log group's processing duration exceeded the default execution timeout of the underlying log parser.

Show answer & explanation

Answer: Metric filters do not support CloudWatch Logs Insights query syntax. The filter pattern should be changed to the literal string 'AccessDenied'.

Answer

Metric filters do not support CloudWatch Logs Insights query syntax. The filter pattern should be changed to the literal string 'AccessDenied'.

The correct answer is correct because CloudWatch Logs metric filters and CloudWatch Logs Insights are two distinct features with different syntaxes. Metric filters scan logs during ingestion using basic string matching patterns or JSON properties, and they do not understand the pipe-separated query syntax of Logs Insights. By changing the pattern to the simple string 'AccessDenied', the filter will correctly match any log line containing that term.

Step-by-Step Solution

Analyze the configured filter pattern syntax.

The developer configured the metric filter pattern with 'fields @message | filter @message like /AccessDenied/', which is a query string designed for CloudWatch Logs Insights.

Identifying the syntax type helps determine if it is compatible with the target service feature (Metric Filters).

Determine compatibility of Logs Insights query syntax with CloudWatch metric filters.

CloudWatch Logs metric filters do not support pipe-delimited query commands or the Logs Insights syntax. They support simple terms, phrases, or JSON object patterns.

Understanding the feature limitations explains why the current configuration is failing to match any log events.

Identify the correct syntax for a basic term match in plain text logs.

For a plain text log, to match a specific keyword, the metric filter pattern should be configured with the keyword itself (e.g., 'AccessDenied' or '"AccessDenied"').

Replacing the invalid query syntax with the correct metric filter pattern resolves the issue and allows the metric to increment.

Key Concept

CloudWatch Logs metric filters use a simple term-matching or JSON-matching syntax and do not support CloudWatch Logs Insights query syntax.

Question 1084Question →

A developer is using AWS CodeDeploy to deploy a Node.js web application to a fleet of Amazon EC2 instances. During the initial deployment run, the deployment fails.

The developer inspects the deployment console and identifies two root causes:
1. The CodeDeploy service is unable to interact with the EC2 instances to initiate the deployment.
2. A bash script specified in the `appspec.yml` file fails with an access denied error when attempting to retrieve database credentials from AWS Systems Manager Parameter Store.

The application's `appspec.yml` file is configured as follows:

yaml
version: 0.0
os: linux
files:
- source: /index.js
destination: /var/www/html/
hooks:
BeforeInstall:
- location: scripts/decrypt_creds.sh
timeout: 300
runas: dbadmin

Which two configurations must the developer implement to resolve these issues? (Select TWO.)

Select all that apply

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

Attach an IAM policy that grants ssm:GetParameters and ssm:GetParameter permissions to the IAM role associated with the EC2 instance profile.

Attach an IAM policy that grants ssm:GetParameters and ssm:GetParameter permissions directly to the CodeDeploy service role.

Change the hook in the appspec.yml file from BeforeInstall to BeforeAllowTraffic to execute the validation script before traffic shifting begins.

Migrate the credentials to AWS Secrets Manager, and grant the EC2 instance profile role permissions to retrieve them using the ssm:GetParameters policy action.

Show answer & explanation

Answer: Configure the trust policy of the CodeDeploy service role to allow the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action.; Attach an IAM policy that grants ssm:GetParameters and ssm:GetParameter permissions to the IAM role associated with the EC2 instance profile.

Answer

Configure the trust policy of the CodeDeploy service role to allow the codedeploy.amazonaws.com service principal to perform the sts:AssumeRole action, and attach an IAM policy that grants ssm:GetParameters and ssm:GetParameter permissions to the IAM role associated with the EC2 instance profile.

The CodeDeploy service role requires a trust policy allowing the codedeploy.amazonaws.com service principal to assume the role. This permits the service to perform deployment orchestration. When the CodeDeploy agent runs scripts defined under the hooks section on the EC2 instance, the script processes assume the identity of the EC2 instance profile. Therefore, to fetch parameters from the Systems Manager Parameter Store, the instance profile's associated role must have the ssm:GetParameters and ssm:GetParameter permission policies attached.

Step-by-Step Solution

Analyze CodeDeploy service permissions.

The CodeDeploy service itself requires an IAM service role to communicate with EC2 instances. The trust relationship for this service role must explicitly permit the codedeploy.amazonaws.com service principal to execute the sts:AssumeRole action.

This establishes trust between CodeDeploy and the IAM role, allowing the service to orchestrate deployments.

Determine the execution environment of AppSpec script hooks.

Scripts defined in the AppSpec hooks section run locally on target EC2 instances, executed by the CodeDeploy agent daemon.

This helps locate which IAM role requires permissions to query external AWS APIs during script runs.

Assign Parameter Store permissions to the correct entity.

Assign ssm:GetParameter and ssm:GetParameters to the EC2 instance profile role rather than the CodeDeploy service role.

Because the agent running on the EC2 instance executes the decrypt_creds.sh script locally, it uses the credentials supplied by the EC2 instance profile.

Key Concept

AWS CodeDeploy Service Role vs. EC2 Instance Profile Permissions

Question 1085Question →

A developer is writing an AWS CloudFormation template to deploy an application on Amazon EC2. The application requires two configurations: a database connection password that is sensitive and must be rotated automatically every 30 days, and an environment-specific application logging level (e.g., DEBUG or INFO) that is non-sensitive and updated frequently. Which configuration strategy should the developer implement in the template to meet these requirements securely and cost-effectively?

Store the database password in AWS Secrets Manager and reference it using a dynamic reference. Store the logging level in Systems Manager Parameter Store and reference it using a Parameter Store dynamic reference.

Store both the database password and the application logging level in AWS Secrets Manager, and reference both using Secrets Manager dynamic references.

Store both the database password and the application logging level in Systems Manager Parameter Store, and reference both using Parameter Store parameters with the SecureString type.

Deploy the EC2 instance using dummy values in the template, and then manually configure the password and logging level directly on the deployed resources after stack creation.

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and reference it using a dynamic reference. Store the logging level in Systems Manager Parameter Store and reference it using a Parameter Store dynamic reference.

Answer

The correct strategy is to store the sensitive database password requiring automatic rotation in AWS Secrets Manager and reference it via dynamic references, while using Systems Manager Parameter Store for the non-sensitive logging level configuration. This aligns with AWS security best practices and cost optimization recommendations.

Step-by-Step Solution

Identify the security and rotation requirements for the database password.

The database password is sensitive and requires automatic rotation every 30 days, which is a native feature of AWS Secrets Manager.

Secrets Manager provides secure storage, built-in rotation integration for databases, and dynamic reference integration with CloudFormation.

Identify the requirements for the application logging level setting.

The logging level is non-sensitive, changes frequently, and does not require rotation.

Systems Manager Parameter Store is designed for configuration data and is more cost-effective than Secrets Manager for non-sensitive data.

Select the correct CloudFormation referencing mechanisms for both resources.

Reference the database password using a Secrets Manager dynamic reference and the logging level using a Parameter Store dynamic reference.

This combined approach maximizes security for secrets while optimizing costs for non-sensitive parameters.

Key Concept

CloudFormation dynamic references for AWS Secrets Manager and Systems Manager Parameter Store

Question 1086Question →

A developer is troubleshooting a distributed application. The flow begins with an Amazon API Gateway HTTP API that integrates with an AWS Lambda function. The Lambda function performs some processing and sends an HTTP request to an internal Java-based microservice running on Amazon ECS on AWS Fargate behind an Application Load Balancer (ALB). The Java microservice then writes records to an Amazon DynamoDB table.

Active tracing is enabled on both the API Gateway and the Lambda function. However, in the AWS X-Ray console, the developer observes that:
1. The trace map shows the Lambda function's execution segment, but the Java microservice and the subsequent DynamoDB calls are represented as a separate, disconnected trace map.
2. The DynamoDB calls themselves are missing from the X-Ray service map entirely.

Which two actions should the developer take to resolve these issues and establish continuous, end-to-end trace propagation?

Select all that apply

In the Lambda function's code, ensure the outgoing HTTP client is instrumented with the AWS X-Ray SDK, or manually retrieve the current trace entity and inject the X-Amzn-Trace-Id header into the HTTP request sent to the ALB.

In the ECS task definition, add a container definition for the aws-xray-daemon, ensure the ECS task role has the xray:PutTraceSegments and xray:PutTelemetryRecords permissions, and configure the Java microservice's AWS SDK clients with the X-Ray SDK's TracingInterceptor.

Configure the ECS task execution role with the xray:PutTraceSegments permission, and configure the Java application to send tracing segments directly to the ALB's DNS name using the X-Ray daemon cluster-wide endpoint.

Change the API Gateway integration type to a Lambda custom integration, and configure a mapping template to extract the X-Amzn-Trace-Id header from API Gateway and pass it as a JSON payload property to the Lambda handler.

Increase the Lambda function's timeout and memory settings to allow the execution context to remain warm long enough for the X-Ray SDK to buffer and flush tracing segments to the daemon before the function container terminates.

Show answer & explanation

Answer: In the Lambda function's code, ensure the outgoing HTTP client is instrumented with the AWS X-Ray SDK, or manually retrieve the current trace entity and inject the X-Amzn-Trace-Id header into the HTTP request sent to the ALB.; In the ECS task definition, add a container definition for the aws-xray-daemon, ensure the ECS task role has the xray:PutTraceSegments and xray:PutTelemetryRecords permissions, and configure the Java microservice's AWS SDK clients with the X-Ray SDK's TracingInterceptor.

Answer

To establish end-to-end trace propagation, the Lambda function must propagate the X-Ray trace header (X-Amzn-Trace-Id) in its outgoing HTTP requests, and the ECS Fargate tasks must run the X-Ray daemon as a sidecar container with the correct IAM Task Role permissions while instrumenting downstream SDK calls.

The correct actions require propagating the trace header from the Lambda function and configuring the X-Ray daemon sidecar and SDK client in ECS Fargate. First, the Lambda function must send the trace context downstream by instrumenting the outgoing HTTP client to add the X-Amzn-Trace-Id header. Second, because Fargate is serverless, the X-Ray daemon cannot be run at the EC2 host level, so it must be added as a sidecar container in the task definition. The application's ECS task role must have permissions to upload the traces, and the AWS SDK clients inside the Java microservice must be instrumented with the TracingInterceptor to record the downstream DynamoDB calls.

Step-by-Step Solution

Identify the trace gap between the Lambda function and the downstream ECS microservice.

Determine that trace context propagation is missing over the custom HTTP client call to the ALB.

X-Ray context is not automatically propagated across custom HTTP boundaries unless the outgoing HTTP client is instrumented or the header is manually injected.

Determine the requirement for running the X-Ray daemon on AWS ECS Fargate.

Specify the X-Ray daemon container as a sidecar in the ECS Task Definition.

Because ECS Fargate does not allow host-level daemon execution, the daemon must run alongside the application in each task.

Identify the correct IAM role and permissions needed for the ECS container to publish traces.

Assign xray:PutTraceSegments and xray:PutTelemetryRecords to the ECS Task Role.

The Task Role gives permissions to the running application and sidecar containers, whereas the Task Execution Role is only used by the ECS agent for tasks like pulling images.

Instrument the downstream calls from the Java microservice to DynamoDB.

Configure the Java AWS SDK client with the X-Ray SDK's TracingInterceptor.

Without SDK client instrumentation, the AWS SDK calls are not monitored by X-Ray, causing DynamoDB segments to be missing from the trace.

Key Concept

AWS X-Ray distributed tracing context propagation across HTTP boundaries and daemon sidecar configuration on ECS Fargate.

Estimated Time:3m 0s

Question 1087Question →

A developer is using Docker Compose to locally test a Python application that uses the AWS SDK (Boto3) to retrieve secrets from AWS Secrets Manager. The application runs inside the container under a non-root user account named `appuser` (with home directory `/home/appuser`).

On the host workstation, the developer has configured the AWS CLI with a profile named `local-dev` that contains the necessary IAM permissions. The container fails to authenticate with AWS, raising a `ClientError` indicating that no credentials can be found. The current `docker-compose.yml` file contains the following volume mount:

yaml
volumes:
- ~/.aws:/root/.aws:ro

Which two actions must the developer take to resolve this issue and ensure Boto3 uses the correct credentials? (Select two.)

Select all that apply

Update the volume mount in the `docker-compose.yml` file to map the host's `~/.aws` directory to `/home/appuser/.aws:ro`.

Add the `AWS_PROFILE=local-dev` environment variable to the container's service environment block in the `docker-compose.yml` file.

Set the `AWS_PROFILE` environment variable to `local-dev` on the host workstation's shell before running `docker-compose up`.

Set the `AWS_SDK_LOAD_CONFIG=true` environment variable in the container and mount the credentials file to `/etc/aws/credentials:ro`.

Configure the AWS Secrets Manager resource policy to allow access from the container's local IP address using a `StringEquals` condition.

Show answer & explanation

Answer: Update the volume mount in the `docker-compose.yml` file to map the host's `~/.aws` directory to `/home/appuser/.aws:ro`.; Add the `AWS_PROFILE=local-dev` environment variable to the container's service environment block in the `docker-compose.yml` file.

Answer

Update the volume mount to target `/home/appuser/.aws:ro` and set the `AWS_PROFILE` environment variable to `local-dev` in the docker-compose file.

The correct actions are to update the volume mount to target `/home/appuser/.aws:ro` and to add the `AWS_PROFILE=local-dev` environment variable in the docker-compose file. Since the application runs under the `appuser` context, Boto3 searches `/home/appuser/.aws` for credentials. Additionally, `AWS_PROFILE` must be set in the container environment so the SDK knows to select the `local-dev` profile rather than falling back to `default`.

Step-by-Step Solution

Determine the executing user context within the container.

The application runs as `appuser`, which means Boto3 will look for config/credentials in `/home/appuser/.aws` instead of `/root/.aws`.

SDKs resolve credentials relative to the home directory of the current user executing the process.

Adjust the volume mounting path to match the user's home directory.

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

This makes the host's AWS profiles accessible to Boto3 running under the `appuser` account.

Ensure the container processes use the correct profile.

Define the `AWS_PROFILE` environment variable as `local-dev` in the container's environment definition.

By default, the SDK looks for the `default` profile. Defining the profile name via `AWS_PROFILE` forces the SDK to load the `local-dev` configuration.

Key Concept

Credential resolution in containerized environments relies on correct volume mounting to the active user's home directory and explicit passing of environment variables like AWS_PROFILE.

Question 1088Question →

A containerized Node.js application is deployed on Amazon ECS using the AWS Fargate launch type. The application processes incoming HTTP requests and offloads compute-heavy processing and downstream database writes to asynchronous worker threads using the Node.js worker_threads module. The application uses the AWS X-Ray SDK to capture traces. The developer has enabled the AWS X-Ray daemon in a sidecar container and initialized the SDK using AWSXRay.captureAWS(AWS). However, the application logs show 'SegmentNotFoundException: Failed to get the current sub/segment from the context' during DynamoDB writes inside the worker threads, and these downstream calls are missing from the X-Ray traces. Which action should the developer take to resolve this issue?

Initialize the DynamoDB client inside the worker thread by hardcoding temporary IAM credentials retrieved from a custom metadata endpoint, ensuring the worker thread has explicit write permissions for AWS X-Ray.

Increase the task-level CPU allocation and configure the client HTTP timeout setting in the AWS SDK configuration within the worker thread to prevent execution context expiration.

Extract the current tracing header in the parent thread using the X-Ray SDK, pass it to the worker thread, and manually initialize and set the segment context in the worker thread before invoking the DynamoDB client.

Increase the visibility timeout of the Amazon SQS queue that feeds tasks to the application to prevent the tracing context from being prematurely deleted from the queue before the worker thread executes.

Show answer & explanation

Answer: Extract the current tracing header in the parent thread using the X-Ray SDK, pass it to the worker thread, and manually initialize and set the segment context in the worker thread before invoking the DynamoDB client.

Answer

The correct action is to extract the current trace header from the parent thread and pass it to the worker thread. Because the AWS X-Ray SDK for Node.js uses continuation-local storage (CLS) to track the active trace context, this context is lost when spawning a new worker thread. The developer must manually pass the trace header string, instantiate a new segment/subsegment using this header in the worker thread, and set it as the active context using the SDK.

Step-by-Step Solution

Retrieve the trace header from the active segment in the main parent thread using the AWS X-Ray SDK.

The parent thread obtains the trace context string containing the trace ID, parent segment ID, and sampling decision.

The main thread has access to the continuation-local storage where the incoming request's trace context is automatically tracked.

Pass the trace header string as worker data when spawning the worker thread.

The worker thread receives the tracing metadata upon initialization.

Spawning a new thread creates a separate execution context, meaning context tracking via continuation-local storage is not shared by default.

In the worker thread, initialize a new segment or subsegment using the received trace header and set it as the active context using the X-Ray SDK.

The X-Ray SDK in the worker thread now has an active segment context populated in its thread-local storage.

This allows downstream AWS SDK clients in the worker thread to successfully associate their calls with the parent trace rather than throwing a SegmentNotFoundException.

Key Concept

Manual segment context propagation across asynchronous thread boundaries in the AWS X-Ray SDK.

Question 1089Question →

A developer is integrating a third-party SaaS monitoring platform with their company's AWS account. The SaaS platform runs in AWS Account $123456789012$ and needs to assume an IAM role in the developer's AWS Account $987654321098$ to retrieve CloudWatch metric data. To prevent the confused deputy problem, the SaaS platform requires the developer to configure an External ID of `SaaS-Monitor-99x`.

Which two actions must the developer perform to establish this cross-account access securely? (Select TWO.)

Select all that apply

Create an IAM role with a trust policy that allows the `sts:AssumeRole` action, designates the principal as `arn:aws:iam::123456789012:root`, and contains a condition block that checks if `sts:ExternalId` matches `SaaS-Monitor-99x`.

Attach an identity-based permissions policy to the IAM role that allows the `cloudwatch:GetMetricData` and `cloudwatch:ListMetrics` actions.

Create an IAM role with a trust policy that designates the principal as the AWS service principal `monitoring.amazonaws.com` and includes the External ID condition.

Configure a resource-based policy on the CloudWatch metric namespaces to allow the SaaS platform's IAM role to perform the `sts:AssumeRole` action.

Hardcode the AWS access keys of an IAM user created in the developer's account directly inside the SaaS platform's client configuration.

Show answer & explanation

Answer: Create an IAM role with a trust policy that allows the `sts:AssumeRole` action, designates the principal as `arn:aws:iam::123456789012:root`, and contains a condition block that checks if `sts:ExternalId` matches `SaaS-Monitor-99x`.; Attach an identity-based permissions policy to the IAM role that allows the `cloudwatch:GetMetricData` and `cloudwatch:ListMetrics` actions.

Answer

To securely configure cross-account access, the developer must create an IAM role with a trust policy that allows the `sts:AssumeRole` action for the external AWS account principal with a condition checking the External ID, and attach an identity-based permissions policy to the role that allows the necessary CloudWatch actions.

Establishing cross-account access for a third-party application requires creating an IAM role in the trusting account. The trust policy of this role must specify the external account ID as the principal and allow the `sts:AssumeRole` action. To prevent the confused deputy problem, a condition block must enforce the `sts:ExternalId` provided by the third-party. Additionally, the role itself must have an identity-based permissions policy attached to it that defines what AWS APIs the assumed role can call (specifically the CloudWatch metric retrieval APIs).

Step-by-Step Solution

Analyze the requirements for cross-account access and security constraints.

Identify that the third-party application operates in AWS Account

123456789012

, requires access to CloudWatch metrics in AWS Account

987654321098

, and requires the mitigation of the confused deputy problem using an External ID.

This establishes the parameters needed to configure the IAM role trust policy and permission policies.

Configure the trust policy of the IAM role to grant assume-role permission to the external account.

Define a trust policy allowing `sts:AssumeRole` with principal `arn:aws:iam::123456789012:root` and a condition block validating that `sts:ExternalId` is `SaaS-Monitor-99x`.

The trust policy establishes which entity can assume the role and validates the External ID to secure the delegation.

Configure the permissions policy of the IAM role to grant access to the required resources.

Define an identity-based policy allowing `cloudwatch:GetMetricData` and `cloudwatch:ListMetrics` actions, and attach it to the role.

The permissions policy defines the API operations the external entity is authorized to execute after assuming the role.

Key Concept

Establishing secure cross-account delegation via IAM roles, trust policies, and External IDs to prevent the confused deputy problem.

Question 1090Question →

A developer has a Python application deployed on Amazon ECS with the AWS Fargate launch type. The application is instrumented using the AWS X-Ray SDK for Python, with `patch_all()` invoked at startup. To improve request throughput, the application uses a `ThreadPoolExecutor` from the `concurrent.futures` module to perform downstream HTTP requests using the `requests` library and write operations to Amazon DynamoDB in parallel worker threads. The X-Ray daemon runs as a sidecar container in the ECS task. When analyzing traces in the AWS X-Ray console, the developer observes that downstream HTTP calls and DynamoDB operations executed within the worker threads are not associated with the main request trace, showing up as separate traces or missing entirely. Which of the following actions should the developer take to resolve this tracing correlation issue?

Set the environment variable `AWS_XRAY_CONTEXT_MISSING` to `IGNORE_ERROR` in the ECS task definition to allow the X-Ray recorder to automatically link detached threads to the parent execution segment.

Retrieve the active trace entity in the parent thread using `xray_recorder.get_trace_entity()`, pass this entity to the worker thread, and call `xray_recorder.set_trace_entity(entity)` inside the worker thread before making the downstream calls.

Initialize the AWS SDK clients within the worker threads using hardcoded IAM access keys and secret keys to authenticate the connection to the X-Ray daemon.

Increase the visibility timeout of the input source queue to ensure that worker threads finish executing and have enough time to flush the local segment buffers to the daemon.

Show answer & explanation

Answer: Retrieve the active trace entity in the parent thread using `xray_recorder.get_trace_entity()`, pass this entity to the worker thread, and call `xray_recorder.set_trace_entity(entity)` inside the worker thread before making the downstream calls.

Answer

The AWS X-Ray SDK for Python stores the tracing context (the current segment or subsegment) in thread-local storage. When the application spawns new threads using a thread pool, the active context is lost because the new thread has its own empty thread-local storage. To resolve this, the active trace entity must be retrieved from the parent thread via `xray_recorder.get_trace_entity()`, passed to the worker thread, and set as the active context using `xray_recorder.set_trace_entity(entity)`. This ensures that downstream HTTP calls and AWS SDK operations executed in the worker threads are correctly attached as subsegments to the parent trace.

Step-by-Step Solution

Identify why tracing context is lost across threads in the AWS X-Ray SDK for Python.

The SDK uses thread-local storage by default, meaning new threads generated by a thread pool executor do not inherit the parent thread's tracing context.

Understanding thread-local storage helps identify why subsegments generated in child threads appear as orphaned or missing.

Determine the mechanism to pass and set the tracing context across threads.

Retrieve the trace entity from the parent thread with `xray_recorder.get_trace_entity()` and set it in the child thread using `xray_recorder.set_trace_entity(entity)`.

Explicitly setting the trace entity on the child thread's recorder links all subsequent HTTP requests and SDK operations in that thread to the main segment.

Key Concept

X-Ray context propagation in multi-threaded environments

Estimated Time:2m 0s

Question 1091Question →

A developer has deployed a Node.js-based AWS Lambda function that retrieves user profiles from an Amazon RDS PostgreSQL database. To minimize latency, the database connection client is declared and initialized globally outside the handler function. During load testing with high request volumes, the function performs correctly. However, during periods of low traffic, subsequent requests fail with database connection errors, causing the Lambda function to time out. Which of the following is the most likely cause of this issue?

The Lambda function is configured to run in a private subnet, preventing it from reaching the database endpoint in another subnet without routing through a NAT Gateway.

The function is attempting to reuse a database connection that was established during a previous container execution and has since been closed by the database due to idle timeout.

The IAM execution role assigned to the Lambda function lacks a trust policy that allows the Amazon RDS database service to assume the role.

The function retrieves database credentials from Systems Manager Parameter Store, which does not support caching parameters during container reuse, leading to authentication failures.

Show answer & explanation

Answer: The function is attempting to reuse a database connection that was established during a previous container execution and has since been closed by the database due to idle timeout.

Answer

The Lambda function is attempting to reuse a database connection that was initialized outside the handler function but has since been terminated by the database due to inactivity.

The correct option identifies that the global database client is reused during warm starts. Because of the low-traffic period, the database terminates the idle connection, leaving a stale connection object in the Lambda execution environment. Subsequent handler invocations attempt to reuse this dead connection, causing timeouts.

Step-by-Step Solution

Analyze the scope of the database connection client declaration in the function code.

The client is declared globally outside the handler function.

Variables declared outside the handler persist across warm starts due to execution environment reuse.

Identify the behavior difference between high-traffic load testing and low-traffic periods.

High-traffic requests succeed because the connection remains active, whereas low-traffic periods allow the database to terminate the idle connection.

Amazon RDS PostgreSQL has default idle connection timeout configurations that terminate inactive TCP connections.

Determine the failure mechanism during the subsequent execution.

The Lambda function attempts to execute query commands over the stale socket, leading to socket hang-ups or TCP timeout errors.

Since the connection client is not re-validated or re-initialized inside the handler, the dead connection is reused.

Key Concept

AWS Lambda execution environment reuse and global variable persistence (warm starts)

Question 1092Question →

A developer is building a serverless e-learning application where students log in using an Amazon Cognito User Pool. The application's frontend client needs to access course content through an Amazon API Gateway REST API. The developer needs to secure the API so that only authenticated students can access the resource, verifying their identity directly via their login session tokens. Which solution should the developer implement to meet these requirements with the least operational overhead?

Create a Lambda authorizer in API Gateway that decodes the incoming token, makes an API call to Cognito User Pools to validate it, and returns an IAM policy.

Create an Amazon Cognito User Pool authorizer in API Gateway, configure it with the student User Pool, and set the API method authorization to use this authorizer.

Create an Amazon Cognito Identity Pool authorizer in API Gateway, configure it with the student identity provider, and set the API method authorization to use this authorizer.

Create a Lambda Proxy integration in API Gateway, configure a method execution mapping to validate Cognito tokens, and pass the claims in the request template.

Show answer & explanation

Answer: Create an Amazon Cognito User Pool authorizer in API Gateway, configure it with the student User Pool, and set the API method authorization to use this authorizer.

Answer

Create an Amazon Cognito User Pool authorizer in API Gateway, configure it with the student User Pool, and set the API method authorization to use this authorizer.

API Gateway natively supports Amazon Cognito User Pools authorizers, allowing developers to secure REST APIs by validating user identity tokens directly against the configured User Pool. This requires zero custom code, minimizing development and operational overhead.

Step-by-Step Solution

Analyze the authentication provider and target API structure.

The application uses Amazon Cognito User Pools for directory management and login token generation, and accesses resources via an API Gateway REST API.

Understanding the source of credentials is critical to choosing the correct authorization path.

Evaluate native verification capabilities of API Gateway.

API Gateway natively supports Cognito User Pools authorizers, which validate JSON Web Tokens (JWTs) automatically.

Using a native feature eliminates the need to develop, test, and pay for custom code execution.

Select the option that configures the native authorizer on API Gateway.

Configuring the API method to use the Cognito User Pools authorizer meets the security requirement with the least operational overhead.

This avoids custom Lambda code or the credential exchange overhead associated with Cognito Identity Pools.

Key Concept

API Gateway native Cognito User Pool authorizer integration

Question 1093Question →

A developer is hosting a single-page web application in an Amazon S3 bucket. The application makes API calls to an Amazon API Gateway endpoint that is integrated with a Lambda function using Lambda Proxy integration. During testing, the browser console displays a CORS error stating that the preflight request was blocked because the Access-Control-Allow-Origin header is missing. Which two steps must the developer take to resolve this CORS error? (Select TWO.)

Select all that apply

Configure the API Gateway resource to handle the preflight OPTIONS request and return the Access-Control-Allow-Origin header.

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

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

Change the Lambda function to return a plain text string with the headers instead of a structured JSON response.

Deploy a custom Lambda authorizer to generate and inject the Access-Control-Allow-Origin header into the client request.

Show answer & explanation

Answer: Configure the API Gateway resource to handle the preflight OPTIONS request and return the Access-Control-Allow-Origin header.; Modify the backend Lambda function to include the Access-Control-Allow-Origin header in its response JSON object.

Answer

Configure the API Gateway resource to handle the preflight OPTIONS request and modify the backend Lambda function to include the Access-Control-Allow-Origin header in its response JSON object.

To resolve CORS errors when using Amazon API Gateway with Lambda Proxy integration, two actions are required: enabling CORS on the API Gateway resource to handle the OPTIONS preflight request, and modifying the backend Lambda function to return the Access-Control-Allow-Origin header in its response JSON object.

Step-by-Step Solution

Identify the source of the preflight failure.

Recognize that the browser initiates an OPTIONS preflight request before sending the actual API request.

Before sending non-simple HTTP requests, browsers perform preflight checks to verify allowed origins.

Configure the OPTIONS method response in API Gateway.

Enable CORS on the API Gateway resource to return the Access-Control-Allow-Origin header for the preflight OPTIONS request.

This satisfies the browser's preflight requirements.

Configure the backend response headers.

Update the Lambda function's JSON payload response to include 'Access-Control-Allow-Origin' under the 'headers' object.

For Lambda Proxy integrations, API Gateway does not modify the backend response, requiring the Lambda function to supply the CORS header directly.

Key Concept

Cross-Origin Resource Sharing (CORS) resolution in API Gateway Lambda Proxy integrations requires both the preflight OPTIONS response from API Gateway and the custom origin headers returned by the Lambda function.

Estimated Time:1m 0s

Question 1094Question →

A developer is troubleshooting a hotel reservation system. A backend microservice runs an AWS Lambda function that processes booking requests. The function is configured to connect to an Amazon Aurora PostgreSQL database deployed in private subnets within a custom VPC. After successfully updating the database, the function makes an HTTPS call to a third-party SMS gateway to send confirmation messages. During testing, database updates succeed, but the Lambda function execution fails. The Amazon CloudWatch logs show that the HTTPS request to the external SMS gateway times out, leading to a function-level timeout error: `Task timed out after $15.03$ seconds`. The VPC configurations are as follows: the Lambda function is associated with the same private subnets as the Aurora database; an Internet Gateway is attached to the VPC; the route tables for the private subnets have a default route ( $0.0.0.0/0$ ) pointing directly to the Internet Gateway; and the security group associated with the Lambda function allows all outbound traffic ( $0.0.0.0/0$ ). Which two actions should the developer take to resolve this network connectivity issue?

Select all that apply

Deploy a NAT Gateway in a public subnet of the VPC.

Update the route table of the private subnets to direct traffic destined for

0.0.0.0/0

to the NAT Gateway.

Move the Lambda function configuration to use the public subnets of the VPC that have a direct route to the Internet Gateway.

Enable the public IP mapping configuration on the Elastic Network Interfaces (ENIs) created by the Lambda function.

Increase the Lambda function timeout configuration to

15

minutes to accommodate the connection attempts.

Show answer & explanation

Answer: Deploy a NAT Gateway in a public subnet of the VPC.; Update the route table of the private subnets to direct traffic destined for $0.0.0.0/0$ to the NAT Gateway.

Answer

To resolve the network connectivity issue, the developer must deploy a NAT Gateway in a public subnet and update the route tables of the private subnets containing the Lambda function to route outbound internet traffic through the NAT Gateway.

The correct response is to deploy a NAT Gateway in a public subnet and update the private subnet route tables to direct internet-bound traffic (

0.0.0.0/0

) to the NAT Gateway. Lambda functions deployed within a VPC must run in private subnets to access VPC resources like databases. Because Lambda ENIs lack public IP addresses, they cannot communicate with the internet directly via an Internet Gateway. A NAT Gateway situated in a public subnet acts as a bridge, translating the private IP traffic to a public IP and forwarding it to the Internet Gateway.

Step-by-Step Solution

Analyze the network route requirements of the Lambda function.

The function requires private connectivity to the Aurora database and public connectivity to the third-party SMS gateway.

This determines that both internal VPC and external internet routing paths must be established.

Identify why the direct Internet Gateway route fails for the Lambda function.

Lambda functions in a VPC do not get assigned public IP addresses, meaning they cannot directly use an Internet Gateway even if associated with a public subnet or if a route exists.

This rule explains why the current configuration fails to connect to the external API.

Deploy a NAT Gateway to enable private-to-public network address translation.

A NAT Gateway is created in a public subnet, which has a route to the Internet Gateway.

The NAT Gateway acts as an intermediary that translates private traffic to a public IP.

Configure the private subnets to route outbound traffic through the NAT Gateway.

The route table for the private subnets where the Lambda function resides is updated to direct

0.0.0.0/0

traffic to the NAT Gateway.

This directs the Lambda function's external internet traffic correctly, resolving the timeouts.

Key Concept

Configuring VPC routing and NAT Gateways for AWS Lambda to access external internet endpoints

Estimated Time:2m 0s

Question 1095Question →

A developer is creating an IAM role for an AWS Lambda function that needs to write logs to an Amazon S3 bucket named "my-app-logs-bucket". The developer has written the following permissions policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::my-app-logs-bucket/*"
}
]
}

Which two configuration steps must the developer perform to ensure the Lambda function has the necessary permissions to write to the S3 bucket?

Select all that apply

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

Attach the S3 permissions policy to the IAM role that is associated with the Lambda function.

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

Embed the IAM user access key and secret access key directly in the Lambda function code to authorize the S3 client.

Define the s3:PutObject action inside the principal block of the trust policy document.

Show answer & explanation

Answer: Configure the trust policy of the IAM role to allow the lambda.amazonaws.com service principal to perform the sts:AssumeRole action.; Attach the S3 permissions policy to the IAM role that is associated with the Lambda function.

Answer

Configure the trust policy of the IAM role to allow the lambda.amazonaws.com service principal to perform the sts:AssumeRole action, and attach the permissions policy to the IAM role associated with the Lambda function.

To allow an AWS Lambda function to access S3 resources using an IAM role, two components are required: a permissions policy attached to the role that allows the s3:PutObject action, and a trust policy configured on the role that allows the Lambda service (lambda.amazonaws.com) to assume the role (sts:AssumeRole).

Step-by-Step Solution

Identify the entity assuming the role.

The Lambda service principal (lambda.amazonaws.com) needs to run the function and obtain temporary credentials.

This determines the trust policy configuration allowing sts:AssumeRole.

Identify where permissions are attached.

The permissions policy allowing s3:PutObject must be attached to the execution role.

This grants the assumed role the authority to write to the S3 bucket.

Key Concept

IAM execution roles require both a trust policy allowing the service to assume the role and permissions policies granting access to destination resources.

Question 1096Question →

A developer is configuring a blue/green deployment for an Amazon Elastic Container Service (Amazon ECS) service using AWS CodeDeploy. The deployment must shift traffic to the new task set gradually to allow for monitoring, but the entire deployment process must finish shifting $100\%$ of the traffic in less than $10$ minutes.

Which TWO predefined deployment configurations will meet these requirements? (Select TWO.)

Select all that apply

CodeDeployDefault.ECSLinear10PercentEvery1Minute

CodeDeployDefault.ECSCanary10Percent5Minutes

CodeDeployDefault.ECSLinear10PercentEvery3Minutes

CodeDeployDefault.ECSCanary10Percent15Minutes

CodeDeployDefault.ECSAllAtOnce

Show answer & explanation

Answer: CodeDeployDefault.ECSLinear10PercentEvery1Minute; CodeDeployDefault.ECSCanary10Percent5Minutes

Answer

The configurations CodeDeployDefault.ECSLinear10PercentEvery1Minute and CodeDeployDefault.ECSCanary10Percent5Minutes meet the requirements.

The correct configurations are CodeDeployDefault.ECSLinear10PercentEvery1Minute and CodeDeployDefault.ECSCanary10Percent5Minutes. The linear configuration shifts

10\%

of traffic each minute, completing the transition in

9

minutes. The canary configuration shifts

10\%

first, waits

5

minutes, and then shifts the remaining

90\%

, completing the transition in

5

minutes. Both configurations satisfy the requirements of shifting traffic gradually and completing the deployment in less than

10

minutes.

Step-by-Step Solution

Analyze the requirement to shift traffic gradually.

Discard the all-at-once configuration since it shifts traffic immediately and does not allow for gradual transition or monitoring.

Gradual shifting is a strict constraint specified in the prompt.

Calculate the total traffic shifting duration for each remaining configuration.

The 1-minute linear configuration takes

9

minutes, the 5-minute canary configuration takes

5

minutes, the 3-minute linear configuration takes

27

minutes, and the 15-minute canary configuration takes

15

minutes.

This determines which configurations complete within the required 10-minute window.

Select the configurations that meet the duration constraint.

The 1-minute linear configuration and the 5-minute canary configuration both complete in less than

10

minutes.

Only these two configurations satisfy both the gradual shifting and the time constraint of less than 10 minutes.

Key Concept

AWS CodeDeploy ECS Deployment Configurations

Question 1097Question →

A developer has a Java application running on Amazon EC2 instances. The developer has instrumented the application code using the AWS X-Ray SDK to trace incoming HTTP requests and downstream AWS service calls. However, no trace data is appearing in the AWS X-Ray console. Which TWO actions must the developer take to ensure that trace data is successfully sent to AWS X-Ray?

Select all that apply

Install and run the AWS X-Ray daemon on the EC2 instances.

Attach an IAM role with the AWSXrayWriteOnlyAccess policy to the EC2 instances.

Configure the AWS SDK client in the code by hardcoding the credentials of an IAM user with X-Ray permissions.

Increase the visibility timeout of the Amazon SQS queue that triggers the application to allow enough time for tracing.

Configure Amazon API Gateway to use a Lambda custom integration to proxy the trace data to the EC2 instances.

Show answer & explanation

Answer: Install and run the AWS X-Ray daemon on the EC2 instances.; Attach an IAM role with the AWSXrayWriteOnlyAccess policy to the EC2 instances.

Answer

To successfully send trace data to AWS X-Ray from Java applications on EC2, the developer must install and run the AWS X-Ray daemon on the EC2 instances and attach an IAM role with the AWSXrayWriteOnlyAccess policy to the EC2 instances.

For an application running on Amazon EC2 to send trace segments to AWS X-Ray, the X-Ray daemon must be installed and running on the EC2 instance to listen on UDP port 2000. Additionally, the instance must have permission to upload trace data, which is provided by attaching an IAM role with the AWSXrayWriteOnlyAccess policy to the EC2 instance.

Step-by-Step Solution

Enable tracing daemon on the host.

The AWS X-Ray daemon is running on the EC2 instances, listening on UDP port 2000 for trace data sent by the SDK.

The X-Ray SDK sends trace segments to the daemon, which buffers and uploads them to the X-Ray service in batches.

Configure instance permissions.

An IAM role with the AWSXrayWriteOnlyAccess policy is attached to the EC2 instances.

The daemon running on the EC2 instances needs authorization to call the X-Ray API to write trace data.

Key Concept

AWS X-Ray EC2 configuration requires both the X-Ray daemon running on the host and an IAM instance profile with write permissions to send trace segments to the X-Ray API.

Estimated Time:1m 30s

Question 1098Question →

A developer is maintaining a continuous delivery pipeline in AWS CodePipeline that consists of Source, Build, and Deploy stages. The Deploy stage uses AWS CodeDeploy to release updates to an Amazon ECS service. The developer needs to temporarily prevent new builds from being deployed to ECS while the production database undergoes a scheduled maintenance window. However, developers must still be able to commit code changes, and the pipeline must continue to run the Source and Build stages to validate the builds. Which configuration change should the developer make to achieve this goal with the least administrative effort?

Modify the trust policy of the CodePipeline service role to remove the AssumeRole permission for the CodeDeploy service principal.

Configure the AWS Systems Manager Parameter Store with a boolean flag, and update the ECS task definition to retrieve this parameter and abort the container startup during maintenance.

Disable the transition from the Build stage to the Deploy stage in the CodePipeline console.

Modify the ECS Task Execution Role to temporarily remove permission to pull the container image from Amazon ECR.

Show answer & explanation

Answer: Disable the transition from the Build stage to the Deploy stage in the CodePipeline console.

Answer

Disable the transition from the Build stage to the Deploy stage in the CodePipeline console.

Disabling the transition between stages in AWS CodePipeline prevents new executions from entering the target stage (Deploy) while allowing preceding stages (Source, Build) to complete successfully. The pipeline execution stops at the boundary, and once the maintenance is complete, the transition can be re-enabled to allow the latest build artifact to progress to the Deploy stage automatically.

Step-by-Step Solution

Identify the requirement to pause deployments at a specific stage while allowing earlier stages (Source, Build) to continue execution.

Determine that stopping the entire pipeline or causing errors in subsequent stages is undesirable.

The requirement states that developers must still commit code and runs must occur in the Source and Build stages.

Evaluate CodePipeline's built-in control mechanisms.

Recognize that stage transitions can be disabled to prevent executions from moving from one stage to another.

Disabling transitions is a native feature that cleanly halts the pipeline progress at a boundary without failing the running execution or the pipeline itself.

Configure the transition control in the AWS Management Console or via the AWS CLI.

Disable the transition between the Build and Deploy stages, and re-enable it after the database maintenance is complete.

This satisfies the requirement with the least administrative effort and without altering IAM roles or application logic.

Key Concept

AWS CodePipeline Stage Transitions

Question 1099Question →

A developer is deploying a Python application to AWS Elastic Beanstalk. The application needs to retrieve two values: a connection string password for a self-hosted PostgreSQL database running on an Amazon EC2 instance (which must be rotated every 45 days), and a payment gateway API endpoint URL (which is non-sensitive and static). To meet these requirements with the lowest cost and operational effort, which two configuration steps should the developer perform? (Select TWO.)

Select all that apply

Store the database password in AWS Secrets Manager and configure an AWS Lambda function to rotate the database credential on a 45-day schedule.

Store the payment gateway API endpoint URL in AWS Systems Manager Parameter Store as a String parameter.

Store the database password in AWS Systems Manager Parameter Store as a SecureString parameter and enable the built-in Parameter Store auto-rotation feature.

Hardcode the database password in the application code and use the AWS SDK to decrypt the value during the EC2 instance initialization.

Store both the database password and the payment gateway API endpoint URL in AWS Secrets Manager to centralize credentials and configurations.

Show answer & explanation

Answer: Store the database password in AWS Secrets Manager and configure an AWS Lambda function to rotate the database credential on a 45-day schedule.; Store the payment gateway API endpoint URL in AWS Systems Manager Parameter Store as a String parameter.

Answer

Store the database password in AWS Secrets Manager with a Lambda rotation function, and store the non-sensitive payment gateway URL in AWS Systems Manager Parameter Store.

AWS Secrets Manager is designed for storing sensitive data like database passwords and supports automatic rotation using AWS Lambda. On the other hand, Systems Manager Parameter Store is a cost-effective service for storing non-sensitive configuration data such as API endpoint URLs, which do not change frequently and do not require rotation.

Step-by-Step Solution

Analyze the security and rotation requirements for the database password.

The password is a sensitive credential and must be rotated automatically every 45 days. AWS Secrets Manager is the appropriate service because it supports automatic rotation schedules and integration with Lambda for rotating self-hosted databases.

Parameter Store does not natively support automatic rotation schedules.

Analyze the storage requirements for the payment gateway API endpoint URL.

The URL is non-sensitive and static. AWS Systems Manager Parameter Store is the most cost-effective and appropriate service for storing simple, non-sensitive configuration data.

Secrets Manager is more expensive and unnecessary for non-sensitive data.

Combine the decisions into the correct configuration steps.

Store the database password in Secrets Manager with Lambda rotation, and store the API URL in Parameter Store.

This combination ensures security compliance for the password and cost-efficiency for the configuration data.

Key Concept

Differentiating between AWS Secrets Manager and Systems Manager Parameter Store based on secrets rotation requirements and cost-efficiency.

Question 1100Question →

A frontend Single Page Application (SPA) hosted at `https://dashboard.company.local` makes a cross-origin `POST` request to an Amazon API Gateway REST API configured with a Lambda Proxy Integration. In the browser developer tools, the developer observes that the preflight `OPTIONS` request succeeds with a `200 OK` status code, but the subsequent `POST` request is blocked. The browser console displays: `Access-Control-Allow-Origin 'https://dashboard.company.local' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource`. Additionally, the network tab shows that the `POST` request received a `502 Bad Gateway` status code from API Gateway. Which of the following is the most accurate explanation for this behavior, and what corrective actions should the developer take to resolve both issues?

The Lambda function returned a response payload that does not conform to the required JSON format for Lambda Proxy Integration, causing API Gateway to generate a default 502 Bad Gateway response that lacks the necessary CORS headers. The developer must update the Lambda function to return a structured JSON response containing statusCode, headers (including Access-Control-Allow-Origin), and body, and configure CORS headers on the API Gateway Gateway Responses for 5XX errors.

The CORS headers were only configured on the mock OPTIONS method in API Gateway, which does not propagate to the actual POST integration. The developer must change the integration type to Lambda Custom Integration, configure a custom Integration Response to map CORS headers from the Lambda response, and enable CORS on the S3 bucket hosting the client SPA.

The Lambda function is returning a raw string response because it is configured with Lambda Custom Integration, which requires the frontend to send custom preflight parameters. The developer should change the integration type to Lambda Proxy Integration because proxy integrations automatically inject the required Access-Control-Allow-Origin headers on behalf of the backend Lambda function.

The request failed authentication at the API Gateway level because the custom Lambda Authorizer returned an invalid or expired IAM policy, triggering a 502 error. The developer must modify the Lambda Authorizer to return a policy that allows the OPTIONS method and configure the authorizer to bypass CORS validation for cross-origin client apps.

Show answer & explanation

Answer: The Lambda function returned a response payload that does not conform to the required JSON format for Lambda Proxy Integration, causing API Gateway to generate a default 502 Bad Gateway response that lacks the necessary CORS headers. The developer must update the Lambda function to return a structured JSON response containing statusCode, headers (including Access-Control-Allow-Origin), and body, and configure CORS headers on the API Gateway Gateway Responses for 5XX errors.

Answer

The correct response accurately explains that a 502 Bad Gateway error occurs when the Lambda function output does not conform to the expected schema for Lambda Proxy Integration. Because API Gateway generates this 502 response itself, it bypasses the integration response headers. To fix this, the developer must ensure the Lambda function returns a properly formatted JSON object with 'statusCode', 'headers' (including the 'Access-Control-Allow-Origin' header), and a stringified 'body'. Additionally, to prevent future API Gateway-generated errors from being blocked by CORS, Gateway Responses for 5XX errors must be configured to return the CORS headers.

Step-by-Step Solution

Inspect CloudWatch Logs for the Lambda function backend.

Identify any formatting errors in the returned payload or unhandled exceptions that prevent Lambda from returning the expected JSON structure.

API Gateway generates a 502 Bad Gateway error when the backend Lambda function output does not match the expected structure required by the Lambda Proxy Integration.

Format the Lambda function's return object according to Lambda Proxy Integration specifications.

Ensure the response dictionary contains 'statusCode', 'body' (as a string), and 'headers' (containing 'Access-Control-Allow-Origin').

Under Lambda Proxy Integration, API Gateway expects the backend code to explicitly define the CORS headers in its response payload.

Configure CORS headers on Gateway Responses for 5XX and 4XX errors in API Gateway.

Ensure that if API Gateway itself encounters an error (e.g., Lambda timeout or gateway error), the browser receives the correct Access-Control-Allow-Origin header to avoid CORS errors masking the HTTP error code.

Default gateway-generated errors do not contain CORS headers unless they are configured in Gateway Responses.

Key Concept

API Gateway Lambda Proxy Integration response format and CORS troubleshooting

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