Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company has an ecommerce web application that uses an on-premises MySQL database as a data store. The company migrates the on-premises MySQL database to Amazon RDS for MySQL.
A developer needs to configure the application's access to the RDS for MySQL datab...
To meet the requirement of configuring the application's access to the Amazon RDS for MySQL database without using long-term credentials, let's evaluate each option based on the key factors:
Option A: Enable IAM database authentication on the RDS for MySQL DB instance. Create an IAM role that has the minimum required permissions. Assign the role to the application.
- Why it is selected: IAM database authentication allows the application to authenticate to the RDS for MySQL instance using temporary credentials, which eliminates the need for long-term credentials. This option is specifically designed to provide a secure and scalable method of database access, leveraging AWS IAM for authentication.
- Why other options are rejected:
- Option B (Secrets Manager): While AWS Secrets Manager securely stores credentials and provides temporary access to them, this solution still involves retrieving the credentials (user/password) and using them within the application. Although not long-term cr...
Author: Amelia · Last updated May 18, 2026
A developer is creating an application that must transfer expired items from Amazon DynamoDB to Amazon S3. The developer sets up the DynamoDB table to automatically delete items after a specific TTL. The application must process the items in DynamoDB and then must store the expired items in Amazon S3. The entire process, including it...
Let's evaluate each option based on the key factors such as operational overhead, ease of implementation, scalability, and the specific requirements (processing expired items and storing them in Amazon S3 within 5 minutes):
Option A: Configure DynamoDB Accelerator (DAX) to query for expired items based on the TTL. Save the results to Amazon S3.
- Why it is rejected: DAX is an in-memory caching layer for DynamoDB that accelerates read-heavy workloads. However, it does not provide a mechanism to automatically process expired items from DynamoDB or store them in S3. DAX is primarily used to speed up queries rather than automate the handling of TTL-based expirations. This option would still require additional development effort to monitor and query for expired items, adding unnecessary complexity.
Option B: Configure DynamoDB Streams to invoke an AWS Lambda function. Program the Lambda function to process the items and to store the expired items in Amazon S3.
- Why it is rejected: DynamoDB Streams can capture changes to DynamoDB tables, including deletions, but it does not directly capture items that expire due to TTL. Since expired items are automatically deleted by DynamoDB when their TTL expires, they would not appear in DynamoDB Streams. This solution would require a workaround to detect expired items, adding complexity and not aligning with the requirement for low operational overhead.
Option C: Deploy a custom application on an A...
Author: Ahmed · Last updated May 18, 2026
A developer has an application that uses WebSocket APIs in Amazon API Gateway. The developer wants to use an API Gateway Lambda authorizer to control access to the application.
The developer needs to add credential caching and reduce repeated usage of secret keys and authorization...
To meet the requirements of using a Lambda authorizer with WebSocket APIs in Amazon API Gateway while adding credential caching to reduce repeated usage of secret keys and authorization tokens, we need to carefully configure the authorizer and ensure that tokens can be efficiently cached.
Let's analyze each option:
Option A: Use a token-based Lambda authorizer.
- Why this is selected: A token-based Lambda authorizer is a suitable choice for WebSocket APIs in API Gateway. This type of authorizer uses a token (typically a JWT or OAuth token) provided in the request header. The authorizer can validate the token and then return an IAM policy. One of the key benefits of using a token-based authorizer is that API Gateway supports credential caching for token-based authorizers, which reduces repeated checks against the token for each new request, improving performance.
- Key factor: Token-based Lambda authorizers are ideal for caching credentials and reducing the overhead of repeated authorization token checks.
Option B: Use a request parameter-based Lambda authorizer.
- Why this is rejected: A request parameter-based Lambda authorizer uses query string parameters or headers to pass the token to the authorizer. While this is a valid way to pass data for authorization, it does not directly support credential caching in the same manner that token-based Lambda authorizers do. Additionally, this approach would typically not reduce the need for repeated usage of secret keys and tokens as efficiently as a token-based authorizer.
- Key factor: This option doesn't leverage the caching benefits offered by token-based Lambda authorizers, making it less ideal for reducing repeated use of credentials and tokens.
Option C: Configure an integration request mapping template to reference the context map from the API Gateway Lambda authorizer.
- Why this is selected: The context map in API Gateway contains information about the request, including metadata and authorization-related information. By configuring the integration request mapping template to reference this map, you can ef...
Author: Liam · Last updated May 18, 2026
A developer builds a serverless application on AWS by using Amazon API Gateway, AWS Lambda functions, and Amazon Route 53. During testing, the developer notices errors but cannot immediately locate the root cause.
To identify the errors, the developer needs to search all ...
To address the need for identifying errors in the serverless application with the least operational overhead, let's analyze each option:
Key Considerations:
- Operational Overhead: The goal is to find a solution that minimizes the setup and ongoing maintenance of the system while still enabling the developer to quickly locate and analyze errors in the application.
- Error Identification: The developer needs to search through all the logs from the relevant AWS services (API Gateway, Lambda, Route 53, etc.) to trace errors.
- Real-time Monitoring: While searching for logs, the solution should be easy to query and efficient in terms of querying log data for troubleshooting.
Evaluation of Options:
Option A: Set up API Gateway health checks to monitor the application's availability. Use the Amazon CloudWatch PutMetricData API operation to publish the logs to CloudWatch. Search and query the logs by using Amazon Athena.
- Reasoning:
- API Gateway health checks only monitor availability, not logs or errors directly.
- The solution requires using CloudWatch PutMetricData to manually publish logs, which could lead to added complexity and potential for operational overhead.
- Amazon Athena can be used to query log data in S3, but the logs need to be correctly structured and pushed to S3 beforehand. This is more complex and requires custom solutions for log management.
- Con: The setup of log aggregation and querying with Athena is more complex and introduces unnecessary overhead for a simple log search use case.
Option B: Set up Route 53 health checks to monitor the application's availability. Turn on AWS CloudTrail logs for all the AWS services that the application uses. Send the logs to a specified Amazon S3 bucket. Use Amazon Athena to query the log files directly from Amazon S3.
- Reasoning:
- Route 53 health checks are useful for DNS-level monitoring but do not help in identifying specific errors within application logs.
- CloudTrail logs track API calls, but this is not sufficient for troubleshooting specific application errors. CloudTrail logs can be noisy and not provide enough detail for troubleshooting application logic errors, like those that occur in Lambda functions or API Gateway.
- Amazon Athena for querying log files from S3 is possible but would require significant effort to properly structure and store logs in S3, adding operational overhead.
- Con: The combination of CloudTrail...
Author: ThunderBear · Last updated May 18, 2026
A developer needs to freeze changes to an AWS CodeCommit repository before a production release. The developer will work on new features while a quality assurance (QA) team tests the release.
The QA testing and all bug fixes must take place in isolation from the main branch. After th...
Let's analyze each option carefully based on the requirements:
Key Requirements:
1. Freeze changes to the main branch before a production release.
2. The developer should work on new features during QA testing (isolated from the main branch).
3. QA testing and bug fixes must happen in isolation from the main branch.
4. After the release, all bug fixes must be merged into the main branch.
Option A:
Create a release branch from the latest Git commit that will be in the release. Apply fixes to the release branch. Continue developing new features, and merge the features into the main branch. Merge the release branch into the main branch after the release.
Analysis:
- This option involves creating a separate release branch for the QA team to apply bug fixes.
- New feature development continues independently on the main branch.
- Once the release is finalized, the release branch is merged back into the main branch, ensuring bug fixes from QA are integrated into the main branch.
Why it's suitable:
- It isolates the main branch from QA fixes during testing, pr...
Author: Max · Last updated May 18, 2026
A developer is setting up AWS CodePipeline for a new application. During each build, the developer must generate a test r...
Key Requirements:
- The developer must generate a test report during each build in AWS CodePipeline.
Analysis of Each Option:
Option A: Create an AWS CodeBuild build project that runs tests. Configure the buildspec file with the test report information.
Analysis:
- AWS CodeBuild is specifically designed to run builds and can execute tests during the build process.
- The buildspec file is a configuration file used in CodeBuild to define the phases of the build (install, pre_build, build, post_build). This file allows you to define how to run tests and store the results.
- The test report can be generated by adding the necessary commands in the buildspec file (e.g., generating test reports in formats such as JUnit or others).
Why it's suitable:
- CodeBuild is designed for such tasks, and by configuring the buildspec file with appropriate steps, you can ensure that the test report is generated and made available after the build completes.
- This integrates well into CodePipeline, as CodeBuild can run tests as part of the pipeline.
Option B: Create an AWS CodeDeploy deployment that runs tests. Configure the AppSpec file with the test report information.
Analysis:
- AWS CodeDeploy is primarily used for deployment automation rather than for running tests. While you can use it to deploy your application, it's not typically used for continuous testing during a build phase.
- The AppSpec file in CodeDeploy is used to define deployment hooks (e.g., after or before deployment) and is not intended for configuring build-time test execution or generating test reports.
Why it's not...
Author: Emma · Last updated May 18, 2026
A developer built an application by using multiple AWS Lambda functions. The Lambda functions must access dynamic configuration data at runtime. The data is maintained as a 6 KB JSON document in AWS AppConfig. The configuration data needs to be updated without requiring the redeployment of the application.
The developer needs a solution that will give th...
Key Requirements:
- The Lambda functions need access to dynamic configuration data at runtime.
- The configuration data is stored in AWS AppConfig as a 6 KB JSON document.
- The data must be updated without requiring redeployment of the application.
- Least development effort is preferred.
Analysis of Each Option:
Option A: Migrate the document from AWS AppConfig to a Lambda environment variable. Read the document at runtime.
Analysis:
- Lambda environment variables are static and cannot be easily updated without redeploying the function.
- Since the configuration data needs to be updated dynamically, using environment variables would require redeploying the Lambda function every time the configuration changes, which contradicts the requirement for no redeployment.
Why it's not suitable:
- Environment variables are not designed for dynamic updates, and they wouldn't meet the need for runtime configuration changes without redeployment.
Option B: Configure the AWS AppConfig Agent Lambda extension. Access the dynamic configuration data by calling the extension on a local host.
Analysis:
- The AWS AppConfig Lambda extension is designed specifically for Lambda functions to access dynamic configurations from AWS AppConfig.
- The extension allows Lambda functions to fetch the configuration data dynamically without requiring redeployment.
- This solution integrates well with AWS AppConfig and minimizes the development overhead by leveraging a pre-built extension.
Why it's suitable:
- The Lambda extension allows the Lambda functions to access the dynamic configuration at runtime and automatically updates the configuration as ...
Author: Manish · Last updated May 18, 2026
A developer has AWS Lambda functions that need to access a company's internal data science libraries and reference data. Separate teams manage the libraries and the data. The teams must be able to update and upload new data independently. The Lambda functions are connected t...
To determine the best solution for providing AWS Lambda functions with access to the company's internal data science libraries and reference data, let's analyze each option and consider key factors such as the need for independent updates by teams, scalability, and ease of access.
Option A:
- Attach an Amazon Elastic Block Store (Amazon EBS) volume to the Lambda functions using EBS Multi-Attach.
- Advantages:
- EBS volumes provide block-level storage that is highly durable.
- Disadvantages:
- EBS volumes are designed for attaching to EC2 instances, not directly to Lambda functions. AWS Lambda does not natively support mounting EBS volumes. Furthermore, using EBS Multi-Attach for this use case is not viable because Lambda functions cannot share access to EBS volumes in the same way EC2 instances can.
- Managing updates to EBS volumes would require complex workflows and is not the most appropriate choice for Lambda functions.
Option B:
- Compress libraries and reference data in a Lambda /tmp folder.
- Advantages:
- The `/tmp` folder provides temporary storage up to 512 MB, which could store compressed data and libraries during Lambda function execution.
- Disadvantages:
- The `/tmp` folder is ephemeral, meaning data will not persist across invocations. The Lambda function would lose access to the libraries and reference data once the function execution ends.
- This solution doesn't allow the teams to update or manage the libraries and data independently, as it requires uploading data each time a function runs, which isn't scalable or practical for dynamic data that needs frequent updates.
Option C:
- Set up an Amazon Elastic File System (Amazon EFS) file system with mount targets in the central VPC. Configure the Lambda functions to mount the EFS ...
Author: Max · Last updated May 18, 2026
A company has an application that uses an AWS Lambda function to consume messages from an Amazon Simple Queue Service (Amazon SQS) queue. The SQS queue is configured with a dead-letter queue. Due to a defect in the application, AWS Lambda failed to process some messages. A d...
Key Requirements:
- The Lambda function failed to process messages from an Amazon SQS queue.
- The SQS queue has a dead-letter queue (DLQ) configured.
- The bug in the Lambda function has been fixed, and the developer wants to reprocess the failed messages.
Analysis of Each Option:
Option A: Use the SendMessageBatch API to send messages from the dead-letter queue to the original SQS queue.
Analysis:
- The SendMessageBatch API is used to send messages in batches to an SQS queue. However, this API does not directly work with dead-letter queues (DLQs).
- The developer would have to manually retrieve messages from the DLQ and use this API to re-send them to the original SQS queue.
Why it's not ideal:
- This approach would require additional manual steps to read messages from the DLQ and re-send them to the main queue, introducing more complexity than necessary.
- It is not the most efficient or automated way to process the failed messages again.
Option B: Use the ChangeMessageVisibility API to configure messages in the dead-letter queue to be visible in the original SQS queue.
Analysis:
- The ChangeMessageVisibility API is used to modify the visibility timeout of a message in the queue, i.e., how long a message is hidden from other consumers.
- This API does not support moving messages from a dead-letter queue to the original queue. It only affects the visibility of messages that are already in a queue.
Why it's not suitable:
- The ChangeMessageVisibility API is not designed to move messages between the DLQ and the main queue, making it ineffective for reprocessing messages in the scenario described.
Option C: ...
Author: John · Last updated May 18, 2026
A developer is working on an application that will be deployed on AWS. The developer needs to test and debug the code locally. The code is packaged and stored in an Amazon S3 bucket.
How can t...
To select the best option, let's evaluate each one based on factors like ease of use, configuration complexity, and relevance to local testing and debugging.
Option A: AWS CodeDeploy
- How it works: CodeDeploy is used to automate application deployments to compute services such as EC2 instances or on-premises servers. This option involves creating an application and deployment group, specifying the local machine as the target.
- Why it’s rejected: While it is designed for deployment automation, it requires substantial configuration (setting up CodeDeploy agents, a deployment group, and specifying settings for the local machine). It also involves a more complex deployment pipeline, which isn’t ideal for a simple local testing and debugging setup.
Option B: AWS CodeArtifact
- How it works: CodeArtifact is used to store and share software packages. This option involves creating a repository to store code packages and publishing the application to test it.
- Why it’s rejected: CodeArtifact is primarily used for managing dependencies rather than for testing or debugging code locally. This option is more about managing artifact storage and does not directly facilitate local testing or debugging.
Option C: AWS CodeBuild with CodePipeline
- How it works: CodeBuild is a build service that automates the bu...
Author: Lina Zhang · Last updated May 18, 2026
A developer is creating an application on Amazon Elastic Container Service (Amazon ECS). The developer needs to configure the application parameters. The developer must configure limits for the application's maximum number of simultaneous connections and maximum number of transactions per second.
The maximum number of connections and transactions can change in the future. The develop...
To select the best solution, let's evaluate each option based on the requirements: the need to change application parameters dynamically, apply changes automatically, and ensure zero downtime during the deployment process.
Option A: AWS CodeDeploy with In-Place Deployment
- How it works: In an in-place deployment, AWS CodeDeploy updates the application on the running EC2 instances or containers without launching new instances.
- Why it’s rejected: While CodeDeploy can manage deployment configurations and apply updates, the in-place deployment method does not align well with zero-downtime deployment requirements for dynamic configuration changes. CodeDeploy would likely cause service interruptions during deployment, making this less ideal for automatic, uninterrupted parameter updates like maximum connections or transactions per second.
Option B: AWS Cloud Development Kit (AWS CDK) with ECS Canary Deployment
- How it works: The AWS CDK provides infrastructure as code (IaC) for deploying applications. The ECSCanary10Percent15Minutes deployment strategy would apply the change to 10% of instances for 15 minutes before rolling it out to the rest, allowing for gradual updates.
- Why it’s rejected: While this strategy is useful for ECS container deployments, it requires manual intervention for configuration changes and is more appropriate for infrastructure changes rather than ongoing application configuration management. For dynamic configuration changes like the maximum connections or transactions, the solution would not be as flexible or automatic as needed.
Option C: AWS AppConfig with ECS Integration
- How it works: AWS AppConfig a...
Author: RadiantPhoenixX · Last updated May 18, 2026
A developer has built an application running on AWS Lambda using AWS Serverless Application Model (AWS SAM).
What is the correct ...
To determine the correct sequence of steps for successfully deploying an AWS Lambda application using AWS Serverless Application Model (AWS SAM), let's review each option in light of the best practices for working with AWS SAM.
Option A: Build on EC2, Package to EBS, Deploy from EBS
- How it works: This option suggests building the SAM template on an EC2 instance, then packaging it to Amazon EBS storage and deploying from EBS.
- Why it’s rejected: This option is not suitable for a typical SAM deployment. EBS is not used for packaging and deploying serverless applications in the SAM workflow. AWS SAM relies on Amazon S3 for packaging and storage, not EBS. Additionally, building directly on EC2 introduces unnecessary complexity compared to local or CI/CD-based workflows.
Option B: Build Locally, Package to S3, Deploy from S3
- How it works: This option suggests building the SAM template locally, then packaging it to Amazon S3, and finally deploying it from S3.
- Why it’s selected: This is the correct and recommended sequence for working with AWS SAM. The developer can build the SAM application locally using `sam build`, package the application (including dependencies and Lambda function code) to an S3 bucket using `sam package`, and deploy the application using `sam deploy` with the S3 location as the source for the deployment. This aligns with the typical serverless deploy...
Author: Leah Davis · Last updated May 18, 2026
A developer needs to deploy the code for a new application on an AWS Lambda function. The application needs a dependency file that is 500 MB to run th...
Let's evaluate each option based on the requirements of deploying an AWS Lambda function with a 500 MB dependency file:
Option A: Compress the application code and dependencies into a .zip file and upload it directly to Lambda
- How it works: This approach suggests uploading the compressed .zip file directly to AWS Lambda as the deployment package.
- Why it’s rejected: AWS Lambda has a deployment package size limit of 50 MB when uploading directly through the AWS Management Console or 250 MB when using the AWS CLI or API. Since the dependency file is 500 MB, it exceeds the Lambda limit for deployment packages. This option does not meet the requirements for large packages.
Option B: Compress the application code and dependencies into a .zip file and upload it to an Amazon S3 bucket
- How it works: This method involves uploading the .zip file to S3 and configuring the Lambda function to retrieve and run the code from S3.
- Why it’s rejected: Although this allows for larger deployment packages (up to 3 GB for Lambda functions), Lambda still has an upper limit of 250 MB for direct file uploads. Using S3 in this case would not help with managing the 500 MB dependency file because Lambda functions do not run the code directly from S3; instead, the entire package must be uploaded to Lambda, and S3 is simply used for storage. This option is not ideal for such a large dependency.
Option C: Package the application code and dependencies into a container image, upload the image to S3, and configure Lambda to run from the image
- How it works: This option involves creating a container ...
Author: Liam · Last updated May 18, 2026
A company is developing a publicly accessible single-page application. The application makes calls from a client web browser to backend services to provide a user interface to customers. The application depends on a third-party web service exposed as an HTTP API. The web client must provide an API key to the third-party web service by using the HTTP header as part of the H...
Let's evaluate each option based on the requirement to ensure the company’s API key is not exposed to users, while also providing a solution that is cost-effective for a publicly accessible single-page application.
Option A: Amazon API Gateway with HTTP Integration (Private REST API)
- How it works: This option uses Amazon API Gateway to create a private REST API, which means that the API is not publicly accessible. The company’s API key is added to the HTTP headers list for integration with the third-party HTTP API.
- Why it’s rejected: While this approach would prevent the API key from being exposed directly to the client, using a private API means the API would not be accessible from the public internet, which is a requirement since the application is publicly accessible. Additionally, this option requires extra configuration for handling authentication and access control that could complicate the solution.
Option B: Amazon API Gateway with AWS Lambda Proxy Integration (Private API)
- How it works: This approach uses Amazon API Gateway to create a private REST API that integrates with AWS Lambda via a proxy integration. The Lambda function makes the actual call to the third-party API using the company’s API key.
- Why it’s rejected: Similar to Option A, this option uses a private API, which means it wouldn’t be accessible to the public users of the web application. While Lambda can securely store and manage the API key, the private API would prevent the application from making calls from the client web browser, which is required in this scenario.
Option C: Amazon API Gateway with HTTP Integration (Public REST API)
- How it works: This option uses Amazon API Gat...
Author: Liam · Last updated May 18, 2026
A developer is setting up the deployment of application stacks to new test environments by using the AWS Cloud Development Kit (AWS CDK). The application contains the code for several AWS Lambda functions that will be deployed as assets. Each Lambda function is defined by using the AWS CDK Lambda construct library.
The developer has already successfully deployed the application stacks to the alpha environment in the first account by using the AWS CDK CLI's cdk deploy command. The developer is preparing to deploy to the beta environment in a second account for the first time. The deve...
The error NoSuchBucket indicates that the Lambda functions are trying to be deployed using assets (such as Lambda function code) that depend on an S3 bucket that doesn't exist in the target AWS account or region. When deploying with AWS CDK, assets (like Lambda code) are typically uploaded to an S3 bucket in the account where the CDK is being deployed. Since the error mentions NoSuchBucket, it suggests that the required S3 bucket hasn't been set up in the second (beta) AWS account yet.
Let's break down the options:
A) `cdk synth`
- This command synthesizes an AWS CloudFormation template from the CDK app, showing what AWS resources will be deployed. However, this doesn't resolve any bucket-related issues. It doesn't create the necessary resources (like the S3 bucket). So, this option won't help resolve the NoSuchBucket error.
- Rejected.
B) `cdk bootstrap`
- The `cdk bootstrap` command sets up resources required by AWS CDK for deployment, such as an S3 bucket for asset storage, an ECR repository for container images, and IAM roles for deploying resources. This is th...
Author: Alexander · Last updated May 18, 2026
A developer is automating a new application deployment with AWS Serverless Application Model (AWS SAM). The new application has one AWS Lambda function and one Amazon S3 bucket. The Lambda function must access the S3 bucket to only read objec...
In this case, the Lambda function needs to access an Amazon S3 bucket with read-only permissions. Let's analyze each option to determine the best solution.
A) Reference a second Lambda authorizer function.
- Explanation: Lambda authorizers are typically used in API Gateway to authorize access to APIs. This is unrelated to granting read access to an S3 bucket. The Lambda function needs permission to access S3, not to authorize an API request.
- Rejected: This option is irrelevant to the requirement and is not a valid solution.
B) Add a custom S3 bucket policy to the Lambda function.
- Explanation: AWS recommends granting permissions to resources (like S3 buckets) through IAM roles and policies, rather than directly modifying the bucket policy for Lambda's access. Adding a custom S3 bucket policy directly to the Lambda function would not be the best practice in this scenario.
- Rejected: This is not the recommended or efficient way to configure access in AWS SAM and could lead to unnecessary complexity.
C) Create an Amazon Simple Queue Service (SQS) topic for only S3 object reads. Reference the topic in the template.
- Explanation: Amazon SQS is a message queue service, and it is not necessary for this use case. The Lambda function does n...
Author: Maya · Last updated May 18, 2026
A development team wants to immediately build and deploy an application whenever there is a change to the source code.
Which approac...
To achieve continuous deployment, the goal is to trigger an automated pipeline whenever there is a change in the source code. Let's review the options and evaluate them based on this requirement.
A) Store the source code in an Amazon S3 bucket. Configure AWS CodePipeline to start whenever a file in the bucket changes.
- Explanation: Amazon S3 can be used to store source code. While AWS CodePipeline can be configured to detect changes in an S3 bucket, it is important to note that S3 does not natively provide a mechanism to trigger a pipeline based on file changes, unless using an event like an object creation or modification. This could be set up through Amazon S3 events or other mechanisms, but the exact behavior may not be as seamless as with version-controlled repositories (e.g., CodeCommit).
- Selected: This option can work, though it's less common and might require additional configuration, like triggering the pipeline based on events (e.g., via Lambda or S3 events) when a file is uploaded or modified in the S3 bucket.
B) Store the source code in an encrypted Amazon EBS volume. Configure AWS CodePipeline to start whenever a file in the volume changes.
- Explanation: Amazon EBS volumes are primarily used for storage with EC2 instances, and they do not provide native integration or support for triggering events like file changes to initiate AWS CodePipeline. EBS is typically used for block-level storage, not for continuous integration/continuous deployment (CI/CD) workflows.
- Rejected: This is not a suitable solution for triggering AWS CodePipeline, and EBS does not integrate directly in this manner.
C) Store the source code in an AWS CodeCommit repository. Configure AWS CodePipeline to start whenever a change is committed to the repository.
- Explanation: AWS CodeCommit is a fully managed source control service that integrates directly with AWS CodePipeline. Whenever a commit is made to...
Author: Krishna · Last updated May 18, 2026
A developer is building an application integrating an Amazon API Gateway with an AWS Lambda function. When calling the API, the developer receives the following error:
Wed Nov 08 01:13:00 UTC 2017 : ...
The error message `502` typically indicates a Bad Gateway error, which occurs when there is an issue with the integration between API Gateway and the Lambda function. This can happen if the Lambda function is not responding correctly, or the response format does not meet the expectations of API Gateway.
Let's review the options:
A) Change the HTTP endpoint of the API to an HTTPS endpoint.
- Explanation: This is unlikely to resolve the issue. API Gateway supports both HTTP and HTTPS endpoints, but a `502` error usually suggests that the API Gateway could not correctly integrate with the Lambda function, not an issue related to the protocol (HTTP vs HTTPS).
- Rejected: This option is not related to the cause of the `502` error.
B) Change the format of the payload sent to the API Gateway.
- Explanation: The payload format could be a potential issue, especially if the Lambda function expects a specific structure. However, a `502` error generally indicates a problem with the Lambda function's response rather than the input. The payload format typically impacts how the API Gateway processes incoming requests, but it doesn't directly cause a `502` when the issue lies with Lambda's response format.
- Rejected: This is unlikely to be the root cause of the issue.
C) Change the format of the Lambda function response to the API call.
- Explanation: A common cause of a `502` error is an incorrect or improperly formatted response from ...
Author: Ravi Patel · Last updated May 18, 2026
A developer is building various microservices for an application that will run on Amazon EC2 instances. The developer needs to monitor the end-to-end view of the requests between the microservices and debug any iss...
To monitor the end-to-end view of requests between microservices and debug issues across the application, the goal is to track the flow of requests as they pass through various microservices, pinpointing where failures or performance issues may occur. Let's review each option and evaluate the most suitable one.
A) Use Amazon CloudWatch to aggregate the microservices' logs and metrics, and build the monitoring dashboard.
- Explanation: Amazon CloudWatch is excellent for gathering logs, metrics, and creating dashboards. However, CloudWatch focuses on collecting metrics (e.g., CPU, memory usage, custom metrics) and logs from EC2 instances or services. While CloudWatch is great for general monitoring, it lacks the ability to provide an end-to-end view of requests across microservices, which is required for debugging issues related to request flows and tracing.
- Rejected: CloudWatch doesn’t natively provide distributed tracing or the detailed request flow between microservices. It can help aggregate data but lacks deeper insights into request-specific diagnostics.
B) Use AWS CloudTrail to aggregate the microservices' logs and metrics, and build the monitoring dashboard.
- Explanation: AWS CloudTrail is used for logging and monitoring API calls within an AWS environment. While it is great for tracking user activity and API calls at the AWS service level, it does not provide the deep, request-level tracing or end-to-end visibility needed for microservices monitoring. CloudTrail logs are not designed to trace the flow of individual requests between microservices, making it unsuitable for this use case.
- Rejected: CloudTrail is more for auditing AWS API calls rather than debugging requests across microservices.
C) Use the AWS X-Ray SDK to add instrumentation in all the microservices, and monitor using the X-Ray service m...
Author: Zain · Last updated May 18, 2026
A developer is building a microservice that uses AWS Lambda to process messages from an Amazon Simple Queue Service (Amazon SQS) standard queue. The Lambda function calls external APIs to enrich the SQS message data before loading the data into an Amazon Redshift data warehouse. The SQS queue must handle a maximum of 1,000 messages per second.
During initial testing, the Lambda function repeatedly inserted duplicate data into the Amazon Redshif...
To resolve the issue of duplicate data being inserted into Amazon Redshift due to duplicate SQS messages, let's analyze each option:
Option A: Create an SQS FIFO queue. Enable message deduplication on the SQS FIFO queue.
- Why it's selected: FIFO (First-In-First-Out) queues are designed specifically to maintain the exact order of messages and provide message deduplication. By enabling deduplication on an SQS FIFO queue, any duplicate messages within a 5-minute deduplication interval will not be processed again, preventing the insertion of duplicate data into Amazon Redshift. This is a robust solution, as SQS FIFO queues are built to handle scenarios with a guarantee of message uniqueness and order.
- Why other options are rejected:
- Option B: Reducing Lambda concurrency won't directly solve the problem of message ...
Author: Daniel · Last updated May 18, 2026
A company has an application that uses an Amazon API Gateway API to invoke an AWS Lambda function. The application is latency sensitive.
A developer needs to configure the Lambda function to reduce the cold start time tha...
To meet the requirement of reducing the cold start time for an AWS Lambda function, let's analyze each option:
Option A: Publish a new version of the Lambda function. Configure provisioned concurrency. Set the provisioned concurrency limit to meet the company requirements.
- Why it's selected: Provisioned concurrency ensures that a specific number of Lambda function instances are pre-warmed and ready to handle incoming requests, drastically reducing cold start latency. By configuring provisioned concurrency, the Lambda function will have pre-initialized environments available to process requests immediately, which is ideal for latency-sensitive applications.
- Why other options are rejected:
- Option B: Increasing the Lambda function’s memory and reserved concurrency won't directly address cold start times. While increasing memory ...
Author: Amira99 · Last updated May 18, 2026
A developer is deploying an application on Amazon EC2 instances that run in Account A. The application needs to read data from an existing Amazon Kinesis data stream in Account B.
Which actions should...
To enable the application running on Amazon EC2 instances in Account A to access a Kinesis data stream in Account B, the developer needs to properly configure permissions and trust relationships between the two accounts. Let's evaluate the options:
Option A: Update the instance profile role in Account A with stream read permissions.
- Why it's not selected: The EC2 instance in Account A needs permission to access the Kinesis data stream in Account B. However, directly updating the instance profile in Account A with stream read permissions is not sufficient. Kinesis stream permissions must be granted through a resource-based policy or a cross-account IAM role in Account B.
Option B: Create an IAM role with stream read permissions in Account B.
- Why it's selected: The IAM role in Account B needs to have stream read permissions to allow applications (in this case, EC2 instances in Account A) to read from the Kinesis stream. This role will be assumed by the EC2 instance in Account A through a trust relationship. Creating the role in Account B is necessary to enable access from Account A.
Option C: Add a trust policy to the instance profile role and IAM role in Account B to allow the instance profile role to assume the IAM role.
- Why it's selected: This option is required because the EC2 instance in Account A must assume the IAM role in Account B to gai...
Author: Zara1234 · Last updated May 18, 2026
An ecommerce startup is preparing for an annual sales event. As the traffic to the company's application increases, the development team wants to be notified when the Amazon EC2 instan...
To meet the requirement of notifying the development team when the Amazon EC2 instance's CPU utilization exceeds 80%, let's evaluate each option:
Option A: Create a custom Amazon CloudWatch alarm that sends a notification to an Amazon SNS topic when the CPU utilization exceeds 80%.
- Why it's selected: Amazon CloudWatch is the most straightforward and efficient way to monitor EC2 instances. CloudWatch automatically tracks key metrics like CPU utilization, and you can easily create an alarm that triggers when the CPU utilization exceeds a threshold (80% in this case). The alarm can then send a notification to an Amazon SNS topic. This approach is fully managed, scalable, and designed for such use cases.
- Why other options are rejected:
- Option B: AWS CloudTrail is designed for logging API activity, not for monitoring system metrics like CPU utilization. CloudTrail doesn't capture metric data like CPU usage, so it ...
Author: Joseph · Last updated May 18, 2026
A company has an application that is deployed on AWS Elastic Beanstalk. The application generates user-specific PDFs and stores the PDFs in an Amazon S3 bucket. The application then uses Amazon Simple Email Service (Amazon SES) to send the PDFs by email to subscribers.
Users no longer access the PDFs 90 days after the PDFs are generated. The S3 bucket is not versioned and contains many obsolete PDFs.
A devel...
To meet the requirement of removing PDFs older than 90 days from the S3 bucket with the least development effort, let's evaluate each option:
Option A: Update the application code. In the code, add a rule to scan all the objects in the S3 bucket every day and to delete objects after 90 days.
- Why it's not selected: Updating the application code to scan and delete objects every day would add unnecessary complexity and development overhead. It would also require maintaining this logic within the application, making it less scalable and error-prone. A more straightforward solution exists that doesn't involve modifying the application.
Option B: Create an AWS Lambda function. Program the Lambda function to scan all the objects in the S3 bucket every day and to delete objects after 90 days.
- Why it's not selected: While this is a valid solution, it still requires custom development for the Lambda function to scan and delete files. You would need to set up Lambda, write the code to handle object deletions, and ensure it runs at regular intervals (e.g., daily). Although this solution works, it is more involved than the next option, which offers automation without requiring custom code.
Option C: Create an S3 Lifecycle rule for the S3 bucket to ...
Author: Andrew · Last updated May 18, 2026
A developer is troubleshooting an application. The application includes several AWS Lambda functions that invoke an Amazon API Gateway API. The API Gateway's method request is set up to use an Amazon Cognito authorizer for authentication.
All the Lambda functions pass the user ID as part of the Authorization header t...
To resolve the issue of receiving a 403 status code for all GET requests to the API Gateway API, we need to understand the authentication flow with Amazon Cognito authorizers and the proper configuration of the API Gateway and client requests.
Let's break down the options:
A) Modify the client GET request to include a valid API key in the Authorization header.
- Reasoning: This option is unlikely to solve the issue. API keys are generally used for rate limiting and quota purposes, but they don't handle user authentication. The API Gateway is set up to use a Cognito authorizer for authentication, so an API key in the `Authorization` header would not solve the 403 error if the issue is related to Cognito authentication.
- Rejection: The issue here is related to authentication using Cognito, not API keys. API keys are not used for user authorization in Cognito-based scenarios.
B) Modify the client GET request to include a valid token in the Authorization header.
- Reasoning: This is the most likely solution. The 403 error suggests that the API Gateway does not accept the provided authorization credentials. Since Cognito is being used as an authorizer, the client must pass a valid JWT (JSON Web Token) from Cognito in the `Authorization` header, not just the user ID. The client needs to authenticate against Cognito and use the valid token received in the response as the `Authorization` header for API requests.
- Selected Option: This is the correct o...
Author: SilverBear · Last updated May 18, 2026
A company processes incoming documents from an Amazon S3 bucket. Users upload documents to an S3 bucket using a web user interface. Upon receiving files in S3, an AWS Lambda function is invoked to process the files, but the Lambda function times out intermittently.
If the Lamb...
To address the scenario where an AWS Lambda function times out intermittently during S3 event processing, let's examine the behavior of Lambda with respect to S3 events and timeouts when the Lambda function is configured with default settings.
Understanding the default Lambda behavior with S3 events:
- By default, AWS Lambda retries the event processing twice if the function times out or fails. After two retries, if the function still fails, the event is discarded. There is no automatic notification or retries beyond the default behavior, unless further configured (such as using a Dead Letter Queue).
A) Notification of a failed S3 event is sent as an email through Amazon SNS.
- Reasoning: This option does not align with the default behavior of Lambda. By default, Lambda does not automatically send notifications upon failure, unless you configure additional services like SNS or CloudWatch alarms.
- Rejection: This is not the default behavior of Lambda and would need additional setup to work. It’s not automatically triggered by a timeout or failure in the Lambda function.
B) The S3 event is sent to the default Dead Letter Queue.
- Reasoning: A Dead Letter Queue (DLQ) is used when you explicitly configure it i...
Author: Manish · Last updated May 18, 2026
A developer uses Amazon S3 Event Notifications to invoke AWS Lambda functions. The Lambda functions process images after the images are uploaded to S3 buckets. The developer has set up a development S3 bucket, a production S3 bucket, a development Lambda function, and a production Lambda function in the same AWS account.
The developer notices that uploads to the development S3 bucket wrongly invoke the p...
To resolve the issue where uploads to the development S3 bucket are wrongly invoking the production Lambda function, the developer needs to ensure that the S3 event notifications for each bucket trigger the correct Lambda function and prevent cross-environment interference.
Let’s evaluate the options:
A) Update the execution role for the production Lambda function. Add a policy that allows the execution role to read from only the production S3 bucket.
- Reasoning: This option focuses on the Lambda function's execution role, but it does not address the root cause of the issue, which is that the S3 event notifications are incorrectly triggering the production Lambda function. Changing the execution role for the production Lambda will not prevent the development S3 bucket from invoking the production Lambda function if the event notification configuration is still wrong.
- Rejection: This option addresses permissions for Lambda execution, but it does not directly control which Lambda function gets triggered by the S3 event. The issue lies in how the S3 events are being configured.
B) Update the S3 bucket policy for the production S3 bucket to invoke the production Lambda function. Update the S3 bucket policy for the development S3 bucket to invoke the development Lambda function.
- Reasoning: This approach focuses on configuring the S3 bucket policies to explicitly allow the corresponding Lambda functions to be invoked. This can help restrict the production Lambda to only be invoked by the production S3 bucket, and similarly for the development bucket and Lambda function. However, managing Lambda invocation permissions via S3 bucket policies can lead to complexity and may not be the most straightforward way to prevent wrong Lambda invocations. S3 Event Notifications are often configured directly, and using a policy alone may not fully address the issue, as event notifications can still be misconfigured.
- Rejection: While this could potentially work, it’s generally better to control event-to-Lambda mappings explicitly at the S3 notification configuration level rather than relying on S3 bucket policies.
C) Separate the development environment and the production environm...
Author: Kai99 · Last updated May 18, 2026
A developer is writing an application that will run on Amazon EC2 instances in an Auto Scaling group. The developer wants to externalize the session state to support the application.
Which AWS ...
When the developer wants to externalize session state for an application running on Amazon EC2 instances in an Auto Scaling group, the goal is to store session data outside of the EC2 instances so that it can persist across scaling events and instance failures. Let's evaluate the options available to meet these requirements.
A) Amazon DynamoDB
- Reasoning: Amazon DynamoDB is a fully managed NoSQL database that provides high availability and scalability. It can be used to store session state, allowing sessions to be externalized and persist across Auto Scaling group changes. DynamoDB is designed to handle high throughput and low-latency access, making it a good choice for session storage.
- Selected: This option is a valid choice because DynamoDB provides a reliable and scalable solution for session state storage, which is key for supporting an Auto Scaling application.
B) Amazon Cognito
- Reasoning: Amazon Cognito is typically used for user authentication, authorization, and identity management. It stores user profiles and provides access management but is not specifically designed for general session state management. While it can handle session tokens for authenticated users, it is not intended to be used as a general-purpose session store for applications.
- Rejection: This is not a suitable option for externalizing session state, as Amazon Cognito's focus is on user identity management rather than general session data.
C) Amazon ElastiCache
- Reasoning: Amazon ElastiCache is a fully managed caching service that supports Redis and Memcached. It is commonly used to store session data because it is fast, scalable, and offers low-latency access to data. Using ElastiCache for session state is a common approach for distributed applications, especially for storing session...
Author: Lina Zhang · Last updated May 18, 2026
A company has a serverless application that uses an Amazon API Gateway API to invoke an AWS Lambda function. A developer creates a fix for a defect in the Lambda function code. The developer wants to deploy this fix to the production environment.
To test the changes, the developer needs to send 10% of the li...
To meet the requirement of sending 10% of the live production traffic to the updated Lambda function version, the key is to use weighted routing that allows splitting the traffic between the old and new versions. Let's evaluate the options:
A) Publish a new version of the Lambda function that contains the updated code.
- Reasoning: This step is necessary because to enable versioned traffic routing, you need to publish a new version of the Lambda function. This allows the Lambda function's versions to be tracked and used in routing decisions.
- Selected: This is a valid option, as creating a new version of the Lambda function is essential for deploying updates and routing traffic to the updated version.
B) Set up a new stage in API Gateway with a new Lambda function version. Enable weighted routing in API Gateway stages.
- Reasoning: While API Gateway supports stages and allows you to configure different environments (e.g., development, production), weighted routing is not typically done at the stage level. Instead, traffic routing between Lambda versions is managed using Lambda aliases, not stages. This option is misleading because routing based on Lambda versions is handled by aliases, not API Gateway stages.
- Rejection: This option is incorrect because API Gateway stages themselves do not support weighted routing for Lambda versions.
C) Create an alias for the Lambda function. Configure weighted routing on the alias. Specify a 10% weight for the new Lambda function version.
- Reasoning: This is the correct solution. By creating an alias for the Lambda function, you can configure weighted routing to split the traffic between the old and new versions of the Lambda function. API Gateway uses the alias to route ...
Author: Nathan · Last updated May 18, 2026
A developer is creating a video search application for a global company. The video files have an average size of 2.5 TB. The video storage system must provide instant access to the video files for the first 90 days. After the first 90 days, the video file...
To determine the most cost-effective solution, we need to consider both access speed and cost for the video storage over time. Here's the analysis of each option:
Option A: Amazon EFS Standard and Standard-IA
- EFS Standard provides low-latency, high-throughput file access, suitable for active file access.
- Standard-IA (Infrequent Access) is a low-cost storage option, ideal for infrequently accessed files.
- Analysis:
- EFS is typically more expensive than S3 for storing large volumes of data.
- After 90 days, transitioning to EFS Standard-IA reduces the cost, but EFS is still a file storage solution designed for frequent access, not for archival.
- This solution is costlier and less efficient for large-scale, infrequently accessed video files after 90 days.
Option B: Amazon S3 with Glacier Deep Archive and Glacier Flexible Retrieval
- S3 Glacier Deep Archive is a very low-cost storage option for long-term archiving, with retrieval times of several hours, but provides a significant cost savings.
- Glacier Flexible Retrieval is suitable for infrequent access but provides retrieval times in minutes (which meets the requirement of taking more than 10 minutes after 90 days).
- Analysis:
- For the first 90 days, S3 Glacier Deep Archive would not be appropriate, as it has retrieval times that may exceed 10 minutes and is not designed for immediate access.
- Glacier Flexible Retrieval provides longer retrieval times than standard storage solutions but allows for more affordable long-term storage.
- This solution can be effective after the first 90 days, but it is not ideal for the first 90 days, where instant access is required.
Option C: Amazon EBS and S3 Glacier Deep Archive
- EBS is a block storage solution that provides fast and consistent I/O performance for active workloads but is typically more expensive than S3 for large amounts of storage.
- S3 Glacier Deep Archive is very low-cost...
Author: Emily · Last updated May 18, 2026
A company has a virtual reality (VR) game. The game has a serverless backend that consists of Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. Recently, the company noticed a sudden increase of new users globally. The company also noticed delays in the retrieval of ...
Analysis of the Options:
Option A: Amazon ElastiCache
- ElastiCache is a fully managed in-memory caching service that supports Redis and Memcached. It can help improve database response times by caching frequently accessed data.
- Analysis:
- ElastiCache can significantly reduce database response time by caching frequently queried data, which improves the performance of read-heavy workloads.
- However, this solution is not specifically tailored for DynamoDB. While it could be used for caching, it requires additional management, and the integration may not be as seamless as the next option.
Option B: DynamoDB Accelerator (DAX)
- DAX is a fully managed, highly available, in-memory cache for DynamoDB that delivers microsecond read response times for cached data. It works natively with DynamoDB and can accelerate read-heavy workloads.
- Analysis:
- DAX is purpose-built for DynamoDB and is designed to provide microsecond response times for read queries, which directly addresses the company's requirement of reducing database response times to microseconds.
- DAX automatically handles cache invalidation and refresh, making it a seamless solution for improving DynamoDB performance without the need for additional infrastructure management.
- DAX is the most suitable solution for improving the read performance of DynamoDB specifically.
Option C: DynamoDB Auto Scaling
- DynamoDB Auto Scaling automatically adjusts the read and...
Author: Andrew · Last updated May 18, 2026
A developer is creating a solution to track an account's Amazon S3 buckets over time. The developer has created an AWS Lambda function that will run on a schedule. The function will list the account's S3 buckets and will store the list in an Amazon DynamoDB table. The developer receives a permissions error when the developer runs the function with...
Analysis of the Options:
Option A: Cross-account IAM role
- Cross-account IAM roles allow AWS resources in one account to access resources in another account. This is useful for resources that are in separate AWS accounts.
- Analysis:
- Since the question does not mention multiple accounts, cross-account access is unnecessary here. The Lambda function and DynamoDB are likely in the same account, so this option isn't relevant to the issue.
Option B: Permission for the Lambda function to list buckets in Amazon S3
- The Lambda function needs permission to interact with Amazon S3, specifically to list the account's S3 buckets. The permissions necessary for this are granted by the `s3:ListAllMyBuckets` permission.
- Analysis:
- The permissions error suggests that the Lambda function does not have the necessary permission to list the S3 buckets. The required permission for this action is `s3:ListAllMyBuckets`.
- This permission is essential for the Lambda function to access and list all S3 buckets in the account, making this a necessary selection.
Option C: Permission for the Lambda function to write in DynamoDB
- The Lambda function stores the list of S3 buckets in a DynamoDB table. To do so, it needs permission to write to the DynamoDB table.
- Analysis:
- Since the function stores the S3 bucket list in DynamoDB, the function requires write permissions for the DynamoDB table (e.g., `dynamod...
Author: Aria · Last updated May 18, 2026
A company uses AWS to run its learning management system (LMS) application. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The application's domain name is managed in Amazon Route 53. The application is deployed in a single AWS Region, but the company wants to improve appli...
Analysis of the Options:
Option A: Set up an Amazon CloudFront distribution that uses the ALB as the origin server. Configure Route 53 to create a DNS alias record that points the application's domain name to the CloudFront distribution URL.
- CloudFront is a Content Delivery Network (CDN) service that caches content at edge locations worldwide to provide faster delivery of static and dynamic content. It integrates seamlessly with ALB and improves global performance by caching frequently accessed content.
- Analysis:
- CloudFront caches content globally at edge locations, reducing latency for users by serving them from the closest edge location.
- It works well with Route 53 to route traffic to CloudFront, and the ALB serves as the origin for dynamic content.
- This solution provides excellent performance improvements globally with minimal operational overhead. Once set up, CloudFront manages the caching and routing automatically, and Route 53 handles DNS resolution.
- This solution is simple to implement and requires minimal management after setup.
Option B: Launch more EC2 instances behind the ALB, configure the ALB to use session affinity (sticky sessions), and create a Route 53 alias record for the ALB by using a geolocation routing policy.
- Launching more EC2 instances can help with scaling the application, but this does not address the need for improving global performance.
- Geolocation routing in Route 53 can route users to the closest instances, but this will require more EC2 instances in multiple regions to be truly effective.
- Sticky sessions are typically used to maintain session state between a user and a specific EC2 instance, which is not related to improving global performance or reducing latency.
- Analysis:
- Scaling EC2 instances to multiple regions could improve performance, but it increases complexity and operational overhead due to the need for instance management, load balancing, and regional deployment.
- Geolocation routing could be effective for regional performance improvements, but it requires much more manual management and monitoring compared to using CloudFront.
Option C: Create an AWS Client VPN endpoint in the VPC, instruct users to connec...
Author: Ahmed97 · Last updated May 18, 2026
A developer hosts a static website on Amazon S3 and connects the website to an Amazon CloudFront distribution. The website uses a custom domain name that points to the CloudFront URL.
The developer has set up a continuous integration and continuous delivery (CI/CD) pipeline. The pipeline automatically runs when changes occur in an AWS CodeCommit repository. The pipeline has a source stage and then a build stage. The build stage invokes an AWS CodeBuild project that references a buildspec.yml file. The buildspec.yml file builds the code and deploys the static files to the S3 bucket.
The pipeline runs successfully, and the latest website...
To resolve the issue where updates are visible in the S3 bucket but not reflected on the CloudFront distribution, the problem lies in CloudFront caching. CloudFront caches files at edge locations to improve performance and reduce latency. When a file is updated in the S3 bucket, CloudFront may still serve the cached version, which is why the updates are not reflected on the website when accessed via the CloudFront domain.
Analyzing the Options:
- A) Properly synchronize the objects in the S3 bucket with new files from the source stage.
- This option would ensure the files in S3 are up to date, but it doesn’t address the CloudFront caching issue. Synchronizing the files in S3 does not automatically clear or update CloudFront's cached content.
- B) Delete the previous website files in the S3 bucket and redeploy the website files.
- While this might force the website to use the new files, it’s a more drastic and inefficient solution. There’s no need to delete files in the S3 bucket to update them, as the issue lies in CloudFront caching, not the S3 cont...
Author: Michael · Last updated May 18, 2026
A developer is working on an ecommerce application that stores data in an Amazon RDS for MySQL cluster. The developer needs to implement a caching layer for the application to retrieve informat...
Analyzing the Options:
- A) Edit the RDS for MySQL cluster by adding a cache node. Configure the cache endpoint instead of the cluster endpoint in the application.
- Amazon RDS for MySQL does not support adding a cache node directly. This option is not valid because caching capabilities must be handled separately from RDS, typically through an external caching service like Amazon ElastiCache.
- B) Create an Amazon ElastiCache for Redis cluster. Update the application code to use the ElastiCache for Redis cluster endpoint.
- This is the most appropriate solution. Amazon ElastiCache for Redis is designed to provide in-memory caching, which is ideal for caching frequently accessed data, like the most viewed products in an eCommerce application. Redis supports high-speed caching, and it can be integrated easily with MySQL to cache query results, reducing the load on the RDS database and improving performance for read-heavy workloads.
- C) Create an Amazon DynamoDB Accelerator (DAX) cluster in front of the RDS for MySQL cluster. Configure the appl...
Author: Suresh · Last updated May 18, 2026
A gaming application stores scores for players in an Amazon DynamoDB table that has four attributes: user_id, user_name, user_score, and user_rank. The users are allowed to update their names only. A user is authenticated by web identity federation.
...
To allow users to update only their names in the DynamoDB table, you need to control access with a policy that ensures the user can only modify their own record, specifically the `user_name` attribute. The most important factors to consider are:
Key Considerations:
1. Allow the user to update only their own record: This means the policy must ensure that the update applies to the item with the matching `user_id` of the authenticated user.
2. Allow updating only the `user_name` attribute: The policy must restrict modification to the `user_name` attribute, preventing the user from changing `user_score` or `user_rank`.
Analyzing the Options:
- A) Allow `dynamodb:PutItem` action only on the table and for items where the `user_id` matches the authenticated user’s `user_id` (via web identity federation). Additionally, only the `user_name` attribute is allowed to be updated.
- This is the correct solution. The policy should ensure that the `user_id` in the request is the same as the authenticated user’s `user_id` (which is available through the web identity federation). By restricting the `user_name` attribute in the `PutItem` action, you ensure that only the `user_name` is modified, while the `user_score` and `user_rank` are untouched. This achieves the goal of allowing users to only update their name.
- B) Allow `dynamodb:PutItem` action on the table and for items where the `user_id` is any value. No r...
Author: StarlightBear · Last updated May 18, 2026
A developer is creating a database of products. Queries for frequently accessed products must have retrieval times of microseconds. To ensure data consistency, the application cache must be updated whenever...
Analyzing the Requirements:
- Retrieval Time in Microseconds: The query response times must be very low (microseconds), which means we need a high-performance caching solution.
- Cache Updates for Data Consistency: Whenever products are added, changed, or deleted, the cache must be updated to ensure that the most up-to-date information is available.
Analyzing the Options:
- A) Set up an Amazon DynamoDB database and a DynamoDB Accelerator (DAX) cluster.
- This is the best solution. DynamoDB and DAX work together to provide extremely fast retrieval times in the microsecond range. DAX is a fully managed, in-memory cache for DynamoDB that can serve results from cache, reducing the number of reads from the database. With DAX, you can ensure low-latency access to frequently accessed products, and DynamoDB handles automatic consistency and scalability. When products are added, changed, or deleted, DynamoDB can handle the update process efficiently. DAX will automatically manage the cache consistency with DynamoDB, meeting both the low retrieval times and data consistency requirements.
- B) Set up an Amazon RDS database and an Amazon ElastiCache for Redis cluster. Implement a lazy loading caching strategy with ElastiCache.
- This is a good option but less optimal than option A. Amazon RDS combined with Redis (ElastiCache) can provide fast cache access, but Redis operates in a separate cache and doesn't integrate as seamlessly with RDS as DAX does wi...
Author: Harper · Last updated May 18, 2026
A developer is creating a script to automate the deployment process for a serverless application. The developer wants to use an existing AWS Serverless Application Model (AWS SAM) template fo...
Analyzing the Requirements:
The developer wants to automate the deployment process for a serverless application using an existing AWS SAM template. The goal is to use the AWS Serverless Application Model (SAM) to streamline the deployment and packaging process.
Analyzing the Options:
- A) Call `aws cloudformation package` to create the deployment package. Call `aws cloudformation deploy` to deploy the package afterward.
- This option is valid, but not ideal when working specifically with AWS SAM. While `aws cloudformation package` and `aws cloudformation deploy` can work with SAM templates, they are part of CloudFormation's standard deployment process. The SAM CLI simplifies the process for serverless applications by providing specialized commands, so while this approach works, it lacks the specific benefits of using `sam package` and `sam deploy`, which are tailored for SAM.
- B) Call `sam package` to create the deployment package. Call `sam deploy` to deploy the package afterward.
- This is the most suitable option. The AWS SAM CLI provides the `sam package` command to bundle the application and the `sam deploy` command to deploy it. These commands are specifically designed for working with AWS SAM templates and handle the entire lifecycle of a serverless application, including packaging, uploading, and deploying. Using the SAM CLI commands ensures smooth integration with AWS Lambda, API Gateway, and other serverless resources. This is the recommended approach for a serverless application deployment.
- C) Call `aws s3 cp` to upload the AWS SAM template to Amazon S3. Call `aws lambda update-function-code` to create the application.
- This is not ideal for deploying a full serverless application. While `aws s3 cp` uploads the SAM template, the proce...
Author: Max · Last updated May 18, 2026
A developer is building an application on AWS. The application has an Amazon API Gateway API that sends requests to an AWS Lambda function. The API is experiencing increased latency because the Lambda function has limited available CPU to fulfill the requests.
Before the developer deploys the API ...
Key Considerations:
- Lambda CPU Allocation: AWS Lambda allocates CPU power based on the memory setting for the Lambda function. The more memory allocated, the more CPU is available to the function. Since the function is experiencing increased latency due to limited CPU, the developer needs to increase the available CPU by adjusting the function's configuration.
Analyzing the Options:
- A) Increase the virtual CPU (vCPU) cores quota of the Lambda function.
- This is incorrect. AWS Lambda does not allow direct control over the number of vCPU cores allocated to a function. Instead, the CPU power is indirectly determined by the amount of memory allocated. The Lambda service does not provide a setting to adjust the number of vCPUs; it scales automatically with the memory allocation.
- B) Increase the amount of memory that is allocated to the Lambda function.
- This is the correct solution. In AWS Lambda, CPU is tied to memory. When you increase the memory allocated to a Lambda function, the function also gets more CPU resources. This will directly address the issue of limited CPU and reduce latency. It is a simple and effectiv...
Author: Leo · Last updated May 18, 2026
A developer has an application that uses AWS Lambda functions and AWS CloudFormation templates. Usage of the application has increased. As a result, the Lambda functions are encountering rate limit errors when they retrieve data.
The Lambda functions retrieve an advanced parameter from AWS Systems Manager Parameter Store on every call. The parameter changes only during new deployments. Because t...
Key Considerations:
- Rate Limit Errors: Lambda functions are encountering rate limits when retrieving parameters from AWS Systems Manager Parameter Store, which suggests the functions are hitting the maximum number of allowed API requests to retrieve the parameter.
- Cost-effectiveness: The solution needs to minimize costs while solving the problem of rate limiting.
- Usage of the Parameter: The parameter changes only during new deployments, and the Lambda functions retrieve it on every call, which could lead to unnecessary repeated calls that contribute to rate limiting.
Analyzing the Options:
- A) Configure the Lambda functions to use reserved concurrency that is equal to the last month's average number of concurrent invocations.
- This is not the most suitable solution. Reserved concurrency ensures a set number of concurrent executions for Lambda functions, but it does not address the issue of rate-limiting for parameter retrieval. While it could help with controlling the concurrency, it does not reduce the number of calls made to Parameter Store, which is the main cause of the rate limit errors.
- B) Add a retry mechanism with exponential backoff to the call to Parameter Store.
- This is a useful solution but not the most cost-effective. While retrying with exponential backoff can help mitigate rate limit errors, it does not eliminate the root cause — the frequent calls to Parameter Store on every Lambda invocation. This approach only delays the errors rather than addressing the underlying inefficiency of fetch...
Author: Lucas · Last updated May 18, 2026
A developer is using an AWS Lambda function to process data. The developer needs to extract custom metrics about processing times from the Lambda logs. The developer needs to analyze the metrics, set ...
Let's break down each option to determine which one best fits the developer’s need to extract custom metrics from AWS Lambda logs and analyze those metrics in real time:
A) Publish custom metric data to AWS CloudTrail by using the PutMetricData API operation. Classify and collect the metrics. Create graphs and alarms in CloudTrail for the custom metrics.
- Why this is rejected: AWS CloudTrail logs API calls and user activity, but it is not a service designed for monitoring custom application metrics or logs directly. CloudTrail is typically used for auditing, security, and compliance purposes. It doesn't offer the tools needed to analyze log data or create custom metrics from Lambda logs in real time. CloudWatch is a better fit for these tasks.
B) Use the open source client libraries provided by Amazon to generate the logs in the Amazon CloudWatch embedded metric format. Use CloudWatch to create the required graphs and alarms for the custom metrics.
- Why this is a good option: CloudWatch Embedded Metric Format (EMF) allows you to publish custom metrics from Lambda directly to CloudWatch using the standard log format. This method is efficient and can easily track processing times or any other custom metrics. The custom metrics can then be used to create graphs and alarms in CloudWatch. However, it requires a bit more manual work, as the developer has to modify the Lambda function code to incorporate the embedded metric format.
- When to use: This option is great when you want full control over how the metrics are published and need to embed custom logic directly in the Lambda function to define metrics.
C) Use Amazon CloudWatch Logs Insights to create custom metrics by querying ...
Author: Liam · Last updated May 18, 2026
A developer needs to fix an AWS CodeDeploy deployment that failed. During the failed deployment, the developer received the following error message:
=E2=80=9CThe overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment...
Let's evaluate each option to understand the possible causes of the failed deployment with the error message: "The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH-CONSTRAINTS)".
A) The CodeDeploy agent was not running on the instances that CodeDeploy was trying to deploy to.
- Why this is selected: If the CodeDeploy agent is not running on the instances, CodeDeploy will be unable to deploy the application to those instances. The agent is required for communication between CodeDeploy and the EC2 instances. Without the agent running, the deployment will fail, resulting in unhealthy instances, which leads to the "HEALTH-CONSTRAINTS" error. This is a common cause of deployment failures.
B) The unified Amazon CloudWatch agent was not running on the instances that CodeDeploy was trying to deploy to.
- Why this is rejected: The CloudWatch agent is used for monitoring and logging metrics, but it does not impact the deployment process directly. The deployment failure is related to the CodeDeploy agent, not the CloudWatch agent. The CloudWatch agent’s absence would not lead to the "HEALTH-CONSTRAINTS" error related to deployment health.
C) The developer's IAM role did not have the necessary permissions to perform code deployment to the instances.
- Why this is rejected: The IAM role permissions issue would typically result in errors related to authorization fai...
Author: Aria · Last updated May 18, 2026
A company is developing a serverless application that requires storage of sensitive API keys as environment variables for various services. The application requires the automatic rotation of the encryption k...
Let's break down each option to determine which one best fits the company’s requirements of storing sensitive API keys as environment variables and rotating encryption keys automatically every year, with no development effort involved:
A) Encrypt the environment variables by using AWS Secrets Manager. Set up automatic rotation in Secrets Manager.
- Why this is selected: AWS Secrets Manager is specifically designed to store and manage sensitive data such as API keys. It supports automatic rotation of secrets, including credentials and keys, without requiring custom development. By using Secrets Manager, the API keys can be encrypted and rotated automatically based on the defined schedule, in this case, every year. This solution fully satisfies the requirements with minimal development effort.
B) Encrypt the environment variables by using AWS Key Management Service (AWS KMS) customer managed keys. Enable automatic key rotation.
- Why this is rejected: While AWS KMS customer managed keys can be rotated automatically, KMS itself is focused on encrypting data and does not manage the API keys directly. In this case, KMS would only handle the encryption key rotation, but the application would still need to manage storing and retrieving the sensitive API keys, which adds complexity. It doesn't provide the out-of-the-box functionality for managing and rotating API keys like...
Author: Aarav · Last updated May 18, 2026
An application stores user data in Amazon S3 buckets in multiple AWS Regions. A developer needs to implement a solution that analyzes the user data in the S3 buckets to find sensitive information. The analysis findings from all the S3 buckets must be avail...
Let's evaluate each option based on the need to analyze user data in multiple S3 buckets across AWS Regions, find sensitive information, and make the analysis results available in the eu-west-2 Region with the least development effort.
A) Create an AWS Lambda function to generate findings. Program the Lambda function to send the findings to another S3 bucket in eu-west-2.
- Why this is rejected: While Lambda could be used to generate findings, this approach requires custom development for analyzing the S3 data, generating findings, and copying the results to an S3 bucket in eu-west-2. This introduces significant development and operational overhead. It is not the least effort solution because it requires manual coding and monitoring.
B) Configure Amazon Macie to generate findings. Use Amazon EventBridge to create rules that copy the findings to eu-west-2.
- Why this is selected: Amazon Macie is a fully managed service designed for discovering sensitive data in Amazon S3. It can automatically generate findings when sensitive information is detected in the stored data. EventBridge can be used to route those findings to a specific location, such as an S3 bucket in the eu-west-2 Region. This solution is highly efficient as it leverages managed services with minimal custom development. It ensures findings are automatically transferre...
Author: Arjun · Last updated May 18, 2026
An application ingests data from an Amazon Kinesis data stream. The shards in the data stream are set for normal traffic.
During tests for peak traffic, the application ingests data slowly. A developer needs to adjust the data stream to ...
To address the performance issue and handle peak traffic more effectively, let's evaluate each option:
Option A: Install the Kinesis Producer Library (KPL) to ingest data into the data stream.
- Explanation: KPL is designed to help with batching records, reducing the number of API requests made to Kinesis Data Streams, and improving the overall throughput. However, the problem described seems to be related to the throughput of the data stream itself rather than inefficiencies in data ingestion. Installing KPL is more of an optimization for the producer side (the application sending data to Kinesis), but it will not increase the capacity of the data stream itself to handle peak traffic. Therefore, this option addresses only part of the problem (ingestion efficiency) but does not address the capacity of the Kinesis stream itself.
- Rejected because: It does not directly address the problem of stream capacity under peak traffic.
Option B: Switch to on-demand capacity mode for the data stream. Specify a partition key when writing data to the data stream.
- Explanation: In on-demand mode, Kinesis automatically adjusts the number of shards to accommodate incoming traffic, making it easier to handle varying traffic loads without manual intervention. This option offers the flexibility to scale with demand without the need for predefined shard settings. It can be a great choice when there are unpredictable traffic spikes, as it ensures optimal resource allocation.
- Rejected because: It might be more expensive than manually adjusting the shard count in scenarios where traffic patterns are predictable. On-demand mode scales automatically, but it might lead to higher costs over time, especially when traffic is predictable and could be managed more ...
Author: Leo · Last updated May 18, 2026
A developer is building an application that uses an AWS Lambda function to process data. The application requires minimum latency. The Lambda function must have predictable function start times. All setup activities for the execution environm...
To determine the best solution for the given requirements, let's break down each option:
Option A: Increase the memory of the Lambda function to the maximum amount. Configure an Amazon EventBridge rule to schedule invocations of the Lambda function every minute to keep the execution environment active.
- Explanation: Increasing memory improves performance but doesn't address the setup time issue. While scheduling regular invocations via EventBridge ensures that the Lambda function is kept warm, it is inefficient and costly because it involves continuous invocations even when the function may not be needed. It doesn’t guarantee the predictable start time and setup activities before the function runs, as invocations may still face initialization delays.
- Rejected because: This option is inefficient and costly, and it doesn't guarantee predictable start times or the setup activities before the function’s first invocation.
Option B: Optimize the static initialization code that runs when a new execution environment is prepared for the first time. Decrease and compress the size of the Lambda function package and the imported libraries and dependencies.
- Explanation: Optimizing the Lambda function code and dependencies reduces cold start times, but it doesn't address the need for predictable function start times or the setup of the execution environment before the function is invoked. While this can help minimize latency, it doesn't guarantee that the Lambda function will start quickly or reliably, as some initialization still occurs when the environment is created for the first time.
- Rejected because: This helps with cold starts but doesn't fully meet the requirement for predictable start times and setup completion before invocation.
Option C: Increase the reserved concurrency of the Lambda function to the maximum value for unreserved account co...
Author: Aarav · Last updated May 18, 2026
A company has implemented a pipeline in AWS CodePipeline. The company is using a single AWS account and does not use AWS Organizations. The company needs to test its AWS CloudFormation templates in its primary AWS Region and a disaster...
Let's break down each option based on operational efficiency, feasibility, and how well it addresses the requirement of deploying and testing CloudFormation templates in both the primary AWS Region and the disaster recovery Region:
Option A: In the CodePipeline pipeline, implement an AWS CodeDeploy action for each Region to deploy and test the CloudFormation templates. Update CodePipeline and AWS CodeBuild with appropriate permissions.
- Explanation: AWS CodeDeploy is primarily designed for application deployments, not specifically for CloudFormation template testing and deployment. Using CodeDeploy for CloudFormation templates is not ideal, as it doesn’t directly align with the use case, and it would add unnecessary complexity to the pipeline.
- Rejected because: CodeDeploy is not designed for deploying CloudFormation templates and adds unnecessary complexity.
Option B: Configure CodePipeline to deploy and test the CloudFormation templates. Use CloudFormation StackSets to start deployment across both Regions.
- Explanation: CloudFormation StackSets allows you to manage and deploy CloudFormation stacks across multiple AWS accounts and Regions from a single template. This is a powerful tool for cross-region deployment and testing, and integrating StackSets directly with CodePipeline would automate deployments to both Regions efficiently. This solution would ensure that the CloudFormation templates are deployed and tested across both the primary and disaster recovery Regions with minimal manual intervention, making it an operationally efficient solution.
- Selected because: CloudFormation StackSets directly supports cross-region deployments, and integrating it with CodePipeline provides an automated and scalable solution for deploying and testing in both Regions.
Option C: Configure CodePipeline to invoke AWS ...
Author: Ming88 · Last updated May 18, 2026
A company has an Amazon API Gateway REST API that integrates with an AWS Lambda function. The API=E2=80=99s development stage references a development alias of the Lambda function named dev.
A developer needs make a production alias o...
Let's evaluate the options for making the production alias of the Lambda function available through the API in a way that best meets the requirements.
Option A: Create a new method on the API. Name the method production. Configure the method to include a stage variable that points to the prod Lambda function alias.
- Explanation: Adding a new method named `production` and configuring it with a stage variable would create a separate method for the production alias. However, using stage variables in this way is generally used for managing configuration settings across the entire stage, not for selecting a specific Lambda function alias for integration. This would be inefficient and unnecessary, as it requires managing multiple methods for what could be a simple alias switch via stage configuration.
- Rejected because: This introduces unnecessary complexity by creating a new method when stage variables can be used more effectively for Lambda alias resolution.
Option B: Create a new method on the API. Name the method production. Configure an integration request on the API's development stage that points to the prod Lambda function alias.
- Explanation: This option involves creating a new method and configuring the development stage to use the production alias (`prod`) Lambda function, but this is not ideal. The development stage should be used for the development alias, and altering it to point to the production alias would disrupt the development pipeline and cause confusion. The production environment should ideally be separated with its own stage, not mixed with the development environment.
- Rejected because: It causes confusion and mixes development and production environments, which could lead to unexpected behavior.
Option C: Deploy the API to a new stage named production. Configure the stage to incl...
Author: Charlotte · Last updated May 18, 2026
A developer is implementing a serverless application by using AWS CloudFormation to provision Amazon S3 web hosting. Amazon API Gateway, and AWS Lambda functions. The Lambda function source code is zipped and uploaded to an S3 bucket. The S3 object key of the zipped source code is specified in the Lambda resource in the CloudFormation template.
The devel...
To resolve the issue where there are no changes in the Lambda function every time the CloudFormation stack is updated, let's evaluate the options based on how they would address the lack of updates:
Option A: Create a new Lambda function alias before updating the CloudFormation stack.
- Explanation: Lambda aliases are used to provide a stable reference to specific versions of a Lambda function. Creating a new alias does not address the issue of Lambda function source code updates. Lambda aliases point to specific function versions, and if the function's code hasn't changed, the alias will still reference the same code. This would not solve the problem of triggering updates when the source code changes.
- Rejected because: It does not address the underlying issue of detecting changes to the Lambda function source code.
Option B: Change the S3 object key or the S3 version in the CloudFormation template before updating the CloudFormation stack.
- Explanation: This option involves changing the S3 object key or S3 version that is specified in the CloudFormation template. This ensures that CloudFormation detects a change in the Lambda source code because it will reference a different S3 object (or version) upon each update. This triggers an update to the Lambda function, which forces the deployment of the new source code.
- Selected because: Changing the S3 object key or version forces CloudFormation to detect the change and update the Lambda function, effectively solving the issue of the Lambda function not being updated on stack updates.
Option C: Upload the zipped source code to another S3 bucket before updating the CloudFormation stack.
-...
Author: Liam · Last updated May 18, 2026
A developer published a change to a new version of an AWS Lambda function. To test the change, the developer must route 50% of the traffic to the new version and 60% of the traffic to the curren...
Let's evaluate each option based on the given requirement: routing 50% of the traffic to the new version of the Lambda function and 60% of the traffic to the current version.
Option A:
- Description: This option involves using Amazon Route 53 to route traffic to different versions of the Lambda function by creating two records (one for each version) and applying weighted routing.
- Issue: This option doesn’t work because Route 53 operates at the DNS level and cannot directly control Lambda versions. DNS-based routing will not directly influence Lambda invocations with the level of granularity needed. Additionally, DNS routing cannot be split into 50% and 60% traffic, as it must sum to 100%. Furthermore, Route 53 isn’t designed for handling Lambda traffic weights as directly as Lambda alias or API Gateway can.
- Rejection reason: Inefficient for managing precise traffic routing to Lambda function versions and doesn't allow flexible control over traffic allocation between versions.
- Scenario: Could be used for routing traffic to services that support weighted DNS routing, not specifically Lambda functions.
Option B:
- Description: This option uses Amazon API Gateway and a canary release to route 50% of traffic to the new version.
- Issue: Although API Gateway can work with Lambda functions and support canary releases, it doesn't support precise routing of 50% of traffic to the new version and 60% to the old version. The canary release generally supports routing 5% or 10% (by default) and doesn’t allow flexible traffic split like 50%/60%.
- Rejection reason: While API Gateway is a good choice for controlling traffic between versions in canary deployments, it doesn’t meet the exact requirement for 50%/60% traffic distribution.
- Scenario: This could be used when you want a canary release that routes a small portion of traffic to the new version initially (but not for the specific distribution requested).
Option C:
- Description: This option uses a Lambda alias with weighted r...
