A developer is building a serverless application that connects to an Amazon Aurora PostgreSQL database. The serverless application consists of hundreds of AWS Lambda functions. During every Lambda function scale out, a new database connection is made that increases database resource consumption. The developer needs to decrease the number of c...

To address the problem of excessive database connections during Lambda function scaling, let's evaluate each option carefully. A) Configure provisioned concurrency for each Lambda function by setting the ProvisionedConcurrentExecutions parameter to 10. - Explanation: Provisioned concurrency pre-warms a set number of Lambda instances to ensure they are ready to handle requests immediately. While this reduces cold start latency, it does not directly manage the number of database connections. Each Lambda instance still opens a new database connection, which does not solve the problem of excessive database connections. - Rejection Reason: This option does not reduce the number of database connections made by scaling Lambda functions, which is the core issue. B) Enable cluster cache management for Aurora PostgreSQL. Change the connection string of each Lambda function to point to cluster cache management. - Explanation: Cluster cache management for Aurora PostgreSQL is a feature designed to reduce the load on the primary database by caching query results. However, this is mainly designed to optimize query performance and reduce database load, but it does not address the issue of managing database connections. It doesn’t pool or reduce the number of connections established by Lambda functions. - Rejection Reason: This option does not specifically manage the connection count or pooling for Lambda functions, so it does not meet the requirements. C) Use Amazon RDS Proxy to create a connection pool to manage the database connections. Change the connec...

Author: Ethan Smith · Last updated May 18, 2026

A developer is preparing to begin development of a new version of an application. The previous version of the application is deployed in a production environment. The developer needs to deploy fixes and updates to the current version during the development of the new version of the application...

Let's evaluate each option based on the requirements: the developer needs to deploy fixes and updates to the current version of the application while also developing a new version. The code for the new version is stored in AWS CodeCommit. A) From the main branch, create a feature branch for production bug fixes. Create a second feature branch from the main branch for development of the new version. - Explanation: This option is a standard Git workflow where the main branch holds the production-ready code, and separate feature branches are created for bug fixes and new development. This ensures that the current production version can receive updates and fixes while the new version is being developed in parallel. Both feature branches can be merged back into the main branch after development and testing. - Reason for Selection: This is the most appropriate solution because it allows parallel development of the current version and the new version without affecting each other. It also ensures that bug fixes can be deployed without interfering with the ongoing development of the new version. B) Create a Git tag of the code that is currently deployed in production. Create a Git tag for the development of the new version. Push the two tags to the CodeCommit repository. - Explanation: Git tags are useful for marking specific points in history (like releases). However, using tags alone does not facilitate ongoing development or updates to the production code. Tags don't allow for active development or fixes, and they don’t provide a mechanism for applying bug fixes during the development of the new version. - Rejection Reason: While tags are useful for marking the current state of th...

Author: Noah Williams · Last updated May 18, 2026

A developer is creating an AWS CloudFormation stack. The stack contains IAM resources with custom names. When the developer tries to deploy the stack, they receive an Insufficie...

The issue the developer is facing arises from an InsufficientCapabilities error when deploying IAM resources with custom names in AWS CloudFormation. Let's evaluate each option to identify how to resolve this issue: A) Specify the CAPABILITY_AUTO_EXPAND capability in the CloudFormation stack. - Explanation: The `CAPABILITY_AUTO_EXPAND` capability is used for expanding macros in AWS CloudFormation, such as AWS CloudFormation macros or custom resources. This capability is unrelated to IAM resources, custom names, or permissions required for IAM resource management. - Rejection Reason: This option is irrelevant because `CAPABILITY_AUTO_EXPAND` does not resolve issues with IAM permissions or custom IAM resource names. B) Use an administrator's role to deploy IAM resources with CloudFormation. - Explanation: While using an administrator's role may grant the necessary permissions to deploy IAM resources, it does not address the underlying issue of the error, which specifically relates to the need for a specific capability to allow the creation of IAM resources with custom names in CloudFormation. Using an administrator’s role alone may not resolve the InsufficientCapabilities error, as CloudFormation still needs to be explicitly told that it is allowed to create certain IAM resources. - Rejection Reason: This option...

Author: Aarav · Last updated May 18, 2026

A company uses Amazon API Gateway to expose a set of APIs to customers. The APIs have caching enabled in API Gateway. Customers need a way to invalidate the cache for each API when they test the API. ...

To allow customers to invalidate the cache for the API exposed by Amazon API Gateway, the solution needs to focus on providing customers a way to trigger cache invalidation. Let's evaluate the provided options: A) Ask the customers to use AWS credentials to call the InvalidateCache API operation. - Explanation: This option suggests that customers can use AWS credentials to directly invoke the `InvalidateCache` API operation. While this is technically feasible (the `InvalidateCache` operation is part of the API Gateway management APIs), it is not an efficient or practical approach for API consumers. This would require customers to have AWS credentials and permissions to invoke AWS API Gateway administrative operations, which is generally not recommended for production environments. - Rejection Reason: Requiring customers to directly use AWS credentials to invalidate the cache is not ideal because it involves giving customers access to backend management operations, which introduces security and permission complexity. B) Attach an InvalidateCache policy to the IAM execution role that the customers use to invoke the API. Ask the customers to send a request that contains the Cache-Control:max-age=3D0 HTTP header when they make an API call. - Explanation: The `Cache-Control:max-age=0` header can be used to prevent caching for a particular request, but it doesn’t invalidate the cache for all customers or allow for a global invalidation. This approach will only affect cache behavior for individual API requests but does not provide a method to clear or invalidate the cache for all users. - Rejection Reason: This is not an effective method to invalidate the cache as it doesn't allow for a global or API-wide cache invalida...

Author: Sofia · Last updated May 18, 2026

A developer is creating an AWS Lambda function that will generate and export a file. The function requires 100 MB of temporary storage for temporary files while running. These files will not be needed after the ...

Option A: Store the files in Amazon Elastic Block Store (Amazon EBS) and delete the files at the end of the Lambda function. - Reason for rejection: Amazon EBS is primarily used for persistent storage attached to EC2 instances. AWS Lambda doesn't have direct access to EBS volumes by default. It also adds complexity, as EBS requires provisioning and management, such as attaching it to an EC2 instance. Lambda functions don't inherently support EBS, which would involve additional configuration. This makes it less efficient than other options. - Best scenario: Would be useful for EC2 instances requiring persistent storage, but not for Lambda functions. Option B: Copy the files to Amazon Elastic File System (Amazon EFS) and delete the files at the end of the Lambda function. - Reason for rejection: Amazon EFS is a scalable file storage system suitable for persistent storage across multiple instances, but it is generally overkill for temporary storage in Lambda functions. Using EFS introduces additional costs, configuration complexity, and may increase latency due to network access. Lambda functions can use EFS, but it's unnecessary unless the function requires persistent, shared file systems. - Best scenario: Suitable for multi-instance applications requiring shared file storage, not ideal for Lambda's temporary file needs. Option C: Store the files in the /tmp directory and delete the files at the end of the Lambda function. - Reason for selection: AWS Lambda provides a `/tmp` directory for tempor...

Author: Olivia · Last updated May 18, 2026

A company uses Amazon DynamoDB as a data store for its order management system. The company frontend application stores orders in a DynamoDB table. The DynamoDB table is configured to send change events to a DynamoDB stream. The company uses an AWS Lambda function to log and process the incoming orders based on data from the DynamoDB stream. An operational review reveals that the order quantity of incoming orders is someti...

To select the most appropriate option, let's analyze each solution in the context of the developer's requirement to create a dashboard that shows how many unique customers are affected by orders with quantity equal to 0. Option A: - Grant Lambda’s execution role permissions to upload logs to CloudWatch Logs. This suggests using CloudWatch Logs Insights to query logs, focusing on orders with a quantity of 0. The results would then be visualized on a CloudWatch dashboard. - Advantages: - CloudWatch Logs Insights allows querying logs for specific patterns, including order quantities. - A CloudWatch dashboard can display the query results. - Disadvantages: - Lambda logs could become large and complex, especially if the function processes numerous orders. This might make it harder to query and maintain, especially if the number of logs grows significantly. Option B: - Use Amazon Athena to query CloudTrail logs. Athena is often used to query logs stored in Amazon S3, specifically CloudTrail logs in this case, which track API calls. - Advantages: - Athena is useful for querying large volumes of log data efficiently. - Disadvantages: - CloudTrail logs are primarily for auditing AWS API calls and might not be structured for the specific use case of tracking orders with quantity equal to 0. Therefore, relying on CloudTrail logs would likely not give you the required level of detail about DynamoDB table changes (like order quantity) that are happening in the Lambda function. Option C: - Configure the Lambda function to send events to EventBridge. EventBridge would trigger based on the quantity of orders, and CloudWatch would be used as a target for visualization. - ...

Author: Zara · Last updated May 18, 2026

A developer needs to troubleshoot an AWS Lambda function in a development environment. The Lambda function is configured in VPC mode and needs to connect to an existing Amazon RDS for SQL Server DB instance. The DB instance is deployed in a private subnet and accepts connections by using port 1433. When the developer tests the function, the function...

Option A: Check that the function's security group has outbound access on port 1433 to the DB instance's security group. Check that the DB instance's security group has inbound access on port 1433 from the function's security group. - Reason for selection: In a VPC setup, both the Lambda function and the RDS instance are controlled by security groups. For the Lambda function to access the RDS instance, the function's security group must have the proper outbound rules to allow traffic to the DB instance on port 1433. Similarly, the RDS instance's security group needs to allow inbound traffic from the Lambda function on port 1433. This is a crucial configuration because if the security groups are not set up to allow the appropriate traffic, the Lambda function will be unable to connect to the DB. - Best scenario: Always necessary when dealing with VPCs, security groups, and instances that need to communicate over specific ports (like SQL Server). Option B: Check that the function's security group has inbound access on port 1433 from the DB instance's security group. Check that the DB instance's security group has outbound access on port 1433 to the function's security group. - Reason for rejection: The inbound access for the Lambda function is not the issue; the function requires outbound access to connect to the database. The function's security group must allow outbound traffic to the DB instance's security group, not the other way around. Similarly, RDS instances do not initiate outbound connections to Lambda functions. Therefore, this option would not address the problem. - Best scenario: Incorrect for troubleshooting connection issues where Lambda is trying to access an RDS instance. Option C: Check that the VPC is set up for a NAT gateway. Check that the DB instance has the public access option turned on. - Reason for rejection: The NAT gateway is typically used when instances in a private subnet need to access the internet. In this case, the Lambda function is already within the VPC, and the RDS instance doesn't need to be publicly accessible to allow Lambda to connect to it. This option...

Author: Isabella1 · Last updated May 18, 2026

A developer needs to launch a new Amazon EC2 instance by using the AWS CLI. Which AWS CLI command shou...

Option A: aws ec2 bundle-instance - Reason for rejection: The `aws ec2 bundle-instance` command was used in earlier versions of EC2 to bundle an instance for AMI creation or migration to S3. However, it is no longer used in the latest AWS EC2 management processes. This command does not launch a new EC2 instance, so it’s irrelevant for this scenario. - Best scenario: Used to bundle EC2 instances for migration or backup in older workflows, but not applicable now for launching new instances. Option B: aws ec2 start-instances - Reason for rejection: The `aws ec2 start-instances` command is used to start an existing, stopped EC2 instance, not to launch a new one. To launch a new instance, the developer would need a different command. - Best scenario: Used when restarting a previously stopped instance, not for launching new EC2 instances. Option C: aws ec2 confirm-product-instance - Reason for rejection: The `aw...

Author: Ravi Patel · Last updated May 18, 2026

A developer needs to manage AWS infrastructure as code and must be able to deploy multiple identical copies of the infrastructure, stage changes, and revert t...

Option A: Use cost allocation reports and AWS OpsWorks to deploy and manage the infrastructure. - Reason for rejection: AWS OpsWorks is a configuration management service that helps manage infrastructure but is not focused on infrastructure as code (IaC) or version-controlled deployments. Cost allocation reports are useful for tracking costs but do not help in the actual management or deployment of infrastructure. This option does not provide the flexibility or version control needed to manage infrastructure as code, stage changes, and revert to previous versions. - Best scenario: OpsWorks is suitable for application lifecycle management but not the best fit for infrastructure as code. Option B: Use Amazon CloudWatch metrics and alerts along with resource tagging to deploy and manage the infrastructure. - Reason for rejection: CloudWatch metrics and alerts are used to monitor AWS resources, and resource tagging helps organize resources for management. However, these are not used to manage infrastructure as code. There is no direct way to define infrastructure as code, deploy multiple copies, or revert to previous versions using just CloudWatch and tagging. This approach is primarily focused on monitoring and not on provisioning or version control. - Best scenario: Useful for monitoring and alerting, but not for managing infrastructure deployment or versioning. Option C: Use AWS Elastic Beanstalk and AWS CodeCommit to deploy and manage the infrastructure. - Reason for rejection: Elastic Beanstalk is an application deployment service, primarily for deploying appli...

Author: Maya · Last updated May 18, 2026

A developer is working on an AWS Lambda function that accesses Amazon DynamoDB. The Lambda function must retrieve an item and update some of its attributes, or create the item if it does not exist. The Lambda function has access to the primary key. ...

Let's analyze the IAM permissions that the developer would need to enable the Lambda function to retrieve an item, update its attributes, or create it if it doesn't exist. Breakdown of the operations: 1. Retrieve an item: The Lambda function will need permissions to retrieve an item from DynamoDB. This requires the `dynamodb:GetItem` permission. 2. Update some attributes: If the item exists, the Lambda function will need to modify it. The correct operation for this in DynamoDB is `dynamodb:UpdateItem`, which updates specific attributes of an existing item. 3. Create an item if it doesn't exist: If the item doesn't exist, the function will need to create it, which requires the `dynamodb:PutItem` permission. Now let's evaluate each option: - A) `dynamodb:DeleteItem`, `dynamodb:GetItem`, `dynamodb:PutItem`: - `dynamodb:DeleteItem` is unnecessary because the task does not involve deleting an item. - `dynamodb:GetItem` is required to retrieve an item, so it's valid. - `dynamodb:PutItem` is needed to create an item if it doesn't exist, so it's valid. - However, `DeleteItem` is an extraneous permission here. - B) `dynamodb:UpdateItem`, `dynamodb:GetItem`, `dynamodb:DescribeTable`: - `dynamodb:UpdateItem` is valid to update item attributes. - `dynamodb:GetItem` is valid...

Author: Harper · Last updated May 18, 2026

A developer has built a market application that stores pricing data in Amazon DynamoDB with Amazon ElastiCache in front. The prices of items in the market change frequently. Sellers have begun complaining that, after they update the price of ...

Let's break down each option and reason through the issue: Issue at Hand: The application stores pricing data in Amazon DynamoDB and uses Amazon ElastiCache in front of it to cache the data. Sellers are reporting that after they update the price of an item, the new price doesn't reflect on the product listing. This suggests that the application is likely fetching the cached data instead of the updated price from DynamoDB. Option Analysis: - A) The cache is not being invalidated when the price of the item is changed: - Explanation: ElastiCache is used to cache frequently accessed data, but if the cache is not invalidated or updated when the price of an item is changed in DynamoDB, users may continue to see the old price from the cache. - Why it's valid: If the cache isn't invalidated or updated properly after a price change, the application will continue serving stale data from the cache. This is a common caching problem. - Conclusion: This is a strong candidate for the issue because the complaint is that the price isn't changing on the product listing, implying the application is retrieving stale data from the cache. - B) The price of the item is being retrieved using a write-through ElastiCache cluster: - Explanation: With a write-through cache strategy, whenever data is written to the underlying database (DynamoDB), it should also be written to the cache simultaneously. This ensures that the cache reflects the same data as the database. - Why it's not likely: If the cache is properly set up as write-through, the price would be updated in both DynamoDB and ElastiCache simultaneously, so this wouldn't explain the issue of stale data in the prod...

Author: Benjamin · Last updated May 18, 2026

A company requires that all applications running on Amazon EC2 use IAM roles to gain access to AWS services. A developer is modifying an application that currently relies on IAM user access keys stored in environment variables to access Amazon DynamoDB tables using boto, the AWS SDK for Python. The developer associated a role with the same permissions as the IAM user to the EC2 instance, then deleted the IAM user. When the application was restarted, the AWS AccessDeniedException messa...

Let's evaluate each option to identify the most likely cause of the AccessDeniedException messages after the application was restarted: A) IAM policies might take a few minutes to propagate to resources. - Explanation: IAM policies generally propagate quickly, but in some cases, there could be a brief delay in the application of new policies or role assignments. - Reasoning: The application was restarted after the IAM user was deleted and the role was assigned to the EC2 instance. However, it’s unlikely that IAM policy propagation would take long enough to cause persistent access issues. If the role was correctly associated with the EC2 instance, the access should be granted almost immediately. - Conclusion: While this could be a factor, it's unlikely to be the primary cause in this case, especially since the AWS CLI worked fine on the server. B) Disabled environment variable credentials are still being used by the application. - Explanation: The application was originally using IAM user access keys stored in environment variables. After the IAM user was deleted and replaced by an EC2 instance role, it's possible that the environment variables (which store the old IAM user credentials) are still in use by the application. - Reasoning: When the application restarts, if the environment variables containing the old IAM user credentials are still set, they would take precedence over the instance role credentials. This would cause the application to try to authenticate using invalid IAM user credentials, leading to AccessDeniedException messages. - Conclusion: This is the most likely cause because environment variables containing IAM user credentials would still be in place and would override the instance role permissions. C) The AWS SDK doe...

Author: Alexander · Last updated May 18, 2026

A company has an existing application that has hardcoded database credentials. A developer needs to modify the existing application. The application is deployed in two AWS Regions with an active-passive failover configuration to meet company=E2=80=99s disaster recovery strategy. The developer needs a solution to store the credentials outside the cod...

Let's evaluate each option based on the requirements of storing the credentials securely, complying with the disaster recovery strategy, and being as secure as possible. A) Store the credentials in AWS Secrets Manager in the primary Region. Enable secret replication to the secondary Region. Update the application to use the Amazon Resource Name (ARN) based on the Region. - Pros: - AWS Secrets Manager is designed for securely storing sensitive information such as credentials, and it automatically integrates with AWS services to fetch secrets in a secure manner. - Cross-region replication is available in Secrets Manager, which ensures the credentials are available in both the primary and secondary regions, which aligns with the disaster recovery strategy. - Secrets Manager supports fine-grained access control and automatic rotation of secrets, improving security and reducing the risk of exposed credentials. - The ARN-based access to the secret ensures that the application can access the credentials based on the region dynamically. - Cons: - Slightly more expensive than other solutions like Systems Manager Parameter Store, but the added security features (automatic rotation, fine-grained access control) make it a highly secure option. - Conclusion: This is the most secure and disaster recovery-compliant solution because Secrets Manager was designed for storing sensitive credentials, and cross-region replication ensures the credentials are accessible in both regions. B) Store credentials in AWS Systems Manager Parameter Store in the primary Region. Enable parameter replication to the secondary Region. Update the application to use the Amazon Resource Name (ARN) based on the Region. - Pros: - Systems Manager Parameter Store is also a secure option for storing credentials and supports parameter replication across regions. - It integrates with AWS Identity and Access Management (IAM) for access control, and you can configure access policies for better security. - This solution could be less expensive compared to Secrets Manager. - Cons: - Unlike Secrets Manager, Parameter Store does not support automatic secret rotation out-of-the-box. This means that while it provides basic security and cross-region replication, it lacks some advanced security features. - The application would need to manually manage secret rotation and potentially update the credentials in Parameter Store manually. - Conclusion: While this is a secure solution, it is slightly less feature-rich and less secure than Secrets Manager, particularly when it comes to automatic secret rotation and management. C) Store credentials in a config file. Upload the config f...

Author: Max · Last updated May 18, 2026

A developer is receiving HTTP 400: ThrottlingException errors intermittently when calling the Amazon CloudWatch API. When a call fails, no data is retrieved. ...

Issue: The developer is receiving HTTP 400: ThrottlingException errors when calling the Amazon CloudWatch API, which means the application is exceeding the allowed request rate for CloudWatch API calls. When this error occurs, no data is retrieved, indicating that the request was rejected due to throttling. Key Considerations: 1. ThrottlingException errors are typically caused when an application exceeds the rate limit of API calls. Amazon CloudWatch has specific rate limits for API requests, and exceeding these limits results in throttling. 2. To resolve this issue, the best approach is to minimize the impact of throttling by handling retries properly, rather than just requesting a higher limit or changing the approach drastically. Option Breakdown: - A) Contact AWS Support for a limit increase: - Explanation: While a limit increase can help resolve issues if the application consistently exceeds the rate limits, requesting a limit increase should not be the first step. It’s better to address the throttling issue programmatically by retrying the request using best practices. - Why it's not ideal initially: Exceeding the limit could be a result of improper handling of API calls, and contacting AWS support may not be necessary if the issue can be solved with proper retry logic. - Conclusion: This option is not the best starting point. It's a more drastic approach, and retrying with exponential backoff is a preferred practice. - B) Use the AWS CLI to get the metrics: - Explanation: Using the AWS CLI to retrieve metrics can help troubleshoot the issue, but it does not solve the problem of throttling within the application. The application will still face throttling unless it implements proper handling for the CloudWatch API limits. - Why it's not ideal: This is more of a troubleshooting step rather than a solution to address the actual throttling issue. It doesn't prevent the intermittent ThrottlingException errors from occurring in the application. - Conclusion...

Author: Sophia · Last updated May 18, 2026

An application needs to use the IP address of the client in its processing. The application has been moved into AWS and has been placed behind an Application Load Balancer (ALB). However, all the client IP addresses now appear to be the same. The application must maintain t...

In this scenario, the application has been moved behind an Application Load Balancer (ALB), and all client IP addresses appear the same, likely due to the ALB being used as a proxy. The goal is to maintain horizontal scalability while correctly handling the original client IP address. Analysis of Options: - A) Remove the application from the ALB. Delete the ALB and change Amazon Route 53 to direct traffic to the instance running the application. - Rejected: Removing the ALB would eliminate its ability to distribute traffic across multiple instances, which directly contradicts the requirement for horizontal scalability. Additionally, managing the traffic directly to instances can lead to scalability, security, and maintenance challenges. The load balancing aspect would be lost, which is not cost-effective as it could require manual traffic distribution. - B) Remove the application from the ALB. Create a Classic Load Balancer in its place. Direct traffic to the application using the HTTP protocol. - Rejected: While this option would still provide load balancing, it introduces the use of a Classic Load Balancer (CLB), which lacks some of the more advanced features of the ALB (such as support for HTTP/2, WebSockets, or containerized workloads). Moreover, CLBs are typically considered less flexible and cost-effective than ALBs for applications that need to scale horizontally. This option doesn't provide a direct solution to maintaining the original client IP address without further changes. - C) Alter the application code to inspect the X-Forwarded-For header. Ensure that the code can work properly if a list of IP addresses is passed in the header. - Selected: This ...

Author: Suresh · Last updated May 18, 2026

A developer is designing a serverless application that customers use to select seats for a concert venue. Customers send the ticket requests to an Amazon API Gateway API with an AWS Lambda function that acknowledges the order and generates an order ID. The application includes two additional Lambda functions: one for inventory management and one for payment processing. These two Lambda functions run in parallel and write the order to an Amazon Dynamo DB table. The application must provide seats to customers according to the following requirements. If a seat is accidently sold more than once, the first order that the application received must get the seat. In these cases, th...

In this scenario, the application must ensure that seats are sold in a manner where the first order is given priority for payment processing, and if the first order is rejected, the second order can still receive the seat. Additionally, the solution must ensure that inventory management and payment processing occur in parallel but with the correct sequence of operations based on the order of receipt. Analysis of Options: - A) Send the order ID to an Amazon Simple Notification Service (Amazon SNS) FIFO topic that fans out to one Amazon Simple Queue Service (Amazon SQS) FIFO queue for inventory management and another SQS FIFO queue for payment processing. - Selected: This option is ideal for meeting the requirements because: - SNS FIFO Topic ensures that messages (order IDs) are processed in the exact order they are received. - The use of SQS FIFO queues for both inventory management and payment processing ensures that each function processes messages in a strict order. - FIFO guarantees the first order gets priority for processing the seat, and if payment for the first order fails, the second order gets the seat and proceeds with payment processing. - This ensures that both processes are parallel, but the seat is not double-booked, and the correct order is processed for payment. The FIFO behavior is crucial in this use case, and SNS and SQS FIFO topics/queues provide the needed message sequencing. - It is highly scalable and manages concurrency while maintaining order. - B) Change the Lambda function that generates the order ID to initiate the Lambda function for inventory management. Then initiate the Lambda function for payment processing. - Rejected: This approach results in a sequential and synchronous process, meaning the second Lambda function (payment processing) would only start after the first one (inventory management) completes. This would introduce unnecessary delays and would not allow parallel processing. Moreover, it doesn’t provide any guarantees on th...

Author: Sam · Last updated May 18, 2026

An application uses AWS X-Ray to generate a large amount of trace data on an hourly basis. A developer wants to use filter expressions to limit the returned results through user-specified custom attribu...

To filter the returned results in AWS X-Ray based on user-specified custom attributes, the developer needs to consider how AWS X-Ray stores and indexes trace data for querying. Analysis of Options: - A) Add custom attributes as annotations in the segment document. - Selected: Annotations are used to store key-value pairs in the segment document that are indexed for efficient filtering. Annotations are ideal for filtering trace results because they are indexed by X-Ray, allowing developers to query traces based on specific values in those attributes. - Why it's selected: Since the goal is to filter traces by custom attributes, annotations are specifically designed to be indexed for filtering. This ensures that custom attributes can be efficiently used in filter expressions to limit results. - When to use: This is the preferred choice when filtering traces based on key-value pairs (such as custom attributes) in AWS X-Ray. - B) Add custom attributes as metadata in the segment document. - Rejected: Metadata is used to store additional, non-indexed information in a segment document. While metadata allows storing custom data, it is not indexed by X-Ray, so it cannot be used effectively in filter expressions. - Why it's rejected: Metadata cannot be used for filtering trace results, as it isn't indexed. It's mainly for storing additional context but not for querying purposes. - C) Add custom attributes as ...

Author: Maya · Last updated May 18, 2026

A web application is using Amazon Kinesis Data Streams for clickstream data that may not be consumed for up to 12 hours. How can the developer imple...

To implement encryption at rest for data within Amazon Kinesis Data Streams, we need to ensure that the data is encrypted while it is stored in the stream, not just during transmission or when being processed by consumers. Analysis of Options: - A) Enable SSL connections to Kinesis. - Rejected: Enabling SSL (Secure Sockets Layer) connections ensures that data is encrypted in transit between the producer and the Kinesis stream. However, this does not address the need for encryption at rest (when the data is stored in the stream). SSL protects the data during transmission, but it doesn’t ensure that the data is encrypted while it is stored in the stream. - Why it's rejected: This option does not meet the requirement for encryption at rest, only encryption in transit. - B) Use Amazon Kinesis Consumer Library. - Rejected: The Amazon Kinesis Consumer Library (KCL) is used to process and consume data from Kinesis streams, and it provides features like load balancing and checkpointing. However, it does not handle encryption of data at rest. KCL is focused on data consumption, not data encryption, so it is not relevant to the encryption of data while it is stored in Kinesis. - Why it's rejected: KCL does not provide encryption at rest for the data in Kinesis. - C) Encrypt the data once it is at rest with a Lambda function. - Rejected: Using a Lambda function to manually encrypt the data after it is at rest would be a complex and inefficient solution. This would require additional infrastructure and ...

Author: Ava · Last updated May 18, 2026

An application is real-time processing millions of events that are received through an API. What service could be used to allow multiple consum...

In this scenario, the goal is to real-time process millions of events while allowing multiple consumers to process data concurrently in the most cost-effective way. Analysis of Options: - A) Amazon SNS with fanout to an SQS queue for each application. - Rejected: SNS is a great service for message fanout (broadcasting messages to multiple consumers), and SQS provides a reliable queuing mechanism. However, using standard SQS queues does not guarantee ordering, which might be important depending on the application’s needs. In addition, it would require multiple SQS queues for each consumer application, adding unnecessary complexity and increasing cost. - Why it's rejected: While SNS + SQS can work for fanout and concurrent processing, the solution lacks the scalability and order guarantees that other options (such as Kinesis Data Streams) offer. Also, having multiple queues can lead to higher management overhead and complexity. - B) Amazon SNS with fanout to an SQS FIFO (first-in, first-out) queue for each application. - Rejected: Similar to option A, this solution uses SQS FIFO queues, which provide ordering guarantees. However, FIFO queues introduce higher costs and limitations such as throughput restrictions (limited to 300 transactions per second for a single FIFO queue without batching). This can become a bottleneck when processing millions of events. - Why it's rejected: The added cost and throughput limitations of FIFO queues make this option less suitable for high-volume real-time event processing when compared to other more scalable options like Kinesis Data Streams. - C) Amazon Kinesis Firehose. - Rejected: Kinesis Firehose is designed for loading streaming data to storage destinations (like Amazon S3, Redshift, or Elasticsearch) without requiring you to manage the stream. ...

Author: Siddharth · Last updated May 18, 2026

Given the following AWS CloudFormation template: What is the MOST efficient way to reference the new Amazon S...

To efficiently reference an Amazon S3 bucket from another AWS CloudFormation template, let's review each option and analyze their suitability: Option A: Add an Export declaration to the Outputs section of the original template and use ImportValue in other templates. - Explanation: In CloudFormation, you can use the `Export` feature in the `Outputs` section of one stack, which makes the value available for import by other stacks. By specifying `Export` in the original template and `ImportValue` in the second template, the S3 bucket can be easily referenced by name or ARN in the second template. - Why this is effective: This method is efficient and commonly used in multi-stack architectures. The exported value remains dynamic and automatically updated if the original stack changes. The process is simple, clean, and integrates well within the AWS ecosystem, maintaining good separation of concerns between stacks. - When to use: This method is best when you have separate stacks, need to share resources like S3 buckets between stacks, and want a solution that is simple, low-maintenance, and supported natively by AWS CloudFormation. --- Option B: Add Exported: true to the Content.Bucket in the original template and use ImportResource in other templates. - Explanation: There is no `Exported: true` property in AWS CloudFormation. This option appears to be an invalid or unsupported approach. - Why this is rejected: The syntax and approach used in this option do not align with AWS CloudFormation standards, as `Exported: true` is not a recognized property in CloudFormation templates. --- Option C: Create a custom AWS CloudFormation resource that gets the buck...

Author: Maya · Last updated May 18, 2026

A developer has built an application that inserts data into an Amazon DynamoDB table. The table is configured to use provisioned capacity. The application is deployed on a burstable nano Amazon EC2 instance. The application logs show that the application has been failing because of a Pr...

Let's analyze each option and determine the most appropriate actions to resolve the ProvisionedThroughputExceededException error in Amazon DynamoDB, based on the scenario. Option A: Move the application to a larger EC2 instance. - Explanation: Moving to a larger EC2 instance might provide more computing power and network throughput, but it does not directly address the issue of DynamoDB throughput being exceeded. - Why this is rejected: The issue is related to the provisioned capacity of the DynamoDB table being exceeded, not the EC2 instance performance. The EC2 instance might be insufficient for handling application load, but simply upgrading it does not address the DynamoDB throughput issue directly. - When to use: This could be a consideration if there is a separate performance bottleneck related to the application or EC2 instance itself. However, it is not a direct solution to a DynamoDB throughput issue. --- Option B: Increase the number of read capacity units (RCUs) that are provisioned for the DynamoDB table. - Explanation: Increasing the number of provisioned read capacity units (RCUs) for the table directly addresses the issue by allowing more read requests to be served. This would resolve the ProvisionedThroughputExceededException by making sure that the table has enough capacity to handle the application's read operations. - Why this is selected: If the error is caused by too many read requests that exceed the provisioned throughput, increasing the RCUs can resolve the problem by allowing DynamoDB to handle more read operations concurrently. This is a direct solution. - When to use: This is the appropriate solution if the problem is related to exceeding read capacity. --- Option C: Reduce the frequency of requests to DynamoDB by implementing exponential backoff. - Explanation: Exponential backoff is a retry strategy that gradually increases the time between successive requests when an error like ProvisionedThroughputExceededException occurs. This can help reduce the rate of requests and mitigate temporary throughput limits, but it doesn't solve the root cause of exceeding throughput. - Why this is selected: Exponential backoff is a best practice for handling provisioned throughput exceeded errors. Whil...

Author: CrimsonViperX · Last updated May 18, 2026

A company is hosting a workshop for external users and wants to share the reference documents with the external users for 7 days. The company stores the reference documents in an Amazon S3 bucket that the co...

Let's analyze each option and determine the most secure method to share the documents with external users for 7 days: Option A: Use S3 presigned URLs to share the documents with the external users. Set an expiration time of 7 days. - Explanation: A presigned URL allows temporary access to a private S3 object without making the object publicly accessible. The URL can be configured with an expiration time, after which it becomes invalid. This method is straightforward and can be configured for a specific document or set of documents. - Why this is selected: This method is both secure and simple. The URLs are temporary, and access can be limited to a 7-day period. The objects themselves remain private in the S3 bucket, and the presigned URLs ensure that external users can access the documents only for the specified duration. It's also easy to automate the generation of presigned URLs programmatically. - When to use: This option is ideal when the documents are stored in an S3 bucket, and the access needs to be limited to a short time period (e.g., 7 days). --- Option B: Move the documents to an Amazon WorkDocs folder. Share the links of the WorkDocs folder with the external users. - Explanation: Amazon WorkDocs is a fully managed, secure document storage and collaboration service. You can upload documents to WorkDocs and share them with users via links. However, WorkDocs is a separate service from S3, and it may require more setup and configuration compared to using S3 directly. - Why this is rejected: While WorkDocs can provide secure sharing features, it introduces unnecessary complexity if the documents are already stored in S3. Additionally, managing access via WorkDocs might involve additional permissions and configuration overhead. In this case, the simplest and most secure way is to use presigned URLs within S3. - When to use: WorkDocs is useful for ongoing collaboration and document management within a corporate environment, but for temporary, limited-time sharing, S3 presigned URLs are more appropriate. --- Option C: Create temporary IAM users that have read-only access to...

Author: Evelyn · Last updated May 18, 2026

A developer is planning to use an Amazon API Gateway and AWS Lambda to provide a REST API. The developer will have three distinct environments to manage: development, test, and production. How s...

Let's analyze each option based on the requirement to manage multiple environments (development, test, and production) while minimizing the number of resources to manage: A) Create a separate API Gateway and separate Lambda function for each environment in the same Region. - Pros: - This option creates complete isolation between environments, meaning that each environment can have its own API Gateway and Lambda function. - Cons: - Increased resource management: This approach increases the number of resources needed (API Gateway and Lambda functions) since each environment would require its own set. This can result in significant overhead when managing, monitoring, and maintaining multiple copies of resources. - Scaling issues: As the number of environments grows, it can become cumbersome to replicate and maintain separate configurations for each environment. - Conclusion: While it provides isolation, this option is not efficient in terms of resource management. B) Assign a Region for each environment and deploy API Gateway and Lambda to each Region. - Pros: - This provides full isolation between environments by placing them in different Regions. - Cons: - Increased cost and complexity: Deploying to different Regions for each environment means that you need to manage and maintain resources across multiple Regions. This adds unnecessary complexity and could result in higher costs due to inter-region data transfer. - Not necessary: There's no requirement to use multiple Regions for different environments, and this would increase the operational overhead. - Conclusion: This is an over-engineered solution, as it introduces unnecessary complexity by spreading environments across Regions. C) Create one API Gateway with multiple stages with one Lambda function with multiple aliases. - Pros: - Minimal resources: This option minimizes the number of resources needed. You can use a single API Gateway and Lambda function across all environments. - ...

Author: Emma Brown · Last updated May 18, 2026

A developer registered an AWS Lambda function as a target for an Application Load Balancer (ALB) using a CLI command. However, the Lambda function is not being invoked when the client ...

Let's analyze each option to determine why the Lambda function is not being invoked by the Application Load Balancer (ALB): Option A: A Lambda function cannot be registered as a target for an ALB. - Explanation: This statement is incorrect. AWS Lambda functions can be registered as targets for an ALB. In fact, the feature to integrate Lambda functions with ALB was introduced to allow direct invocation of Lambda functions via HTTP(S) requests through the ALB. Therefore, this option is not the correct explanation. - Why this is rejected: This option is factually incorrect because Lambda functions can be used as targets in an ALB, so this cannot be the cause of the issue. - When to use: This is never the case, as Lambda functions can indeed be targets for ALB. --- Option B: A Lambda function can be registered with an ALB using AWS Management Console only. - Explanation: Lambda functions can be registered as ALB targets not only through the AWS Management Console but also via the AWS CLI or SDKs. Therefore, it is not true that the console is the only method for registration. - Why this is rejected: This statement is incorrect because Lambda functions can be registered through multiple methods, including the CLI. The issue described is unrelated to the method of registration. - When to use: This is never the case. Lambda functions can be registered using both the console and the CLI. --- Option C: The permissions to invoke the Lambda function are missing. - Explanation: This option is very plausible. For an ALB to invoke a Lambda function, the Lambda function must have the appropriate permissions to be invoked by the ALB. If the correct IAM role and policy that allows the ...

Author: Isabella1 · Last updated May 18, 2026

A developer is creating an AWS Lambda function that will connect to an Amazon RDS for MySQL instance. The developer wants to store the database credentials. The database credentials need to be encrypted and the databa...

Let's analyze each option: A) Store the database credentials as environment variables for the Lambda function. Set the environment variables to rotate automatically. - Reasoning: Environment variables are an easy way to store credentials, but AWS Lambda does not have native support for automatic rotation of environment variables. You would need to implement your own password rotation process, which would require extra management overhead and may not be as secure as a purpose-built solution. - Why rejected: This option doesn’t provide automatic rotation of database credentials, and you would need to handle encryption and key management manually. B) Store the database credentials in AWS Secrets Manager. Set up managed rotation on the database credentials. - Reasoning: AWS Secrets Manager is a fully managed service that can store, manage, and automatically rotate secrets like database credentials. It integrates with Lambda and RDS and provides built-in encryption and automatic credential rotation. - Why selected: This option provides everything needed — encrypted storage, automatic rotation, and ease of integration with Lambda and RDS. It minimizes management overhead and ensures the database password is always r...

Author: Mia · Last updated May 18, 2026

A developer wants to reduce risk when deploying a new version of an existing AWS Lambda function. To test the Lambda function, the developer needs to split the traffic between the existing version and ...

Let’s evaluate each option: A) Configure a weighted routing policy in Amazon Route 53. Associate the versions of the Lambda function with the weighted routing policy. - Reasoning: Route 53 is used to manage DNS routing, not for Lambda function version management. Lambda function versions are not directly associated with Route 53, and a weighted routing policy in Route 53 would be more appropriate for splitting traffic between different endpoints (e.g., EC2 instances or load balancer targets). Lambda versions do not integrate with Route 53 in this context. - Why rejected: Route 53 is not the right tool for splitting traffic between Lambda function versions. It is meant for routing traffic based on DNS rather than directly splitting traffic between versions of a Lambda function. B) Create a function alias. Configure the alias to split the traffic between the two versions of the Lambda function. - Reasoning: AWS Lambda supports function aliases, which can point to specific versions of a Lambda function. With an alias, you can define the percentage of traffic sent to different versions of the function. This is an ideal solution for testing a new version of the Lambda function in production, allowing the developer to gradually roll out the new version and monitor its behavior. - Why selected: This is the correct and most straightforward solution for splitting traffic between different Lambda function versions. It is a native AWS feature, supports fin...

Author: VenomousSerpent42 · Last updated May 18, 2026

A developer has created a large AWS Lambda function. Deployment of the function is failing because of an InvalidParameterValueException error. The error message indicates that the unzipped size of the function exceeds the maxi...

Let’s evaluate each option: A) Submit a quota increase request to AWS Support to increase the function to the required size. - Reasoning: AWS Lambda has a hard limit on the unzipped size of a Lambda function (250 MB). There is no option to increase this limit, as it is a service limit, not configurable by a quota request. Even if you submit a request, AWS Lambda will not allow function sizes to exceed this limit. - Why rejected: There is no way to increase the unzipped size of a Lambda function beyond the 250 MB limit. Therefore, this option cannot resolve the issue. B) Use a compression algorithm that is more efficient than ZIP. - Reasoning: Lambda only accepts function packages in ZIP format for deployment. While you may be able to compress the file using other algorithms, Lambda still requires the function to be in ZIP format for deployment. Therefore, using a different compression algorithm won’t help to meet the size requirements. - Why rejected: This option does not address the root problem, as Lambda only supports ZIP files for function deployment, regardless of the compression algorithm. C) Break up the function into multiple smaller functions. - Reasoning: Splitting a large Lambda function into multiple smaller, more manageable functions is a good strategy for optimizing function size. This would allow each individual function to stay within the size limits and enable more granular control over the function's purpose. You can then use other AWS services (e.g., Step Functions or EventBridge) to orc...

Author: Elizabeth · Last updated May 18, 2026

A developer is troubleshooting an application in an integration environment. In the application, an Amazon Simple Queue Service (Amazon SQS) queue consumes messages and then an AWS Lambda function processes the messages. The Lambda function transforms the messages and makes an API call to a third-party service. There has been an increase in application usage. The third-party API frequently returns an HTTP...

Let's evaluate each option: A) Increase the SQS event source's batch size setting. - Reasoning: The batch size determines how many messages from the SQS queue are processed together in a single invocation of the Lambda function. Increasing the batch size would mean that more messages are sent to the Lambda function at once. However, this doesn't address the underlying problem, which is that the third-party API is rate-limited and responds with HTTP 429 errors. Increasing the batch size would only increase the load on the third-party API, potentially exacerbating the problem. - Why rejected: Increasing the batch size would result in more requests to the third-party API at once, which could overwhelm it even further, worsening the error scenario. B) Configure provisioned concurrency for the Lambda function based on the third-party APIs documented rate limits. - Reasoning: Provisioned concurrency enables a predefined number of Lambda instances to be ready to serve requests immediately, which is useful for reducing cold start latency. However, it does not directly address the issue of rate-limiting by the third-party API. Even if Lambda is provisioned with concurrency, if the API can't handle the volume of requests, it will still return HTTP 429 errors. This solution is more useful for reducing latency, not for handling rate-limiting from an external service. - Why rejected: This option does not address the rate-limiting problem caused by the third-party API and would not reduce the frequency of HTTP 429 errors. C) Increase the retry attempts and maximum event age in the Lambda function's asynchr...

Author: Liam123 · Last updated May 18, 2026

A company has a three-tier application that is deployed in Amazon Elastic Container Service (Amazon ECS). The application is using an Amazon RDS for MySQL DB instance. The application performs more database reads than writes. During times of peak usage, the application=E2=80=99s performance degrades. When this performance degradation occurs, the DB...

Let's evaluate each option: A) Use Amazon ElastiCache to cache query results. - Reasoning: Since the application performs more database reads than writes, implementing a caching layer using Amazon ElastiCache (either with Redis or Memcached) would be a highly effective solution. By caching frequent query results, the application can reduce the number of read requests made to the RDS MySQL database, which can alleviate pressure on the database and reduce read latency during peak usage times. This would directly address the performance degradation caused by the increased ReadLatency metric in CloudWatch. - Why selected: Caching frequently accessed data with ElastiCache reduces the load on the RDS instance, thus improving application performance. It's a common and effective solution for read-heavy workloads, especially when the database is a bottleneck during peak times. B) Scale the ECS cluster to contain more ECS instances. - Reasoning: Scaling the ECS cluster would provide more resources for running the application itself, but it doesn’t directly address the issue of read latency in the RDS MySQL database. If the database is the bottleneck, simply adding more ECS instances won't improve database performance. While scaling ECS may provide more capacity for the application to handle traffic, it could still lead to the same RDS performance degradation if the database can't handle the load. - Why rejected: Scaling ECS would not solve the issue related to RDS database performance degradation, as it does n...

Author: Matthew · Last updated May 18, 2026

A company has an online web application that includes a product catalog. The catalog is stored in an Amazon S3 bucket that is named DOC-EXAMPLE-BUCKET. The application must be able to list the objects in the S3 bucket and must be able to do...

Author: Leo · Last updated May 18, 2026

A developer is writing an application to encrypt files outside of AWS before uploading the files to an Amazon S3 bucket. The encryption must be symmetric and must be performed inside the application. How ...

Let's review each option and analyze which one meets the requirements for performing symmetric encryption inside the application, while uploading files to Amazon S3: A) Create a data key in AWS Key Management Service (AWS KMS). Use the AWS Encryption SDK to encrypt the files. - Pros: - Symmetric encryption: AWS KMS provides symmetric encryption, which is the requirement here. - AWS Encryption SDK: The AWS Encryption SDK is a high-level tool that simplifies the encryption and decryption of data. It supports the generation of data keys from KMS, which can be used for local encryption before uploading the data to S3. - Security: The data key is generated by KMS and can be used to encrypt the data locally in the application, meeting the requirement to perform encryption inside the application. - Compliance: This approach ensures that encryption is done following AWS best practices, with KMS managing the keys securely. - Conclusion: This option fits perfectly as it satisfies all the requirements—symmetric encryption and internal encryption in the application before uploading the files to S3. B) Create a Hash-Based Message Authentication Code (HMAC) key in AWS Key Management Service (AWS KMS). Use the AWS Encryption SDK to encrypt the files. - Cons: - HMAC is not encryption: HMAC (Hash-Based Message Authentication Code) is used for verifying integrity and authenticity of data, not for encryption. This does not provide the encryption functionality required in the problem statement. - Misalignment with requirements: Since the requirement is for symmetric encryption, HMAC is not suitable because it is designed for integrity checks, not encryption. - Conclusion: This option is not appropriate because it does not fulfill the encryption requirement. C) Create a data key pair in AWS Key Management Service (...

Author: Carlos Garcia · Last updated May 18, 2026

A developer is working on an application that is deployed on an Amazon EC2 instance. The developer needs a solution that will securely transfer files from the application to an Amazon S3 bucket...

Let's analyze each option to determine which solution will securely transfer files from the application to Amazon S3 with the highest level of security: A) Create an IAM user. Create an access key for the IAM user. Store the access key in the application's environment variables. - Cons: - Hardcoding credentials: Storing the IAM user’s access key in environment variables is not recommended because the credentials are effectively hardcoded. If the EC2 instance is compromised, the access key could be extracted and misused. - IAM user management: IAM users are typically for human users, and using IAM users for application access can be harder to manage, especially as the application scales or evolves. - Security risks: Storing access keys on the EC2 instance, even as environment variables, can expose the credentials to potential attackers, making this less secure. - Conclusion: This is not the best option because it introduces security risks by managing credentials directly in the application environment. B) Create an IAM role. Create an access key for the IAM role. Store the access key in the application's environment variables. - Cons: - Similar issues to option A: Even though an IAM role is created, using an access key associated with the IAM role and storing it in the environment variables still exposes the credentials in the application environment, which introduces the same security risks as option A. - IAM role should not require hardcoded keys: IAM roles should be assigned to EC2 instances directly, without the need to create or manage access keys in the environment variables. - Conclusion: This option also introduces unnecessary security risks by managing access keys in the environment variables, which is not ideal. C) Create an IAM role. Configure the IAM role to access the specific Amazon S3 API calls the application requires. Associate the IAM role with the EC2 instance. - Pros: - IAM role for EC2: This approach uses an IAM role,...

Author: Ella · Last updated May 18, 2026

A developer created a web API that receives requests by using an internet-facing Application Load Balancer (ALB) with an HTTPS listener. The developer configures an Amazon Cognito user pool and wants to ensure that every request to the ...

To ensure that every request to the API is authenticated through Amazon Cognito, the solution should authenticate incoming requests based on the presence and validity of a token issued by the Amazon Cognito user pool. Let's evaluate each option: Key Considerations: 1. Integration with Amazon Cognito: The solution must integrate directly with Amazon Cognito for user authentication. 2. API security: It must ensure that only authenticated requests can reach the web API. 3. Use of ALB (Application Load Balancer): The ALB is already handling the HTTPS listener, so it should be leveraged for authentication. Option Analysis: Option A: Add a listener rule to the listener to return a fixed response if the Authorization header is missing. Set the fixed response to 401 Unauthorized. - Fixed Response: This option involves checking for the Authorization header and returning a 401 Unauthorized response if it's missing. However, it doesn't provide a mechanism for authenticating the user with Cognito; it only checks if the header is present. - Limited Functionality: This option doesn’t address the requirement for authenticating the request with Amazon Cognito. - Rejected: While it ensures the header is present, it doesn’t authenticate the user, so it doesn't meet the requirement. Option B: Create an authentication action for the listener rules of the ALB. Set the rule action type to authenticate-cognito. Set the OnUnauthenticatedRequest field to "deny." - Authentication with Cognito: This option uses an ALB listener rule to integrate directly with Amazon Cognito for user authentication. It specifies that requests should be authenticated using Cognito, and if unauthenticated, they will be denied. - Ideal Solution: This directly integrates Cognito authentication with the ALB, which is exactly what is needed to ensure only authenticated requests are allowed. - Selected: This option is the best choice because it integrates Cognito ...

Author: Amelia · Last updated May 18, 2026

A company recently deployed an AWS Lambda function. A developer notices an increase in the function throttle metrics in Amazon CloudWatch. What are the MOST operation...

To address an increase in throttling metrics for an AWS Lambda function, we need to look at ways to increase the concurrency limit or optimize the function's capacity to prevent throttling. Here's an analysis of each option based on operational efficiency: Key Factors: - Concurrency: Throttling typically happens when the Lambda function exceeds the allowed concurrency limits, so increasing available concurrency or managing it better is essential. - Operational Efficiency: The solution should minimize manual intervention and be scalable without introducing unnecessary complexity. Option Analysis: Option A: Migrate the function to Amazon Elastic Kubernetes Service (Amazon EKS). - EKS: Migrating the Lambda function to Amazon EKS involves a significant architectural change. Lambda and EKS are different services with different operational models. EKS is best for containerized applications and not for serverless functions like Lambda. - Complexity and Effort: Migrating to EKS requires more operational overhead, such as managing containers, networking, scaling, and other complexities. This is not an efficient solution for Lambda throttling. - Rejected: This option would significantly increase operational complexity and is not relevant for addressing Lambda throttling. Option B: Increase the maximum age of events in Lambda. - Event Age: Increasing the maximum age of events only impacts the ability to retry or process events that may be delayed. This doesn't directly influence the throttling behavior of Lambda, as throttling occurs when the function exceeds its concurrency limits, not when events are aged. - Ineffective: This action doesn't address the core issue of throttling related to concurrency limits. - Rejected: Not an effective solution for reducing throttling, as it doesn’t directly impact the number of concurrent executions. Option C: Increase the function's reserved concurrency. - Reserved Concurrency: This option ensures that the Lambda function has a dedicated pool of concurrency, limiting the number of concurrent executions for other functions while preventing throttling on the target function. By increasing reserved concur...

Author: Joseph · Last updated May 18, 2026

A company is creating a REST service using an Amazon API Gateway with AWS Lambda integration. The service must run different versions for testi...

When managing different versions of an API in Amazon API Gateway, the ideal approach balances ease of implementation, flexibility, and clear separation of concerns. Let's evaluate each option based on these factors: A) Use an X-Version header to denote which version is being called and pass that header to the Lambda function(s). - Pros: This allows flexibility because the API can handle multiple versions through the header without needing separate endpoints for each version. It's simple to implement and can be used with any HTTP request. - Cons: While it simplifies the API’s surface area by reusing the same endpoint, it increases complexity on the Lambda side since the function must inspect and handle the version logic. The versions will need to be maintained within the Lambda code itself, which might not be ideal if there are significant changes between versions or if versioning grows complex. - When to use: This approach works when the API versions are relatively small in change and are closely related. It’s better suited when you want to avoid managing multiple endpoints. B) Create an API Gateway Lambda authorizer to route API clients to the correct API version. - Pros: This approach centralizes the routing logic and delegates the responsibility of version handling to the Lambda authorizer, providing a way to isolate logic at the authentication level. - Cons: The Lambda authorizer would need to contain complex logic for version routing, which might be overkill for simple version management. This could result in redundant logic and added complexity in routing, especially if version changes are frequent. - When to use: This approach could be helpful when using different levels of authentication or authorization for different API versions, but it is not ideal for simpler versioning schemes. C) Create an API Gateway resource policy to isolate versions and provide context to ...

Author: SilverBear · Last updated May 18, 2026

A company is using AWS CodePipeline to deliver one of its applications. The delivery pipeline is triggered by changes to the main branch of an AWS CodeCommit repository and uses AWS CodeBuild to implement the test and build stages of the process and AWS CodeDeploy to deploy the application. The pipeline has been operating successfully for several months and there have been no modifications. Following...

Evaluating each option: A) The change was not made in the main branch of the AWS CodeCommit repository. - Pros: This is a valid scenario. If the change was made in a branch other than the main branch and the pipeline is set to trigger only on changes to the main branch, then the pipeline would not be triggered. - Cons: This issue could be easily identified by checking if the change was committed to the correct branch. - When to use: This applies when a change was mistakenly made to a branch that doesn’t trigger the pipeline. It's a good check if the trigger event (CodeCommit push to the main branch) didn’t happen. B) One of the earlier stages in the pipeline failed and the pipeline has terminated. - Pros: This is a common reason for deployment failures. AWS CodePipeline will stop the process if any of its earlier stages fail. For instance, if the CodeBuild stage fails (e.g., due to errors in the code), the pipeline won't reach the CodeDeploy stage. - Cons: This could be easily checked by reviewing the CodePipeline execution logs, where any errors or failures in prior stages are reported. - When to use: This scenario applies if CodePipeline was triggered but failed in the test/build stage or elsewhere, preventing CodeDeploy from running. C) One of the Amazon EC2 instances in the company’s AWS CodePipeline cluster is inactive. - Pros: While an inactive EC2 instance could affect deployments, AWS CodeDeploy can deploy to multiple EC2 instances in an Auto Scaling group, and AWS CodeDeploy can handle the scenario if only one instance is inactive. - Cons: If the EC2 instance is inactive but others are running, the deployment should still proceed successfully to the active instances. - When to use: This scenario would be relevant if CodeDeploy is set to deploy to a very specific EC2 instance, and that instance is not available. However, in most cases, the pipeline would not fail entirely due to one instance. D) The ...

Author: Olivia · Last updated May 18, 2026

A developer is building a serverless application by using AWS Serverless Application Model (AWS SAM) on multiple AWS Lambda functions. When the application is deployed, the developer wants to shift 10% of the traffic to the new deployment of the application for the first 10 minutes after deployment. If there ...

To meet the requirements of shifting 10% of the traffic to the new Lambda deployment for the first 10 minutes, and then fully switching to the new version if there are no issues, let's analyze each option carefully: A) Set the Deployment Preference Type to Canary10Percent10Minutes. Set the AutoPublishAlias property to the Lambda alias. - Pros: The `Canary10Percent10Minutes` deployment preference will shift 10% of the traffic to the new version for the first 10 minutes. This matches the requirement for a canary release (10% traffic for 10 minutes). - Cons: The `AutoPublishAlias` property should be set to the Lambda alias to ensure traffic routing, and this option doesn’t include a rollback or validation step explicitly tied to pre/post-traffic actions. - When to use: This is a good choice if the focus is on using canary-style traffic shifting and automatically updating the alias without needing custom pre/post traffic actions. B) Set the Deployment Preference Type to Linear10PercentEvery10Minutes. Set AutoPublishAlias property to the Lambda alias. - Pros: The `Linear10PercentEvery10Minutes` deployment preference will shift 10% of the traffic every 10 minutes. This is useful for gradual traffic shifting. - Cons: This doesn’t fully align with the requirement of shifting 10% of the traffic for only the first 10 minutes. A linear shift happens gradually over a longer period (increasing traffic in stages), not in a quick 10-minute window. This would delay full switch-over beyond the desired time frame. - When to use: This option is suited for gradual traffic shifting over a longer duration rather than a quick canary shift. C) Set the Deployment Preference Type to Canary10Percent10Minutes. Set the PreTraffic and PostTraffic properties to the Lambda alias. - Pros: The `Canary10Percent10Minutes` deployment preference shifts 10% of traffic to the new version for 10 minutes. The ...

Author: Elizabeth · Last updated May 18, 2026

An AWS Lambda function is running in a company=E2=80=99s shared AWS account. The function needs to perform an additional ec2:DescribeInstances action that is directed at the company=E2=80=99s development accounts. A developer must configure the required permissions acro...

Let’s evaluate each option carefully in terms of permissions and adherence to the principle of least privilege. A) Create an IAM role in the shared account. Add the ec2:DescribeInstances permission to the role. Establish a trust relationship between the development accounts for this role. Update the Lambda function IAM role in the shared account by adding the ec2:DescribeInstances permission to the role. - Cons: This approach places the `ec2:DescribeInstances` permission in the shared account’s IAM role, which is not ideal because the Lambda function needs to query the development accounts. This violates the least privilege principle by potentially granting broader access to EC2 instances in the shared account, which is not needed. - When to use: This option is not appropriate for this use case, as it unnecessarily applies permissions in the wrong context (the shared account), which could lead to security risks. B) Create an IAM role in the development accounts. Add the ec2:DescribeInstances permission to the role. Establish a trust relationship with the shared account for this role. Update the Lambda function IAM role in the shared account by adding the iam:AssumeRole permissions. - Pros: This is a good approach because the Lambda function in the shared account assumes a role in the development accounts that has the necessary `ec2:DescribeInstances` permission. The principle of least privilege is respected because the Lambda function will only be able to assume the role in the development account, not the shared account, and only the necessary permission (`ec2:DescribeInstances`) will be granted. - Cons: This approach requires careful setup of the trust relationship and the `iam:AssumeRole` permission in the Lambda role. However, this is a standard practice when working across AWS accounts. - When to use: This is the best solution, as it ensures that the Lambda function in the shared account can assume a role in the development account ...

Author: James · Last updated May 18, 2026

A developer is building a new application that will be deployed on AWS. The developer has created an AWS CodeCommit repository for the application. The developer has initialized a new project for the application by invoking the AWS Cloud Development Kit (AWS CDK) cdk init command. The developer must write unit tests for the infrastructure as code (IaC) templates that the AWS CDK generates. The developer also must run a validation tool across all construct...

To meet the requirements with the least development overhead, we need to focus on efficient ways to: 1. Write unit tests for the generated AWS CDK templates. 2. Validate security configurations in the infrastructure as code (IaC) templates. Analysis of Each Option: Option A: Use a unit testing framework to write custom unit tests against the cdk.out file that the AWS CDK generates. Run the unit tests in a continuous integration and continuous delivery (CI/CD) pipeline that is invoked after any commit to the repository. - Why it's rejected: The `cdk.out` file contains the synthesized CloudFormation templates and other output files, which are not intended for direct unit testing. Writing custom unit tests against this file adds unnecessary complexity and doesn’t offer the best approach for testing CDK constructs. The `cdk.out` file is more of a product of the synthesis process and not the source code for the infrastructure, which makes it less efficient for validation. Option B: Use the CDK assertions module to integrate unit tests with the application. Run the unit tests in a continuous integration and continuous delivery (CI/CD) pipeline that is invoked after any commit to the repository. - Why it's selected: The CDK assertions module is specifically designed for unit testing AWS CDK applications. It allows for direct testing of the generated AWS CloudFormation templates (from within the CDK app itself) without needing to interact with the `cdk.out` file. This is efficient for validating the infrastructure as code (IaC) logic, and the tests can be easily integrated into a CI/CD pipeline for continuous validation, making it the best choice with minimal overhead. - Key factor: This option integrates seamlessly with the AWS CDK workflow and allows for automated unit testing of CDK constructs. Option C: Use the CDK runtime context to set key-value pairs that must be present in the cdk.out file that the AWS CDK generates. Fail the stack synthesis if any violations ar...

Author: Olivia · Last updated May 18, 2026

An online sales company is developing a serverless application that runs on AWS. The application uses an AWS Lambda function that calculates order success rates and stores the data in an Amazon DynamoDB table. A developer wants an efficient way to invoke the L...

To solve this problem, the key factors to consider are efficiency, development effort, and scalability. Let’s evaluate each option: Option A: Amazon EventBridge Rule - EventBridge is a fully managed service that can trigger events on a schedule using rate expressions, such as every 15 minutes. - Efficiency: This is highly efficient since EventBridge is serverless, and there is no infrastructure to manage. - Development effort: Minimal effort is required. Setting up a simple EventBridge rule and linking it to the Lambda function is straightforward. - Scalability: EventBridge scales automatically, making it ideal for serverless applications. - Why selected: This solution fits perfectly as it directly addresses the requirement to invoke the Lambda function every 15 minutes without any complex setup. Option B: AWS Systems Manager (SSM) Document - This option involves using an EC2 instance to run a script that invokes the Lambda function. - Efficiency: This approach introduces unnecessary complexity by requiring an EC2 instance, managing the script, and setting up Systems Manager. - Development effort: Significant effort required for provisioning and managing EC2 instances, and setting up Systems Manager to invoke the Lambda function. - Scalability: This method is not scalable as it requires maintaining EC2 infrastructure. - Why rejected: While functional, it adds overhead and is not ideal for a serverless approach, which should avoid managing servers unless necessary. Option C: AWS Step Functions - ...

Author: Kai · Last updated May 18, 2026

A company deploys a photo-processing application to an Amazon EC2 instance. The application needs to process each photo in less than 5 seconds. If processing takes longer than 5 seconds, the company=E2=80=99s development team must receive a notification. H...

Let's analyze the options based on the key factors: operational overhead, simplicity, and scalability. Option A: CloudWatch Custom Metric with SNS Notification - CloudWatch Custom Metric: You can create a custom metric to track the time it takes to process each photo. - CloudWatch Alarm: Set a static threshold of 5 seconds. If processing time exceeds this threshold, CloudWatch can trigger an alarm. - SNS Notification: Once the alarm triggers, it can notify the development team via SNS. - Efficiency: This is a highly efficient, serverless solution. You don’t need to manage any infrastructure, and CloudWatch can easily measure time-based metrics. - Operational Overhead: Very low. After initial setup, CloudWatch handles monitoring and notification automatically. - Why selected: This option directly addresses the requirement with minimal setup and management, making it ideal for operational simplicity and efficiency. Option B: SQS Queue and Custom Application - SQS: Publish the processing time to an SQS queue. - Custom Application: A separate application would need to poll the queue, process each entry, and check if the time exceeds 5 seconds. - Operational Overhead: Significant. You would need to manage the SQS queue, the polling application, and ensure that the system runs correctly. - Why rejected: While it would work, this approach introduces unnecessary complexity with additional infrastructure management (SQS, custom application) when compared to using CloudWatch directly. ...

Author: Ming · Last updated May 18, 2026

A company is using AWS Elastic Beanstalk to manage web applications that are running on Amazon EC2 instances. A developer needs to make configuration changes. The developer must deploy the changes to new instances onl...

To meet the requirement of deploying configuration changes only to new EC2 instances while leaving the existing instances unaffected, we need to carefully analyze each deployment type. Let's go over the options: Option A: All at once - Description: This deployment strategy replaces all EC2 instances in the environment simultaneously. - Reasoning: Since it updates all instances, it does not meet the requirement to apply changes to only the new instances. - Why rejected: The entire environment, including existing instances, is updated at the same time. This option does not allow for selective deployment to new instances. Option B: Immutable - Description: In this deployment strategy, a new set of EC2 instances is created with the new configuration, and only after the new instances are successfully running, the old instances are terminated. - Reasoning: This strategy only deploys the changes to new instances and ensures that the old instances are not affected until the new ones are ready. - Why selected: This is exactly what is needed: changes are deployed only to new EC2 instances, and it avoids any impact on the existing instances during the deployment process. Option C: Rolling - Description: In a rolling deployment, EC2 instances are updated in batches, with a certain number of instances being updated at a time while others remain operational. - Reasoning: This updates instances incrementally, which doesn't guarantee that changes will be applied only to new instances. Existing instances will be updated, so it does not fully meet the requi...

Author: Emma · Last updated May 18, 2026

A developer needs to use Amazon DynamoDB to store customer orders. The developer=E2=80=99s company requires all customer data to be encrypted at rest with a key that the com...

To meet the requirement of encrypting customer data at rest in Amazon DynamoDB using a key that the company generates, let’s analyze each option carefully. Option A: Create the DynamoDB table with encryption set to None and manually encrypt/decrypt - Description: The DynamoDB table would not have any encryption enabled. Instead, the developer would need to manually encrypt and decrypt the data using the company's key during reads and writes. - Reasoning: This approach introduces significant complexity. The developer would need to handle encryption logic in the application, which adds development overhead and can lead to potential security risks or mistakes in handling the keys. - Why rejected: It is inefficient and error-prone to manage encryption manually, especially when AWS offers native encryption solutions. This approach also doesn't meet the requirement of using the key for encryption at rest directly in DynamoDB. Option B: Store the key using AWS KMS and choose a customer-managed key for DynamoDB encryption - Description: Store the encryption key in AWS Key Management Service (KMS), and use a customer-managed key (CMK) for DynamoDB encryption. - Reasoning: This option ensures that all data in DynamoDB is encrypted at rest using the company’s own KMS key. The company has full control over the key, and it integrates seamlessly with DynamoDB's encryption capabilities. - Why selected: This is the most straightforward and secure solution, as AWS KMS will manage the encryption process on behalf of the developer. It meets the requirement of using a key that the company generates, and AWS handles the encryption automatically, reducing operational overhead. Option C: Store the...

Author: Victoria · Last updated May 18, 2026

A company uses AWS CloudFormation to deploy an application that uses an Amazon API Gateway REST API with AWS Lambda function integration. The application uses Amazon DynamoDB for data persistence. The application has three stages: development, testing, and production. Each stage uses its own DynamoDB table. The company has encountered unexpected issues when promoting changes to the production stage. The changes were successful in the development and testing stages. A developer needs to route 20% of the traffic to the new production stage API with the next production release. T...

To meet the requirement of routing 20% of the traffic to the new production stage API while minimizing errors, let’s carefully analyze each option. Option A: Update 20% of the planned changes and monitor the results - Description: This option involves manually rolling out 20% of the planned changes, deploying the new production stage, and then monitoring the results. After each deployment, the developer repeats the process. - Reasoning: While this approach ensures that changes are gradually introduced, it is highly manual, labor-intensive, and does not provide a controlled, automatic way to split traffic. It also introduces a high risk of errors due to its iterative nature, making it less efficient and scalable. - Why rejected: This approach is inefficient and does not meet the need for an automated, scalable solution to gradually introduce changes while managing traffic flow. Option B: Use Route 53 weighted routing policy - Description: This option proposes updating the Route 53 DNS record with a weighted routing policy, directing 80% of the traffic to the existing production stage and 20% to the new production stage. The developer would need to set up a second record for the new stage and configure it to route 20% of the traffic. - Reasoning: While Route 53 weighted routing is an option for controlling traffic distribution, it is not ideal for API Gateway traffic management. API Gateway doesn't natively integrate with Route 53 for routing traffic based on percentage weights. Additionally, this option would involve complex DNS management and might not support precise routing of API Gateway traffic with API versioning and deployment stages. - Why rejected: Route 53 DNS routing is not the most suitable for controlling API Gateway traffic and doesn’t offer the fine-grained control that the developer requires for API deployment stages. Option C: Use an Application Load Balancer (ALB) with weig...

Author: James · Last updated May 18, 2026

A developer has created a data collection application that uses Amazon API Gateway, AWS Lambda, and Amazon S3. The application=E2=80=99s users periodically upload data files and wait for the validation status to be reflected on a processing dashboard. The validation process is complex and time-consuming for large files. Some users are uploading dozens of large files and have to wait and refresh the processing dashboard to see if the files have been validated. The developer must refactor ...

Let's break down the options and evaluate the most operationally efficient solution: Option A: Integrate the client with an API Gateway WebSocket API. Save the user-uploaded files with the WebSocket connection ID. Push the validation status to the connection ID when the processing is complete to initiate an update of the user interface. - Pros: - WebSocket APIs allow real-time, two-way communication, which directly meets the need for immediate updates on the user interface. - Once the validation is complete, the system can directly push the update to the specific user connection, which means no need to refresh the full dashboard. - It eliminates polling or refreshing, making it highly efficient. - Cons: - Requires managing WebSocket connections at scale, especially if many users upload files simultaneously. This could lead to some operational overhead, but it is a scalable solution with proper implementation. Key factors in favor: - Real-time communication. - No need for polling. - Scalability. Option B: Launch an Amazon EC2 micro instance, and set up a WebSocket server. Send the user-uploaded file and user detail to the EC2 instance after the user uploads the file. Use the WebSocket server to send updates to the user interface when the uploaded file is processed. - Pros: - Similar to Option A, this uses WebSockets to push updates. - Allows for more control over the WebSocket server and connections. - Cons: - Requires setting up and managing an EC2 instance, which adds complexity in terms of maintenance, scaling, patching, and cost. - More operational overhead compared to using a fully managed service like API Gateway. Key factors in favor: - Control over server. - Customization. Key factors against: - High operational overhead. - Management of EC2 instance is needed. Option C: Save the users email address along with the user-uploaded file. When the validation process is complete, send an email notification through Amazon Simple Notification Service (Amazon SNS) to the user who uploaded the file. - Pros: - Si...

Author: Maya2022 · Last updated May 18, 2026

A company=E2=80=99s developer is creating an application that uses Amazon API Gateway. The company wants to ensure that only users in the Sales department can use the application. The users authenticate to the application by using federated credentials from a third-party identity provider (IdP) through Amazon Cognito. The developer has set up an attribute mapping to map an attribute that is named Department and to pass the attribute to a custom AWS Lambda authorizer. To test the access limitation, the developer sets their department to Engineering in the IdP and attempts to log in to the application. The developer is denied access. The developer then updates their department to Sales in the IdP and attempts to log in. Again, the develo...

Let's break down each option and evaluate the possible causes for the issue described: Option A: Authorization caching is enabled in the custom Lambda authorizer. - Reasoning: The custom Lambda authorizer could be caching the result of the previous authorization decision based on the user's earlier department value (Engineering), even though the department attribute was updated in the IdP (from Engineering to Sales). - Possible Explanation: If the authorization is cached, the custom Lambda authorizer could be returning the old "Engineering" department value from a previous request instead of the updated one. Key factors in favor: - Authorization caching in Lambda authorizers is a common practice for performance improvement, but it could lead to stale data if not invalidated appropriately after attribute changes. - The developer's issue of receiving the "Engineering" department value despite updating to "Sales" fits this scenario. Key factors against: - This explanation is the most plausible based on the scenario described. Option B: Authorization caching is enabled on the Amazon Cognito user pool. - Reasoning: This option suggests that the problem is related to caching at the Cognito user pool level. - Possible Explanation: Amazon Cognito itself caches attributes during the authentication process. However, in this case, the issue is likely not due to caching at the Cognito level because the department attribute is being passed through to the Lambda authorizer (indicating it's being evaluated there), rather than being directly cached in Cognito. Key factors against: - This option is less likely because the issue seems related to how the attribute is being passed to and processed by the Lambda authorizer, not how it's cached in Cognito. Option C: The IAM role for the custom Lambda authorizer does not have a Department tag. - Reasoning: This option concerns whether ...

Author: Liam123 · Last updated May 18, 2026

A company has migrated an application to Amazon EC2 instances. Automatic scaling is working well for the application user interface. However, the process to deliver shipping requests to the company=E2=80=99s warehouse staff is encountering issues. Duplicate shipping requests are arriving, and some requests are lost or arrive out of order. The company must avoid duplicate shipping requests and must process the requests in the order that the requests arrive. Requests are never more than 250 KB in size...

Let's evaluate each option and how well it aligns with the requirements: Requirements: 1. Avoid Duplicate Requests: The system should not process duplicate shipping requests. 2. Process Requests in Order: The requests must be processed in the order they arrive. 3. Reliability and Durability: Requests should be handled reliably, without being lost. 4. Request Size and Processing Time: Requests are no more than 250 KB in size and take 5-10 minutes to process. Option A: Create an Amazon Kinesis Data Firehose delivery stream to process the requests. Create an Amazon Kinesis data stream. Modify the application to write the requests to the Kinesis data stream. - Reasoning: Kinesis is designed for real-time streaming data, but it’s more suited for high-throughput, real-time data streams and not for reliable, ordered processing of smaller requests like shipping orders. - Key factors against: - Kinesis Data Streams are generally used for high-throughput, real-time data processing scenarios. While it can ensure that the requests are processed in order, it doesn't provide built-in features for preventing duplicates or ensuring no message loss. - Kinesis streams can lead to out-of-order processing if not configured with proper sequence numbers, and it doesn’t guarantee exactly-once delivery without additional handling. Rejected because: - This is a better option for real-time data streaming scenarios, not for reliable and ordered processing of shipping requests. Option B: Create an AWS Lambda function to process the requests. Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the Lambda function to the SNS topic. Modify the application to write the requests to the SNS topic. - Reasoning: SNS is a pub/sub service for sending notifications. It's generally designed for broadcasting messages to multiple subscribers, but it doesn't guarantee the order of message delivery or handle deduplication inherently. - Key factors against: - SNS doesn't provide guarantees for message order or deduplication by default, which is critical in this scenario. - It’s not designed for sequential, reliable message processing with order or deduplication, which is ...

Author: Lucas · Last updated May 18, 2026

A developer is creating a machine learning (ML) pipeline in AWS Step Functions that contains AWS Lambda functions. The developer has configured an Amazon Simple Queue Service (Amazon SQS) queue to deliver ML model parameters to the ML pipeline to train ML models. The developer uploads the trained models are uploaded to an Amazon S3 bucket. The developer needs a solu...

Let's evaluate each option based on the need to test the machine learning pipeline locally without making service integration calls to Amazon SQS and Amazon S3: Option A: Use the Amazon CodeGuru Profiler to analyze the Lambda functions used in the AWS Step Functions pipeline. - Reasoning: Amazon CodeGuru is a tool that provides code quality analysis and performance profiling for applications. However, it is not designed for local testing or simulating the execution of AWS services such as SQS or S3. - Key factors against: - CodeGuru is more focused on identifying code quality and performance issues in production environments, rather than testing the entire ML pipeline locally or simulating AWS service integrations. - It does not allow for local testing of Lambda functions or service integrations. Rejected because: - CodeGuru is not intended for local testing or simulating service integrations. Option B: Use the AWS Step Functions Local Docker Image to run and locally test the Lambda functions. - Reasoning: The AWS Step Functions Local Docker image allows you to test AWS Step Functions workflows and Lambda functions locally. However, it does not support service integrations with AWS services like SQS, S3, or other AWS resources natively. - Key factors against: - While it allows testing of the Step Functions workflow, it does not mock or simulate interactions with services like SQS or S3. For testing the ML pipeline locally, service interactions need to be simulated or mocked to avoid real AWS service calls. Rejected because: - Does not support service integrations or the ability to mock SQS or S3 calls, which is necessary for local testing. Option C: Use the AWS Serverless Application Model (AWS SAM) CL...

Author: Elizabeth · Last updated May 18, 2026

A company runs a batch processing application by using AWS Lambda functions and Amazon API Gateway APIs with deployment stages for development, user acceptance testing, and production. A development team needs to configure the APIs in the dep...

Let's evaluate each option based on the requirement to configure API Gateway deployment stages to connect to third-party service endpoints: Option A: Store the third-party service endpoints in Lambda layers that correspond to the stage. - Reasoning: Lambda layers are used for packaging libraries and dependencies that can be shared across multiple Lambda functions. While you can store configuration data in Lambda layers, this is not an ideal solution for different API Gateway stages. Layers are not designed for storing environment-specific configurations like third-party service endpoints. The configuration would also be hard to update without redeploying the Lambda function. Key factors against: - Lambda layers are more suited for packaging code or dependencies, not for storing environment-specific configurations like service endpoints. - This solution would require redeployment if any endpoint changes, which is not efficient. Rejected because: - Lambda layers are not appropriate for storing environment-specific configuration values like third-party service endpoints. Option B: Store the third-party service endpoints in API Gateway stage variables that correspond to the stage. - Reasoning: API Gateway stage variables are designed for storing environment-specific configurations. They allow you to specify values that can vary depending on the deployment stage (e.g., development, testing, production). These values can be referenced in API Gateway mappings and Lambda functions, making them ideal for storing third-party service endpoints that vary by environment. Key factors in favor: - Stage variables are specifically designed for this kind of scenario, where different configurations are needed per environment (such as API endpoints). - API Gateway provides a way to reference these variables within Lambda functions or integration settings. - This solution is simple to implement and manage since stage variables are tied to each deployment stage and can be easily updated without redeploying the functions themselves. Selected because: - API Gateway stage variables are a great fit for storing environment-specific configuration values like third-party service endpoints. They provide a clean and maintainable solution for this requirement. Option C: Encode the third-party service endpoints as query parameters in the API Gateway request URL. - Reason...

Author: Oscar · Last updated May 18, 2026

A developer is building a serverless application that runs on AWS. The developer wants to create an accelerated development workflow that deploys incremental changes to AWS for testing. The developer wants to deploy the incremental changes but does not want to fully dep...

In order to build an efficient development workflow that allows incremental deployments without fully deploying the entire application every time, the developer needs to focus on tools that enable fast updates and minimize the overhead of redeploying the entire stack. Let's break down each option: A) Use the AWS Serverless Application Model (AWS SAM) to build the application. Use the `sam sync` command to deploy the incremental changes. - Why it's selected: The `sam sync` command is specifically designed to deploy only the incremental changes in a serverless application. It enables rapid testing by syncing local changes to the cloud without redeploying the entire stack. This approach minimizes deployment time and enhances the developer's workflow. - Why other options are rejected: - The `sam init` command is used to initialize a new project and is not used for incremental deployments. - The `sam sync` command provides the precise incremental deployment functionality required here, making it the best choice. B) Use the AWS Serverless Application Model (AWS SAM) to build the application. Use the `sam init` command to deploy the incremental changes. - Rejected: The `sam init` command is used to initialize a new SAM project but not to deploy changes. It does not allow incremental deployment...

Author: Zara · Last updated May 18, 2026