Amazon Practice Questions, Discussions & Exam Topics by our Authors
A developer is building an application that will use an Amazon API Gateway API with an AWS Lambda backend. The team that will develop the frontend requires immediate access to the API endpoints to build the UI. To prepare the backend application for integration, the developer needs to set up endpoints. The endpoints need to return predefined HTTP sta...
The developer's goal is to set up API endpoints that return predefined HTTP status codes and JSON responses for the frontend team. The API should simulate the backend behavior before the actual Lambda function is implemented. Let's evaluate each option:
A) Set the integration type to AWS_PROXY. Provision Lambda functions to return hardcoded JSON data.
- Rejected: The AWS_PROXY integration type is designed to allow full control of the request and response by the Lambda function. However, this approach requires implementing actual Lambda functions to return data. This goes beyond the scope of simply simulating endpoints with hardcoded responses. It doesn't align with the requirement to simulate API responses quickly before implementing the Lambda functions.
B) Set the integration type to MOCK. Configure the method's integration request and integration response to associate JSON responses with specific HTTP status codes.
- Selected: The MOCK integration type allows the API Gateway to return predefined responses without invoking any backend services like Lambda. This is perfect for simulating the behavior of the backend for frontend development. The developer can easily configure HTTP status codes and JSON responses that the frontend team can use to build their UI. This is the most efficient approach for setting up mock endpoints with hardcoded responses quickly.
C) Set the integration type to HTTP_PROXY. Configure API Gateway ...
Author: Noah · Last updated May 18, 2026
A developer is migrating an application to Amazon Elastic Kubernetes Service (Amazon EKS). The developer migrates the application to Amazon Elastic Container Registry (Amazon ECR) with an EKS cluster. As part of the application migration to a new backend, the developer creates a new AWS account. The developer makes configuration changes to the application to point the application to the new AWS account and to use new backend resources. The developer successfully tests the changes within the application by deploying the pipeline.
The Docker image build and the pipeline deployment are successful, but the application is sti...
The issue at hand is that the application is still connecting to the old backend, even though the Docker image build and pipeline deployment were successful. The developer has made configuration changes to point the application to the new AWS account and backend resources, but the application isn't reflecting these changes. Let's analyze each option:
A) The developer did not successfully create the new AWS account.
- Rejected: The scenario specifies that the developer has successfully migrated the application to a new AWS account. The application works as expected in terms of the Docker image build and pipeline deployment. This suggests that the AWS account creation is not the issue. The problem lies with the application configuration or the way it's referencing backend resources, not with the creation of the new account.
B) The developer added a new tag to the Docker image.
- Rejected: Adding a new tag to the Docker image wouldn't directly cause the application to reference the old backend. The tag change is not relevant to the connection between the application and the backend resources. The application's issue lies with its internal configuration, not the image tag itself.
C) The developer did not update the Docker image tag to a new version.
- Selected: This is the most likely explanation. If the application is still referencing the old backend, it might be b...
Author: Olivia Johnson · Last updated May 18, 2026
A developer is creating an application that reads and writes to multiple Amazon S3 buckets. The application will be deployed to an Amazon EC2 instance. The developer wants to make secure API requests from the EC2 instances without the need to manage the security credentials for the a...
The developer's goal is to securely make API requests from an EC2 instance to multiple Amazon S3 buckets while following the principle of least privilege. The solution must avoid managing security credentials manually and ensure the application only has the necessary permissions to perform its tasks. Let's evaluate each option:
A) Create an IAM user. Create access keys and secret keys for the user. Associate the user with an IAM policy that allows `s3:` permissions.
- Rejected: While creating an IAM user with access keys and associating an `s3:` policy will grant the necessary permissions, it requires manual management of access keys and secret keys. This is not ideal because it introduces the risk of key exposure or mismanagement. Additionally, using access keys on EC2 instances is not recommended because it can lead to security vulnerabilities if not handled properly.
B) Associate the EC2 instance with an IAM role that has an IAM policy that allows `s3:ListBucket` and `s3:Object` permissions for specific S3 buckets.
- Selected: This is the most secure and appropriate option. By associating an IAM role with the EC2 instance, the EC2 instance can use temporary security credentials that AWS automatically rotates, thus eliminating the need for manual management of credentials. The role is granted specific permissions (e.g., `s3:ListBucket` and `s3:Object`) to only the necessary S3 buckets, following the principle of least privilege. This solution allows secure API access without exposing ...
Author: Lucas Carter · Last updated May 18, 2026
A developer is writing an application that will retrieve sensitive data from a third-party system. The application will format the data into a PDF file. The PDF file could be more than 1 MB. The application will encrypt the data to disk by using AWS Key Management Service (AWS KMS). The application will decrypt the file when a user requests to download it. The retrieval and formatting portions of the application are complete.
The developer needs to use the GenerateDataKey ...
To meet the developer's requirements of securely encrypting a PDF file using AWS Key Management Service (AWS KMS) and enabling decryption later, the developer needs to use the `GenerateDataKey` API to generate both a plaintext data key and an encrypted data key. The plaintext key will be used to encrypt the PDF file, while the encrypted key will be stored securely for later decryption. Let's evaluate each option:
A) Write the encrypted key from the GenerateDataKey API to disk for later use. Use the plaintext key from the GenerateDataKey API and a symmetric encryption algorithm to encrypt the file.
- Selected: This is the correct approach. When using the `GenerateDataKey` API, AWS KMS returns both an encrypted data key and a plaintext data key. The plaintext data key is used to encrypt the sensitive data (in this case, the PDF file) using a symmetric encryption algorithm. The encrypted data key is stored securely (e.g., in a database or another secure location) and can be used later to decrypt the file. This approach ensures that the plaintext key is never exposed after encryption and can be securely decrypted using the encrypted data key when needed.
B) Write the plain text key from the GenerateDataKey API to disk for later use. Use the encrypted key from the GenerateDataKey API and a symmetric encryption algorithm to encrypt the file.
- Rejected: Storing the plaintext key on disk is a security risk, as it exposes the key in an unsecured way. The plaintext key should never be written to disk, as it could be ac...
Author: Sophia · Last updated May 18, 2026
A company runs an application on Amazon EC2 instances. The EC2 instances open connections to an Amazon RDS for SQL Server database. A developer needs to store and access the credentials and wants to automatically rotate the credentials. The developer does not want to store...
To determine the most secure and efficient way to handle credentials and rotate them automatically, let's evaluate each option:
A) Create an IAM role that has permissions to access the database. Attach the IAM role to the EC2 instances.
- Reasoning: This option suggests using an IAM role for EC2 instances to access the database, but IAM roles are typically used for granting AWS service permissions rather than storing and rotating database credentials. For Amazon RDS SQL Server, IAM-based authentication is not supported out of the box like it is for certain other AWS services (e.g., RDS for MySQL, PostgreSQL).
- Rejected: This solution doesn't meet the requirement to store database credentials securely or automate their rotation for RDS SQL Server, since IAM roles aren't the right tool for storing credentials for SQL Server.
B) Store the credentials as secrets in AWS Secrets Manager. Create an AWS Lambda function to update the secrets and the database. Retrieve the credentials from Secrets Manager as needed.
- Reasoning: AWS Secrets Manager is a managed service specifically designed for securely storing and rotating credentials, including database credentials. It provides an automated mechanism for rotating secrets (e.g., database passwords) without needing to modify the code. AWS Lambda can be used to update the secrets in Secrets Manager and interact with the database, ensuring the credentials are always fresh.
- Selected Option: This is the most secure and convenient solution. It meets the requirement of storing the credentials securely, automating the credential rotation, and accessing the credentials dynamically from the application code without hardcoding them.
C) Store the credentials in an encrypted text file in an Amazon S3 bucket. Configure the EC2 instance launch template to download the...
Author: Lucas Carter · Last updated May 18, 2026
A company wants to test its web application more frequently. The company deploys the application by using a separate AWS CloudFormation stack for each environment. The company deploys the same CloudFormation template to each stack as the application progresses through the development lifecycle.
A developer needs to build in notifications for the quality assurance (QA)...
To meet the requirements of notifying the QA team upon new deployments in the final preproduction environment, let's evaluate each option based on its relevance to the problem:
A) Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the QA team to the Amazon SNS topic. Update the CloudFormation stack options to point to the SNS topic in the pre-production environment.
- Reasoning: This option suggests creating an SNS topic, but there is no direct integration between CloudFormation and SNS for notifications about stack updates. You would need to manually integrate CloudFormation stack updates with SNS, which could be cumbersome and error-prone. CloudFormation provides native ways to send notifications, such as via CloudFormation Events or through other AWS services like Lambda, so this is not the most automated or scalable approach.
- Rejected: This solution lacks automation and direct integration with CloudFormation events. Other solutions provide better integration with AWS CloudFormation for notifications.
B) Create an AWS Lambda function that notifies the QA team. Create an Amazon EventBridge rule to invoke the Lambda function on the default event bus. Filter the events on the CloudFormation service and on the CloudFormation stack Amazon Resource Name (ARN).
- Reasoning: This approach uses Amazon EventBridge to listen for CloudFormation events, which is a good fit. EventBridge is a serverless event bus that integrates well with AWS services. You can filter CloudFormation events for specific stacks, such as the preproduction environment, and trigger a Lambda function to notify the QA team. This solution offers strong flexibility and automation, as well as direct integration with CloudFormation.
- Selected Option: This is the most appropriate solution, as it integrates well with CloudFormation, provides the required notification automation, and allows for specific filtering by stack ARN, ensuring notifications are sent only for the desired environment (preproduction).
...
Author: Rohan · Last updated May 18, 2026
A developer manages three AWS accounts. Each account contains an Amazon RDS DB instance in a private subnet. The developer needs to define users in each database in a consistent way. The developer must ensure that the same users are created and updated lat...
To determine the most efficient solution for creating and updating users in Amazon RDS DB instances across three AWS accounts, let's evaluate each option:
A) Create an AWS CloudFormation template. Declare the users in the template. Attach the users to the database. Deploy the template in each account.
- Reasoning: This approach suggests using CloudFormation to declare and deploy users in the databases. While CloudFormation can be used to manage resources across accounts, it doesn’t natively handle the creation or management of users inside databases like RDS. Additionally, if the users need to be created or updated dynamically, CloudFormation templates may not be flexible enough for regular updates.
- Rejected: CloudFormation is primarily for managing infrastructure and doesn’t provide the flexibility needed to directly manage database users in a dynamic and consistent way across multiple accounts.
B) Create an AWS CloudFormation template that contains a custom resource to create the users in the database. Deploy the template in each account.
- Reasoning: This option enhances CloudFormation by using a custom resource to create the users within the database. This solution allows for better flexibility than the previous one by leveraging a Lambda function within the custom resource. The Lambda function would be responsible for creating and updating users in the database. This option ensures that the process is automated and can be consistent across accounts.
- Selected Option: This is the most operationally efficient approach. The use of a custom resource in CloudFormation provides the flexibility to create and manage users dynamically while still using CloudFormation to deploy and manage resources. Additionally, this allows for easy updates and a consistent approach across accounts.
C) Write a script that creates the users. Deploy an Am...
Author: Nia · Last updated May 18, 2026
A company is building a new application that runs on AWS and uses Amazon API Gateway to expose APIs. Teams of developers are working on separate components of the application in parallel. The company wants to publish an API without an integrated backend so that teams that depend on the application backen...
The company needs a solution where an API is exposed via Amazon API Gateway but doesn’t yet have an integrated backend. This allows the teams working on the backend to continue their work while allowing other teams that depend on the API to proceed with development. Let’s evaluate each option:
A) Create API Gateway resources and set the integration type value to MOCK. Configure the method integration request and integration response to associate a response with an HTTP status code. Create an API Gateway stage and deploy the API.
- Reasoning: This option suggests using API Gateway with a "MOCK" integration type. With this setup, the API Gateway can return pre-configured mock responses for requests, which is useful for simulating API calls without the need for an actual backend. This allows the development of the front-end or client applications to proceed without waiting for the backend to be ready.
- Selected Option: This is the most suitable and efficient solution. Using the MOCK integration type allows for seamless development by providing static, predefined responses that mimic the behavior of the backend. It's easy to implement and requires minimal setup. It’s also highly scalable and does not require provisioning or managing additional resources (like Lambda or EC2) for mocking.
B) Create an AWS Lambda function that returns mocked responses and various HTTP status codes. Create API Gateway resources and set the integration type value to AWS_PROXY. Deploy the API.
- Reasoning: This approach involves creating an AWS Lambda function to return mocked responses, with API Gateway using the AWS_PROXY integration type. While this would work, it introduces unnecessary complexity since AWS_PROXY is used for direct integration with Lambda functions for dynamic backends, which is not needed for mocking. The mock responses could be returned more simply using the MOCK integration type.
- Rejected: This solution is over-complicated for the given use case. The Lambda function ad...
Author: Alexander · Last updated May 18, 2026
An application that runs on AWS receives messages from an Amazon Simple Queue Service (Amazon SQS) queue and processes the messages in batches. The application sends the data to another SQS queue to be consumed by another legacy application. The legacy system can take up to 5 minutes to process some transaction data.
A developer wants to ensure that there are...
The problem involves ensuring that messages are processed in order and without out-of-order updates in the legacy system, while adhering to the constraint that the legacy system takes up to 5 minutes to process some transaction data. The key requirement is to preserve the order of the messages as they are transferred from one queue to another. Let's evaluate each option:
A) Use an SQS FIFO queue. Configure the visibility timeout value.
- Reasoning: An SQS FIFO (First-In-First-Out) queue guarantees the order in which messages are processed, which is critical for this scenario. The visibility timeout ensures that a message is not processed by another consumer until the current consumer finishes processing. This would ensure that messages are processed in the correct order, and no messages are processed out of order. However, the visibility timeout value should be carefully set to ensure that it is long enough for the legacy system to process the message without it being considered available for reprocessing.
- Selected Option: This is the best solution. Using a FIFO queue guarantees message order, and the visibility timeout can be adjusted to match the maximum processing time of the legacy system (5 minutes). This will ensure that messages are not processed out of order while the legacy system is processing them.
B) Use an SQS standard queue with a SendMessageBatchRequestEntry data type. Configure the DelaySeconds values.
- Reasoning: SQS standard queues do not guarantee message order, so using this queue type is not appropriate for ensuring that the legacy system processes the messages in order. Additionally, configuring `DelaySeconds` will introduce a fixed delay before messages are delivered, but this does not guarantee that messages will be processed in order by the legacy system, which is a key requirement.
- Rejected: A standard queue does not guarantee message order, which is essential in this ca...
Author: Ravi Patel · Last updated May 18, 2026
A company is building a compute-intensive application that will run on a fleet of Amazon EC2 instances. The application uses attached Amazon Elastic Block Store (Amazon EBS) volumes for storing data. The Amazon EBS volumes will be created at time of initial deployment. The application will process sensitive information. All ...
Solution Explanation:
A) Configure the fleet of EC2 instances to use encrypted EBS volumes to store data.
- Pros:
- Amazon EBS supports encryption at rest, which can protect sensitive information.
- Encryption of the EBS volumes is done seamlessly at the hardware level, without requiring additional configurations from the application side.
- Performance impact is minimal, as Amazon EBS encryption leverages hardware acceleration (AES-256 encryption).
- Managed solution that is native to AWS and integrates well with EC2 instances.
- Cons:
- Slight performance overhead compared to unencrypted volumes, but it’s minimal and should not have a significant impact for compute-intensive applications.
- Why it’s the best option:
- The solution provides both encryption and minimal performance impact, which meets the requirement of encrypting sensitive data without significant overhead. The EBS volumes are specifically designed to work with EC2 instances and ensure data is encrypted automatically.
B) Configure the application to write all data to an encrypted Amazon S3 bucket.
- Pros:
- Amazon S3 supports server-side encryption, which protects the data.
- Amazon S3 is designed to scale well and can be used to store data efficiently.
- Cons:
- The data needs to be accessed over the network, which could introduce latency and performance overhead for compute-intensive applications that require fast access to large amounts of data.
- Writing to S3 is not directly integrated with EBS, meaning additional management for syncing data between S3 and EC2 could be required.
- Why it’s rejected:
- For a compute-intensive application, storing data on S3 would add unnecessary network latency, making it unsuitable for applications that require low-latency access to data.
C) Configure a custom encryption algorithm for the application that will en...
Author: Sophia · Last updated May 18, 2026
A developer is updating the production version of an AWS Lambda function to fix a defect. The developer has tested the updated code in a test environment. The developer wants to slowly roll out the updates to a small subset of production users before rolling out the changes to all users. On...
Explanation:
The goal is to slowly roll out the new Lambda code to a small subset of users, starting with 10% of users being exposed to the new code. The most efficient and secure way to achieve this is by using Lambda versions and aliases, which are designed for controlled traffic shifting.
Let's analyze each option:
---
A) Update the Lambda code and create a new version of the Lambda function. Create a Lambda function trigger. Configure the traffic weights in the trigger between the two Lambda function versions. Send 90% of the traffic to the production version, and send 10% of the traffic to the new version.
- Cons:
- Lambda triggers (such as API Gateway, S3 events, etc.) are typically associated with a single function version. While you can configure traffic routing with some event sources, this approach isn't the typical pattern for version-based traffic shifting within Lambda.
- The mechanism for configuring traffic weight on triggers is not straightforward and may not work in the way this solution suggests.
- Conclusion: This solution is not the most appropriate because Lambda triggers themselves do not have a native feature to route traffic based on versioning.
---
B) Create a new Lambda function that uses the updated code. Create a Lambda alias for the production Lambda function. Configure the Lambda alias to send 90% of the traffic to the production Lambda function, and send 10% of the traffic to the test Lambda function.
- Cons:
- This solution suggests creating a new Lambda function rather than working with Lambda versions and aliases of the same function. Creating a completely new Lambda function would involve more resources and maintenance overhead.
- Managing traffic distribution across entirely separate Lambda functions is more complex than working with versions of the same function.
- Conclusion: This option is overly complicated, as it involves managing two separate Lambda functions and would requ...
Author: VenomousSerpent42 · Last updated May 18, 2026
A developer is creating an AWS Lambda function that consumes messages from an Amazon Simple Queue Service (Amazon SQS) standard queue. The developer notices that the Lambda function processes some mes...
Solution Explanation:
A) Change the Amazon SQS standard queue to an Amazon SQS FIFO queue by using the Amazon SQS message deduplication ID.
- Pros:
- FIFO queues are designed to ensure that messages are processed exactly once and in the exact order they are sent.
- Using message deduplication IDs helps prevent processing the same message multiple times within a 5-minute deduplication interval.
- Cons:
- SQS FIFO queues are typically more expensive than standard queues.
- Changing from a standard queue to a FIFO queue may not be necessary, as the issue might be better addressed with other solutions that don’t require such a change.
- If the order of message processing is not important, using a FIFO queue could be an over-engineered solution and could incur unnecessary cost increases.
- Why it’s rejected:
- While FIFO queues prevent message duplication, they come with higher costs and complexity, especially when the requirement is to prevent multiple processing of messages rather than ensuring ordered message processing.
B) Set up a dead-letter queue.
- Pros:
- A dead-letter queue (DLQ) allows you to capture messages that failed processing after multiple attempts, helping to isolate problematic messages.
- Useful for debugging and monitoring message processing failures.
- Cons:
- A DLQ doesn't directly prevent a message from being processed multiple times; it only helps to isolate messages that can't be processed after retrying.
- If Lambda keeps processing the same message multiple times, simply using a DLQ won’t fix the root cause (which is typically due to message visibility timeout or Lambda concurrency issues).
- Why it’s rejected:
- This approach helps with failure management but doesn't prevent multiple processing of messages. It’s more of a recovery strategy, not a prevention measure for duplicate processing.
C) Set the maximum concurrency limit of the AWS Lambda function to 1.
- Pros:
- By setting the Lambda concurrency to 1, you ensure that only one instance of the Lambda function can process messages at a time.
- This effectively serializes the processing of messages, eliminating the possibility of multiple...
Author: Leo · Last updated May 18, 2026
A developer is optimizing an AWS Lambda function and wants to test the changes in production on a small percentage of all traffic. The Lambda function serves requests to a RE ST API in Amazon API Gateway. The developer needs to deploy their changes and per...
Analysis of Each Option:
The goal is to test changes to the Lambda function in production by directing a small percentage of traffic to the new version of the function while keeping the rest of the traffic on the existing production version, all without changing the API Gateway URL.
---
A) Define a function version for the currently deployed production Lambda function. Update the API Gateway endpoint to reference the new Lambda function version. Upload and publish the optimized Lambda function code. On the production API Gateway stage, define a canary release and set the percentage of traffic to direct to the canary release. Update the API Gateway endpoint to use the $LATEST version of the Lambda function. Publish the API to the canary stage.
- Pros:
- Canary releases are specifically designed for rolling out changes gradually by shifting a portion of the traffic to a new Lambda version. This is exactly what is needed for the use case.
- You can direct a percentage of the traffic to the new Lambda version, making it ideal for testing in production.
- Cons:
- The part about updating the API Gateway to reference `$LATEST` and using the canary release is somewhat contradictory. If you're using a canary release, the API Gateway stage should reference an alias, not `$LATEST`, as `$LATEST` always points to the latest deployed version of the Lambda function.
- Conclusion: This option is close to being correct but requires adjustments, particularly around the use of `$LATEST` and canary releases.
---
B) Define a function version for the currently deployed production Lambda function. Update the API Gateway endpoint to reference the new Lambda function version. Upload and publish the optimized Lambda function code. Update the API Gateway endpoint to use the $LATEST version of the Lambda function. Deploy a new API Gateway stage.
- Cons:
- Updating the API Gateway to use `$LATEST` contradicts the intention of testing a specific Lambda version. `$LATEST` always points to the most recent version of the function, so using it would make it difficult to control traffic to the production and test versions.
- Creating a new API Gateway stage is unnecessary and doesn't address the core goal of testing the changes incrementally in production.
- Conclusion: This approach adds unnecessary complexity and doesn't provide the fine-grained traffic control required for the test.
---
C) Define an alias on the $LATEST ve...
Author: Isabella · Last updated May 18, 2026
A company notices that credentials that the company uses to connect to an external software as a service (SaaS) vendor are stored in a configuration file as plaintext.
The developer needs to secure the API credentials and enforce automatic...
Solution Explanation:
A) Use AWS Key Management Service (AWS KMS) to encrypt the configuration file. Decrypt the configuration file when users make API calls to the SaaS vendor. Enable rotation.
- Pros:
- AWS KMS can provide encryption for sensitive data and protect API credentials stored in the configuration file.
- Cons:
- Encrypting the configuration file with KMS only secures the data at rest. However, this solution does not address the need for automatic rotation of the credentials on a regular basis (quarterly). While KMS encryption is secure, manual processes would still be required for credential rotation, making it a less optimal solution.
- Handling key management and decryption manually could add complexity and increase the risk of human error.
- Why it’s rejected:
- KMS is more suitable for encrypting data at rest but does not offer the native ability to rotate credentials automatically, which is a key requirement.
B) Retrieve temporary credentials from AWS Security Token Service (AWS STS) every 15 minutes. Use the temporary credentials when users make API calls to the SaaS vendor.
- Pros:
- Temporary credentials can be used to improve security, and they have a limited lifespan, reducing the impact of a compromised credential.
- Cons:
- This solution does not address the use case for the external SaaS vendor. AWS STS is typically used to provide temporary credentials for AWS resources, not for external SaaS integration.
- Using temporary AWS credentials doesn’t directly solve the issue of securing and rotating API credentials for a third-party SaaS application.
- Why it’s rejected:
- This option is not applicable to the external SaaS integration, as STS is designed for use within AWS services, not for external services.
C) Store the credentials in AWS Secrets Manager and enable rotation. Configure the API to have Secrets Manager access.
- Pros:
- Best solution for automatic credential rotation: AWS Secrets Manager is designed ...
Author: GlowingTiger · Last updated May 18, 2026
A company has an application that is hosted on Amazon EC2 instances. The application stores objects in an Amazon S3 bucket and allows users to download objects from the S3 bucket. A developer turns on S3 Block Public Access for the S3 bucket. After this change, users report errors when they attempt to download objects. The developer needs to implement a solution so that only users who...
The goal is to allow only authenticated users to access objects in the S3 bucket while ensuring secure access. Let’s evaluate each option to meet the requirement in the most secure way.
Option A: Create an EC2 instance profile and role with an appropriate policy. Associate the role with the EC2 instances.
- Reasoning: This option ensures that the EC2 instances, which host the application, can access the S3 bucket. The instance role would have an IAM policy that allows access to the S3 bucket, enabling secure access for the application. This option follows best practices for securing access by using IAM roles and instance profiles, instead of embedding credentials directly in the EC2 instances.
- Why it's selected: It's a secure way to provide the necessary permissions for EC2 instances to interact with the S3 bucket without hardcoding credentials.
Option B: Create an IAM user with an appropriate policy. Store the access key ID and secret access key on the EC2 instances.
- Reasoning: Storing access keys directly on EC2 instances is not a best practice, as it introduces security risks (e.g., potential key exposure or compromise). IAM roles should be used instead of IAM users for EC2 instance access, which eliminates the need for hardcoded credentials.
- Why it's rejected: Storing credentials on EC2 instances is not recommended because of the potential for credential leaks.
Option C: Modify the application to use the S3 GeneratePresignedUrl API call.
- Reasoning: The `GeneratePresignedUrl` API call creates a temporary URL that grants time-limited access to an object in S3. This ensures that users can only access the object for a limited period, which is useful for allowing specific users to d...
Author: Emma · Last updated May 18, 2026
An Amazon Simple Queue Service (Amazon SQS) queue serves as an event source for an AWS Lambda function. In the SQS queue, each item corresponds to a video file that the Lambda function must convert to a smaller resolution. The Lambda function is timing out on longer video files, but the Lambda function's tim...
In this scenario, the issue is that the Lambda function is timing out when processing longer video files, even though the timeout setting for the function has already been set to its maximum value. The goal is to avoid timeouts without adding additional code, meaning the solution should focus on improving the function's ability to process the video files without exceeding the Lambda execution time.
Let’s evaluate each option:
Option A: Increase the memory configuration of the Lambda function.
- Reasoning: Increasing the memory allocated to the Lambda function can improve its processing speed. AWS Lambda allocates CPU power proportional to the memory, meaning that more memory can result in faster processing of tasks. For tasks like video conversion, where computation power is important, increasing the memory might allow the Lambda function to complete the task more quickly, thus avoiding timeouts.
- Best Use Case: This is a relevant option because allocating more memory to Lambda can reduce processing time and help prevent timeouts.
- Explanation: Given that the video processing task is taking too long, increasing memory may help speed up the operation and finish the task within the timeout.
Option B: Increase the visibility timeout on the SQS queue.
- Reasoning: The visibility timeout on the SQS queue determines how long a message remains hidden from other consumers after it has been retrieved by a Lambda function. However, increasing the visibility timeout will not help with Lambda timeouts. It is useful for ensuring that messages are not processed multiple times while the Lambda function is still working on them, but it does not affect the function's execution time.
- Rejection: This will not resolve the Lambda function’s time...
Author: Ahmed97 · Last updated May 18, 2026
A company is building an application on AWS. The application's backend includes an Amazon API Gateway REST API. The company's frontend application developers cannot continue work until the backend API is ready for integration. The company needs a solution that will allow the frontend applicat...
In this scenario, the company needs a way for the frontend developers to continue their work while the backend API is being developed. This can be done by providing mock responses for the API methods so the frontend developers can test and integrate the frontend components. Let’s evaluate each option:
Option A: Configure mock integrations for API Gateway API methods.
- Reasoning: Mock integrations in Amazon API Gateway allow you to define responses directly in API Gateway without needing to set up any backend systems (like Lambda functions). You can configure mock responses for any HTTP status code, which can mimic the backend behavior. This will allow the frontend developers to work with predefined responses without the backend being fully implemented.
- Best Use Case: This is the most operationally efficient solution because it provides the mock behavior of the API without additional code, such as Lambda functions or backend services. The mock integration can quickly simulate the API endpoints, allowing frontend developers to continue their work without delays.
- Explanation: Mock integrations do not require backend systems or additional infrastructure, making them highly efficient for this type of scenario.
Option B: Integrate a Lambda function with API Gateway and return a mocked response.
- Reasoning: You can integrate a Lambda function with API Gateway and have the Lambda return a mocked response. While this solution would work, it involves setting up and managing a Lambda function, which adds extra complexity and is not as operationally efficient as the mock integration.
- Rejection: Although this will work, it requires more setup (creating a Lambda function), which is...
Author: Aria · Last updated May 18, 2026
A company is preparing to migrate an application to the company's first AWS environment. Before this migration, a developer is creating a proof-of-concept application to validate a model for building and deploying container-based applications on AWS.
Which combination of steps should ...
In this scenario, the developer needs to deploy a containerized proof-of-concept application to AWS with the least operational effort. The key factors to consider include the simplicity of the deployment, minimal management overhead, and avoiding manual infrastructure management. Let's break down each option:
Option A: Package the application into a .zip file by using a command line tool. Upload the package to Amazon S3.
- Reasoning: This option describes packaging the application as a ZIP file and uploading it to Amazon S3. While Amazon S3 is excellent for storage, this is not the best solution for deploying a containerized application. Containerized applications are typically packaged into Docker images, not ZIP files, and stored in container registries like Amazon Elastic Container Registry (Amazon ECR) for deployment.
- Rejection: Packaging the application into a ZIP file is not appropriate for container-based applications, as it doesn't align with containerization best practices (which involve Docker images). Additionally, using S3 would require more manual steps to deploy the application, which goes against the goal of minimizing operational effort.
Option B: Package the application into a container image by using the Docker CLI. Upload the image to Amazon Elastic Container Registry (Amazon ECR).
- Reasoning: This option aligns with best practices for containerized application deployment. By packaging the application as a Docker image and uploading it to Amazon ECR (which is AWS's managed container registry), the developer can use the image to deploy to various container services like Amazon ECS or EKS.
- Best Use Case: This is the correct and most efficient step in container-based application deployments, as it follows the standard workflow for building and storing Docker images on AWS. ECR simplifies storing and versioning container images and integrates well with ECS or EKS.
Option C: Deploy the application to an Amazon EC2 instance by using AWS CodeDeploy.
- Reasoning: Deploying to an EC2 instance directly and using AWS CodeDeploy involves managing the infrastructure for EC2 instances, which increases the operational effort. For a containerized application, it is more efficient to use container orchestration services like Amazon ECS or EKS, which abstract away the need to manage i...
Author: Aditya · Last updated May 18, 2026
A developer supports an application that accesses data in an Amazon DynamoDB table. One of the item attributes is expirationDate in the timestamp format. The application uses this attribute to find items, archive them, and remove them from the table based on the timestamp value.
The application will be decommissioned soon, and the developer must find another way to i...
In this scenario, the developer is looking for a solution that requires the least amount of code to implement while maintaining the ability to handle items in DynamoDB based on the `expirationDate` attribute. The goal is to automatically delete and potentially process items with minimal custom coding. Let's evaluate each option:
Option A: Enable TTL on the expirationDate attribute in the table. Create a DynamoDB stream. Create an AWS Lambda function to process the deleted items. Create a DynamoDB trigger for the Lambda function.
- Reasoning: Time to Live (TTL) in DynamoDB can automatically delete items when the expiration timestamp is reached. By enabling TTL on the `expirationDate` attribute, items will be automatically deleted without any need for custom deletion logic. Additionally, creating a DynamoDB stream and using a Lambda function to process the deleted items can help in any post-deletion tasks like archiving or logging.
- Best Use Case: This option requires the least amount of custom code because TTL takes care of the deletion automatically. The DynamoDB stream provides an easy mechanism to handle any actions after items are deleted, and Lambda can be used to process them efficiently.
- Explanation: TTL simplifies the deletion process by automatically removing expired items without needing manual intervention. The stream and Lambda function are simply to handle post-deletion tasks, and the setup is straightforward.
Option B: Create two AWS Lambda functions: one to delete the items and one to process the items. Create a DynamoDB stream. Use the DeleteItem API operation to delete the items based on the expirationDate attribute. Use the GetRecords API operation to get the items from the DynamoDB stream and process them.
- Reasoning: This option suggests manually deleting the items with a Lambda function using the `DeleteItem` API and then processing the deleted items via a DynamoDB stream. While this approach works, it involves more custom code than necessary. The manual deletion via `DeleteItem` introduces unnecessary complexity when TTL can handle this automatically.
- Rejection: This option requires more code and logic for manually del...
Author: Ethan · Last updated May 18, 2026
A developer needs to implement a custom machine learning (ML) library in an application. The size of the library is 15 GB. The size of the library is increasing. The application uses AWS Lambda functions. All the Lamb...
To determine the best solution for meeting the requirements, let's analyze each option:
Option A: Save the library in Lambda layers. Attach the layers to all Lambda functions.
- Limitations: Lambda layers have a maximum size limit of 50 MB for direct uploads and 250 MB for compressed archives. Given that the library is 15 GB and growing, this option is not viable as Lambda layers cannot accommodate such large sizes.
- Use case: Lambda layers are ideal for small, reusable libraries or dependencies shared across Lambda functions, but not for large files.
Rejected because of the size limitation.
Option B: Save the library in Amazon S3. Download the library from Amazon S3 inside the Lambda function.
- Advantages: S3 is highly scalable and can accommodate large files, such as a 15 GB library. However, Lambda functions have a 15-minute execution time limit, so downloading and initializing a large library each time the function is invoked could lead to performance issues or timeouts. Additionally, the function would need to handle the download and unzipping of the library in each invocation, adding overhead.
- Use case: This option is typically used for scenarios where the library is updated frequently or the application does not have strict performance requirements regarding startup time.
Rejected due to the potential for performance degradation and timeouts for large files.
Option C: Save the library as a Lambda container image. Redeploy the ...
Author: Daniel · Last updated May 18, 2026
A developer is designing a serverless application for a game in which users register and log in through a web browser. The application makes requests on behalf of users to a set of AWS Lambda functions that run behind an Amazon API Gateway HTTP API.
The developer needs to implement a solution to register and log in users on the application's sign-in page...
The goal is to implement a user registration and login system for a serverless application with minimal operational overhead and ongoing management of user identities. Let’s evaluate each option to see which one best aligns with these requirements.
Option A: Create Amazon Cognito user pools for external social identity providers. Configure IAM roles for the identity pools.
- Reasoning: Amazon Cognito user pools are specifically designed for managing user registration, authentication, and profile management with minimal overhead. With Cognito, you can set up user pools to handle sign-up and sign-in, and you can integrate with external social identity providers (like Google, Facebook, or Amazon) for authentication. This solution also scales automatically and requires minimal maintenance. The use of IAM roles in conjunction with Cognito identity pools allows users to access AWS resources securely based on their roles.
- Why it's selected: This solution is highly suited for managing user identities with minimal operational overhead, as it handles user registration, authentication, and authorization seamlessly. It also integrates with API Gateway and Lambda with ease, making it ideal for serverless applications. The ongoing management of user identities is minimal, as Cognito takes care of it.
Option B: Program the sign-in page to create users' IAM groups with the IAM roles attached to the groups.
- Reasoning: Managing user sign-ins and registrations via IAM groups is not appropriate for most applications, especially serverless ones. IAM is designed for managing permissions for AWS resources rather than for handling user authentication in applications. IAM groups are primarily used for granting access to AWS resources, not for handling user identities in web applications. This approach would require significant custom coding to manage users, roles, and permissions.
- Why it's rejected: This solution adds unnecessary complexity and doesn't provide the speci...
Author: Lucas Carter · Last updated May 18, 2026
A company has a web application that is hosted on Amazon EC2 instances. The EC2 instances are configured to stream logs to Amazon CloudWatch Logs. The company needs to receive an Amazon Simple Notification Service (Amazon SNS) notification when the number of application...
Let's evaluate each option in the context of receiving an SNS notification when the number of application error messages exceeds a defined threshold within a 5-minute period:
Option A: Rewrite the application code to stream application logs to Amazon SNS. Configure an SNS topic to send a notification when the number of errors exceeds the defined threshold within a 5-minute period.
- Reasoning: This option suggests modifying the application code to stream logs directly to SNS, but SNS is primarily used for sending notifications and not for log management or analysis. SNS cannot efficiently process and filter logs based on patterns such as error messages or thresholds. This would require significant changes to the application and is inefficient for this use case.
- Why it's rejected: SNS is not designed to directly handle log processing or error counting, so this approach would introduce unnecessary complexity and operational overhead.
Option B: Configure a subscription filter on the CloudWatch Logs log group. Configure the filter to send an SNS notification when the number of errors exceeds the defined threshold within a 5-minute period.
- Reasoning: CloudWatch Logs allows you to configure a filter pattern to look for specific log messages (such as error messages) in the log stream. However, the subscription filter feature is mainly used for sending log data to other services like Lambda or Kinesis Streams, and it does not directly support counting events or thresholds within a period.
- Why it's rejected: While the filter pattern could match error messages, subscription filters cannot directly handle the concept of counting errors over a specific time frame (like 5 minutes). You would need an additional step to aggregate and trigger notifications, which complicates the solution.
Option C: Install and configure the Amazon Inspector agent on the EC2 instances to monitor for errors. Configure Amazon Inspector to send an SNS notification when the number of errors exceeds ...
Author: Ella · Last updated May 18, 2026
A photo sharing application uses Amazon S3 to store image files. All user images are manually audited for inappropriate content by a third-party company. The audits are completed 1-24 hours after user upload and the results are written to an Amazon DynamoDB table, which uses the S3 object key as a primary key. The database items can be queried by using a REST API created by the third-party company.
An application developer needs to im...
The goal is to automate the process of tagging S3 objects based on content audit results stored in DynamoDB, using the most operationally efficient solution. Let’s evaluate the options:
Option A: Create an AWS Lambda function to run in response to the s3:ObjectCreated event type. Write the S3 key to an Amazon Simple Queue Service (Amazon SQS) queue with a visibility timeout of 24 hours. Create and configure a second Lambda function to read items from the queue. Retrieve the results for each item from the DynamoDB table. Tag each S3 object accordingly.
- Reasoning: This option involves using Lambda in response to S3 events to send the S3 key to an SQS queue. The second Lambda reads from the queue, waits for the audit result in DynamoDB, and then tags the object. While this solution could work, the use of SQS with a 24-hour visibility timeout introduces complexity in managing the queue, ensuring that items are not lost or processed too early, and monitoring for failures.
- Why it's rejected: The extra overhead of managing an SQS queue, including the visibility timeout and failure handling, adds complexity that can be avoided in other solutions.
Option B: Create an AWS Lambda function to run in response to the s3:ObjectCreated event type. Integrate the function into an AWS Step Functions standard workflow. Define an AWS Step Functions Wait state and set the value to 24 hours. Create and configure a second Lambda function to retrieve the audit results and tag the S3 objects accordingly after the Wait state is over.
- Reasoning: This solution uses Step Functions with a Wait state to introduce a 24-hour delay before retrieving audit results and tagging the S3 object. While Step Functions provides a nice framework for orchestrating workflows, it introduces additional complexity and costs with the need to manage the Step Functions state machine, especially if the workflow is simple. Step Functions also has execution costs and timeouts that need to be managed carefully.
- Why it's rejected: While functional, Step Functions adds unnecessary complexity for this task, especially given the need to wait for a fixed amount of time (24 hours). Simpler solutions would be more efficient.
Option C: Cre...
Author: Noah · Last updated May 18, 2026
A company has built an AWS Lambda function to convert large image files into output files that can be used in a third-party viewer application. The company recently added a new module to the function to improve the output of the generated files. However, the new module has increased the bundle size and has increased th...
The goal is to increase the speed of Lambda function deployment after a module was added that increased the bundle size and the time needed for deployment. Let's evaluate each option:
Option A: Use AWS CodeDeploy to deploy the function code.
- Reasoning: AWS CodeDeploy is a service designed for automating application deployments across various compute resources such as EC2 instances or Lambda functions. However, it doesn't directly improve the deployment speed itself for Lambda functions; rather, it provides deployment management and monitoring capabilities. It’s more beneficial for managing deployment processes but does not reduce the size of the Lambda deployment package or optimize the deployment time.
- Why it's rejected: CodeDeploy does not directly address the issue of large function packages or reduce the time needed for Lambda code updates. It is more for managing deployment logistics rather than optimizing the deployment speed.
Option B: Use Lambda layers to package and load dependencies.
- Reasoning: Lambda layers allow you to separate dependencies from your function code. By moving the dependencies (e.g., libraries, modules) into a layer, the Lambda function code itself can be kept smaller and only the function-specific code needs to be deployed. This means only the core changes to the function code are deployed, not the entire bundle of dependencies, which speeds up deployment times. Layers can also be shared across multiple functions, further improving operational efficiency.
- Why it's selected: Using Lambda layers reduces the overall size of the Lambda function deployment and can significantly speed up the deployment process ...
Author: Ethan Smith · Last updated May 18, 2026
A developer creates a static website for their department. The developer deploys the static assets for the website to an Amazon S3 bucket and serves the assets with Amazon CloudFront. The developer uses origin access control (OAC) on the CloudFront distribution to access the S3 bucket.
The developer notices users can access the root URL and specific pages but cannot access directories without specifying a file name. For example, /products/index.html works, but...
Let’s analyze each option based on the requirements and explain which one will meet the needs of enabling access to directories without exposing the S3 bucket publicly.
A) Update the CloudFront distribution's settings to index.html as the default root object is set.
- Explanation: This option configures CloudFront to serve the `index.html` file when a directory is requested, like `/products/`. However, it doesn't solve the problem of serving directories without a file being specified. This option would work for requests to the root directory (`/`), but it doesn’t handle cases where a directory is specified but the user doesn’t type `index.html` (e.g., `/products/`).
- Rejected: This option does not address the issue of directory access in general, only the root.
B) Update the Amazon S3 bucket settings and enable static website hosting. Specify index.html as the Index document. Update the S3 bucket policy to enable access. Update the CloudFront distribution's origin to use the S3 website endpoint.
- Explanation: Enabling static website hosting on the S3 bucket and specifying `index.html` as the index document would allow directories to return the `index.html` file when accessed. The S3 website endpoint would then serve the files as a website, and CloudFront would forward requests to that endpoint. However, the problem with this solution is that it exposes the S3 bucket publicly (via the website endpoint), which goes against the requirement to not expose the S3 bucket publicly.
- Rejected: This option would expose the S3 bucket publicly, which contradicts the requirement.
C) Create a CloudFront function that examines the request URL and appends index.html when dir...
Author: Ethan Smith · Last updated May 18, 2026
A developer is testing a RESTful application that is deployed by using Amazon API Gateway and AWS Lambda. When the developer tests the user login by using credentials that are not valid, the developer receives an HTTP 405: METHOD_NOT_ALLOWED error. The developer has verified that the test i...
To resolve this issue, let's break down each option and analyze the appropriate error code for the situation where invalid credentials are provided.
A) HTTP 401 (Unauthorized)
- Explanation: HTTP 401 is the most appropriate response when the client request requires authentication, but the credentials provided are either missing, incorrect, or invalid. This is exactly the scenario when a user attempts to log in with invalid credentials, and it is a standard response for failed authentication.
- Selected: This is the correct response because it indicates that the user is not authorized due to incorrect credentials.
B) HTTP 404 (Not Found)
- Explanation: HTTP 404 is used when the requested resource could not be found on the server. It implies that the URL does not exist or is incorrect. In this case, if the URL is correct, but the credentials are wrong, the resource does exist, but access is denied due to invalid credentials. Therefore, HTTP 404 is not appropriate.
- Rejected: This error code would be misleading, as the resource exists b...
Author: Noah Williams · Last updated May 18, 2026
A developer must use multi-factor authentication (MFA) to access data in an Amazon S3 bucket that is in another AWS account.
Which AWS Security Token Service (AWS STS) API operati...
To address this requirement, we need to focus on using multi-factor authentication (MFA) with AWS Security Token Service (STS) to access data in an Amazon S3 bucket across AWS accounts. Let's analyze each option in detail.
A) AssumeRoleWithWebIdentity
- Explanation: `AssumeRoleWithWebIdentity` is used for web identity federation (such as logging in with Google or Facebook) to assume an IAM role. It doesn’t directly involve MFA for cross-account access. This API operation is intended for use with federated users (e.g., users authenticated by external identity providers).
- Rejected: This option is irrelevant for multi-factor authentication and cross-account access using MFA.
B) GetFederationToken
- Explanation: `GetFederationToken` is used to create temporary security credentials for federated users. It doesn't require MFA as part of the operation itself. It is commonly used when you want to provide temporary access to AWS resources for users outside of your AWS environment (e.g., employees or systems in a different organization).
- Rejected: This option does not support MFA and is not designed for cross-account access in the way MFA would be used.
C) AssumeRoleWithSAML
- Explanation: `AssumeRoleWithSAML` is used in the context of SA...
Author: Harper · Last updated May 18, 2026
A developer designed an application on an Amazon EC2 instance. The application makes API requests to objects in an Amazon S3 bucket.
Which combination of steps will ensure that t...
To ensure the application on an Amazon EC2 instance can make API requests to objects in an Amazon S3 bucket in the most secure manner, let's analyze each option:
A) Create an IAM user that has permissions to the S3 bucket. Add the user to an IAM group.
- Explanation: This approach involves creating an IAM user, granting permissions to the S3 bucket, and then placing the user in an IAM group. However, managing permissions for an application running on EC2 using IAM users and groups isn't the best practice. It involves manual management of credentials, which increases the risk of exposing them.
- Rejected: Storing IAM user credentials on the EC2 instance is not a best practice. It's prone to security risks, such as unintentional exposure of the credentials.
B) Create an IAM role that has permissions to the S3 bucket.
- Explanation: This option is good because creating an IAM role with permissions to the S3 bucket is the right approach for securely granting the EC2 instance permissions to access S3. However, the role by itself needs to be associated with the EC2 instance in some way.
- Partial Selection: This step is important but not sufficient on its own, as the IAM role needs to be attached to the EC2 instance for it to take effect.
C) Add the IAM role to an instance profile. Attach the instance profile to the EC2 instance.
- Explanation: This is the recommended approach. After creating the IAM role with appropriate permissions for the S3 bucket, the next step is to create an instance profile and attach it to the EC2 instance. This allows the EC2 instance to assume t...
Author: Ethan Smith · Last updated May 18, 2026
An AWS Lambda function requires read access to an Amazon S3 bucket and requires read/write access to an Amazon DynamoDB table. The correct IAM policy already exists.
What is the MOST secur...
Let's analyze each option and determine the most secure way to grant an AWS Lambda function access to an S3 bucket and a DynamoDB table.
A) Attach the existing IAM policy to the Lambda function.
- Explanation: Lambda functions don’t directly have IAM policies attached to them. Instead, they are granted permissions through an IAM role that is associated with the Lambda function. This option is incorrect because you cannot directly attach IAM policies to the Lambda function.
- Rejected: IAM policies cannot be attached directly to Lambda functions; they must be associated through an IAM role.
B) Create an IAM role for the Lambda function. Attach the existing IAM policy to the role. Attach the role to the Lambda function.
- Explanation: This is the most secure and recommended approach. AWS Lambda functions assume an IAM role to obtain the necessary permissions to interact with other AWS services. By creating a specific IAM role for the Lambda function and attaching the appropriate policy (already existing) to the role, you can securely grant the Lambda function the required read access to S3 and read/write access to DynamoDB.
- Selected: This is the most secure method because it uses IAM roles, which provide a least-privilege approach by granting only the necessary permissions for the function's operations.
C) Create an IAM user with programmatic access. Attach the existing IAM policy to the user. Add the user access key ID and secret access key as environme...
Author: Grace · Last updated May 18, 2026
A developer is using AWS Step Functions to automate a workflow. The workflow defines each step as an AWS Lambda function task. The developer notices that runs of the Step Functions state machine fail in the GetResource task with either an IllegalArgumentException error or a TooManyRequestsException error.
The developer wants the state machine to stop running when the state machine encounters an IllegalArgumentException error. The state machine needs to retry the GetResource task one additional time after 10 seconds if the state machine encounters a T...
Let’s break down each option based on the requirements and factors involved:
Option A
- What it does: The solution includes adding a Delay task after the GetResource task. The Delay task would be triggered when a `TooManyRequestsException` is encountered. After the delay of 10 seconds, the GetResource task would run again.
- Why this is not ideal: Although this does address the retry with a delay, adding an additional Delay task is not the most straightforward or efficient approach for retrying a task with a specific interval. This adds unnecessary complexity because AWS Step Functions already has built-in retry mechanisms that don’t require explicitly adding a Delay task. Additionally, this solution would need manual configuration for retry logic and doesn’t directly prevent the state machine from failing on the second retry if it fails again.
Option B
- What it does: This solution adds a catcher to handle the `TooManyRequestsException` with a retry configuration of one additional attempt after an interval of 10 seconds.
- Why this is not ideal: This solution doesn't directly address the condition where you need to stop the state machine on the second failure. If the second retry fails, this option doesn't define the failure action well enough. The "catcher" will just handle the exception, and the task will attempt to continue instead of stopping on the second failure. Also, it introduces unnecessary complexity in managing both the "catcher" and retry parameters manually.
Option C (Selected Option)
- What it does: This option uses a retrier to configure retry behavior directly for the GetResource task. It specifies th...
Author: Zara · Last updated May 18, 2026
A developer is creating a serverless application that uses an AWS Lambda function. The developer will use AWS CloudFormation to deploy the application. The application will write logs to Amazon CloudWatch Logs. The developer has created a log group in a CloudFormation template for the application to use. The developer needs to modify th...
Let’s analyze each option based on the requirement to pass the log group name to the Lambda function at runtime.
Option A: Use the AWS::Include transform in CloudFormation to provide the log group's name to the application.
- What it does: The `AWS::Include` transform allows you to include external files (such as templates or scripts) into your CloudFormation template. This can help include pre-existing CloudFormation templates or resources.
- Why this is not ideal: This option is unnecessary for simply passing a log group’s name to the Lambda function. The `AWS::Include` transform is useful for including external files or templates but isn't directly suited for referencing resources like a log group in the current template and passing them to the Lambda function. This adds unnecessary complexity and is not the best fit for the use case.
Option B: Pass the log group's name to the application in the user data section of the CloudFormation template.
- What it does: The `UserData` section is primarily used to specify commands that are executed when launching EC2 instances (e.g., for configuring servers when they start).
- Why this is not ideal: The `UserData` section is not relevant in a serverless context because it's meant for EC2 instances. Lambda functions don’t use EC2-like `UserData` sections. Using `UserData` for a Lambda function is not the correct approach.
Option C: Use the CloudFormation template's Mappings section to specify the log group's name for the application.
- What it does: The Mappings section in a CloudFormation template all...
Author: Liam · Last updated May 18, 2026
A developer is creating an Amazon DynamoDB table by using the AWS CLI. The DynamoDB table must use server-side encryption with an AWS owned encryption key.
How sh...
Let's analyze each option based on the requirement to use server-side encryption with an AWS owned encryption key for the DynamoDB table:
Option A: Create an AWS Key Management Service (AWS KMS) customer managed key. Provide the key's Amazon Resource Name (ARN) in the KMSMasterKeyId parameter during creation of the DynamoDB table.
- What it does: This option involves creating a customer managed key in AWS KMS (Key Management Service) and specifying its ARN during the table creation. Customer managed keys are fully under the control of the user, providing more flexibility and fine-grained permissions.
- Why this is not ideal: The requirement specifically asks for an AWS owned encryption key, which means using an AWS managed key rather than a customer-managed key. A customer-managed key involves more complexity, such as managing key rotation, access control, and policy configurations, which is not required in this case. This option is too advanced and unnecessary for the given requirement.
Option B: Create an AWS Key Management Service (AWS KMS) AWS managed key. Provide the key's Amazon Resource Name (ARN) in the KMSMasterKeyId parameter during creation of the DynamoDB table.
- What it does: This option uses an AWS managed key for encryption and specifies the ARN of that key during the table creation.
- Why this is not ideal: AWS managed keys are indeed the proper solution for encryption but, AWS DynamoDB automatically uses an AWS owned encryption key by default, so you don't need to explicitly specify the ARN of a managed key. The scenario call...
Author: Liam · Last updated May 18, 2026
A company has an application that runs across multiple AWS Regions. The application is experiencing performance issues at irregular intervals. A developer must use AWS X-Ray to implement distributed tracing for the application to troublesh...
Let's analyze each option based on the requirement to implement distributed tracing for the application across multiple AWS Regions to troubleshoot performance issues:
Option A: Use the X-Ray console to add annotations for AWS services and user-defined services.
- What it does: The X-Ray console allows you to visualize and manage traces but does not allow you to directly add annotations for services. Annotations need to be added at the application level, typically through the X-Ray SDK or daemon.
- Why this is not ideal: This option does not fulfill the requirement to add annotations programmatically. Adding annotations in the console is not a method that allows for real-time tracing or capturing data across multiple Regions in the application, so it's not a viable solution for troubleshooting performance issues.
Option B: Use Region annotation that X-Ray adds automatically for AWS services. Add Region annotation for user-defined services.
- What it does: X-Ray automatically adds the Region annotation for AWS services, but for user-defined services, the developer must manually add Region annotations to the traces.
- Why this is ideal: This option is correct for addressing the requirement. AWS X-Ray automatically captures the region information for AWS services, which is useful when tracing performance issues across multiple regions. For user-defined services (like a custom API or application), adding Region annotations manually allows you to correlate traces across regions more accurately. This ensures the developer can trace the flow of requests between services, regardless of the region in which they are running.
...
Author: Emma · Last updated May 18, 2026
A company runs an application on AWS. The application uses an AWS Lambda function that is configured with an Amazon Simple Queue Service (Amazon SQS) queue called high priority queue as the event source. A developer is updating the Lambda function with another SQS queue called low priority queue as the event source. The Lambda function must always read up to 10 simultaneous messages from the high priority...
Let's evaluate each option to find the best solution for ensuring the Lambda function processes up to 10 simultaneous messages from the high priority queue before reading from the low priority queue, with a maximum of 100 simultaneous invocations.
Option A: Set the event source mapping batch size to 10 for the high priority queue and to 90 for the low priority queue.
- What it does: This sets the batch size (the number of messages Lambda reads at once) for each SQS queue. The batch size for the high priority queue is set to 10, meaning Lambda will read 10 messages at a time from that queue. The low priority queue has a batch size of 90, meaning Lambda can read 90 messages at a time from that queue.
- Why this is not ideal: This does not guarantee that Lambda will process messages from the high priority queue first. It only controls how many messages are processed in each batch but does not control the concurrency or prioritization between queues. This does not directly limit Lambda's simultaneous invocations based on prioritization.
Option B: Set the delivery delay to 0 seconds for the high priority queue and to 10 seconds for the low priority queue.
- What it does: Delivery delay determines how long messages are delayed before they are available for processing in the SQS queue. By setting a delay of 10 seconds on the low priority queue, the messages from that queue will not be processed until the delay expires.
- Why this is not ideal: This approach introduces an artificial delay to the low priority queue, which doesn't provide the fine-grained control over concurrency or ensure that high priority messages are processed first. It also doesn’t meet the requirement of limiting Lambda invocations to 100 simultaneous executions.
Option C: Set the event source mapping maximum concurrency to 10 for the high priority queue and to 90 for the low priority queue.
- What it does...
Author: Alexander · Last updated May 18, 2026
A data visualization company wants to strengthen the security of its core applications. The applications are deployed on AWS across its development, staging, pre-production, and production environments. The company needs to encrypt all of its stored sensitive credentials. The sensitive credentials need to be automatically rotated. A version of the...
To meet the company's requirements, the solution needs to encrypt sensitive credentials, automatically rotate them, and store different versions for each environment (development, staging, pre-production, and production). Let’s evaluate the options based on these key factors:
A) Configure AWS Secrets Manager versions to store different copies of the same credentials across multiple environments.
- Encryption & Rotation: AWS Secrets Manager supports encryption and automatic rotation of secrets, which is crucial for sensitive credentials.
- Versioning: Secrets Manager supports versioning, which allows for different versions of the same secret.
- Multiple Environments: However, using the same secret for multiple environments (even with different versions) can create confusion and risks in managing access and identifying the right version for each environment.
- Operational Efficiency: While Secrets Manager does provide versioning, managing versions for each environment in one secret is not ideal for clarity and organization. It can increase the complexity of management and access control.
B) Create a new parameter version in AWS Systems Manager Parameter Store for each environment. Store the environment-specific credentials in the parameter version.
- Encryption & Rotation: AWS Systems Manager Parameter Store supports encryption, but the automatic rotation of credentials is a manual process or requires an additional setup (e.g., Lambda function).
- Versioning: Parameter Store allows versioning, which can be used to track different credentials for each environment. However, the manual process of credential rotation could lead to operational overhead.
- Multiple Environments: This approach could be effective if the company is already using Systems Manager, but it's less scalable compared to Secrets Manager for automated credential rotation.
- Operational Efficiency: Though possible, this option would require more custom automation for rotating credentials and managing ...
Author: ShadowWolf101 · Last updated May 18, 2026
A developer is investigating an issue in part of a company's application. In the application, messages are sent to an Amazon Simple Queue Service (Amazon SQS) queue. The AWS Lambda function polls messages from the SQS queue and sends email messages by using Amazon Simple Email Service (Amazon SES). Users have been rec...
To investigate the issue of duplicate email messages, we need to consider the behavior of the Amazon SQS queue, the AWS Lambda function, and the Amazon SES service. Let's evaluate each option and determine which ones are most likely to explain the duplication:
Option A: Standard SQS queues support at-least-once message delivery.
- Why this is selected: Standard SQS queues guarantee at-least-once delivery of messages, meaning that a message might be delivered multiple times in high-traffic situations. This could lead to duplicate emails being sent if the same message is processed more than once. This is a common issue when using standard SQS queues.
- Key factor: The "at-least-once" delivery policy is a key reason for potential duplication, especially under heavy traffic, because SQS could deliver the same message multiple times.
Option B: Standard SQS queues support exactly-once processing, so the duplicate email messages are because of user error.
- Why it's rejected: Standard SQS queues do not support exactly-once processing. They support at-least-once delivery, which means that duplicate messages are possible. Exactly-once processing is only supported by FIFO queues, not standard queues. Hence, this option is incorrect.
- Key factor: SQS does not guarantee exactly-once processing for standard queues, making this explanation inaccurate.
Option C: Amazon SES has the DomainKeys Identified Mail (DKIM) authentication incorrectly configured.
- Why it's rejected: While DKIM misconfigurations can cause delivery or authenticity issues, they are unlikely to cause duplicate email messages. Duplicat...
Author: Lucas · Last updated May 18, 2026
A developer is deploying a company's application to Amazon EC2 instances. The application generates gigabytes of data files each day. The files are rarely accessed, but the files must be available to the application's users within minutes of a request during the first year of storage. The company must ...
To implement the application to meet the given requirements in the most cost-effective manner, we need to focus on the following key factors:
1. Data storage: The data files are large (gigabytes per day), and the files are rarely accessed but must be available within minutes.
2. Retention period: The files must be retained for 7 years, which suggests a long-term storage solution.
3. Cost-effectiveness: The solution must be cost-effective because of the large amount of data being generated.
Let's evaluate each option:
Option A: Store the files in an Amazon S3 bucket. Use the S3 Glacier Instant Retrieval storage class. Create an S3 Lifecycle policy to transition the files to the S3 Glacier Deep Archive storage class after 1 year.
- Why this is selected:
- S3 Glacier Instant Retrieval is designed for data that is rarely accessed but needs to be retrieved quickly when needed, which fits the application's requirement of having files available within minutes.
- S3 Glacier Deep Archive offers the lowest cost storage for long-term retention, making it a very cost-effective option for storing data that needs to be retained for 7 years but is rarely accessed.
- Lifecycle policies: The use of S3 Lifecycle policies allows automatic management of transitions from Glacier Instant Retrieval to Glacier Deep Archive after one year, optimizing both access time and cost.
- Key factor: This combination gives quick access when needed (Glacier Instant Retrieval) and long-term, low-cost storage (Glacier Deep Archive) after one year, making it ideal for the application’s needs.
Option B: Store the files in an Amazon S3 bucket. Use the S3 Standard storage class. Create an S3 Lifecycle policy to transition the files to the S3 Glacier Flexible Retrieval storage class after 1 year.
- Why this is rejected:
- S3 Standard is more expensive than the Glacier storage classes. Since the files are rarely accessed, storing them in S3 Standard would not be cost-effective for the application's needs.
- Glacier Flexible Retrieval is more expensive than Glacier Deep Archive and is better suited for use cas...
Author: Mia · Last updated May 18, 2026
A company's developer has deployed an application in AWS by using AWS CloudFormation. The CloudFormation stack includes parameters in AWS Systems Manager Parameter Store that the application uses as configuration settings. The application can modify the parameter values.
When the developer updated the stack to create additional resources with tags, the developer noted that the parameter values were reset and that the values ignored the latest changes made by the application. The developer needs to change...
To address the issue where the application modifies parameters in AWS Systems Manager Parameter Store but the updates are reset when the CloudFormation stack is updated, let's evaluate the solutions based on the requirements:
Key Requirements:
- The developer needs to avoid resetting the parameter values outside the CloudFormation stack.
- The solution should minimize development effort.
A) Modify the CloudFormation stack to set the deletion policy to Retain for the Parameter Store parameters.
- Reasoning:
- The `Retain` deletion policy ensures that resources (like Parameter Store parameters) are not deleted when the stack is deleted or updated.
- Issue: While this will prevent the parameters from being deleted during stack updates, it does not address the problem of parameters being reset (overwritten with default values) when the stack is updated. The issue is about updating the stack, not deleting it.
- Conclusion: This option won't fully solve the problem of preserving the updated parameter values during stack updates.
B) Create an Amazon DynamoDB table as a resource in the CloudFormation stack to hold configuration data for the application. Migrate the parameters that the application is modifying from Parameter Store to the DynamoDB table.
- Reasoning:
- DynamoDB could serve as a highly scalable and easily accessible storage solution for configuration data. It would allow the application to modify the data without risk of overwriting during stack updates.
- Development Effort: This solution requires more work to set up the DynamoDB table, implement read/write access in the application, and migrate existing data. While this approach avoids the reset problem, it adds significant development overhead compared to other options.
- Conclusion: This option solves the issue but involves more development effort, making it less optimal than others.
C) Create an Amazon RDS DB instance as a resource in the CloudFormation stack. Create a table i...
Author: RadiantJaguar56 · Last updated May 18, 2026
A company has a social media application that receives large amounts of traffic. User posts and interactions are continuously updated in an Amazon RDS database. The data changes frequently, and the data types can be complex. The application must serve read requests with minimal latency.
The application's current architecture struggles to deliver the...
To address the performance challenges of serving rapid read requests with minimal latency in the context of frequently updated data with complex data types, we need to focus on optimizing read performance and reducing the load on the underlying Amazon RDS database.
Let's evaluate each option:
Option A: Use Amazon DynamoDB Accelerator (DAX) in front of the RDS database to provide a caching layer for the high volume of rapidly changing data.
- Why this is rejected: DAX is specifically designed for Amazon DynamoDB, not Amazon RDS. While it provides an in-memory cache for DynamoDB, it does not work with Amazon RDS databases. Since the application uses RDS, DAX is not a suitable solution here.
- Key factor: DAX is incompatible with RDS because it’s built for DynamoDB, making it irrelevant for this use case.
Option B: Set up Amazon S3 Transfer Acceleration on the RDS database to enhance the speed of data transfer from the databases to the application.
- Why this is rejected: S3 Transfer Acceleration is a service designed to speed up transfers of large files to and from Amazon S3 over the internet. It does not apply to RDS databases and would not provide a performance improvement for rapidly changing data or help with read latency issues.
- Key factor: S3 Transfer Acceleration is not relevant to an RDS-based architecture, where the challenge is to improve real-time read performance.
Option C: Add an Amazon CloudFront distribution in front of the RDS database to provide a caching layer for the high volume of rapidly changing data.
- Why this is rejected: CloudFront is a content delivery network (CDN) primarily used ...
Author: Olivia · Last updated May 18, 2026
A developer created an AWS Lambda function that performs a series of operations that involve multiple AWS services. The function's duration time is higher than normal. To determine the cause of the issue, the developer must investigate traffic...
To investigate the cause of high duration times in an AWS Lambda function involving multiple services, it's important to trace the traffic and interactions between the services involved. Here’s a breakdown of each option:
A) Enable AWS X-Ray active tracing in the Lambda function. Review the logs in X-Ray.
- Explanation: AWS X-Ray is a service designed specifically for tracing the path of requests as they travel through various AWS services. By enabling active tracing in the Lambda function, you can visualize the time taken by each service in the chain, along with any delays between the services.
- Why it's selected: X-Ray will provide a comprehensive end-to-end trace of the request, showing exactly where the time is spent (e.g., which AWS service is taking longer to respond), and will allow you to analyze and pinpoint bottlenecks between services.
- Why other options are rejected:
- CloudTrail logs (B) give details on AWS API calls, but they won’t help in identifying performance bottlenecks or the specific time taken by different AWS services in a Lambda execution.
- AWS Config logs (C) focus on tracking configuration changes in AWS resources, not the performance or traffic between them.
- CloudWatch logs (D) provide logs from the Lambda execution but do not offer insights into the traffic between services or detailed tracing of performance over time.
B) Configure AWS CloudTrail. View the trail logs that are associated with the Lambda function.
- Explanation: CloudTrail records API calls made on AWS resources. While it can show you when a Lambda function was invoked and what AWS services were called, it does not provide the detailed timing information or performance-related data needed to identify latency ...
Author: Zara1234 · Last updated May 18, 2026
A company has on-premises data centers that run an image processing service. The service consists of containerized applications that run on Kubernetes clusters. All the applications have access to the same NFS share for files and data storage.
The company is running out of NFS capacity in the data centers and needs to migrate to AWS as so...
To meet the requirements of migrating to AWS and maintaining high availability for the Kubernetes clusters, it's essential to find solutions that address both the storage needs (due to the NFS capacity issue) and the deployment of the containerized applications on a highly available infrastructure.
Breakdown of each option:
A) Transfer the information that is in the NFS share to an Amazon Elastic Block Store (Amazon EBS) volume. Upload the container images to Amazon Elastic Container Registry (Amazon ECR).
- Why it's rejected:
- Amazon EBS is a block storage service, not designed for sharing data between multiple instances (like the NFS share). EBS volumes are attached to individual EC2 instances, meaning they are not natively scalable or shared in the way NFS is used across multiple Kubernetes pods.
- While ECR is a good solution for storing container images, using EBS for shared storage will not meet the need for high availability across Kubernetes nodes.
B) Transfer the information that is in the NFS share to an Amazon Elastic File System (Amazon EFS) volume. Upload the container images to Amazon Elastic Container Registry (Amazon ECR).
- Why it's selected:
- Amazon EFS is a fully managed, scalable file storage service that is designed for use with multiple EC2 instances (or Kubernetes nodes), which is exactly what is needed to replace the on-premises NFS share.
- EFS supports high availability and scalability, ensuring that the data can be shared across the Kubernetes cluster in AWS without running into capacity issues.
- ECR is the standard AWS service for container image storage, which is a good choice for storing the container images.
C) Create an Amazon Elastic Container Service (Amazon ECS) cluster to run the applications. Configure each node of the cluster to mount the Amazon Elastic Block Store (Amazon EBS) volume at the required path for the container images.
- Why it's rejected:
- ECS can be used to run containerized applications, but it does not natively support the high availability and scaling needs that Kubernetes can provide. The problem is that EBS volumes cannot be shared between multiple ECS...
Author: Maya2022 · Last updated May 18, 2026
A company has an analytics application that uses an AWS Lambda function to process transaction data asynchronously. A developer notices that asynchronous invocations of the Lambda function sometimes fail. When failed Lambda function invocations occur, the developer wants...
To address the requirement of handling failed asynchronous Lambda invocations and triggering a second Lambda function to log and process errors, let’s evaluate each option in detail:
A) Configure a Lambda function destination with a failure condition. Specify Lambda function as the destination type. Specify the error-handling Lambda function's Amazon Resource Name (ARN) as the resource.
- Explanation: AWS Lambda provides a built-in destination feature for asynchronous invocations, which allows you to specify a destination for both successful and failed invocations. When a failure occurs, Lambda can send the event data to a specified destination, such as another Lambda function, an SNS topic, or an SQS queue. This feature directly supports handling error scenarios by triggering another Lambda function when the primary function fails.
- Why it's selected: This solution is designed specifically for handling failure scenarios in asynchronous invocations, allowing you to trigger the error-handling Lambda function automatically whenever the primary function fails.
- Why other options are rejected:
- B) Enabling X-Ray active tracing helps you trace the execution of Lambda functions but does not automatically trigger a secondary Lambda function to handle errors. X-Ray captures dia...
Author: ThunderBear · Last updated May 18, 2026
A company introduced a new feature that should be accessible to only a specific group of premium customers. A developer needs the ability to turn the feature on and off in response to performance and feedback. The developer needs a solution to validate and deploy these...
To address the need for managing feature configurations and deploying them quickly, let's break down the options based on the requirements: the ability to turn the feature on and off, quick validation and deployment, and ensuring minimal disruptions to the system.
A) Use AWS AppConfig to manage the feature configuration and to validate and deploy changes. Use feature flags to turn the feature on and off.
- Explanation: AWS AppConfig is a service specifically designed for managing application configurations. It allows you to deploy configurations in a controlled way, validate them before deployment, and use feature flags to toggle features on and off dynamically. This provides a safe way to test new configurations in production environments without disrupting users, and it allows for fast rollbacks or changes based on customer feedback or performance.
- Why it's selected: AWS AppConfig is ideal for managing feature flags, validating configurations, and deploying changes without impacting the overall application performance. It supports use cases where quick changes and toggling of features are required, such as enabling or disabling the new feature for specific customer groups.
- Why other options are rejected:
- B) AWS Secrets Manager is primarily designed for managing sensitive data like passwords, database credentials, and API keys, not...
Author: StarlightBear · Last updated May 18, 2026
A developer needs approval from a product owner before the developer can deploy code for an application to production. The developer uses AWS CodePipeline to deploy the application. The developer configures an Amazon Simple Notification Service (Amazon SNS) topic to send notifications to the produ...
To determine the most operationally efficient way for the developer to get approval from the product owner before deploying code to production, let's evaluate each option:
A) Add a new stage to CodePipeline before the production deployment. Add a manual approval action to the new stage. Add a new notification rule in the pipeline settings. Specify manual approval as the event that initiates the notification. Specify the SNS topic's Amazon Resource Name (ARN) to notify the product owner.
- Explanation: This approach uses CodePipeline’s built-in manual approval action, which is designed specifically to pause the pipeline and wait for an approval before continuing. Adding this action as a new stage before production deployment allows the product owner to review and approve the deployment via an SNS notification. The manual approval step is an efficient, native way to handle such approvals in a continuous delivery pipeline.
- Why it's selected: CodePipeline's manual approval action is directly integrated into the deployment process and is the most operationally efficient solution. It minimizes the need for custom solutions or additional services, making it easy to configure and manage.
- Why other options are rejected:
- B) While AWS Step Functions can be used to orchestrate complex workflows and notifications, this adds unnecessary complexity...
Author: Stella · Last updated May 18, 2026
A developer is building a serverless application on AWS for a workflow that processes high volumes of data. In the workflow, an AWS Step Functions state machine invokes several AWS Lambda functions.
One of the Lambda functions occasionally fails because of timeout errors during periods of high demand. The developer must ensure ...
Let's evaluate each option based on the goal: automatically retrying a failed Lambda invocation in the Step Functions workflow when a timeout error occurs.
Option A: Add a Retry field in the Step Functions state machine definition. Configure the state machine with the maximum number of retry attempts and the timeout error type to retry on.
- Explanation: Step Functions allows you to configure retry behavior using a `Retry` field in the state machine definition. You can specify the maximum number of retry attempts, the error types to retry (including timeout errors), and the interval between retries. This option directly supports the requirement, ensuring that when a Lambda function times out, Step Functions will automatically retry it based on the defined conditions.
- Advantages: This option provides a built-in and direct way to handle retries for specific error types such as timeouts. It is native to Step Functions, so it integrates well with the existing workflow.
- Why it's selected: This is the most appropriate solution because it offers precise control over retries based on the error type, directly addressing the problem of Lambda timeout failures.
Option B: Add a Timeout field in the Step Functions state machine definition. Configure the state machine with the maximum number of retry attempts.
- Explanation: A `Timeout` field in Step Functions specifies the maximum amount of time the state machine will wait for a task (like a Lambda function) to complete. While this can prevent a function from running indefinitely, it doesn't directly address retrying after a timeout. Adding retries for timeouts would require using the `Retry` field, not the `Timeout` field.
- Why it's rejected: This option doesn’t solve the problem because it doesn't handle retries specifically after a timeout error;...
Author: Elizabeth · Last updated May 18, 2026
A company runs a serverless application on AWS. The application includes an AWS Lambda function. The Lambda function processes data and stores the data in an Amazon RDS for PostgreSQL database. A developer created a user credentials in the database for the application.
The developer needs to use AWS Secrets Manager to manage the user credentials. The password must to be rotated on a regular basis. The ...
Let's analyze each option and determine the best solution for the developer's requirements:
Key Requirements:
1. Use AWS Secrets Manager to manage the user credentials.
2. Password rotation needs to be automatic and on a regular basis.
3. High availability and no downtime during secret rotation.
4. The credentials are for a single user in an Amazon RDS for PostgreSQL database.
Option A: Configure managed rotation with the single user rotation strategy.
- Explanation: The single user rotation strategy in AWS Secrets Manager involves rotating a single user credential without introducing another user for the rotation process. This is suitable when there is only one user and you want to ensure the password is automatically rotated at regular intervals.
- Advantages: This strategy is simple and works well when there is only one user. Secrets Manager will create a new password, update the secret, and then apply it to the database, all while ensuring no downtime during the process.
- Why it’s rejected: This is actually the most appropriate solution in the case of a single user because it allows seamless rotation with no additional complexity.
Option B: Configure managed rotation with the alternating users rotation strategy.
- Explanation: The alternating users rotation strategy involves rotating between two users—one for the current credential and one for rotation. The process involves one user for normal operations and another user for secret rotation.
- Why it's rejected: This strategy is more complex than needed for a single user. It’s useful for scenarios where mult...
Author: Abigail · Last updated May 18, 2026
A company runs an application on AWS. The application consists of a static website that is hosted on Amazon S3. The application includes Amazon API Gateway APIs that invoke AWS Lambda functions. During a period of high traffic on the application, application users reported that the application was slow at irregular intervals. There were no...
Let's analyze each option to determine the most suitable solution for finding slow Lambda executions during high traffic:
Key Requirements:
- The goal is to find slow Lambda function executions across all Lambda functions, and the application is experiencing slowdowns during high traffic.
- The solution should provide insights into execution durations of Lambda functions, ideally without failed requests, focusing on performance bottlenecks.
Option A: Perform a query across all the Lambda function log groups by using Amazon CloudWatch Logs Insights. Filter on type of report and sort descending by Lambda function execution duration.
- Explanation: CloudWatch Logs Insights allows you to run queries on logs stored in CloudWatch. You can filter the logs for Lambda functions and query them based on the execution duration, which would help pinpoint slow executions across all functions.
- Advantages: This is a direct and effective way to query logs and identify Lambda functions that are performing poorly. CloudWatch Logs Insights is designed for querying large sets of logs efficiently, making it an ideal solution for this scenario.
- Why it's selected: This option provides a fast and straightforward approach for analyzing Lambda execution times and finding the slow functions by querying the logs. It's simple to implement and provides immediate results without additional configuration or complexity.
Option B: Enable AWS CloudTrail Insights on the account where the Lambda functions are running. After CloudTrail Insights has finished processing, review CloudTrail Insights to find the anomalous functions.
- Explanation: CloudTrail Insights helps detect unusual patterns or anomalies in API activity, such as spikes in invocation counts or error rates. However, it does not directly measure Lambda function execution duration.
- Why it's rejected: CloudTrail Insights is designed to detect anomalies in API activity, but it doesn't provide detailed insights into the execution time of individual Lambda functions. This makes it unsuitable for identifying slow executions.
Option C: Enable AWS X-Ray for all the Lambda functions. Configure an X-Ray insight on a new group that includes all the Lambda...
Author: Ravi Patel · Last updated May 18, 2026
A company is building a serverless application on AWS. The application uses Amazon API Gateway and AWS Lambda. The company wants to deploy the application to its development, test, and production environ...
Let’s evaluate each option to find the solution that will deploy the application to development, test, and production environments with the least development effort:
Key Requirements:
- Deploy a serverless application using Amazon API Gateway and AWS Lambda.
- Deploy the application across multiple environments (development, test, and production).
- The solution should minimize development effort and avoid duplicating code.
Option A: Use API Gateway stage variables and create Lambda aliases to reference environment-specific resources.
- Explanation: API Gateway stage variables allow you to configure environment-specific settings for different stages (e.g., dev, test, prod). Using Lambda aliases to point to different versions of the Lambda functions for each environment ensures that the correct version of the Lambda is invoked based on the environment.
- Advantages: This solution enables managing multiple environments with minimal changes to the codebase. It avoids code duplication and allows for seamless management of different environments within the same API Gateway and Lambda setup. Environment-specific configurations are controlled through API Gateway and Lambda aliases, so deployment effort is low.
- Why it's selected: This option allows the application to be deployed across multiple environments with minimal overhead and is easily scalable, making it the best choice for the least development effort.
Option B: Use Amazon Elastic Container Service (Amazon ECS) to deploy the application to the environments.
- Explanation: ECS is a service used to run containerized applications, typically for applications that require more control over the infrastructure and are not purely serverless.
- Why it's rejected: E...
Author: Aria · Last updated May 18, 2026
A developer uses AWS CloudFormation to deploy an Amazon API Gateway API and an AWS Step Functions state machine. The state machine must reference the API Gateway API after the CloudFormation template is deployed. The developer needs a solution that uses the state ma...
Let's evaluate the options for configuring the CloudFormation template to reference the API Gateway endpoint in the AWS Step Functions state machine, considering cost-effectiveness and simplicity.
Key Requirements:
- The state machine must reference the API Gateway endpoint after deployment.
- The solution should be cost-effective and avoid unnecessary complexity.
Option A: Configure the CloudFormation template to reference the API endpoint in the DefinitionSubstitutions property for the AWS::StepFunctions::StateMachine resource.
- Explanation: The DefinitionSubstitutions property allows for dynamic substitution of values (such as the API endpoint) within the state machine definition. This can reference CloudFormation outputs or parameters to inject the API endpoint into the state machine's definition.
- Advantages: This is a direct and simple approach that allows for dynamic referencing without needing to create additional AWS resources like Secrets Manager or environment variables. It is highly cost-effective because it directly substitutes the endpoint in the state machine definition.
- Why it's selected: This solution is cost-effective, direct, and integrates well with CloudFormation without adding unnecessary complexity or resources. It's also very efficient because it does not require extra services or configuration.
Option B: Configure the CloudFormation template to store the API endpoint in an environment variable for the AWS::StepFunctions::StateMachine resource. Configure the state machine to reference the environment variable.
- Explanation: This approach would require setting up an environment variable within the state machine’s execution context, and the state machine would reference that variable.
- Why it's rejected: Step Functions does not support environment variables natively, which means you'd need to either implement a custom solution using Lambda f...
Author: Leo · Last updated May 18, 2026
A developer is building an application on AWS. The application includes an AWS Lambda function that processes messages from an Amazon Simple Queue Service (Amazon SQS) queue.
The Lambda function sometimes fails or times out. The developer needs to figure out why the Lambda fun...
To determine the best approach to debug the Lambda function failure, let's analyze the given options:
A) Increase the maximum timeout of the Lambda function to 15 minutes. Check the AWS CloudTrail event history for error details.
- Analysis: While increasing the Lambda function timeout may give the function more time to process the messages, this doesn't directly help in identifying the root cause of failures or timeouts. CloudTrail logs may show events related to Lambda invocations, but CloudTrail is not a great tool for detailed error analysis within Lambda itself.
- Why rejected: This option doesn't address the underlying problem (why the Lambda function fails), and CloudTrail is not the most effective tool to debug Lambda processing issues. It also requires manual checks of logs without offering a clear mechanism to handle failures or retries.
B) Increase the visibility timeout of the SQS queue. Check logs in Amazon CloudWatch Logs for error details.
- Analysis: The visibility timeout of the SQS queue determines how long a message remains invisible to other consumers after Lambda starts processing it. Increasing it could allow Lambda more time to process a message before another instance of Lambda tries to process it again. However, this doesn't directly address why the Lambda function is failing. CloudWatch Logs can provide useful error details, but it won't give a clear mechanism to handle the failure either.
- Why rejected: Although this might reduce message reprocessing, it doesn't identify or fix the issue causing the Lambda function to fail. The focus should be on how to effectively capture failed messages for analysis.
C) Create a dead-letter queue. Configure the Lambda function to send the failed messages...
