Amazon Practice Questions, Discussions & Exam Topics by our Authors

A developer is building various microservices for an application that will run on Amazon EC2 instances. The developer needs to monitor the end-to-end view of the requests between the microservices and debug any iss...

To monitor the end-to-end view of requests between microservices and debug issues across the application, the goal is to track the flow of requests as they pass through various microservices, pinpointing where failures or performance issues may occur. Let's review each option and evaluate the most suitable one. A) Use Amazon CloudWatch to aggregate the microservices' logs and metrics, and build the monitoring dashboard. - Explanation: Amazon CloudWatch is excellent for gathering logs, metrics, and creating dashboards. However, CloudWatch focuses on collecting metrics (e.g., CPU, memory usage, custom metrics) and logs from EC2 instances or services. While CloudWatch is great for general monitoring, it lacks the ability to provide an end-to-end view of requests across microservices, which is required for debugging issues related to request flows and tracing. - Rejected: CloudWatch doesn’t natively provide distributed tracing or the detailed request flow between microservices. It can help aggregate data but lacks deeper insights into request-specific diagnostics. B) Use AWS CloudTrail to aggregate the microservices' logs and metrics, and build the monitoring dashboard. - Explanation: AWS CloudTrail is used for logging and monitoring API calls within an AWS environment. While it is great for tracking user activity and API calls at the AWS service level, it does not provide the deep, request-level tracing or end-to-end visibility needed for microservices monitoring. CloudTrail logs are not designed to trace the flow of individual requests between microservices, making it unsuitable for this use case. - Rejected: CloudTrail is more for auditing AWS API calls rather than debugging requests across microservices. C) Use the AWS X-Ray SDK to add instrumentation in all the microservices, and monitor using the X-Ray service m...

Author: Sofia · Last updated Jul 14, 2026

A developer is building a microservice that uses AWS Lambda to process messages from an Amazon Simple Queue Service (Amazon SQS) standard queue. The Lambda function calls external APIs to enrich the SQS message data before loading the data into an Amazon Redshift data warehouse. The SQS queue must handle a maximum of 1,000 messages per second. During initial testing, the Lambda function repeatedly inserted duplicate data into the Amazon Redshif...

To resolve the issue of duplicate data being inserted into Amazon Redshift due to duplicate SQS messages, let's analyze each option: Option A: Create an SQS FIFO queue. Enable message deduplication on the SQS FIFO queue. - Why it's selected: FIFO (First-In-First-Out) queues are designed specifically to maintain the exact order of messages and provide message deduplication. By enabling deduplication on an SQS FIFO queue, any duplicate messages within a 5-minute deduplication interval will not be processed again, preventing the insertion of duplicate data into Amazon Redshift. This is a robust solution, as SQS FIFO queues are built to handle scenarios with a guarantee of message uniqueness and order. - Why other options are rejected: - Option B: Reducing Lambda concurrency won't directly solve the problem of message ...

Author: Lucas Carter · Last updated Jul 14, 2026

A company has an application that uses an Amazon API Gateway API to invoke an AWS Lambda function. The application is latency sensitive. A developer needs to configure the Lambda function to reduce the cold start time tha...

To meet the requirement of reducing the cold start time for an AWS Lambda function, let's analyze each option: Option A: Publish a new version of the Lambda function. Configure provisioned concurrency. Set the provisioned concurrency limit to meet the company requirements. - Why it's selected: Provisioned concurrency ensures that a specific number of Lambda function instances are pre-warmed and ready to handle incoming requests, drastically reducing cold start latency. By configuring provisioned concurrency, the Lambda function will have pre-initialized environments available to process requests immediately, which is ideal for latency-sensitive applications. - Why other options are rejected: - Option B: Increasing the Lambda function’s memory and reserved concurrency won't directly address cold start times. While increasing memory ...

Author: Vikram · Last updated Jul 14, 2026

A developer is deploying an application on Amazon EC2 instances that run in Account A. The application needs to read data from an existing Amazon Kinesis data stream in Account B. Which actions should...

To enable the application running on Amazon EC2 instances in Account A to access a Kinesis data stream in Account B, the developer needs to properly configure permissions and trust relationships between the two accounts. Let's evaluate the options: Option A: Update the instance profile role in Account A with stream read permissions. - Why it's not selected: The EC2 instance in Account A needs permission to access the Kinesis data stream in Account B. However, directly updating the instance profile in Account A with stream read permissions is not sufficient. Kinesis stream permissions must be granted through a resource-based policy or a cross-account IAM role in Account B. Option B: Create an IAM role with stream read permissions in Account B. - Why it's selected: The IAM role in Account B needs to have stream read permissions to allow applications (in this case, EC2 instances in Account A) to read from the Kinesis stream. This role will be assumed by the EC2 instance in Account A through a trust relationship. Creating the role in Account B is necessary to enable access from Account A. Option C: Add a trust policy to the instance profile role and IAM role in Account B to allow the instance profile role to assume the IAM role. - Why it's selected: This option is required because the EC2 instance in Account A must assume the IAM role in Account B to gai...

Author: Ravi Patel · Last updated Jul 14, 2026

An ecommerce startup is preparing for an annual sales event. As the traffic to the company's application increases, the development team wants to be notified when the Amazon EC2 instan...

To meet the requirement of notifying the development team when the Amazon EC2 instance's CPU utilization exceeds 80%, let's evaluate each option: Option A: Create a custom Amazon CloudWatch alarm that sends a notification to an Amazon SNS topic when the CPU utilization exceeds 80%. - Why it's selected: Amazon CloudWatch is the most straightforward and efficient way to monitor EC2 instances. CloudWatch automatically tracks key metrics like CPU utilization, and you can easily create an alarm that triggers when the CPU utilization exceeds a threshold (80% in this case). The alarm can then send a notification to an Amazon SNS topic. This approach is fully managed, scalable, and designed for such use cases. - Why other options are rejected: - Option B: AWS CloudTrail is designed for logging API activity, not for monitoring system metrics like CPU utilization. CloudTrail doesn't capture metric data like CPU usage, so it ...

Author: Emma · Last updated Jul 14, 2026

A company has an application that is deployed on AWS Elastic Beanstalk. The application generates user-specific PDFs and stores the PDFs in an Amazon S3 bucket. The application then uses Amazon Simple Email Service (Amazon SES) to send the PDFs by email to subscribers. Users no longer access the PDFs 90 days after the PDFs are generated. The S3 bucket is not versioned and contains many obsolete PDFs. A devel...

To meet the requirement of removing PDFs older than 90 days from the S3 bucket with the least development effort, let's evaluate each option: Option A: Update the application code. In the code, add a rule to scan all the objects in the S3 bucket every day and to delete objects after 90 days. - Why it's not selected: Updating the application code to scan and delete objects every day would add unnecessary complexity and development overhead. It would also require maintaining this logic within the application, making it less scalable and error-prone. A more straightforward solution exists that doesn't involve modifying the application. Option B: Create an AWS Lambda function. Program the Lambda function to scan all the objects in the S3 bucket every day and to delete objects after 90 days. - Why it's not selected: While this is a valid solution, it still requires custom development for the Lambda function to scan and delete files. You would need to set up Lambda, write the code to handle object deletions, and ensure it runs at regular intervals (e.g., daily). Although this solution works, it is more involved than the next option, which offers automation without requiring custom code. Option C: Create an S3 Lifecycle rule for the S3 bucket to ...

Author: Joseph · Last updated Jul 14, 2026

A developer is troubleshooting an application. The application includes several AWS Lambda functions that invoke an Amazon API Gateway API. The API Gateway's method request is set up to use an Amazon Cognito authorizer for authentication. All the Lambda functions pass the user ID as part of the Authorization header t...

To resolve the issue of receiving a 403 status code for all GET requests to the API Gateway API, we need to understand the authentication flow with Amazon Cognito authorizers and the proper configuration of the API Gateway and client requests. Let's break down the options: A) Modify the client GET request to include a valid API key in the Authorization header. - Reasoning: This option is unlikely to solve the issue. API keys are generally used for rate limiting and quota purposes, but they don't handle user authentication. The API Gateway is set up to use a Cognito authorizer for authentication, so an API key in the `Authorization` header would not solve the 403 error if the issue is related to Cognito authentication. - Rejection: The issue here is related to authentication using Cognito, not API keys. API keys are not used for user authorization in Cognito-based scenarios. B) Modify the client GET request to include a valid token in the Authorization header. - Reasoning: This is the most likely solution. The 403 error suggests that the API Gateway does not accept the provided authorization credentials. Since Cognito is being used as an authorizer, the client must pass a valid JWT (JSON Web Token) from Cognito in the `Authorization` header, not just the user ID. The client needs to authenticate against Cognito and use the valid token received in the response as the `Authorization` header for API requests. - Selected Option: This is the correct o...

Author: Liam · Last updated Jul 14, 2026

A company processes incoming documents from an Amazon S3 bucket. Users upload documents to an S3 bucket using a web user interface. Upon receiving files in S3, an AWS Lambda function is invoked to process the files, but the Lambda function times out intermittently. If the Lamb...

To address the scenario where an AWS Lambda function times out intermittently during S3 event processing, let's examine the behavior of Lambda with respect to S3 events and timeouts when the Lambda function is configured with default settings. Understanding the default Lambda behavior with S3 events: - By default, AWS Lambda retries the event processing twice if the function times out or fails. After two retries, if the function still fails, the event is discarded. There is no automatic notification or retries beyond the default behavior, unless further configured (such as using a Dead Letter Queue). A) Notification of a failed S3 event is sent as an email through Amazon SNS. - Reasoning: This option does not align with the default behavior of Lambda. By default, Lambda does not automatically send notifications upon failure, unless you configure additional services like SNS or CloudWatch alarms. - Rejection: This is not the default behavior of Lambda and would need additional setup to work. It’s not automatically triggered by a timeout or failure in the Lambda function. B) The S3 event is sent to the default Dead Letter Queue. - Reasoning: A Dead Letter Queue (DLQ) is used when you explicitly configure it i...

Author: Arjun · Last updated Jul 14, 2026

A developer uses Amazon S3 Event Notifications to invoke AWS Lambda functions. The Lambda functions process images after the images are uploaded to S3 buckets. The developer has set up a development S3 bucket, a production S3 bucket, a development Lambda function, and a production Lambda function in the same AWS account. The developer notices that uploads to the development S3 bucket wrongly invoke the p...

To resolve the issue where uploads to the development S3 bucket are wrongly invoking the production Lambda function, the developer needs to ensure that the S3 event notifications for each bucket trigger the correct Lambda function and prevent cross-environment interference. Let’s evaluate the options: A) Update the execution role for the production Lambda function. Add a policy that allows the execution role to read from only the production S3 bucket. - Reasoning: This option focuses on the Lambda function's execution role, but it does not address the root cause of the issue, which is that the S3 event notifications are incorrectly triggering the production Lambda function. Changing the execution role for the production Lambda will not prevent the development S3 bucket from invoking the production Lambda function if the event notification configuration is still wrong. - Rejection: This option addresses permissions for Lambda execution, but it does not directly control which Lambda function gets triggered by the S3 event. The issue lies in how the S3 events are being configured. B) Update the S3 bucket policy for the production S3 bucket to invoke the production Lambda function. Update the S3 bucket policy for the development S3 bucket to invoke the development Lambda function. - Reasoning: This approach focuses on configuring the S3 bucket policies to explicitly allow the corresponding Lambda functions to be invoked. This can help restrict the production Lambda to only be invoked by the production S3 bucket, and similarly for the development bucket and Lambda function. However, managing Lambda invocation permissions via S3 bucket policies can lead to complexity and may not be the most straightforward way to prevent wrong Lambda invocations. S3 Event Notifications are often configured directly, and using a policy alone may not fully address the issue, as event notifications can still be misconfigured. - Rejection: While this could potentially work, it’s generally better to control event-to-Lambda mappings explicitly at the S3 notification configuration level rather than relying on S3 bucket policies. C) Separate the development environment and the production environm...

Author: Vivaan · Last updated Jul 14, 2026

A developer is writing an application that will run on Amazon EC2 instances in an Auto Scaling group. The developer wants to externalize the session state to support the application. Which AWS ...

When the developer wants to externalize session state for an application running on Amazon EC2 instances in an Auto Scaling group, the goal is to store session data outside of the EC2 instances so that it can persist across scaling events and instance failures. Let's evaluate the options available to meet these requirements. A) Amazon DynamoDB - Reasoning: Amazon DynamoDB is a fully managed NoSQL database that provides high availability and scalability. It can be used to store session state, allowing sessions to be externalized and persist across Auto Scaling group changes. DynamoDB is designed to handle high throughput and low-latency access, making it a good choice for session storage. - Selected: This option is a valid choice because DynamoDB provides a reliable and scalable solution for session state storage, which is key for supporting an Auto Scaling application. B) Amazon Cognito - Reasoning: Amazon Cognito is typically used for user authentication, authorization, and identity management. It stores user profiles and provides access management but is not specifically designed for general session state management. While it can handle session tokens for authenticated users, it is not intended to be used as a general-purpose session store for applications. - Rejection: This is not a suitable option for externalizing session state, as Amazon Cognito's focus is on user identity management rather than general session data. C) Amazon ElastiCache - Reasoning: Amazon ElastiCache is a fully managed caching service that supports Redis and Memcached. It is commonly used to store session data because it is fast, scalable, and offers low-latency access to data. Using ElastiCache for session state is a common approach for distributed applications, especially for storing session...

Author: Vivaan · Last updated Jul 14, 2026

A company has a serverless application that uses an Amazon API Gateway API to invoke an AWS Lambda function. A developer creates a fix for a defect in the Lambda function code. The developer wants to deploy this fix to the production environment. To test the changes, the developer needs to send 10% of the li...

To meet the requirement of sending 10% of the live production traffic to the updated Lambda function version, the key is to use weighted routing that allows splitting the traffic between the old and new versions. Let's evaluate the options: A) Publish a new version of the Lambda function that contains the updated code. - Reasoning: This step is necessary because to enable versioned traffic routing, you need to publish a new version of the Lambda function. This allows the Lambda function's versions to be tracked and used in routing decisions. - Selected: This is a valid option, as creating a new version of the Lambda function is essential for deploying updates and routing traffic to the updated version. B) Set up a new stage in API Gateway with a new Lambda function version. Enable weighted routing in API Gateway stages. - Reasoning: While API Gateway supports stages and allows you to configure different environments (e.g., development, production), weighted routing is not typically done at the stage level. Instead, traffic routing between Lambda versions is managed using Lambda aliases, not stages. This option is misleading because routing based on Lambda versions is handled by aliases, not API Gateway stages. - Rejection: This option is incorrect because API Gateway stages themselves do not support weighted routing for Lambda versions. C) Create an alias for the Lambda function. Configure weighted routing on the alias. Specify a 10% weight for the new Lambda function version. - Reasoning: This is the correct solution. By creating an alias for the Lambda function, you can configure weighted routing to split the traffic between the old and new versions of the Lambda function. API Gateway uses the alias to route ...

Author: Akash · Last updated Jul 14, 2026

A developer is creating a video search application for a global company. The video files have an average size of 2.5 TB. The video storage system must provide instant access to the video files for the first 90 days. After the first 90 days, the video file...

To determine the most cost-effective solution, we need to consider both access speed and cost for the video storage over time. Here's the analysis of each option: Option A: Amazon EFS Standard and Standard-IA - EFS Standard provides low-latency, high-throughput file access, suitable for active file access. - Standard-IA (Infrequent Access) is a low-cost storage option, ideal for infrequently accessed files. - Analysis: - EFS is typically more expensive than S3 for storing large volumes of data. - After 90 days, transitioning to EFS Standard-IA reduces the cost, but EFS is still a file storage solution designed for frequent access, not for archival. - This solution is costlier and less efficient for large-scale, infrequently accessed video files after 90 days. Option B: Amazon S3 with Glacier Deep Archive and Glacier Flexible Retrieval - S3 Glacier Deep Archive is a very low-cost storage option for long-term archiving, with retrieval times of several hours, but provides a significant cost savings. - Glacier Flexible Retrieval is suitable for infrequent access but provides retrieval times in minutes (which meets the requirement of taking more than 10 minutes after 90 days). - Analysis: - For the first 90 days, S3 Glacier Deep Archive would not be appropriate, as it has retrieval times that may exceed 10 minutes and is not designed for immediate access. - Glacier Flexible Retrieval provides longer retrieval times than standard storage solutions but allows for more affordable long-term storage. - This solution can be effective after the first 90 days, but it is not ideal for the first 90 days, where instant access is required. Option C: Amazon EBS and S3 Glacier Deep Archive - EBS is a block storage solution that provides fast and consistent I/O performance for active workloads but is typically more expensive than S3 for large amounts of storage. - S3 Glacier Deep Archive is very low-cost...

Author: Maya · Last updated Jul 14, 2026

A company has a virtual reality (VR) game. The game has a serverless backend that consists of Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. Recently, the company noticed a sudden increase of new users globally. The company also noticed delays in the retrieval of ...

Analysis of the Options: Option A: Amazon ElastiCache - ElastiCache is a fully managed in-memory caching service that supports Redis and Memcached. It can help improve database response times by caching frequently accessed data. - Analysis: - ElastiCache can significantly reduce database response time by caching frequently queried data, which improves the performance of read-heavy workloads. - However, this solution is not specifically tailored for DynamoDB. While it could be used for caching, it requires additional management, and the integration may not be as seamless as the next option. Option B: DynamoDB Accelerator (DAX) - DAX is a fully managed, highly available, in-memory cache for DynamoDB that delivers microsecond read response times for cached data. It works natively with DynamoDB and can accelerate read-heavy workloads. - Analysis: - DAX is purpose-built for DynamoDB and is designed to provide microsecond response times for read queries, which directly addresses the company's requirement of reducing database response times to microseconds. - DAX automatically handles cache invalidation and refresh, making it a seamless solution for improving DynamoDB performance without the need for additional infrastructure management. - DAX is the most suitable solution for improving the read performance of DynamoDB specifically. Option C: DynamoDB Auto Scaling - DynamoDB Auto Scaling automatically adjusts the read and...

Author: Krishna · Last updated Jul 14, 2026

A developer is creating a solution to track an account's Amazon S3 buckets over time. The developer has created an AWS Lambda function that will run on a schedule. The function will list the account's S3 buckets and will store the list in an Amazon DynamoDB table. The developer receives a permissions error when the developer runs the function with...

Analysis of the Options: Option A: Cross-account IAM role - Cross-account IAM roles allow AWS resources in one account to access resources in another account. This is useful for resources that are in separate AWS accounts. - Analysis: - Since the question does not mention multiple accounts, cross-account access is unnecessary here. The Lambda function and DynamoDB are likely in the same account, so this option isn't relevant to the issue. Option B: Permission for the Lambda function to list buckets in Amazon S3 - The Lambda function needs permission to interact with Amazon S3, specifically to list the account's S3 buckets. The permissions necessary for this are granted by the `s3:ListAllMyBuckets` permission. - Analysis: - The permissions error suggests that the Lambda function does not have the necessary permission to list the S3 buckets. The required permission for this action is `s3:ListAllMyBuckets`. - This permission is essential for the Lambda function to access and list all S3 buckets in the account, making this a necessary selection. Option C: Permission for the Lambda function to write in DynamoDB - The Lambda function stores the list of S3 buckets in a DynamoDB table. To do so, it needs permission to write to the DynamoDB table. - Analysis: - Since the function stores the S3 bucket list in DynamoDB, the function requires write permissions for the DynamoDB table (e.g., `dynamod...

Author: Layla · Last updated Jul 14, 2026

A company uses AWS to run its learning management system (LMS) application. The application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The application's domain name is managed in Amazon Route 53. The application is deployed in a single AWS Region, but the company wants to improve appli...

Analysis of the Options: Option A: Set up an Amazon CloudFront distribution that uses the ALB as the origin server. Configure Route 53 to create a DNS alias record that points the application's domain name to the CloudFront distribution URL. - CloudFront is a Content Delivery Network (CDN) service that caches content at edge locations worldwide to provide faster delivery of static and dynamic content. It integrates seamlessly with ALB and improves global performance by caching frequently accessed content. - Analysis: - CloudFront caches content globally at edge locations, reducing latency for users by serving them from the closest edge location. - It works well with Route 53 to route traffic to CloudFront, and the ALB serves as the origin for dynamic content. - This solution provides excellent performance improvements globally with minimal operational overhead. Once set up, CloudFront manages the caching and routing automatically, and Route 53 handles DNS resolution. - This solution is simple to implement and requires minimal management after setup. Option B: Launch more EC2 instances behind the ALB, configure the ALB to use session affinity (sticky sessions), and create a Route 53 alias record for the ALB by using a geolocation routing policy. - Launching more EC2 instances can help with scaling the application, but this does not address the need for improving global performance. - Geolocation routing in Route 53 can route users to the closest instances, but this will require more EC2 instances in multiple regions to be truly effective. - Sticky sessions are typically used to maintain session state between a user and a specific EC2 instance, which is not related to improving global performance or reducing latency. - Analysis: - Scaling EC2 instances to multiple regions could improve performance, but it increases complexity and operational overhead due to the need for instance management, load balancing, and regional deployment. - Geolocation routing could be effective for regional performance improvements, but it requires much more manual management and monitoring compared to using CloudFront. Option C: Create an AWS Client VPN endpoint in the VPC, instruct users to connec...

Author: Max · Last updated Jul 14, 2026

A developer hosts a static website on Amazon S3 and connects the website to an Amazon CloudFront distribution. The website uses a custom domain name that points to the CloudFront URL. The developer has set up a continuous integration and continuous delivery (CI/CD) pipeline. The pipeline automatically runs when changes occur in an AWS CodeCommit repository. The pipeline has a source stage and then a build stage. The build stage invokes an AWS CodeBuild project that references a buildspec.yml file. The buildspec.yml file builds the code and deploys the static files to the S3 bucket. The pipeline runs successfully, and the latest website...

To resolve the issue where updates are visible in the S3 bucket but not reflected on the CloudFront distribution, the problem lies in CloudFront caching. CloudFront caches files at edge locations to improve performance and reduce latency. When a file is updated in the S3 bucket, CloudFront may still serve the cached version, which is why the updates are not reflected on the website when accessed via the CloudFront domain. Analyzing the Options: - A) Properly synchronize the objects in the S3 bucket with new files from the source stage. - This option would ensure the files in S3 are up to date, but it doesn’t address the CloudFront caching issue. Synchronizing the files in S3 does not automatically clear or update CloudFront's cached content. - B) Delete the previous website files in the S3 bucket and redeploy the website files. - While this might force the website to use the new files, it’s a more drastic and inefficient solution. There’s no need to delete files in the S3 bucket to update them, as the issue lies in CloudFront caching, not the S3 cont...

Author: Emma · Last updated Jul 14, 2026

A developer is working on an ecommerce application that stores data in an Amazon RDS for MySQL cluster. The developer needs to implement a caching layer for the application to retrieve informat...

Analyzing the Options: - A) Edit the RDS for MySQL cluster by adding a cache node. Configure the cache endpoint instead of the cluster endpoint in the application. - Amazon RDS for MySQL does not support adding a cache node directly. This option is not valid because caching capabilities must be handled separately from RDS, typically through an external caching service like Amazon ElastiCache. - B) Create an Amazon ElastiCache for Redis cluster. Update the application code to use the ElastiCache for Redis cluster endpoint. - This is the most appropriate solution. Amazon ElastiCache for Redis is designed to provide in-memory caching, which is ideal for caching frequently accessed data, like the most viewed products in an eCommerce application. Redis supports high-speed caching, and it can be integrated easily with MySQL to cache query results, reducing the load on the RDS database and improving performance for read-heavy workloads. - C) Create an Amazon DynamoDB Accelerator (DAX) cluster in front of the RDS for MySQL cluster. Configure the appl...

Author: Deepak · Last updated Jul 14, 2026

A gaming application stores scores for players in an Amazon DynamoDB table that has four attributes: user_id, user_name, user_score, and user_rank. The users are allowed to update their names only. A user is authenticated by web identity federation. ...

To allow users to update only their names in the DynamoDB table, you need to control access with a policy that ensures the user can only modify their own record, specifically the `user_name` attribute. The most important factors to consider are: Key Considerations: 1. Allow the user to update only their own record: This means the policy must ensure that the update applies to the item with the matching `user_id` of the authenticated user. 2. Allow updating only the `user_name` attribute: The policy must restrict modification to the `user_name` attribute, preventing the user from changing `user_score` or `user_rank`. Analyzing the Options: - A) Allow `dynamodb:PutItem` action only on the table and for items where the `user_id` matches the authenticated user’s `user_id` (via web identity federation). Additionally, only the `user_name` attribute is allowed to be updated. - This is the correct solution. The policy should ensure that the `user_id` in the request is the same as the authenticated user’s `user_id` (which is available through the web identity federation). By restricting the `user_name` attribute in the `PutItem` action, you ensure that only the `user_name` is modified, while the `user_score` and `user_rank` are untouched. This achieves the goal of allowing users to only update their name. - B) Allow `dynamodb:PutItem` action on the table and for items where the `user_id` is any value. No r...

Author: Henry · Last updated Jul 14, 2026

A developer is creating a database of products. Queries for frequently accessed products must have retrieval times of microseconds. To ensure data consistency, the application cache must be updated whenever...

Analyzing the Requirements: - Retrieval Time in Microseconds: The query response times must be very low (microseconds), which means we need a high-performance caching solution. - Cache Updates for Data Consistency: Whenever products are added, changed, or deleted, the cache must be updated to ensure that the most up-to-date information is available. Analyzing the Options: - A) Set up an Amazon DynamoDB database and a DynamoDB Accelerator (DAX) cluster. - This is the best solution. DynamoDB and DAX work together to provide extremely fast retrieval times in the microsecond range. DAX is a fully managed, in-memory cache for DynamoDB that can serve results from cache, reducing the number of reads from the database. With DAX, you can ensure low-latency access to frequently accessed products, and DynamoDB handles automatic consistency and scalability. When products are added, changed, or deleted, DynamoDB can handle the update process efficiently. DAX will automatically manage the cache consistency with DynamoDB, meeting both the low retrieval times and data consistency requirements. - B) Set up an Amazon RDS database and an Amazon ElastiCache for Redis cluster. Implement a lazy loading caching strategy with ElastiCache. - This is a good option but less optimal than option A. Amazon RDS combined with Redis (ElastiCache) can provide fast cache access, but Redis operates in a separate cache and doesn't integrate as seamlessly with RDS as DAX does wi...

Author: Isabella1 · Last updated Jul 14, 2026

A developer is creating a script to automate the deployment process for a serverless application. The developer wants to use an existing AWS Serverless Application Model (AWS SAM) template fo...

Analyzing the Requirements: The developer wants to automate the deployment process for a serverless application using an existing AWS SAM template. The goal is to use the AWS Serverless Application Model (SAM) to streamline the deployment and packaging process. Analyzing the Options: - A) Call `aws cloudformation package` to create the deployment package. Call `aws cloudformation deploy` to deploy the package afterward. - This option is valid, but not ideal when working specifically with AWS SAM. While `aws cloudformation package` and `aws cloudformation deploy` can work with SAM templates, they are part of CloudFormation's standard deployment process. The SAM CLI simplifies the process for serverless applications by providing specialized commands, so while this approach works, it lacks the specific benefits of using `sam package` and `sam deploy`, which are tailored for SAM. - B) Call `sam package` to create the deployment package. Call `sam deploy` to deploy the package afterward. - This is the most suitable option. The AWS SAM CLI provides the `sam package` command to bundle the application and the `sam deploy` command to deploy it. These commands are specifically designed for working with AWS SAM templates and handle the entire lifecycle of a serverless application, including packaging, uploading, and deploying. Using the SAM CLI commands ensures smooth integration with AWS Lambda, API Gateway, and other serverless resources. This is the recommended approach for a serverless application deployment. - C) Call `aws s3 cp` to upload the AWS SAM template to Amazon S3. Call `aws lambda update-function-code` to create the application. - This is not ideal for deploying a full serverless application. While `aws s3 cp` uploads the SAM template, the proce...

Author: Suresh · Last updated Jul 14, 2026

A developer is building an application on AWS. The application has an Amazon API Gateway API that sends requests to an AWS Lambda function. The API is experiencing increased latency because the Lambda function has limited available CPU to fulfill the requests. Before the developer deploys the API ...

Key Considerations: - Lambda CPU Allocation: AWS Lambda allocates CPU power based on the memory setting for the Lambda function. The more memory allocated, the more CPU is available to the function. Since the function is experiencing increased latency due to limited CPU, the developer needs to increase the available CPU by adjusting the function's configuration. Analyzing the Options: - A) Increase the virtual CPU (vCPU) cores quota of the Lambda function. - This is incorrect. AWS Lambda does not allow direct control over the number of vCPU cores allocated to a function. Instead, the CPU power is indirectly determined by the amount of memory allocated. The Lambda service does not provide a setting to adjust the number of vCPUs; it scales automatically with the memory allocation. - B) Increase the amount of memory that is allocated to the Lambda function. - This is the correct solution. In AWS Lambda, CPU is tied to memory. When you increase the memory allocated to a Lambda function, the function also gets more CPU resources. This will directly address the issue of limited CPU and reduce latency. It is a simple and effectiv...

Author: Ethan · Last updated Jul 14, 2026

A developer has an application that uses AWS Lambda functions and AWS CloudFormation templates. Usage of the application has increased. As a result, the Lambda functions are encountering rate limit errors when they retrieve data. The Lambda functions retrieve an advanced parameter from AWS Systems Manager Parameter Store on every call. The parameter changes only during new deployments. Because t...

Key Considerations: - Rate Limit Errors: Lambda functions are encountering rate limits when retrieving parameters from AWS Systems Manager Parameter Store, which suggests the functions are hitting the maximum number of allowed API requests to retrieve the parameter. - Cost-effectiveness: The solution needs to minimize costs while solving the problem of rate limiting. - Usage of the Parameter: The parameter changes only during new deployments, and the Lambda functions retrieve it on every call, which could lead to unnecessary repeated calls that contribute to rate limiting. Analyzing the Options: - A) Configure the Lambda functions to use reserved concurrency that is equal to the last month's average number of concurrent invocations. - This is not the most suitable solution. Reserved concurrency ensures a set number of concurrent executions for Lambda functions, but it does not address the issue of rate-limiting for parameter retrieval. While it could help with controlling the concurrency, it does not reduce the number of calls made to Parameter Store, which is the main cause of the rate limit errors. - B) Add a retry mechanism with exponential backoff to the call to Parameter Store. - This is a useful solution but not the most cost-effective. While retrying with exponential backoff can help mitigate rate limit errors, it does not eliminate the root cause — the frequent calls to Parameter Store on every Lambda invocation. This approach only delays the errors rather than addressing the underlying inefficiency of fetch...

Author: SolarFalcon11 · Last updated Jul 14, 2026

A developer is using an AWS Lambda function to process data. The developer needs to extract custom metrics about processing times from the Lambda logs. The developer needs to analyze the metrics, set ...

Let's break down each option to determine which one best fits the developer’s need to extract custom metrics from AWS Lambda logs and analyze those metrics in real time: A) Publish custom metric data to AWS CloudTrail by using the PutMetricData API operation. Classify and collect the metrics. Create graphs and alarms in CloudTrail for the custom metrics. - Why this is rejected: AWS CloudTrail logs API calls and user activity, but it is not a service designed for monitoring custom application metrics or logs directly. CloudTrail is typically used for auditing, security, and compliance purposes. It doesn't offer the tools needed to analyze log data or create custom metrics from Lambda logs in real time. CloudWatch is a better fit for these tasks. B) Use the open source client libraries provided by Amazon to generate the logs in the Amazon CloudWatch embedded metric format. Use CloudWatch to create the required graphs and alarms for the custom metrics. - Why this is a good option: CloudWatch Embedded Metric Format (EMF) allows you to publish custom metrics from Lambda directly to CloudWatch using the standard log format. This method is efficient and can easily track processing times or any other custom metrics. The custom metrics can then be used to create graphs and alarms in CloudWatch. However, it requires a bit more manual work, as the developer has to modify the Lambda function code to incorporate the embedded metric format. - When to use: This option is great when you want full control over how the metrics are published and need to embed custom logic directly in the Lambda function to define metrics. C) Use Amazon CloudWatch Logs Insights to create custom metrics by querying ...

Author: Stella · Last updated Jul 14, 2026

A developer needs to fix an AWS CodeDeploy deployment that failed. During the failed deployment, the developer received the following error message: =E2=80=9CThe overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment...

Let's evaluate each option to understand the possible causes of the failed deployment with the error message: "The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems. (Error code: HEALTH-CONSTRAINTS)". A) The CodeDeploy agent was not running on the instances that CodeDeploy was trying to deploy to. - Why this is selected: If the CodeDeploy agent is not running on the instances, CodeDeploy will be unable to deploy the application to those instances. The agent is required for communication between CodeDeploy and the EC2 instances. Without the agent running, the deployment will fail, resulting in unhealthy instances, which leads to the "HEALTH-CONSTRAINTS" error. This is a common cause of deployment failures. B) The unified Amazon CloudWatch agent was not running on the instances that CodeDeploy was trying to deploy to. - Why this is rejected: The CloudWatch agent is used for monitoring and logging metrics, but it does not impact the deployment process directly. The deployment failure is related to the CodeDeploy agent, not the CloudWatch agent. The CloudWatch agent’s absence would not lead to the "HEALTH-CONSTRAINTS" error related to deployment health. C) The developer's IAM role did not have the necessary permissions to perform code deployment to the instances. - Why this is rejected: The IAM role permissions issue would typically result in errors related to authorization fai...

Author: Sofia · Last updated Jul 14, 2026

A company is developing a serverless application that requires storage of sensitive API keys as environment variables for various services. The application requires the automatic rotation of the encryption k...

Let's break down each option to determine which one best fits the company’s requirements of storing sensitive API keys as environment variables and rotating encryption keys automatically every year, with no development effort involved: A) Encrypt the environment variables by using AWS Secrets Manager. Set up automatic rotation in Secrets Manager. - Why this is selected: AWS Secrets Manager is specifically designed to store and manage sensitive data such as API keys. It supports automatic rotation of secrets, including credentials and keys, without requiring custom development. By using Secrets Manager, the API keys can be encrypted and rotated automatically based on the defined schedule, in this case, every year. This solution fully satisfies the requirements with minimal development effort. B) Encrypt the environment variables by using AWS Key Management Service (AWS KMS) customer managed keys. Enable automatic key rotation. - Why this is rejected: While AWS KMS customer managed keys can be rotated automatically, KMS itself is focused on encrypting data and does not manage the API keys directly. In this case, KMS would only handle the encryption key rotation, but the application would still need to manage storing and retrieving the sensitive API keys, which adds complexity. It doesn't provide the out-of-the-box functionality for managing and rotating API keys like...

Author: Emily · Last updated Jul 14, 2026

An application stores user data in Amazon S3 buckets in multiple AWS Regions. A developer needs to implement a solution that analyzes the user data in the S3 buckets to find sensitive information. The analysis findings from all the S3 buckets must be avail...

Let's evaluate each option based on the need to analyze user data in multiple S3 buckets across AWS Regions, find sensitive information, and make the analysis results available in the eu-west-2 Region with the least development effort. A) Create an AWS Lambda function to generate findings. Program the Lambda function to send the findings to another S3 bucket in eu-west-2. - Why this is rejected: While Lambda could be used to generate findings, this approach requires custom development for analyzing the S3 data, generating findings, and copying the results to an S3 bucket in eu-west-2. This introduces significant development and operational overhead. It is not the least effort solution because it requires manual coding and monitoring. B) Configure Amazon Macie to generate findings. Use Amazon EventBridge to create rules that copy the findings to eu-west-2. - Why this is selected: Amazon Macie is a fully managed service designed for discovering sensitive data in Amazon S3. It can automatically generate findings when sensitive information is detected in the stored data. EventBridge can be used to route those findings to a specific location, such as an S3 bucket in the eu-west-2 Region. This solution is highly efficient as it leverages managed services with minimal custom development. It ensures findings are automatically transferre...

Author: MysticJaguar44 · Last updated Jul 14, 2026

An application ingests data from an Amazon Kinesis data stream. The shards in the data stream are set for normal traffic. During tests for peak traffic, the application ingests data slowly. A developer needs to adjust the data stream to ...

To address the performance issue and handle peak traffic more effectively, let's evaluate each option: Option A: Install the Kinesis Producer Library (KPL) to ingest data into the data stream. - Explanation: KPL is designed to help with batching records, reducing the number of API requests made to Kinesis Data Streams, and improving the overall throughput. However, the problem described seems to be related to the throughput of the data stream itself rather than inefficiencies in data ingestion. Installing KPL is more of an optimization for the producer side (the application sending data to Kinesis), but it will not increase the capacity of the data stream itself to handle peak traffic. Therefore, this option addresses only part of the problem (ingestion efficiency) but does not address the capacity of the Kinesis stream itself. - Rejected because: It does not directly address the problem of stream capacity under peak traffic. Option B: Switch to on-demand capacity mode for the data stream. Specify a partition key when writing data to the data stream. - Explanation: In on-demand mode, Kinesis automatically adjusts the number of shards to accommodate incoming traffic, making it easier to handle varying traffic loads without manual intervention. This option offers the flexibility to scale with demand without the need for predefined shard settings. It can be a great choice when there are unpredictable traffic spikes, as it ensures optimal resource allocation. - Rejected because: It might be more expensive than manually adjusting the shard count in scenarios where traffic patterns are predictable. On-demand mode scales automatically, but it might lead to higher costs over time, especially when traffic is predictable and could be managed more ...

Author: Victoria · Last updated Jul 14, 2026

A developer is building an application that uses an AWS Lambda function to process data. The application requires minimum latency. The Lambda function must have predictable function start times. All setup activities for the execution environm...

To determine the best solution for the given requirements, let's break down each option: Option A: Increase the memory of the Lambda function to the maximum amount. Configure an Amazon EventBridge rule to schedule invocations of the Lambda function every minute to keep the execution environment active. - Explanation: Increasing memory improves performance but doesn't address the setup time issue. While scheduling regular invocations via EventBridge ensures that the Lambda function is kept warm, it is inefficient and costly because it involves continuous invocations even when the function may not be needed. It doesn’t guarantee the predictable start time and setup activities before the function runs, as invocations may still face initialization delays. - Rejected because: This option is inefficient and costly, and it doesn't guarantee predictable start times or the setup activities before the function’s first invocation. Option B: Optimize the static initialization code that runs when a new execution environment is prepared for the first time. Decrease and compress the size of the Lambda function package and the imported libraries and dependencies. - Explanation: Optimizing the Lambda function code and dependencies reduces cold start times, but it doesn't address the need for predictable function start times or the setup of the execution environment before the function is invoked. While this can help minimize latency, it doesn't guarantee that the Lambda function will start quickly or reliably, as some initialization still occurs when the environment is created for the first time. - Rejected because: This helps with cold starts but doesn't fully meet the requirement for predictable start times and setup completion before invocation. Option C: Increase the reserved concurrency of the Lambda function to the maximum value for unreserved account co...

Author: Liam123 · Last updated Jul 14, 2026

A company has implemented a pipeline in AWS CodePipeline. The company is using a single AWS account and does not use AWS Organizations. The company needs to test its AWS CloudFormation templates in its primary AWS Region and a disaster...

Let's break down each option based on operational efficiency, feasibility, and how well it addresses the requirement of deploying and testing CloudFormation templates in both the primary AWS Region and the disaster recovery Region: Option A: In the CodePipeline pipeline, implement an AWS CodeDeploy action for each Region to deploy and test the CloudFormation templates. Update CodePipeline and AWS CodeBuild with appropriate permissions. - Explanation: AWS CodeDeploy is primarily designed for application deployments, not specifically for CloudFormation template testing and deployment. Using CodeDeploy for CloudFormation templates is not ideal, as it doesn’t directly align with the use case, and it would add unnecessary complexity to the pipeline. - Rejected because: CodeDeploy is not designed for deploying CloudFormation templates and adds unnecessary complexity. Option B: Configure CodePipeline to deploy and test the CloudFormation templates. Use CloudFormation StackSets to start deployment across both Regions. - Explanation: CloudFormation StackSets allows you to manage and deploy CloudFormation stacks across multiple AWS accounts and Regions from a single template. This is a powerful tool for cross-region deployment and testing, and integrating StackSets directly with CodePipeline would automate deployments to both Regions efficiently. This solution would ensure that the CloudFormation templates are deployed and tested across both the primary and disaster recovery Regions with minimal manual intervention, making it an operationally efficient solution. - Selected because: CloudFormation StackSets directly supports cross-region deployments, and integrating it with CodePipeline provides an automated and scalable solution for deploying and testing in both Regions. Option C: Configure CodePipeline to invoke AWS ...

Author: Lucas Carter · Last updated Jul 14, 2026

A company has an Amazon API Gateway REST API that integrates with an AWS Lambda function. The API=E2=80=99s development stage references a development alias of the Lambda function named dev. A developer needs make a production alias o...

Let's evaluate the options for making the production alias of the Lambda function available through the API in a way that best meets the requirements. Option A: Create a new method on the API. Name the method production. Configure the method to include a stage variable that points to the prod Lambda function alias. - Explanation: Adding a new method named `production` and configuring it with a stage variable would create a separate method for the production alias. However, using stage variables in this way is generally used for managing configuration settings across the entire stage, not for selecting a specific Lambda function alias for integration. This would be inefficient and unnecessary, as it requires managing multiple methods for what could be a simple alias switch via stage configuration. - Rejected because: This introduces unnecessary complexity by creating a new method when stage variables can be used more effectively for Lambda alias resolution. Option B: Create a new method on the API. Name the method production. Configure an integration request on the API's development stage that points to the prod Lambda function alias. - Explanation: This option involves creating a new method and configuring the development stage to use the production alias (`prod`) Lambda function, but this is not ideal. The development stage should be used for the development alias, and altering it to point to the production alias would disrupt the development pipeline and cause confusion. The production environment should ideally be separated with its own stage, not mixed with the development environment. - Rejected because: It causes confusion and mixes development and production environments, which could lead to unexpected behavior. Option C: Deploy the API to a new stage named production. Configure the stage to incl...

Author: Maya · Last updated Jul 14, 2026

A developer is implementing a serverless application by using AWS CloudFormation to provision Amazon S3 web hosting. Amazon API Gateway, and AWS Lambda functions. The Lambda function source code is zipped and uploaded to an S3 bucket. The S3 object key of the zipped source code is specified in the Lambda resource in the CloudFormation template. The devel...

To resolve the issue where there are no changes in the Lambda function every time the CloudFormation stack is updated, let's evaluate the options based on how they would address the lack of updates: Option A: Create a new Lambda function alias before updating the CloudFormation stack. - Explanation: Lambda aliases are used to provide a stable reference to specific versions of a Lambda function. Creating a new alias does not address the issue of Lambda function source code updates. Lambda aliases point to specific function versions, and if the function's code hasn't changed, the alias will still reference the same code. This would not solve the problem of triggering updates when the source code changes. - Rejected because: It does not address the underlying issue of detecting changes to the Lambda function source code. Option B: Change the S3 object key or the S3 version in the CloudFormation template before updating the CloudFormation stack. - Explanation: This option involves changing the S3 object key or S3 version that is specified in the CloudFormation template. This ensures that CloudFormation detects a change in the Lambda source code because it will reference a different S3 object (or version) upon each update. This triggers an update to the Lambda function, which forces the deployment of the new source code. - Selected because: Changing the S3 object key or version forces CloudFormation to detect the change and update the Lambda function, effectively solving the issue of the Lambda function not being updated on stack updates. Option C: Upload the zipped source code to another S3 bucket before updating the CloudFormation stack. -...

Author: Olivia · Last updated Jul 14, 2026

A developer published a change to a new version of an AWS Lambda function. To test the change, the developer must route 50% of the traffic to the new version and 60% of the traffic to the curren...

Let's evaluate each option based on the given requirement: routing 50% of the traffic to the new version of the Lambda function and 60% of the traffic to the current version. Option A: - Description: This option involves using Amazon Route 53 to route traffic to different versions of the Lambda function by creating two records (one for each version) and applying weighted routing. - Issue: This option doesn’t work because Route 53 operates at the DNS level and cannot directly control Lambda versions. DNS-based routing will not directly influence Lambda invocations with the level of granularity needed. Additionally, DNS routing cannot be split into 50% and 60% traffic, as it must sum to 100%. Furthermore, Route 53 isn’t designed for handling Lambda traffic weights as directly as Lambda alias or API Gateway can. - Rejection reason: Inefficient for managing precise traffic routing to Lambda function versions and doesn't allow flexible control over traffic allocation between versions. - Scenario: Could be used for routing traffic to services that support weighted DNS routing, not specifically Lambda functions. Option B: - Description: This option uses Amazon API Gateway and a canary release to route 50% of traffic to the new version. - Issue: Although API Gateway can work with Lambda functions and support canary releases, it doesn't support precise routing of 50% of traffic to the new version and 60% to the old version. The canary release generally supports routing 5% or 10% (by default) and doesn’t allow flexible traffic split like 50%/60%. - Rejection reason: While API Gateway is a good choice for controlling traffic between versions in canary deployments, it doesn’t meet the exact requirement for 50%/60% traffic distribution. - Scenario: This could be used when you want a canary release that routes a small portion of traffic to the new version initially (but not for the specific distribution requested). Option C: - Description: This option uses a Lambda alias with weighted r...

Author: Benjamin · Last updated Jul 14, 2026

A developer is building an application that processes a stream of user-supplied data. The data stream must be consumed by multiple Amazon EC2 based processing applications in parallel and in real time. Each processor must be able to resume without losing data if there is a service interruption. The application architect plans to add othe...

To determine the best solution for the requirements outlined, let's break down the key needs: 1. Multiple processors consuming data in parallel in real-time: This requires a system that can distribute data to multiple consumers simultaneously and allow for parallel processing. 2. Resume without losing data in case of service interruptions: This indicates the need for durability and the ability to track where each processor left off so they can resume from the correct point. 3. Minimize data duplication: The system should avoid sending the same data to multiple processors unnecessarily, ensuring efficient use of resources. Option Analysis: A) Publish the data to Amazon Simple Queue Service (Amazon SQS). - Why not selected? - Amazon SQS is a messaging service that works well for decoupling components of an application. However, it’s not ideal for streaming large volumes of data in real-time. SQS is designed for point-to-point communication and doesn’t support multiple consumers consuming the same message in parallel by default (without configuring additional queues). It also lacks the built-in mechanism for real-time data distribution to multiple consumers without some architectural overhead. - Data Duplication: SQS typically delivers messages to a single consumer at a time, leading to potential duplication issues if you want parallel consumers. - SQS doesn’t provide the same real-time, parallel consumption model as required. B) Publish the data to Amazon Data Firehose. - Why not selected? - Amazon Kinesis Data Firehose is designed for data ingestion, transformation, and delivery to destinations like Amazon S3, Redshift, or Elasticsearch. It’s ideal for loading large-scale data into these services for further analysis. However, it’s not intended for real-time parallel processing of stream data by multiple consumers. Once the data is processed by Firehose, it is delivered to a storage or analytics destination, and it doesn’t support multiple EC2 instances processing the stream in parallel. - Parallel Consumption: Firehose delivers to a destination and does not support direct, real-tim...

Author: Elijah · Last updated Jul 14, 2026

A developer is using AWS CloudFormation to deploy an AWS Lambda function. The developer needs to set the Lambda function's timeout value based on the environment parameter of the template. The template contains mappings of EnvironmentData for each environment's timeout value. The environment parameter and EnvironmentDat...

Author: Ahmed · Last updated Jul 14, 2026

A company=E2=80=99s AWS accounts are in an organization in AWS Organizations. An application in Account A uses environment variables that are stored as parameters in AWS Systems Manager Parameter Store. A developer is creating a new application in Account B that needs to use the same environment variables. The application in Account B needs access to the pa...

In this scenario, the goal is to allow the application in Account B to access parameters stored in Account A's AWS Systems Manager Parameter Store, without duplicating the parameters. The solution should minimize operational overhead, ensuring efficient access control and permissions. Option Analysis: A) Configure the application in Account B to use credentials for an IAM user in Account A that has access to the parameters. - Why not selected? - While creating an IAM user in Account A and configuring the application in Account B to use that user’s credentials is technically feasible, it introduces operational overhead. You would need to manage and rotate credentials for that IAM user, which adds complexity in terms of security and ongoing maintenance. Additionally, it doesn’t scale well as the number of applications or parameters grows. - Key Concern: Managing credentials across accounts manually could become cumbersome and risky over time, making this a less optimal choice for ease of management. B) Create an assumable IAM role in Account A. Grant the role the permission to access the parameters. - Why selected? - This solution is secure and scalable. By creating an IAM role in Account A that has permissions to access the parameters in AWS Systems Manager Parameter Store, and allowing applications in Account B to assume this role, you can control cross-account access via a well-defined IAM policy. - Least operational overhead: Once the role is set up and properly configured, the application in Account B can assume the role and access the parameters without needing to handle separate credentials directly. It also allows for fine-grained access control through IAM policies and is highly scalable as new applications or accounts are added to the organization. - Key Advantage: The IAM role can be assumed tempo...

Author: Stella · Last updated Jul 14, 2026

In a move toward using microservices, a company=E2=80=99s management team has asked all development teams to build their services so that API requests depend only on that service=E2=80=99s data store. One team is building a Payments service which has its own database; the service needs data that originates in the Accounts database. Both are using A...

When building microservices with decoupling and reliability in mind, the approach chosen should minimize inter-service dependencies, ensure low-latency data transfer, and scale efficiently as the services evolve. Let's review each option based on these considerations: A) Use AWS Glue to perform frequent ETL updates from the Accounts database to the Payments database. - Pros: AWS Glue is great for transforming and processing large amounts of data. It’s suitable for batch processing where regular, large-scale data synchronization is needed. - Cons: It’s a batch process and would introduce latency between updates from the Accounts service and Payments service. This is not ideal for real-time requirements. It also creates additional complexity in orchestrating ETL jobs, leading to tighter coupling between services. - Scenario: This could be used in scenarios where real-time data updates are not critical, such as in a reporting or analytics service that needs periodic synchronization. B) Use Amazon ElastiCache in Payments, with the cache updated by triggers in the Accounts database. - Pros: ElastiCache can help improve performance by caching data for fast reads. It would reduce the number of calls to the Accounts database. - Cons: While this can speed up read operations, it doesn't directly solve the problem of ensuring reliable, near-real-time data transfer. Using triggers on the Accounts database could result in a setup that is complex and harder to maintain, as it introduces dependencies between two separate services at the database level. - Scenario: This approach is best suited for scenarios where caching frequently accessed data to improve read performance is a priority, but real-time consistency isn’t as critical. C) Use Amazon Data Firehose to deliver all changes from the Accounts database to the Payments database. - Pros: Amazon Kinesis Data Firehose is good for ingesting str...

Author: BlazingPhoenix22 · Last updated Jul 14, 2026

A developer compiles an AWS Lambda function and packages the result as a .zip file. The developer uses the Functions page on the Lambda console to attempt to upload the local packaged .zip file. When pushing the package ta Lambda, the console re...

Author: IceDragon2023 · Last updated Jul 14, 2026

A company runs an application on Amazon EC2 instances in an Auto Scaling group. The application experiences variable loads throughout each day. The company needs to collect detailed metrics from the EC2 instances to right-size the instances. The company also wants to monitor custo...

To address the company's need for detailed EC2 instance metrics and custom application metrics, let's analyze each option: A) Install the AWS X-Ray agent on the instances. Configure the agent to collect the EC2 instance metrics and the custom application metrics. - Pros: AWS X-Ray is great for tracing and analyzing the performance of distributed applications, helping with insights into the request flow across services. It's particularly useful for identifying bottlenecks and performance issues. - Cons: However, X-Ray is focused on tracing and application-level performance analysis, not specifically on collecting EC2 instance-level metrics (like CPU utilization, memory usage, disk I/O, etc.). It doesn't natively provide detailed EC2 instance metrics. - Scenario: This option is ideal when you need to monitor application traces for performance issues but not for EC2 instance metrics or when you need to integrate tracing with application insights. B) Install the Amazon CloudWatch agent on the instances. Configure the agent to collect the EC2 instance metrics and the custom application metrics. - Pros: The CloudWatch agent is specifically designed to collect EC2 instance metrics (such as CPU, memory, disk, and network utilization) as well as custom application metrics. It provides detailed and comprehensive monitoring that helps in right-sizing EC2 instances. It's easy to set up and integrates seamlessly with Amazon CloudWatch for real-time monitoring and alarms. - Cons: There's really no significant downside here if the goal is to collect EC2 metrics and custom application metrics. - Scenario: This is the ideal solution because it directly addresses both the EC2 instance metrics and custom application metrics in a simple and scalable manner, leveraging the powerful CloudWatch monitoring service. C) Install the AWS SDK in the application code. Upda...

Author: Akash · Last updated Jul 14, 2026

A developer is creating an application that uses an Amazon DynamoDB table. The developer needs to develop code that reads all records that were added to the table during the previous day, creates HTML reports, and pushes the reports into third-party storage. The item size varies from 1 KB to 4 KB, and the index structure is defined with the date. The developer needs to minimize the ...

In this scenario, the developer needs to efficiently retrieve all records from the DynamoDB table that were added during the previous day, minimizing the read capacity used while ensuring that the records are fetched based on the defined index structure. A) Query - Pros: The `Query` operation is ideal for retrieving items based on an indexed attribute. Since the index structure is defined with the date, `Query` allows the developer to specify the date range (e.g., the previous day) and efficiently retrieve the items that meet that condition. This operation uses fewer read capacity units compared to a `Scan` because it only retrieves items matching the index criteria. - Cons: The `Query` operation requires that the date be indexed and is effective when the query conditions can be satisfied by the index. It works well when the query can be based on specific key conditions (e.g., date). - Scenario: This is the most appropriate choice because it allows you to limit the results based on the date index, minimizing unnecessary reads and ensuring that only the relevant records (added in the previous day) are retrieved. B) Scan - Pros: The `Scan` operation reads all items in a table or a secondary index. It can be used to retrieve items without the need for a specific key or index. - Cons: The `Scan` operation is inefficient when dealing with large datasets, as it reads every item in the table or index, regardless of the filtering criteria. This consumes more read capacity, especially when only a subset of the data is needed, as in this case where only items from the previous day are required. - Scenario: While a `Scan` could technically work, it is not optimal for this use case, as it would consume more read capacity an...

Author: RadiantPhoenixX · Last updated Jul 14, 2026

A company is launching a feature that uses an HTTP API built with Amazon API Gateway and AWS Lambda. An API Gateway endpoint performs several independent tasks that run in a Lambda function. The independent tasks can take up to 10 minutes in total to finish running. Users report that the endpoint sometimes returns an HTTP 604 ...

The company is encountering HTTP 504 status codes in its API Gateway endpoint, which indicates that the Lambda function is taking longer to execute than API Gateway’s maximum allowed timeout (which is 29 seconds by default). The Lambda function itself is capable of running for up to 10 minutes, but there seems to be a timeout issue with the API Gateway endpoint. Let’s analyze each option to find the solution: A) Increase the Lambda function's timeout value. - Pros: Increasing the Lambda function's timeout value would allow the Lambda function to run for a longer period of time (up to a maximum of 15 minutes). - Cons: While this may help if the Lambda function itself is taking too long to finish, it does not directly address the problem with the API Gateway timeout. API Gateway has a maximum timeout of 29 seconds for synchronous calls, which means even if the Lambda function is set to run longer, API Gateway will still time out if the Lambda function does not return within 29 seconds. - Scenario: This approach only works if the function is not already being cut off by API Gateway’s timeout limit. It won't resolve the issue if the Lambda function’s execution time exceeds the API Gateway timeout. B) Increase the reserved concurrency of the Lambda function. - Pros: Reserved concurrency ensures that a fixed number of Lambda function instances are always available, potentially preventing throttling. - Cons: Increasing reserved concurrency would improve availability, but it does not affect the execution time of the Lambda function. If the function is still taking too long to complete, this won't prevent timeouts from API Gateway, which is the core issue here. - Scenario: This option is useful if you're facing throttling issues but does not help with the timeout problem, which is related to API Gateway waiting for a response. C) Increase the memory that is available to the Lambda fu...

Author: NightmareDragon2025 · Last updated Jul 14, 2026

A company has an application that uses an Amazon Cognito user pool for authentication. A developer needs to add a new REST API that will use the user pool to authenticate requests. ...

To meet the requirement of adding a new REST API that will authenticate requests using an Amazon Cognito user pool, the solution needs to integrate the Cognito authentication process with the API. Here's an analysis of each option: Option A: Create a new API key and a new usage plan. - Explanation: An API key is typically used to track and control access to an API, but it is not suitable for user authentication, especially when the request should be authenticated against a Cognito user pool. An API key alone does not provide user authentication or authorization based on credentials stored in a Cognito user pool. - Why rejected: This option does not fulfill the requirement to authenticate users using a Cognito user pool, so it's not the most suitable solution. Option B: Create a Cognito authorizer for the correct user pool. - Explanation: A Cognito authorizer is specifically designed to authenticate API requests using Amazon Cognito user pools. The Cognito authorizer will automatically validate the JWT token (Cognito token) passed with the request, ensuring the user is authenticated based on the Cognito user pool. - Why this option is ideal: It directly leverages the built-in functionality of AWS API Gateway and Cognito to authenticate users with the least development effort. The process of setting up a Cognito authorizer involves specifying the user pool and using the JWT token passed by the client to authorize the API request. - Why others are rejected: This option is a purpose-built solution with minimal configuration, making it the easiest and fastest to implement for the given requirement. Option C: Create an AWS Lambda token authorize...

Author: Siddharth · Last updated Jul 14, 2026

A developer is testing an AWS Lambda function that has an event source of an Amazon Simple Queue Service (Amazon SQS) queue. The developer notices that some of the messages the Lambda function processes re-appear in the queue while the messages are ...

The issue where some messages are reappearing in the SQS queue while being processed by an AWS Lambda function is likely due to the message being processed longer than the visibility timeout of the SQS queue. When the Lambda function does not complete processing a message within the time allowed by the visibility timeout, the message becomes visible to other consumers again, resulting in it being processed again. Option A: Increase the timeout of the Lambda function. - Explanation: Increasing the timeout of the Lambda function will allow it to run longer, but it does not directly address the problem of the message becoming visible in the queue before processing is complete. The real issue is the visibility timeout of the queue, not the Lambda timeout. - Why rejected: This option does not fix the problem. Even if the Lambda function has a longer timeout, the message could still be reprocessed if the SQS visibility timeout is too short. Option B: Increase the visibility timeout of the SQS queue. - Explanation: Visibility timeout in Amazon SQS is the period during which a message is not visible to other consumers after being read by a Lambda function. If the Lambda function does not finish processing a message within this time, the message becomes visible again in the queue, causing it to be retried. By increasing the visibility timeout, you give the Lambda function more time to process the message before it can be retried. - Why selected: This is the most appropriate solution because it directly addresses the issue. By increasing the visibility timeout to match or exceed the expected processing time of t...

Author: Layla · Last updated Jul 14, 2026

A developer created reusable code that several AWS Lambda functions need to use. The developer bundled the code into a zip archive. The developer needs to deploy the code to AWS and update the Lambda functions to use t...

The key goal is to ensure that reusable code is efficiently shared across multiple AWS Lambda functions with minimal operational overhead. Let's analyze each option: Option A: Upload the zip archive to Amazon S3. Configure an import path on the Lambda functions to point to the zip archive. - Explanation: While this option suggests uploading the code to Amazon S3 and configuring Lambda functions to reference it, Lambda does not natively support importing code from S3 in the way this solution suggests. Lambda functions typically cannot reference shared code directly via an import path in this manner. - Why rejected: This approach is not supported by AWS Lambda and is impractical for managing reusable code. Option B: Create a new Lambda function that contains and runs the shared code. Update the existing Lambda functions to invoke the new Lambda function synchronously. - Explanation: This solution involves creating a separate Lambda function that contains the shared code and then invoking it from other Lambda functions. This requires making synchronous calls to the new Lambda function every time the shared code is needed, leading to increased latency and complexity in managing multiple invocations. - Why rejected: Although it could work, this approach introduces unnecessary complexity and increased execution time due to the synchronous Lambda invocations, making it less efficient compared to other solutions. Option C: Create a Lambda layer that contains the zip archive. Attach the Lambda layer to the Lambda functions. - Explanation: Lambda layers are specifically designed for packaging reusable code or dependencies. By creating a Lambda layer, the developer can bundle the shared code into the layer, which can then be attached to multiple Lambda f...

Author: Harper · Last updated Jul 14, 2026

A team has an Amazon API Gateway REST API that consists of a single resource and a GET method that is backed by an AWS Lambda integration. A developer makes a change to the Lambda function and deploys the function as a new version. The developer needs to set up a process to test the new version of the function before using the new version i...

The goal here is to test the new version of the Lambda function without affecting the production REST API, and to do so with minimal operational overhead. Let's analyze each option: Option A: Create a new resource in the REST API. Add a GET method to the new resource, and add a Lambda integration to the updated version of the Lambda function. Deploy the new version. - Explanation: This option creates a new resource and a new GET method, effectively creating a separate endpoint to test the new version of the Lambda function. However, this introduces unnecessary complexity by adding a new resource, which might not be needed when a simpler solution is available. Additionally, you would need to deploy and manage a separate resource, which adds operational overhead. - Why rejected: While this solution works, it introduces unnecessary complexity by requiring a new resource and GET method, leading to more management tasks than necessary. Option B: Create a new stage for the REST API. Create a stage variable. Assign the stage variable to the Lambda function. Set the API Gateway integrated Lambda function name to the stage variable. Deploy the new version. - Explanation: This option involves creating a new stage for the API and using a stage variable to dynamically reference the updated Lambda function version. It provides an easy way to test the new version in isolation without affecting the production stage. By using stage variables, you can quickly switch between versions without modifying the API configuration itself. - Why selected: This solution is the most efficient and least intrusive. It allows testing of the new Lambda version in a dedicated stage, without modifying the production environment. The use of stage variables simplifies version management and reduces overhead. ...

Author: Sofia · Last updated Jul 14, 2026

A developer manages encryption keys in AWS Key Management Service (AWS KMS). The developer must ensure that all encryption keys can be deleted immediately when the keys are no longer required. The developer wants a solution that is highly available and d...

The key requirement here is to ensure that encryption keys in AWS Key Management Service (AWS KMS) can be deleted immediately when no longer required. Additionally, the solution should be highly available and not require manual management of compute infrastructure. Let's evaluate each option: Option A: Use AWS KMS managed keys. When the keys are no longer required, schedule the keys for immediate deletion. - Explanation: AWS KMS managed keys (also known as AWS-managed keys) are automatically created, managed, and rotated by AWS. While AWS handles the operational overhead of managing these keys, these keys cannot be deleted immediately. Instead, they are deleted based on a schedule that cannot be controlled by the user. This means the deletion process involves waiting for AWS to eventually delete the keys after a waiting period. - Why rejected: The keys cannot be deleted immediately as required by the developer. They are subject to a waiting period, so this option does not meet the need for immediate deletion. Option B: Use customer managed keys with imported key material. When the keys are no longer required, delete the imported key material. - Explanation: With customer managed keys that have imported key material, the key material can be deleted when it is no longer needed. However, this requires the management of the imported key material. While it offers flexibility, the process still involves manual intervention to delete the imported key material, and this doesn't meet the requirement for an automated, immediate deletion solution. - Why rejected: This solution still requires manual management of the imported key material and doesn't offer an automated or immediate deletion process, which does not fulfill the requirement for no manual intervention. Option C: Use customer managed keys. When the keys are no longer required, delete the key material. - E...

Author: Noah Williams · Last updated Jul 14, 2026

A company has an ecommerce application. The application's API sends order data to an Amazon Simple Queue Service (Amazon SOS) queue. A developer needs to modify the application to enrich the order data before the application sends the order dat...

Let's evaluate each option to see which one provides the least development effort to meet the requirements of enriching order data before sending it to the fulfillment system: A) Create an AWS Lambda function to poll the SQS queue, enrich the message data, and send the enriched data to the fulfillment system. Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the Lambda function to the SNS topic. - Analysis: This option involves using AWS Lambda to poll the SQS queue, enrich the order data, and send it to the fulfillment system. The SNS topic is included, but it's not necessary to subscribe to it if the focus is only on enrichment and direct fulfillment. - Why it might be rejected: Adding an SNS topic can complicate the architecture unnecessarily, increasing the amount of infrastructure to manage without providing significant benefits for the specific enrichment task. - Best use case: If you need to implement a broad event-driven notification system, or a more complex architecture where multiple services need to react to order events, SNS could be helpful. However, for just enriching and sending the data to a fulfillment system, this adds more complexity. B) Create an AWS Step Functions state machine. Configure an Amazon EventBridge rule to run the state machine when an order is published to the SQS queue. Map the orders to an AWS Lambda function. Program the Lambda function to perform the data enrichment and invoke the state machine. Configure the last step of the state machine to send the enriched data to the fulfillment system. - Analysis: This option uses AWS Step Functions and EventBridge to trigger a Lambda function that enriches the data, with the last step sending the enriched data to the fulfillment system. While this is a possible solution, it introduces a lot of complexity with multiple services (Step Functions, EventBridge, Lambda). - Why it might be rejected: This option requires extensive configuration of multiple services, including EventBridge, Step Functions, and Lambda. The added complexity may not be justified if the primary goal is simply enriching data. - Best use case: This would be useful if the workflow required more advanced orchestration with multiple steps or if the enrichme...

Author: Ava · Last updated Jul 14, 2026

An application interacts with Amazon Aurora to store and track customer information. The primary database is set up with multiple read replicas for improving the performance of the read queries. However, one of the Aurora replicas is receiving m...

Let's evaluate each option based on the issue of one Aurora replica receiving most or all of the traffic while the other replica remains idle. The goal is to achieve a more balanced distribution of read traffic across all replicas. A) Disable application-level DNS caching. - Analysis: Disabling application-level DNS caching means that each time the application makes a request to the database, it will perform a DNS lookup to find the current endpoint for the Aurora replicas. This would allow the application to always use the most up-to-date endpoint, but it could still result in a single replica handling most of the traffic if the application is designed to consistently connect to one specific endpoint. - Why it might be rejected: While disabling DNS caching might result in the application fetching updated DNS information, it won’t necessarily distribute the load across all replicas. Aurora uses a specific read-write endpoint for the primary database and read-only endpoints for replicas. If the application connects to the same read replica consistently, it will still overload that replica. - Best use case: Disabling DNS caching is more useful when you need the application to always resolve fresh DNS information but does not directly solve the issue of load balancing across replicas. B) Enable application-level DNS caching. - Analysis: Enabling DNS caching at the application level can help to cache the DNS lookup for the Aurora replicas, preventing excessive DNS resolution calls. However, it could exacerbate the problem if the application always connects to the same replica, as the DNS resolution might direct traffic to one specific endpoint (e.g., one replica). - Why it might be rejected: This option might lead to worse traffic distribution since caching DNS results could lock the application to one specific endpoint for a longer period, especially if the application resolves the DNS name once and keeps using the cached endpoint. - Best use case: Useful when you want to reduce the DNS lookup overhead, but in this case, it could worsen the imbalance of traffi...

Author: Arjun · Last updated Jul 14, 2026

A company runs continuous integration/continuous delivery (CI/CD) pipelines for its application on AWS CodePipeline. A developer must write unit tests and run them as part of the pipelines before staging the artifact...

Let's evaluate each option to determine how the developer can best incorporate unit tests into the CI/CD pipeline in AWS CodePipeline. A) Create a separate CodePipeline pipeline to run unit tests. - Analysis: Creating a separate pipeline solely for unit tests would add unnecessary complexity. The goal of CI/CD pipelines is to streamline the process, and splitting the unit tests into a different pipeline would introduce overhead by creating an additional pipeline that needs to be maintained and managed. - Why it might be rejected: Having a separate pipeline for running unit tests is redundant and goes against the idea of integrating unit testing as part of the main pipeline. It complicates the process instead of simplifying it. - Best use case: This could be used in scenarios where testing requires a separate environment or highly isolated execution, but it’s not suitable for regular CI/CD workflows. B) Update the AWS CodeBuild build specification to include a phase for running unit tests. - Analysis: This option integrates the unit tests directly into the build process. CodeBuild is used to run the build steps, and updating the build specification (buildspec.yml) to include a test phase ensures that the unit tests are executed during the CI/CD pipeline before the artifacts are staged for further testing. This is the most efficient and standard way to include unit tests in a pipeline. - Why it’s the best option: The developer can easily include a `test` phase in the `buildspec.yml` file where the unit tests are run before staging the artifacts. This is a streamlined and effective approach to ensure that unit tests are part of the pipeline without adding extra complexity. - Best use case: This is the ideal approach when you want to ensure that unit tests are automatically run during the pipeline’s build phase, allowing quick feedback on code quality. C) Install the AWS CodeDeploy ...

Author: GlowingTiger · Last updated Jul 14, 2026

A developer is troubleshooting a three-tier application, which is deployed on Amazon EC2 instances. There is a connectivity problem between the application servers and the database servers. Which...

To identify the faulty component causing the connectivity issue between application servers and database servers in a three-tier application deployed on Amazon EC2, the developer needs to use services that can help diagnose network-related issues and provide visibility into communication between EC2 instances. Let's evaluate each option: A) AWS CloudTrail - Analysis: AWS CloudTrail records API calls made within your AWS account, including calls to EC2 instances, VPCs, and other AWS resources. While it provides an audit trail of actions taken on AWS resources, it doesn't provide insights into real-time network traffic or connectivity issues between EC2 instances. - Why it might be rejected: CloudTrail is more useful for tracking administrative activities and changes in configuration, not for identifying connectivity issues between application and database servers. It won't help in diagnosing network-level problems. - Best use case: CloudTrail would be useful for auditing and tracking API activity but not for diagnosing network connectivity issues. B) AWS Trusted Advisor - Analysis: AWS Trusted Advisor provides best practice recommendations for optimizing your AWS environment in various areas, including cost optimization, performance, security, and fault tolerance. While it helps with general best practices, it doesn't provide detailed network-level diagnostics. - Why it might be rejected: Trusted Advisor focuses on providing recommendations rather than diagnosing specific connectivity issues. While it can highlight security or networking configuration recommendations, it doesn't directly address real-time connectivity troubleshooting. - Best use case: Trusted Advisor can be useful for overall environment optimization but isn't directly suited for troubleshooting connectivity problems in a three-tier architecture. C) Amazon VPC Flow Logs - Analysis: Amazon VPC Flow Logs capture information about IP traffic going to and from network interfaces in your VPC. This data includes information about source and destination IPs, ports, and protocols, making it an excellent tool for diagnosing connectivity issues, especially if there's a problem with security groups, NACLs, or routing between application servers and database servers. - Why it’s the best option: VPC Flow Logs provide detailed insights into the network traffic, all...

Author: Maya · Last updated Jul 14, 2026

A company runs a new application on AWS Elastic Beanstalk. The company needs to deploy updates to the application. The updates must not cause any downtime for application users. The deployment must forward a specified percentage of incoming client traffic ...

Let's evaluate the deployment types available in AWS Elastic Beanstalk to identify the best option for the requirements of minimizing downtime and forwarding a specified percentage of traffic to a new application version during an evaluation period. A) Rolling - Analysis: In a rolling deployment, Elastic Beanstalk updates instances in batches, replacing one batch at a time. While this helps minimize downtime by avoiding full application outages, it does not provide a mechanism for splitting traffic between the old and new application versions during the evaluation period. - Why it might be rejected: Rolling deployments don't allow for traffic splitting, which is a key requirement in this scenario. It would only shift traffic gradually to the new version without explicitly forwarding a percentage of traffic during an evaluation period. - Best use case: Rolling deployments are good for minimizing downtime during updates but don't meet the need for traffic splitting and gradual evaluation of the new version. B) Traffic-splitting - Analysis: Traffic-splitting deployments in Elastic Beanstalk allow you to route a specified percentage of incoming traffic to the new application version while the rest continues to use the old version. This deployment type supports the exact requirement of forwarding a percentage of traffic to the new version during an evaluation period, making it an ideal solution. - Why it’s the best option: Traffic-splitting ensures no downtime for users by gradually transitioning traffic to the new version and allows for monitoring and testing of the new application version during the evaluation period. This meets both the zero-downtime and traffic-splitting requirements effectively. - Best use case: This option is perfect when you need to evaluate the new version under real user traffic conditions and can progressively shift traffic without disrupting the user experience. C) In-place - Analysis: In an in-pl...

Author: Olivia Johnson · Last updated Jul 14, 2026