A developer has an application that makes batch requests directly to Amazon DynamoDB by using the BatchGetItem low-level API operation. The responses frequently return values in the UnprocessedKeys element. Which actions should the developer take to incre...

Let's evaluate each option and determine the most suitable actions to take when dealing with unprocessed keys in DynamoDB's BatchGetItem operation: A) Retry the batch operation immediately. - Retrying the operation immediately without any delay or backoff may lead to further throttling, as the system may still be under high load. This can worsen the problem instead of resolving it. It is important to handle unprocessed keys gracefully to avoid overloading the service. - Rejection reason: Immediate retries without backoff can lead to inefficient resource use and potential throttling. B) Retry the batch operation with exponential backoff and randomized delay. - This is the best option. Exponential backoff and randomized delay help to avoid overwhelming the DynamoDB service and reduce the risk of encountering repeated throttling. This strategy is a standard best practice for handling request retries in AWS services. By applying this method, the application becomes more resilient, as it avoids overloading DynamoDB with frequent retries and improves the chances of successful processing after each delay. - Selected reason: This approach reduces load on DynamoDB, adheres to best practices for retries, and improves the chances of processing unprocessed keys successfully. C) Update the application to use an AWS software development kit (AWS SDK) to make the requests. - While using the AWS SDK simplifies the interaction with AWS services, it doesn't specifically address how to handle unprocessed keys in the BatchGetItem operation. The SDK may handle retries and errors in some cases, but it do...

Author: Ava · Last updated May 18, 2026

A company is running a custom application on a set of on-premises Linux servers that are accessed using Amazon API Gateway. AWS X-Ray tracing has been enabled on the API test stage. How can a developer ...

Let's evaluate each option based on its feasibility and ease of implementation: A) Install and run the X-Ray SDK on the on-premises servers to capture and relay the data to the X-Ray service. - The X-Ray SDK allows applications to capture trace data and send it to X-Ray. However, setting up the SDK would require significant configuration for each server to instrument the application code. While this option provides flexibility, it can be more complex to configure compared to other solutions. It also requires changes to the application code, which might not be ideal for the least amount of configuration. - Rejection reason: Although feasible, it requires significant effort to modify and instrument the application code. B) Install and run the X-Ray daemon on the on-premises servers to capture and relay the data to the X-Ray service. - The X-Ray daemon is the simplest option for enabling X-Ray tracing on on-premises servers. It captures trace data from the application and relays it to the X-Ray service. The daemon runs as a background process and doesn't require any changes to the application code. This option requires minimal configuration, as the daemon handles the communication with AWS X-Ray, making it a low-effort solution. - Selected reason: This option allows the developer to enable tracing with the least configuration and without modifying the application code. It is the simplest and most efficient solution. C) Capture incoming requests o...

Author: Liam123 · Last updated May 18, 2026

A company wants to share information with a third party. The third party has an HTTP API endpoint that the company can use to share the information. The company has the required API key to access the HTTP API. The company needs a way to manage the API key by using code. The integration of the API...

Let's evaluate each option and select the most secure and efficient solution: A) Store the API credentials in AWS Secrets Manager. Retrieve the API credentials at runtime by using the AWS SDK. Use the credentials to make the API call. - Advantages: - Security: AWS Secrets Manager is designed specifically for storing and managing sensitive information such as API keys, passwords, and access keys. - Access Control: Secrets Manager integrates seamlessly with IAM policies, allowing fine-grained access control to the credentials. - Automatic Rotation: Secrets Manager supports automatic rotation of credentials, reducing the risk of using stale or compromised API keys. - Minimal Performance Impact: Secrets Manager caches secrets to reduce the performance overhead, ensuring that the API key is retrieved quickly with minimal delay at runtime. - Conclusion: This solution is the most secure as it uses a dedicated service for managing sensitive credentials with built-in encryption, access control, and rotation. B) Store the API credentials in a local code variable. Push the code to a secure Git repository. Use the local code variable at runtime to make the API call. - Disadvantages: - Security Risks: Storing sensitive credentials directly in code (even in a Git repository) is risky. Even though the repository is secure, the credentials can be exposed if anyone gains unauthorized access to the repository or if the code is pushed to a less secure location by mistake. - Lack of Management Features: This approach lacks features like automatic rotation, audit logs, or access control that are essential for securely managing API keys. - Rejection Reason: This method exposes sensitive information in the codebase, making it highly insecure. C) Store the API credentials as an object in a private Amazon S3 bucket. Restrict access to the S3 object by using IAM policies. Retrieve the API credentials at runtime by using the AWS SDK. Use the credentials to make the API call. - Advantages: - Security: S3 provides encryption (both at rest and in transit) and access contr...

Author: Nia · Last updated May 18, 2026

A developer is deploying a new application to Amazon Elastic Container Service (Amazon ECS). The developer needs to securely store and retrieve different types of variables. These variables include authentication information for a remote API, the URL for the API, and credentials. The authentication information and API URL must be available to all current and future deployed versio...

To solve this problem, the goal is to securely store and retrieve various types of variables (authentication information, API URL, and credentials) with minimal changes to the application, while also ensuring the values are available across development, testing, and production environments. Let's go through each option and evaluate it: A) Update the application to retrieve the variables from AWS Systems Manager Parameter Store. Use unique paths in Parameter Store for each variable in each environment. Store the credentials in AWS Secrets Manager in each environment. - Pros: AWS Systems Manager Parameter Store and AWS Secrets Manager are secure and highly scalable solutions for managing configuration values and sensitive information, respectively. They integrate easily with AWS ECS, allowing applications to retrieve configuration data securely without hardcoding values. With Parameter Store and Secrets Manager, you can maintain unique paths and versions for different environments (e.g., dev, test, prod). - Cons: The developer would need to update the application code to use the AWS SDK to retrieve values from these services. However, this is minimal effort compared to other alternatives. Parameter Store supports both plain text and encrypted values, and Secrets Manager provides automatic rotation of credentials. B) Update the application to retrieve the variables from AWS Key Management Service (AWS KMS). Store the API URL and credentials as unique keys for each environment. - Pros: KMS can encrypt and decrypt data, but it's not designed to directly manage variables such as API URLs or authentication credentials. - Cons: KMS is primarily for managing encryption keys, not for storing application configuration values. While you can use KMS for encryption, it doesn't provide easy access management for variables like API URLs and credentials. This would also require more custom development effort to retrieve the variables and decrypt them at runtime. C) Update the application to retrieve the variables from an encrypte...

Author: FrostFalcon88 · Last updated May 18, 2026

A company is migrating legacy internal applications to AWS. Leadership wants to rewrite the internal employee directory to use native AWS services. A developer needs to create a solution for storing employee contact details and high-resolution photos for use with the new application. Which ...

Let's evaluate each of the options based on key factors such as scalability, performance, cost, ease of use, and suitability for storing employee contact information and high-resolution photos. Option A: Encode each employee's contact information and photos using Base64. Store the information in an Amazon DynamoDB table using a sort key. - Pros: DynamoDB is a fast, scalable NoSQL database, and it would be able to handle contact information retrieval. - Cons: Base64 encoding increases the size of both the contact information and photos by approximately 33%. This is inefficient, especially for high-resolution images, and increases both storage costs and processing overhead. Storing large photos in DynamoDB would not be ideal, as DynamoDB is better suited for small, fast key-value data rather than large binary objects. - Scenario where applicable: This solution might be applicable for small, lightweight applications where data size is not a concern, but for high-resolution photos, this is a poor choice. Option B: Store each employee's contact information in an Amazon DynamoDB table along with the object keys for the photos stored in Amazon S3. - Pros: DynamoDB is well-suited for fast lookups of employee contact details and metadata. Amazon S3 is optimized for storing large binary objects, such as high-resolution photos, with low cost and high availability. By storing the contact information in DynamoDB and using S3 for the photos, the solution is highly scalable and cost-effective. S3's integration with AWS APIs makes it easy to access individual photos using object keys stored in DynamoDB. - Cons: There is a slight complexity in managing two services (DynamoDB for contact data and S3 for photos), but this is manageable. - Scenario where applicable: This is a great choice for applications where both structured data (contact information) and unstructured data (photos) need to be stored and retrieved efficiently. Option C: Use Amazon Cognito user pools to im...

Author: Liam · Last updated May 18, 2026

A developer is creating an application that will give users the ability to store photos from their cellphones in the cloud. The application needs to support tens of thousands of users. The application uses an Amazon API Gateway REST API that is integrated with AWS Lambda functions to process the photos. The application stores details about the photos in Amazon DynamoDB. Users need to create an account to access the application. In the application, users must...

Let's evaluate the options based on operational overhead, scalability, security, and simplicity: Option A: Use Amazon Cognito user pools to manage user accounts. Create an Amazon Cognito user pool authorizer in API Gateway to control access to the API. Use the Lambda function to store the photos and details in the DynamoDB table. Retrieve previously uploaded photos directly from the DynamoDB table. - Pros: Amazon Cognito simplifies user authentication and user management. Using API Gateway with Cognito as the authorizer is a common setup for controlling access. DynamoDB is a good choice for storing structured data like photo metadata. - Cons: Directly storing photos in DynamoDB is inefficient because DynamoDB is not optimized for large binary objects like photos. Storing photos in DynamoDB could lead to higher costs and operational overhead due to size limitations and performance constraints. - Scenario where applicable: Suitable for applications where all data is small and manageable in DynamoDB, but not ideal for photo storage in this scenario. Option B: Use Amazon Cognito user pools to manage user accounts. Create an Amazon Cognito user pool authorizer in API Gateway to control access to the API. Use the Lambda function to store the photos in Amazon S3. Store the object's S3 key as part of the photo details in the DynamoDB table. Retrieve previously uploaded photos by querying DynamoDB for the S3 key. - Pros: This approach uses Cognito for easy user authentication and S3 for photo storage, which is highly scalable and cost-effective for large binary data like photos. S3 is designed for this use case, providing low-latency access to photos. Storing the S3 key in DynamoDB keeps the metadata lightweight and enables fast queries. - Cons: The only potential downside is the added complexity of managing S3 keys, but it is a minimal complexity compared to the benefits. - Scenario where applicable: This is an ideal solution for applications that need to store and retrieve large binary files (photos) with minimal overhead. Option C: Create an IAM user for each user of the application during the sign-up process. Use IAM authentication to access the API Gateway API. Use th...

Author: Olivia Johnson · Last updated May 18, 2026

A company receives food orders from multiple partners. The company has a microservices application that uses Amazon API Gateway APIs with AWS Lambda integration. Each partner sends orders by calling a customized API that is exposed through API Gateway. The API call invokes a shared Lambda function to process the orders. Partners need to be notified after the Lambda function processes the orders. Each partner must receive updates for onl...

Let's evaluate each option based on scalability, maintainability, and ease of adding new partners: Option A: Create a different Amazon Simple Notification Service (Amazon SNS) topic for each partner. Configure the Lambda function to publish messages for each partner to the partner's SNS topic. - Pros: This solution allows for separate topics for each partner, ensuring messages are delivered to the correct partner. - Cons: As the number of partners grows, the complexity of managing a large number of SNS topics increases. Each time a new partner is added, a new SNS topic needs to be created, and the Lambda function needs to be updated to publish to this new topic. This approach can become difficult to manage as the number of partners grows. - Scenario where applicable: This could be suitable for small numbers of partners, but it’s not scalable for a large or growing number of partners, as the number of topics to manage increases over time. Option B: Create a different Lambda function for each partner. Configure the Lambda function to notify each partner's service endpoint directly. - Pros: This solution allows for direct and customized notifications for each partner. - Cons: Creating a separate Lambda function for each partner introduces significant operational overhead. The system will become difficult to maintain as the number of partners grows, and adding new partners would require creating new Lambda functions and updating the existing infrastructure. This does not meet the requirement of being easily scalable or requiring few code changes when adding new partners. - Scenario where applicable: This could work in very small-scale environments with a limited number of partners, but it is not scalable or maintainable in the long term. Option C: Create an Amazon SNS topic. Configure the Lambda function to publish messages with specific attributes to the SNS topic. Subscribe each partner to the SNS topic. Apply the approp...

Author: CrimsonViperX · Last updated May 18, 2026

A financial company must store original customer records for 10 years for legal reasons. A complete record contains personally identifiable information (PII). According to local regulations, PII is available to only certain people in the company and must not be shared with third parties. The company needs to make the records available to third-party organizations for statistical analysis without sharing the PII. A developer wants to store the original immutable record in Amazon S3. Depending on who accesses the S3 document, the document should be returned as is or with all the PII re...

Let's evaluate the options based on the requirements of storing customer records with personally identifiable information (PII) in Amazon S3, making the records available to third-party organizations without sharing PII, and ensuring compliance with legal regulations: Option A: Set up an S3 event notification that invokes the removePii function when an S3 GET request is made. Call Amazon S3 by using a GET request to access the object without PII. - Pros: The event notification on GET requests could trigger the removal of PII when a specific person or system accesses the file, and the document could be returned without PII. However, this approach would not work well for directly modifying the document on-the-fly as a GET request is intended for data retrieval, not data modification. - Cons: S3 event notifications trigger on PUT, POST, COPY, or DELETE operations, not on GET requests. This means you cannot invoke a Lambda function based on a GET request directly. Additionally, a GET request fetches data, so removing PII on the fly during the GET request is not feasible. - Scenario where applicable: This is not a suitable solution, as GET events cannot directly trigger a Lambda function. Option B: Set up an S3 event notification that invokes the removePii function when an S3 PUT request is made. Call Amazon S3 by using a PUT request to access the object without PII. - Pros: A PUT request triggers when an object is uploaded or overwritten in S3, which might be useful if you want to update the stored document after removing the PII. - Cons: The event notification on a PUT request would invoke the Lambda function when the document is uploaded or updated. However, it does not solve the problem of making the original document available in its unaltered form for authorized users and with PII removed for third-party access. It also does not allow real-time access to the document without modifying it each time. - Scenario where applicable: This is not the most efficient approach, as it involves modifying the object, but the company needs to keep the original immutable record intact. ...

Author: Michael · Last updated May 18, 2026

A developer is deploying an AWS Lambda function The developer wants the ability to return to older versions of the function quickly and seamlessly. How can ...

Let's evaluate each option based on the developer's goal of quickly and seamlessly returning to older versions of the Lambda function with the least operational overhead: Option A: Use AWS OpsWorks to perform blue/green deployments. - Pros: AWS OpsWorks is a configuration management service that supports deployment automation, including blue/green deployments. It allows for easy rollbacks and versioning of deployments. - Cons: AWS OpsWorks is a more complex service compared to the other options and generally requires more configuration and management effort. For Lambda functions, this might be an over-engineered solution, adding unnecessary complexity and operational overhead when simpler approaches are available. - Scenario where applicable: This option is better suited for more complex deployment scenarios involving multiple components or services, not just for Lambda function versioning. Option B: Use a function alias with different versions. - Pros: This is the best option for Lambda versioning with minimal operational overhead. Lambda allows you to create multiple versions of a function. By using function aliases, you can easily manage which version of the Lambda function is live. You can point an alias to the desired version and quickly switch between versions with a few API calls or configuration changes. This is simple, native to Lambda, and does not require additional services or heavy management. - Cons: There are no significant downsides. This approach is highly efficient for managing different versions of a Lambda function. - Scenario where applicable: This is the optimal solution for managing versions of a Lambda function and performing rollbacks with minimal operational overhead. Option C: Maintain deployment packages for older versions in Amazon S3. - Pr...

Author: Matthew · Last updated May 18, 2026

A developer has written an AWS Lambda function. The function is CPU-bound. The developer wants to ensure that the function returns responses quic...

To improve the performance of a CPU-bound AWS Lambda function, the key focus should be on enhancing its ability to process CPU-intensive tasks faster. Here’s the evaluation of the options: A) Increase the function's CPU core count AWS Lambda does not allow the explicit control of CPU cores. Instead, Lambda allocates CPU resources proportional to the amount of memory allocated to the function. Since Lambda does not give direct control over the CPU cores, this option isn’t feasible. B) Increase the function's memory Increasing the memory allocation for the Lambda function will automatically increase the CPU resources available to the function. This is particularly important for CPU-bound tasks, as more memory translates to more CPU power, leading to faster execution times for CPU-heavy operations. By allocating more memory, the function will get access to more processing power, which can directly reduce the execution time. C) Increase the function's reserved concurrency Reserved concurrency controls the number of concurrent executions of your Lambda function. While it can help with scaling and handling more req...

Author: Isabella1 · Last updated May 18, 2026

For a deployment using AWS Code Deploy, what is the run order of the hooks for in-place deployments?

For an in-place deployment using AWS CodeDeploy, the run order of the hooks is essential for ensuring that the application is updated smoothly and without downtime. Let's break down the possible options: A) BeforeInstall -> ApplicationStop -> ApplicationStart -> AfterInstall - BeforeInstall is typically used to prepare the environment before installation, such as backing up files or checking configurations. - ApplicationStop is used to stop the current version of the application. - ApplicationStart would typically be used after the installation to start the application again. - AfterInstall is used after the installation is complete, usually for tasks like configuring or finalizing the deployment. This order does not match the typical in-place deployment sequence, as ApplicationStart should ideally happen after installation (not before the AfterInstall step). This order is incorrect. B) ApplicationStop -> BeforeInstall -> AfterInstall -> ApplicationStart - ApplicationStop stops the current application version. - BeforeInstall prepares the environment for the new version (e.g., backing up files). - AfterInstall is used to finalize the deployment, such as configuring new application files. - ApplicationStart starts the application after the new version is deployed. This order is the correct run order for an in-place deployment in AWS CodeDeploy. Stopping the application first, preparing the environment, then installing, configuring, and finally starting the application is the typical sequence. C) BeforeInstall -> ApplicationStop -> Valid...

Author: Leo · Last updated May 18, 2026

A company is building a serverless application on AWS. The application uses an AWS Lambda function to process customer orders 24 hours a day, 7 days a week. The Lambda function calls an external vendor's HTTP API to process payments. During load tests, a developer discovers that the external vendor payment processing API occasionally times out and returns errors. The company expects that some payment processing API calls will return errors. The company wants the support team to receive notifications in near real time only when the payment processing external API err...

Let’s analyze the options and determine the best solution for the given scenario: A) Write the results of payment processing API calls to Amazon CloudWatch. Use Amazon CloudWatch Logs Insights to query the CloudWatch logs. Schedule the Lambda function to check the CloudWatch logs and notify the existing SNS topic. - CloudWatch Logs Insights can be useful for querying logs, but scheduling a Lambda function to process logs regularly is not the most efficient approach. This method introduces complexity and potential delays in data processing since the Lambda function would need to periodically check logs. It also doesn’t provide real-time monitoring or alerting. - Not ideal, because it adds complexity and latency with scheduled checks rather than providing near real-time notifications. B) Publish custom metrics to CloudWatch that record the failures of the external payment processing API calls. Configure a CloudWatch alarm to notify the existing SNS topic when the error rate exceeds the specified rate. - Publishing custom metrics to CloudWatch is a great approach for tracking API failures, as CloudWatch provides native support for metrics and alarms. By publishing metrics such as the failure count of the payment API calls and setting an alarm based on the error rate (e.g., exceeding 5% failures within an hour), you can achieve near real-time monitoring. - CloudWatch alarms can then trigger notifications directly to the SNS topic when the error rate threshold is exceeded, making this solution very efficient for monitoring and alerting in real time. - Ideal solution, as it’s simple, leverages AWS-native services for real-time monitoring and alerts, and meets the requirement to notify the support team only when the error rate exceeds 5%. C) Publish the results of the external payment processing API calls to a new Amazon SNS topic. Subscribe the...

Author: Ethan Smith · Last updated May 18, 2026

A company is offering APIs as a service over the internet to provide unauthenticated read access to statistical information that is updated daily. The company uses Amazon API Gateway and AWS Lambda to develop the APIs. The service has become popular, and the...

Let's break down the options and analyze the best choice for improving the responsiveness of the APIs: A) Enable API caching in API Gateway - API caching helps improve the responsiveness of APIs by reducing the number of calls to backend services (like AWS Lambda). When a client makes a request, the response can be cached for a specified time, and subsequent requests for the same data are served directly from the cache instead of invoking the Lambda function again. This reduces the latency and can significantly improve API performance, especially for frequently accessed or static data like the statistical information that is updated daily. - Ideal solution, as caching reduces repeated calls to Lambda, making the API more responsive and scalable. B) Configure API Gateway to use an interface VPC endpoint - Interface VPC endpoints allow communication between API Gateway and services in a VPC, providing a private and secure connection. However, in this case, the company is offering unauthenticated read-only APIs over the internet. Since the data is publicly available and not requiring internal VPC communication, setting up an interface VPC endpoint is unnecessary and will not enhance API responsiveness. This is more useful for services that require private, secure communication within a VPC. - Not ideal, as it is primarily used for private communication, and it won’t significantly improve the responsiveness for public APIs. C) Enable cross-origin resource sharing (CORS...

Author: Maya · Last updated May 18, 2026

A developer wants to store information about movies. Each movie has a title, release year, and genre. The movie information also can include additional properties about the cast and production crew. This additional information is inconsistent across movies. For example, one movie might have an assistant director, and another movie might have an animal trainer. The developer needs to implement a solution to support the following use cases: For a given title and release year, get all details about the movie that has that t...

To address the given use cases for storing movie information, we need to ensure that the data store can support efficient querying for movie details based on various attributes (title, release year, genre), while also handling the flexibility of inconsistent additional properties (such as the cast and crew). Let's evaluate each option: Option A: Create an Amazon DynamoDB table. Configure the table with a primary key that consists of the title as the partition key and the release year as the sort key. Create a global secondary index that uses the genre as the partition key and the title as the sort key. - Pros: - This configuration would efficiently support queries based on a specific title and release year (through the primary key), which satisfies one of the use cases. - The global secondary index (GSI) on genre allows you to query all movies by genre, fulfilling the requirement to get all movies within a specific genre. - DynamoDB's flexible schema is well-suited to store inconsistent data, such as varying cast or crew information, because the attributes can be dynamically added to each record. - Cons: - For querying by title alone, you would need to scan the table (since the GSI uses the title as the sort key), which can be inefficient for large datasets. - However, this is a minor issue given the use case, since querying by title alone is likely less frequent than querying by both title and release year or by genre. Option B: Create an Amazon DynamoDB table. Configure the table with a primary key that consists of the genre as the partition key and the release year as the sort key. Create a global secondary index that uses the title as the partition key. - Pros: - This configuration supports querying by genre and release year efficiently, and the GSI on title could help retrieve movies by title. - Cons: - The primary key based on genre and release year does not efficiently support querying for all movies by title (if you want to get all movies with the same title across different years, this would require scanning, which is inefficient). - This approach does not meet the requirement to query by title and release year, as it limits efficient access to queries ba...

Author: Mia · Last updated May 18, 2026

A developer maintains an Amazon API Gateway REST API. Customers use the API through a frontend UI and Amazon Cognito authentication. The developer has a new version of the API that contains new endpoints and backward-incompatible interface changes. The developer needs to provide beta access to other de...

In this scenario, the goal is to provide beta access to a new version of an API while minimizing operational overhead and ensuring that existing customers are not affected. Let's review each option: A) Define a development stage on the API Gateway API. Instruct the other developers to point the endpoints to the development stage. - Reasoning: A development stage in Amazon API Gateway allows you to define separate deployment environments for testing, staging, and production. This enables the developer to deploy the new version of the API to a non-production stage while keeping the production version intact. - Key Factors: The key advantage of this option is that it provides isolated environments for testing without changing the API that customers interact with. Developers can test the new API version independently by pointing to the development stage, ensuring there is no disruption for customers. - Why Rejected: This option meets the requirements, so it is not rejected. It provides the least overhead and does not require creating a new API or complex changes in the application code. B) Define a new API Gateway API that points to the new API application code. Instruct the other developers to point the endpoints to the new API. - Reasoning: This option would involve creating an entirely new API Gateway instance for the new API version. Developers would need to point their endpoints to this new API. - Key Factors: While this is a valid solution, it introduces higher operational overhead because you are managing two separate APIs. It requires additional resources, API configurations, and potentially a new setup for authorization and monitoring. It can also create confusion with managing multiple APIs. - Why Rejected: This solution introduces unnecessary complexity by requiring a new API Gateway setup, leading to more operational overhead. It is more resource-intensive compared to defining a simple development stag...

Author: Noah Williams · Last updated May 18, 2026

A developer is creating an application that will store personal health information (PHI). The PHI needs to be encrypted at all times. An encrypted Amazon RDS for MySQL DB instance is storing the data. The developer wants to increase the performance of the application by caching frequent...

To meet the given requirements, let’s analyze each option based on performance, encryption, caching capabilities, and the ability to sort or rank datasets: A) Create an Amazon ElastiCache for Redis instance. Enable encryption of data in transit and at rest. Store frequently accessed data in the cache. - Pros: - Redis supports rich data structures like sorted sets, which makes it ideal for ranking or sorting datasets. - Encryption of data in transit and at rest can be enabled to meet security requirements. - Excellent caching capabilities for frequently accessed data, improving performance significantly. - Cons: - Redis requires proper management of memory to avoid data loss. - It is a key-value store, so data management (e.g., sorting) requires thoughtful design but works very well for specific use cases like ranking. B) Create an Amazon ElastiCache for Memcached instance. Enable encryption of data in transit and at rest. Store frequently accessed data in the cache. - Pros: - Memcached is a great caching solution for fast access to frequently requested data. - Supports encryption in transit and at rest. - Cons: - Memcached does not have built-in support for sorting or ranking datasets. It’s primarily a simple key-value store, so additional application-level logic would be required for sorting or ranking. - Lacks rich data structures that are available in Redis (e.g., sorted sets). C) Create an Amazon RDS for MySQL read replica. Connect to the read replica by using SSL. Configure the read replica to store frequently acc...

Author: Ravi Patel · Last updated May 18, 2026

A company has a multi-node Windows legacy application that runs on premises. The application uses a network shared folder as a centralized configuration repository to store configuration files in .xml format. The company is migrating the application to Amazon EC2 instances. As part of the migration to AWS, a developer mus...

To determine the most cost-effective solution for ensuring high availability of the shared configuration repository during the migration to Amazon EC2 instances, let's evaluate each option: Option A: Mount an Amazon Elastic Block Store (Amazon EBS) volume onto one of the EC2 instances. Deploy a file system on the EBS volume. Use the host operating system to share a folder. Update the application code to read and write configuration files from the shared folder. - Analysis: - EBS volumes are designed for use with a single EC2 instance at a time, so this setup would not provide high availability across multiple EC2 instances. - The EBS volume would need to be mounted individually on each EC2 instance, but sharing it in a high-availability manner between multiple instances would require complex configurations (e.g., using a clustered file system), which would increase management complexity. - This solution can be cost-effective but does not meet the high availability requirement. Option B: Deploy a micro EC2 instance with an instance store volume. Use the host operating system to share a folder. Update the application code to read and write configuration files from the shared folder. - Analysis: - Instance store volumes are ephemeral (data is lost when the instance is stopped or terminated), so they are not suitable for storing critical configuration files like the ones required here. - Additionally, relying on a single EC2 instance for shared file storage introduces a risk of downtime, so this solution does not provide high availability. - This is not a cost-effective solution because of the lack of durability and high availability. Option C: Create an Amazon S3 bucket to...

Author: Amelia · Last updated May 18, 2026

A company wants to deploy and maintain static websites on AWS. Each website's source code is hosted in one of several version control systems, including AWS CodeCommit, Bitbucket, and GitHub. The company wants to implement phased releases by using development, staging, user acceptance testing, and production environments in the AWS Cloud. Deployments to each environment must be started by code merges on the relevant Git branch. The company wants to...

To determine the best solution for deploying and maintaining static websites on AWS with the least operational overhead, let's evaluate each option based on key requirements: ease of deployment, serverless architecture, HTTPS, automation, and minimizing operational overhead. Option A: Host each website by using AWS Amplify with a serverless backend. Connect the repository branches that correspond to each of the desired environments. Start deployments by merging code changes to a desired branch. - Analysis: - Serverless architecture: AWS Amplify is a fully managed service, offering serverless hosting for static websites with built-in integration to various version control systems, including CodeCommit, GitHub, and Bitbucket. - HTTPS support: Amplify automatically provides HTTPS for websites. - Phased releases: You can set up separate environments (development, staging, production) corresponding to different Git branches. Each time code is merged into the desired branch, Amplify triggers the deployment automatically. - Minimal operational overhead: AWS Amplify handles the underlying infrastructure, including scaling, SSL certificates, and deployment triggers. This option is designed to reduce operational tasks. - This solution is ideal because it aligns with all the requirements, offering serverless hosting, automated deployments, HTTPS, and environment-based deployments. Option B: Host each website in AWS Elastic Beanstalk with multiple environments. Use the EB CLI to link each repository branch. Integrate AWS CodePipeline to automate deployments from version control code merges. - Analysis: - Serverless: Elastic Beanstalk is not fully serverless. While it abstracts infrastructure management, it still requires managing EC2 instances. - HTTPS: Beanstalk can provide HTTPS via an Application Load Balancer, but this requires additional setup. - Operational overhead: Elastic Beanstalk requires more management than AWS Amplify, particularly with configuring and maintaining environments and integrating with CodePipeline. - Suitability: Elastic Beanstalk is better for applications that need server-side processing, but for static websites, it's more complex than necessary, adding unnecessary operational overhead. Option C:...

Author: Mia · Last updated May 18, 2026

A company is migrating an on-premises database to Amazon RDS for MySQL. The company has read-heavy workloads. The company wants to refactor the code to achieve optimum read performance for queri...

To meet the company's requirements of optimizing read-heavy workloads for a MySQL database on Amazon RDS with the least current and future effort, let's evaluate each option: A) Use a multi-AZ Amazon RDS deployment. Increase the number of connections that the code makes to the database or increase the connection pool size if a connection pool is in use. - Pros: - Multi-AZ deployments improve availability and automatic failover, providing high availability in case of failure. - Connection pool size adjustments might improve connection handling performance. - Cons: - Multi-AZ deployments are designed for high availability, not read scalability. In a multi-AZ setup, the secondary replica is read-only and not intended for querying. It is primarily used for failover purposes, not for read-heavy workloads. - Increasing the number of connections or connection pool size can help performance for certain types of workloads, but it doesn't address the need for optimized read scalability across the application. It only manages connections and doesn’t scale the database for reads specifically. B) Use a multi-AZ Amazon RDS deployment. Modify the code so that queries access the secondary RDS instance. - Pros: - Multi-AZ deployments can ensure high availability in case of failures. - Cons: - In a Multi-AZ RDS deployment, the secondary instance is read-only for failover purposes, so it cannot be used for direct query access. - This would require significant changes to the architecture and potentially disrupt application logic, making this a less practical solution for optimizing read-heavy workloads. C) Deploy Amazon RDS with one or more read replicas. Modify the application code so that queries use the URL for the read replicas. - Pros: - Read replicas are specifically designed for scaling read workloads. By adding one or more read replicas, you can offload read-heavy queries from the primary instance, improving performance. - Automatic replication from the primary ...

Author: Max · Last updated May 18, 2026

A developer is creating an application that will be deployed on IoT devices. The application will send data to a RESTful API that is deployed as an AWS Lambda function. The application will assign each API request a unique identifier. The volume of API requests from the application can randomly increase at any given time of day. During periods of request throttling, the applicatio...

To meet the given requirements, we need a solution that can handle duplicate requests without inconsistencies or data loss. Let's evaluate each option based on key factors such as handling retries, scalability, and data consistency. Option A: Amazon RDS for MySQL DB Instance - Strengths: Amazon RDS is a managed relational database that provides strong consistency and ACID transactions. - Weaknesses: Using RDS can introduce higher latency, especially in high-volume or unpredictable traffic patterns. In a scenario with potentially many retries and random request spikes, the relational database could become a bottleneck. Additionally, relational databases generally require more overhead for scalability compared to NoSQL options, especially under unpredictable or high-volume traffic. - Conclusion: This option would work but is less efficient for handling high throughput and random spikes in requests. It’s not the ideal choice for IoT environments with high-frequency, potentially duplicate requests. Option B: Amazon DynamoDB Table - Strengths: DynamoDB is a managed NoSQL database designed for high scalability, low-latency responses, and handling unpredictable traffic spikes. It supports eventual consistency, which is acceptable in many use cases where strict consistency is not required. It is well-suited to handle high-throughput IoT workloads. - Weaknesses: The Lambda function must check if an identifier exists before processing the request, and if it's a retry, it must ensure no inconsistency occurs, such as reprocessing the same request. DynamoDB offers features like conditional writes, which can help avoid overwriting data during retries. However, careful implementation is needed to avoid race conditions. - Conclusion: This is an ideal solution for handling large-scale IoT requests with a high volume and varying traffic. It can effectively prevent inconsistencies and data loss due to retries. Option C: Amazon DynamoDB Table with Client Error Response for Duplicates - Strengths: Similar to Option B, this option leverages DynamoDB for handling high through...

Author: Ava · Last updated May 18, 2026

A developer wants to expand an application to run in multiple AWS Regions. The developer wants to copy Amazon Machine Images (AMIs) with the latest changes and create a new application stack in the destination Region. According to company requirements, all AMIs must be encrypted in all Regions. However, not all the AMIs that the comp...

The developer needs to meet the encryption requirement for Amazon Machine Images (AMIs) when expanding the application to a new AWS Region. Let's analyze each option based on key factors such as encryption, regional replication, and applicability. Option A: Create New AMIs, and Specify Encryption Parameters. Copy the Encrypted AMIs to the Destination Region. Delete the Unencrypted AMIs. - Strengths: This option explicitly creates new, encrypted AMIs, ensuring compliance with the encryption requirement. Once the AMIs are encrypted, they can be copied to the destination Region. - Weaknesses: Creating new AMIs may involve downtime or additional complexity since you are essentially generating fresh copies of the instances, potentially losing custom configurations that are tied to the original AMIs. It also involves deleting the unencrypted AMIs, which could be an issue if the unencrypted AMIs are needed for backup or rollback. - Conclusion: This solution is effective in meeting the encryption requirement but introduces additional steps, including creating new AMIs and deleting old ones. It's a good option if there is no need to retain unencrypted versions and the creation of new AMIs is acceptable. Option B: Use AWS Key Management Service (AWS KMS) to Enable Encryption on the Unencrypted AMIs. Copy the Encrypted AMIs to the Destination Region. - Strengths: AWS KMS allows for encrypting the AMIs with a customer-managed key, ensuring compliance with the encryption policy. After encryption, the AMIs can be copied to the destination Region. - Weaknesses: AMIs that are already created cannot be directly encrypted after creation. The AMI's volumes need to be copied and encrypted using KMS, but this can’t be done directly on the existing AMI itself. Instead, a new encrypted copy of the AMI must be created by creating snapshots of the associated EBS volumes and copying those with encryption enabled. - Conclusion: This is a viable solution but requires a process of creating new encrypted copies of the AMI rather than directly enabling encryption on e...

Author: Daniel · Last updated May 18, 2026

A company hosts a client-side web application for one of its subsidiaries on Amazon S3. The web application can be accessed through Amazon CloudFront from https://www.example.com. After a successful rollout, the company wants to host three more client-side web applications for its remaining subsidiaries on three separate S3 buckets. To achieve this goal, a developer moves all the common JavaScript files and web fonts to a central S3 bucket that serves the web applications. Ho...

In this scenario, the developer wants to allow access to JavaScript files and web fonts stored in a central S3 bucket from different web applications hosted on separate S3 buckets. However, the browser is blocking these resources, likely due to cross-origin restrictions. Let's evaluate the options to resolve this issue: Option A: Create Four Access Points That Allow Access to the Central S3 Bucket. Assign an Access Point to Each Web Application Bucket. - Strengths: S3 Access Points can simplify managing permissions for large-scale applications and workloads. They provide a unique hostname for each access point, which could be useful if you have different use cases. - Weaknesses: Access Points are generally more useful for fine-grained access management across multiple applications, but they don’t directly address the issue of cross-origin resource sharing (CORS). The main issue here seems to be related to CORS policy, not access point configuration. - Conclusion: While useful in some scenarios, this option does not directly resolve the CORS-related issue preventing the browser from loading the JavaScript files and web fonts. Option B: Create a Bucket Policy That Allows Access to the Central S3 Bucket. Attach the Bucket Policy to the Central S3 Bucket. - Strengths: A bucket policy can control access at the bucket level and restrict access based on IP addresses, VPCs, and other conditions. - Weaknesses: Bucket policies govern access permissions, but they do not address cross-origin resource sharing (CORS). Without a proper CORS configuration, the browser will block the resources due to security restrictions, even if access is allowed via the bucket policy. - Conclusion: A bucket policy alone would not solve the problem of blocked resources in the browser, as it does not address CORS. It's an access control measure, but not a solution for cross-origin issues. Option C: Create a Cross-Origin Resource Sharing (CORS) Configuration Th...

Author: Noah · Last updated May 18, 2026

An application is processing clickstream data using Amazon Kinesis. The clickstream data feed into Kinesis experiences periodic spikes. The PutRecords API call occasionally fails and the logs show that the failed call return...

When using Amazon Kinesis, spikes in data throughput can cause failures in the `PutRecords` API call due to exceeding throughput limits. To mitigate the issue, let's evaluate each technique for handling the exception: Option A: Implement Retries with Exponential Backoff - Strengths: Exponential backoff is a recommended approach for handling transient failures when interacting with AWS services like Kinesis. It retries requests at increasing intervals, allowing the system to recover gracefully from temporary spikes in traffic. This helps avoid overwhelming the system with retries at a constant rate. - Weaknesses: None, as exponential backoff is specifically designed to handle situations where there are intermittent failures due to temporary spikes in traffic. - Conclusion: This is a valid technique and will help mitigate the exception by giving the system time to recover during periods of high load. Option B: Use a PutRecord API Instead of PutRecords - Strengths: `PutRecord` sends a single record at a time, which can reduce the likelihood of exceeding throughput limits for bulk requests. If the failure is due to an overload of requests in a batch, using `PutRecord` might mitigate the issue for smaller, isolated data points. - Weaknesses: The main issue is that switching from `PutRecords` to `PutRecord` may not solve the fundamental issue of throughput limits, especially if the spikes in data are large. `PutRecord` only handles one record at a time, which could result in more frequent API calls that may not scale well during high traffic. - Conclusion: While `PutRecord` could reduce the impact of overload, it may not be the most efficient solution compared to handling bulk requests properly with retries and backoff. It could introduce overhead due to a large number of API calls. Option C: Reduce the Frequency and/or Size of the Requests - Strengths: Reducing the frequency and/or size of the requests directly addresses the core issue of throughput limits by reducing the volume of data being sent during peak spikes. This approach can help prevent exceeding the available limits for `PutRecords`. - Weaknesses: This solution may not be feasible if the application needs to ...

Author: Evelyn · Last updated May 18, 2026

A company has an application that uses Amazon Cognito user pools as an identity provider. The company must secure access to user records. The company has set up multi-factor authentication (MFA). The company also wants to send a login activity notification by ...

To meet the requirement of sending a login activity notification by email every time a user logs in, we need an operationally efficient solution that triggers an email notification automatically when a login occurs. Let's evaluate each option based on simplicity, effectiveness, and operational efficiency: Option A: Create an AWS Lambda function that uses Amazon Simple Email Service (Amazon SES) to send the email notification. Add an Amazon API Gateway API to invoke the function. Call the API from the client side when login confirmation is received. - Strengths: This option provides a custom solution where the client can directly invoke the API to send a notification. - Weaknesses: This requires the client-side application to make an additional API call after login, adding complexity and extra steps. It also increases the risk of failure if the client-side integration is not done properly. Additionally, it may introduce unnecessary operational overhead for maintaining an extra API Gateway and Lambda integration. - Conclusion: While this approach works, it is not efficient as it requires extra steps from the client and adds complexity to the system. This is not the most operationally efficient option. Option B: Create an AWS Lambda function that uses Amazon Simple Email Service (Amazon SES) to send the email notification. Add an Amazon Cognito post authentication Lambda trigger for the function. - Strengths: Amazon Cognito provides built-in support for Lambda triggers, and the post-authentication trigger is designed to invoke a Lambda function immediately after a successful login. This means the function can be triggered automatically without additional client-side code or API calls. The Lambda function can then use Amazon SES to send the email notification. - Weaknesses: None. This is a built-in integration within the Cognito user pool and requires minimal configuration. - Conclusion: This is the most operationally efficient solution because it leverages built-in Cognito functionality to automatically trigger the email notification after each login without requiring additio...

Author: VioletCheetah55 · Last updated May 18, 2026

A developer has an application that stores data in an Amazon S3 bucket. The application uses an HTTP API to store and retrieve objects. When the PutObject API operation adds objects to the S3 bucket the developer must encrypt these objects at rest by u...

To meet the requirement of encrypting objects at rest using Amazon S3's server-side encryption with Amazon S3 managed keys (SSE-S3), we need to focus on the configuration that directly controls the encryption of objects as they are stored in S3. Here's an analysis of each option: A) Create an AWS Key Management Service (AWS KMS) key. Assign the KMS key to the S3 bucket. - This option would use AWS KMS-managed keys (SSE-KMS) for encryption, but the requirement is specifically to use SSE-S3, which does not involve the use of KMS keys. SSE-S3 uses S3-managed keys (not KMS keys), so this is not the correct option for the specified requirement. B) Set the x-amz-server-side-encryption header when invoking the PutObject API operation. - This option is valid. When using SSE-S3, you can specify the `x-amz-server-side-encryption` header with a value of `AES256` when performing the `PutObject` operation. This tells Amazon S3 to encrypt the objects with S3-managed keys (SSE-S3), which is exactly what the developer requires. C) Provide the encryption key in the HTTP hea...

Author: IronLion88 · Last updated May 18, 2026

A developer needs to perform geographic load testing of an API. The developer must deploy resources to multiple AWS Regions to support the load testing of the API. How can...

To meet the requirement of performing geographic load testing without additional application code, the developer needs a solution that allows deploying resources to multiple AWS Regions. Let’s analyze each option: A) Create and deploy an AWS Lambda function in each desired Region. Configure the Lambda function to create a stack from an AWS CloudFormation template in that Region when the function is invoked. - This approach would involve deploying Lambda functions across multiple Regions. While possible, it introduces unnecessary complexity. Each Lambda function would need to be configured to invoke CloudFormation stacks, which requires additional setup, maintenance, and management. This approach is more complex than necessary for geographic load testing, as it introduces more components and manual orchestration than the other options. B) Create an AWS CloudFormation template that defines the load test resources. Use the AWS CLI create-stack-set command to create a stack set in the desired Regions. - This option is the most appropriate. AWS CloudFormation StackSets allow you to deploy resources in multiple Regions simultaneously using a single CloudFormation template. The `create-stack-set` command allows you to easily create stacks in multiple regions, which aligns with the geographic load testing requirements without requiring additional application code. It’s simple, scalable, and managed directly via CloudFormation. C) Create an AWS Systems Manager document that defines the resources. Use the document to create the resources in th...

Author: Ryan · Last updated May 18, 2026

A developer is creating an application that includes an Amazon API Gateway REST API in the us-east-2 Region. The developer wants to use Amazon CloudFront and a custom domain name for the API. The developer has acquired an SSL/TLS certificate for the d...

To configure a custom domain for an Amazon API Gateway REST API and use Amazon CloudFront, the developer needs to ensure that the SSL/TLS certificate is properly integrated with both API Gateway and CloudFront. Here’s an analysis of each option: A) Import the SSL/TLS certificate into AWS Certificate Manager (ACM) in the same Region as the API. Create a DNS A record for the custom domain. - This option suggests importing the SSL/TLS certificate into ACM in the same region as the API (us-east-2) and creating a DNS A record. However, API Gateway REST APIs require the SSL/TLS certificate to be imported into AWS Certificate Manager (ACM) in the US-East-1 Region for use with CloudFront, which is automatically set up by API Gateway for custom domains. This approach is incorrect because API Gateway uses CloudFront for the distribution, and the certificate needs to be in the US-East-1 Region, not in the same region as the API (us-east-2). B) Import the SSL/TLS certificate into CloudFront. Create a DNS CNAME record for the custom domain. - This option is incorrect because CloudFront does not directly manage SSL/TLS certificates. While CloudFront does use SSL/TLS certificates, they are typically managed in ACM. You cannot import the certificate directly into CloudFront without first using ACM to issue or import the certificate in the correct region (US-East-1). Additionally, creating a CNAME record is required, but the certificate management aspect is not configured properly here. C) Import the SSL/TLS certificate into AWS Certificat...

Author: MysticJaguar44 · Last updated May 18, 2026

A developer is creating a template that uses AWS CloudFormation to deploy an application. The application is serverless and uses Amazon API Gateway, Amazon DynamoDB, and AWS Lambda. Which AW...

When defining serverless resources in YAML for a CloudFormation template, the best option is to use a framework specifically designed to simplify serverless application development and deployment. Let's analyze each option: A) CloudFormation serverless intrinsic functions - This option refers to using CloudFormation intrinsic functions like `Fn::GetAtt` or `Ref` within a template. While intrinsic functions are a core part of CloudFormation and can be used to manage resources, they are not a dedicated solution for defining serverless resources in a simple, declarative way in YAML. This option is not ideal for simplifying the process of defining serverless applications specifically. B) AWS Elastic Beanstalk - AWS Elastic Beanstalk is an excellent service for deploying and managing applications but is primarily used for traditional applications (e.g., web servers, databases) rather than serverless applications. Elastic Beanstalk is not designed specifically for managing serverless resources like API Gateway, Lambda, and DynamoDB in a CloudFormation template, so it's not the best choice for this use case. C) AWS Serverless Application Model (AWS SAM) - This option is the best choice. AWS Serverless Application Model (AWS SAM) is an extension of AWS CloudFormation that simp...

Author: ElectricLionX · Last updated May 18, 2026

A developer wants to insert a record into an Amazon DynamoDB table as soon as a new file is added to an Amazon S3 bucket. ...

To achieve the goal of inserting a record into an Amazon DynamoDB table when a new file is added to an S3 bucket, we need an event-driven mechanism that reacts to the upload action and triggers the insertion. Let's evaluate each option: A) Create an event with Amazon EventBridge that will monitor the S3 bucket and then insert the records into DynamoDB. - EventBridge can monitor events from S3 and trigger actions in response. However, while this approach could work, EventBridge is typically used for a broader range of event-driven scenarios (e.g., inter-service communication or multi-service workflows). It’s more complex for a simple case like inserting a record into DynamoDB when a file is uploaded. Lambda functions are generally more straightforward and cost-effective for such a use case. B) Configure an S3 event to invoke an AWS Lambda function that inserts records into DynamoDB. - This is the best solution. You can configure an S3 event notification to trigger a Lambda function whenever a new file is uploaded to the S3 bucket. The Lambda function can then insert a record into DynamoDB based on the event data (such as file metadata or the file name). This solution is simple, efficient, and fully managed. It integrates well with S3 and DynamoDB, and Lambda automatically scales based on the event volume. C) Create an AWS Lambda function that will poll the S3 bucket and then insert the records into DynamoDB. - While this option involves using La...

Author: Sofia · Last updated May 18, 2026

A development team maintains a web application by using a single AWS CloudFormation template. The template defines web servers and an Amazon RDS database. The team uses the Cloud Formation template to deploy the Cloud Formation stack to different environments. During a recent application deployment, a developer caused the primary development database to be dropped and recreated. The resu...

Let's break down each option and explain the reasoning: A) Add a CloudFormation Deletion Policy attribute with the Retain value to the database resource. - Reasoning: The `DeletionPolicy` attribute with the `Retain` value ensures that when the CloudFormation stack is deleted or updated, the specified resource (in this case, the database) is not deleted. Instead, the resource is retained, preserving any data or configuration that was set up. This option specifically addresses the issue of accidental deletion and data loss by preventing the RDS instance from being dropped during stack updates or deletions. - Why it's selected: This option directly meets the requirement of preventing accidental database deletion and data loss. It is the most direct and effective solution. B) Update the CloudFormation stack policy to prevent updates to the database. - Reasoning: A stack policy is used to control which resources can be updated within a CloudFormation stack, but it doesn't necessarily prevent resource deletion. While this could prevent updates to the database, it doesn't directly address the issue of accidental deletion. The goal is to ensure that the database isn't deleted, which this policy doesn't fully achieve. - Why it's rejected: It prevents updates, but doesn't fully prevent accidental deletion, which is the main concern in the question. C) Modify the database to use a Multi-AZ deployment. - Reasoning: Multi-AZ deployments are designed to enhance the availability and durability of the database. In th...

Author: Lucas · Last updated May 18, 2026

A company has an Amazon S3 bucket that contains sensitive data. The data must be encrypted in transit and at rest. The company encrypts the data in the S3 bucket by using an AWS Key Management Service (AWS KMS) key. A developer needs to grant several other AWS accounts the permission to use the S3 GetObject operation to ...

Let's evaluate each option for enforcing encryption in transit for the S3 bucket: A) Define a resource-based policy on the S3 bucket to deny access when a request meets the condition "aws:SecureTransport": "false". - Reasoning: This option allows you to set a condition that denies access to the S3 bucket when the request is not encrypted in transit (i.e., not using HTTPS). The `aws:SecureTransport` condition key specifically checks if the request is sent over a secure (HTTPS) connection. If `false`, the request will be denied. This ensures that only secure requests (those that use HTTPS) are allowed to access the data in the S3 bucket. - Why it's selected: This is the correct approach, as it uses a condition directly on the S3 bucket to ensure that all requests for retrieving the data are made over HTTPS, fulfilling the requirement to enforce encryption in transit. B) Define a resource-based policy on the S3 bucket to allow access when a request meets the condition "aws:SecureTransport": "false". - Reasoning: This option allows access when the request is not secure (`"aws:SecureTransport": "false"`), which is the opposite of what is needed. We want to enforce encryption in transit, so allowing insecure requests would violate that requirement. - Why it's rejected: This option is incorrect because it allows unsecured requests rather than denying them, which contradicts the need to enforce encryption in transit. C) Define a role-based ...

Author: Harper · Last updated May 18, 2026

An application that is hosted on an Amazon EC2 instance needs access to files that are stored in an Amazon S3 bucket. The application lists the objects that are stored in the S3 bucket and displays a table to the user. During testing, a developer discovers ...

Let's evaluate each option to determine the most secure and effective solution for the issue where the application on an EC2 instance cannot list objects in an S3 bucket: A) Update the IAM instance profile that is attached to the EC2 instance to include the S3: permission for the S3 bucket. - Reasoning: The `S3:` permission grants full access to all S3 actions, including `ListBucket`, `GetObject`, `PutObject`, etc. While this would allow the EC2 instance to list the objects, it grants more permissions than necessary. Granting excessive permissions violates the principle of least privilege, which aims to minimize the permissions granted to only those needed for a specific task. - Why it's rejected: This is not the most secure option because it grants overly broad permissions. It is better to grant only the necessary permissions. B) Update the IAM instance profile that is attached to the EC2 instance to include the S3:ListBucket permission for the S3 bucket. - Reasoning: The `S3:ListBucket` permission allows the EC2 instance to list the objects in the S3 bucket. This is the minimum required permission to allow the application to display the objects stored in the bucket. This solution follows the principle of least privilege by granting only the specific permission needed to fulfill the task. - Why it's selected: This is the most secure option, as it grants only t...

Author: Liam · Last updated May 18, 2026

A company is planning to securely manage one-time fixed license keys in AWS. The company's development team needs to access the license keys in automaton scripts that run in Amazon EC2 instances and in AWS C...

Let's evaluate each option based on the scenario of securely managing one-time fixed license keys and meeting the requirements of automation scripts running in EC2 instances and CloudFormation stacks: A) Amazon S3 with encrypted files prefixed with "config" - Reasoning: Storing license keys as files in Amazon S3 and encrypting them is a viable option, but it would require significant manual management (e.g., managing access control to specific files, ensuring encryption, etc.). Also, S3 is more commonly used for storing objects like backups, static assets, and not for secrets or sensitive configuration data. - Why it's rejected: While S3 with encryption could work, it is not the most secure or best practice for managing sensitive data like license keys. It also lacks native integrations with AWS services for secure access and automation, which would make it harder to manage efficiently. B) AWS Secrets Manager secrets with a tag that is named SecretString - Reasoning: AWS Secrets Manager is designed to securely store and manage secrets. However, using a tag to store the `SecretString` is not the recommended approach. Secrets Manager automatically handles secret versions, encryption, and access control, but the use of a tag for storing secret data is not a good practice as it is not intended for storing the actual secret data. Secrets should be stored in the "secret value" field, not tags. - Why it's rejected: This is an unconventional and insecure use of tags. Secrets Manager is suitable for securely managing secrets, but tags should not be used to store the actual secret data. This approach introduces potential security risks. ...

Author: IronLion88 · Last updated May 18, 2026

A company has deployed infrastructure on AWS. A development team wants to create an AWS Lambda function that will retrieve data from an Amazon Aurora database. The Amazon Aurora database is in a private subnet in company's VPC. The VPC is named VPC1. The data is relati...

Let's break down the options and analyze them based on the requirements: A) Create the Lambda function. Configure VPC1 access for the function. Attach a security group named SG1 to both the Lambda function and the database. Configure the security group inbound and outbound rules to allow TCP traffic on Port 3306. - Reasoning: This option involves creating the Lambda function inside the VPC (VPC1) and configuring access using security groups. By attaching a security group to both the Lambda function and the Aurora database, you can control traffic between the Lambda function and the Aurora database. Security group rules can be set to allow TCP traffic on port 3306 (the default port for MySQL-compatible Aurora), ensuring secure communication between the Lambda function and the database. This is a secure and simple solution that keeps all components within the same VPC. - Why it's selected: This solution is effective and secure. The Lambda function will securely connect to the Aurora database inside VPC1 using security groups, ensuring traffic is controlled and encrypted within the VPC. B) Create and launch a Lambda function in a new public subnet that is in a new VPC named VPC2. Create a peering connection between VPC1 and VPC2. - Reasoning: This option introduces unnecessary complexity by creating a new VPC (VPC2) and peering it with VPC1. A Lambda function in a public subnet in VPC2 will need to access the Aurora database in VPC1 via the VPC peering connection, which adds network complexity and potential security concerns. It also introduces latency and could complicate security group configurations. This setup is not optimal since you can directly deploy the Lambda function within VPC1. - Why it's rejected: While VPC peering can allow communication between VPCs, this option unnecessarily complicates the setup by adding a second VPC and peering, when a simpler and more secure solution within VPC1 is possible. C) Create the Lambda function. Configure VPC1 access for the function. Assign a security gro...

Author: Liam · Last updated May 18, 2026

A developer is building a web application that uses Amazon API Gateway to expose an AWS Lambda function to process requests from clients. During testing, the developer notices that the API Gateway times out even though the Lambda function finishes under the set time limit. Whic...

To troubleshoot the issue of API Gateway timing out while the Lambda function is completing within the set time limit, we need to look for specific API Gateway metrics that can provide insights into the processing and interaction between API Gateway and Lambda. Let's review the options: A) CacheHitCount This metric tracks the number of times API Gateway served requests from the cache. However, this is not relevant in the context of a timeout issue between API Gateway and Lambda because the problem is not related to caching. The issue is likely due to how API Gateway is interacting with Lambda, not caching. Rejected. B) IntegrationLatency This metric measures the time between when API Gateway relays the request to the backend (in this case, AWS Lambda) and when it receives a response. If API Gateway is experiencing issues connecting to Lambda or waiting for a response, this metric could show a delay in that communication. Since the Lambda function is completing within the set time limit, but API Gateway is timing out, this metric will help identify if the Lambda response is being delayed or if there are other connection issues. Selected. C) CacheMissCount This metric tracks the number of times API Gateway requests data that isn't present in the cache, which is irrelevant when troubleshooting...

Author: Olivia Johnson · Last updated May 18, 2026

A development team wants to build a continuous integration/continuous delivery (CI/CD) pipeline. The team is using AWS CodePipeline to automate the code build and deployment. The team wants to store the program code to pr...

To store the program code in preparation for a CI/CD pipeline using AWS CodePipeline, the team needs a version control service that integrates well with the pipeline for managing source code. Let's analyze the options: A) AWS CodeDeploy AWS CodeDeploy is a service designed for automating code deployment to various environments, such as EC2 instances, Lambda functions, and on-premises servers. While it is a key part of a CI/CD pipeline for deployment, it is not intended for storing or managing the program code itself. Rejected. B) AWS CodeArtifact AWS CodeArtifact is a managed artifact repository service designed to store and manage dependencies and packages, such as libraries or third-party packages. It is commonly used for managing dependencies during builds rather than storing the program's source code itself. Therefore, this service is not suitable for storing the program code. Rejected. C) AWS CodeCommit AWS CodeCommit is a fully managed source control service that hosts secure Git repositories. It is specifically designed for storin...

Author: Scarlett · Last updated May 18, 2026

A developer is designing an AWS Lambda function that creates temporary files that are less than 10 MB during invocation. The temporary files will be accessed and modified multiple times during invocation. The developer has no...

In this scenario, the developer needs to store temporary files that are created during the execution of an AWS Lambda function and are only needed for the duration of the function’s invocation. The developer does not need to save or retrieve the files after the function completes. Let's analyze each option: A) the /tmp directory The /tmp directory in AWS Lambda is a local disk storage available during the execution of the Lambda function. Lambda functions can use this directory to store temporary files up to 10 GB in size. Since the files are temporary and only needed during the function's invocation, this is the ideal place to store them. The /tmp directory is fast, ephemeral, and automatically cleared after the Lambda execution, making it perfect for temporary files that don’t need to persist beyond the function’s lifecycle. Selected. B) Amazon Elastic File System (Amazon EFS) Amazon EFS provides scalable file storage that can be accessed by multiple EC2 instances and Lambda functions, but it is designed for persistent storage, typically for files that need to be shared or accessed after Lambda executions. It introduces complexity and additional cost for use in Lambda functions, especially if the data doesn't need to be persistent. Since the developer only needs temporary file storage during invocation, EFS is overkill and not ideal for this use case. Rejected. ...

Author: Krishna · Last updated May 18, 2026

A developer is designing a serverless application with two AWS Lambda functions to process photos. One Lambda function stores objects in an Amazon S3 bucket and stores the associated metadata in an Amazon DynamoDB table. The other Lambda function fetches the objects from the S3 bucket by using the metadata from the DynamoDB table. Both Lambda functions use the same Python library to perform complex computations and are approach...

Let's evaluate each of the options based on reducing the size of the Lambda deployment packages with the least operational overhead: A) Package each Python library in its own .zip file archive. Deploy each Lambda function with its own copy of the library. - Reasoning: This option suggests packaging the Python libraries separately and deploying a copy of the library with each Lambda function. However, this would increase the overall size of the deployment packages, as each Lambda function would include a copy of the library. Additionally, maintaining multiple copies of the same library across multiple Lambda functions would introduce unnecessary duplication and make it harder to manage library updates. - Rejected: This option creates more overhead due to duplication of libraries and larger deployment sizes. B) Create a Lambda layer with the required Python library. Use the Lambda layer in both Lambda functions. - Reasoning: A Lambda layer is a distribution mechanism for libraries and dependencies that can be shared across multiple Lambda functions. By creating a Lambda layer, you can package the Python library separately and reference it in both Lambda functions. This solution significantly reduces the size of each Lambda deployment package, as the library is stored in the layer, not directly in the Lambda function. This also ensures that both Lambda functions use the same version of the library and simplifies updates. - Selected: This option reduces the deployment size, provides a centralized way to manage the library, and minimizes operational overhead. C) Combine the two Lambda functions into one Lambda function. Deploy the Lambda function as a single .zip...

Author: ShadowWolf101 · Last updated May 18, 2026

A developer is writing an AWS Lambda function. The developer wants to log key events that occur while the Lambda function runs. The developer wants to include a unique identifier to associate the events with a specific function invocation. Th...

To meet the requirement of logging key events with a unique identifier for each Lambda invocation, let's carefully evaluate each option: A) Obtain the request identifier from the AWS request ID field in the context object. Configure the application to write logs to standard output. - Reasoning: The AWS request ID is available in the context object during a Lambda invocation, which is a great choice for identifying the specific request. Lambda automatically logs to CloudWatch Logs when the logs are written to standard output (`stdout`). This is the recommended method for logging events in AWS Lambda, as it ensures logs are captured in CloudWatch Logs without additional configuration. - Selected: This option is ideal because it correctly uses the context object for the request ID and writes to standard output, which integrates well with CloudWatch. B) Obtain the request identifier from the AWS request ID field in the event object. Configure the application to write logs to a file. - Reasoning: The event object contains the event data sent to the Lambda function, not the request ID. The request ID is part of the context object, not the event object. Writing logs to a file is not the typical practice in Lambda functions, as AWS Lambda does not have a persistent file system, and managing logs in this way would introduce complexity. Lambda functions are designed to write logs to CloudWatch, not to files. - Rejected: Using the event object for the request ID is incorrect, and writing to a file is unnecessary and problematic in Lambda's stateless environment. C) Obt...

Author: Benjamin · Last updated May 18, 2026

A developer is working on a serverless application that needs to process any changes to an Amazon DynamoDB table with an AWS Lambda function. How should the develope...

To process changes to a DynamoDB table with an AWS Lambda function, let's review each option and determine the best configuration for this scenario. Option A: Create an Amazon Kinesis data stream, and attach it to the DynamoDB table. Create a trigger to connect the data stream to the Lambda function. - Why it's rejected: DynamoDB itself does not directly support integrating with Kinesis streams to process changes. While both Kinesis and DynamoDB are powerful services, this approach requires additional setup and complexity for streaming changes from DynamoDB to Kinesis, which is not necessary in this use case. - When to use: This method can be useful in scenarios where the application has more complex real-time data streaming needs, but it's over-engineered for simply processing DynamoDB changes. Option B: Create an Amazon EventBridge rule to invoke the Lambda function on a regular schedule. Connect to the DynamoDB table from the Lambda function to detect changes. - Why it's rejected: EventBridge can trigger scheduled events, but it doesn't natively handle changes or real-time updates from DynamoDB. This option involves polling the DynamoDB table regularly, which is inefficient and does not provide an immediate response to changes in the table. - When to use: EventBridge would be more suited for scheduled tasks or for triggering Lambda functions on specific events that happen on a regular basis, rather than processing real-time changes to the DynamoDB table. Option C: Enable DynamoDB Streams on the table. Create a trigger to connect the Dy...

Author: Rohan · Last updated May 18, 2026

An application uses an Amazon EC2 Auto Scaling group. A developer notices that EC2 instances are taking a long time to become available during scale-out events. The UserData script is taking a long time to run. The developer must implement a solution to decrease the time that elapses before an EC2 instance becomes available. The solution must make the most recent version of the application available at all times and must apply all available security update...

To address the issue of EC2 instances taking too long to become available during scale-out events, the solution should focus on reducing startup times while ensuring that the most recent application version and necessary security patches are applied. Let’s evaluate each option: Option A: Use EC2 Image Builder to create an Amazon Machine Image (AMI). Install all the patches and agents that are needed to manage and run the application. Update the Auto Scaling group launch configuration to use the AMI. - Why it's rejected: This option involves using EC2 Image Builder to create an AMI with the patches and agents already installed. While it reduces the time required for instance startup, it doesn't address the requirement of always having the most recent version of the application available. The AMI would need to be rebuilt and validated whenever an application update is required, which increases the effort involved in managing updates. - When to use: This approach is helpful if you need to manage base images with specific configurations but does not fulfill the "most recent version of the application" requirement. Option B: Use EC2 Image Builder to create an Amazon Machine Image (AMI). Install the latest version of the application and all the patches and agents that are needed to manage and run the application. Update the Auto Scaling group launch configuration to use the AMI. - Why it's selected: This option creates an AMI using EC2 Image Builder, installing the latest version of the application along with necessary patches and agents. The AMI is validated, and when new EC2 instances are launched, they will be up to date with both the application and security patches. By using EC2 Image Builder, this solution minimizes the number of images created while ensuring that the most recent version of the application is always available. Updating the Auto Scaling group launch configuration to use the new AMI ensures that scale-out events use the latest image. - When to use: This option is ideal when you need to create a consistent and updated image that incorporates the latest application version and patches. It balances image management with application version control. Option C: Set up AWS Co...

Author: Oscar · Last updated May 18, 2026

A developer is creating an AWS Lambda function that needs credentials to connect to an Amazon RDS for MySQL database. An Amazon S3 bucket currently stores the credentials. The developer needs to improve the existing solution by implementing credential rotation and secure storage. The developer also needs to provide integration...

To select the most appropriate solution for securely storing and rotating credentials with minimal management overhead, let's analyze each option: Option A: Store the credentials in AWS Systems Manager Parameter Store. Select the database that the parameter will access. Use the default AWS Key Management Service (AWS KMS) key to encrypt the parameter. Enable automatic rotation for the parameter. Use the parameter from Parameter Store on the Lambda function to connect to the database. - Why it's rejected: While AWS Systems Manager Parameter Store offers encrypted storage for parameters, it does not natively support automatic credential rotation for Amazon RDS credentials in the same way that AWS Secrets Manager does. This would require additional custom development to manage rotation and synchronization with the RDS instance. - When to use: Systems Manager Parameter Store can be useful for storing non-credential parameters or for simple secrets, but it’s not the best choice for a fully managed, integrated credential rotation solution. Option B: Encrypt the credentials with the default AWS Key Management Service (AWS KMS) key. Store the credentials as environment variables for the Lambda function. Create a second Lambda function to generate new credentials and to rotate the credentials by updating the environment variables of the first Lambda function. Invoke the second Lambda function by using an Amazon EventBridge rule that runs on a schedule. Update the database to use the new credentials. On the first Lambda function, retrieve the credentials from the environment variables. Decrypt the credentials by using AWS KMS, Connect to the database. - Why it's rejected: Storing credentials as Lambda environment variables and rotating them manually adds significant management overhead. It requires creating additional Lambda functions, updating environment variables, and synchronizing the database credentials. This solution also lacks a native mechanism for automatically rotating RDS credentials, making it more error-prone and harder to maintain. - When to use: This approach could be used in environments where extreme customization is required, but it’s inefficient and complex for managing database credentials compared to other options. Option C: Store the credentials in AWS Secrets Manager. Set the secret type to Credentials for Amazon RDS database...

Author: Emily · Last updated May 18, 2026

A developer has written the following IAM policy to provide access to an Amazon S3 bucket: Which access does the policy all...

Author: Scarlett · Last updated May 18, 2026

A developer is creating a mobile app that calls a backend service by using an Amazon API Gateway REST API. For integration testing during the development phase, the developer wants to simulate different backend responses without invoking...

Let’s review each option and evaluate them based on the requirement of simulating different backend responses with the least operational overhead. Option A: Create an AWS Lambda function. Use API Gateway proxy integration to return constant HTTP responses. - Why it's rejected: Using an AWS Lambda function for simulating different backend responses involves more setup and maintenance than necessary. While Lambda can indeed simulate different responses, this option introduces more operational overhead by requiring Lambda code, configuration, and integration management. Also, it may not be as flexible or efficient as using built-in API Gateway features to mock responses. - When to use: This would be appropriate if you need more complex logic or dynamic backend responses, but it doesn't meet the "least operational overhead" requirement for simple testing. Option B: Create an Amazon EC2 instance that serves the backend REST API by using an AWS CloudFormation template. - Why it's rejected: This option involves creating and managing an EC2 instance, which introduces significant operational overhead for a simple task like simulating backend responses. You would need to manage the EC2 instance, handle scaling, maintenance, and security, making this approach far more complicated than necessary for integration testing. - When to use: This could be used in a more complex production environment where the backend service is not yet ready, but it involves unnecessary management overhead for a simple mock integration during development. Option C: Customize the API Gateway stage to select a response type based on the request. - Why it's rejected: This opt...

Author: Sofia · Last updated May 18, 2026

A developer has a legacy application that is hosted on-premises. Other applications hosted on AWS depend on the on-premises application for proper functioning. In case of any application errors, the developer wants to be able to use Amazon Cloud...

To monitor and troubleshoot all applications from one place using Amazon CloudWatch, the developer needs a solution that allows seamless integration between the on-premises server and AWS CloudWatch. Let's evaluate the options: Option A: Install an AWS SDK on the on-premises server to automatically send logs to CloudWatch. - Pros: The AWS SDK can be used to programmatically send logs from the on-premises server to CloudWatch. - Cons: This approach requires custom development, including setting up the SDK, handling authentication, and error handling. It’s less efficient compared to other methods designed specifically for log management. - Reason for Rejection: The developer would need to write and maintain custom code, which could add unnecessary complexity for simply sending logs to CloudWatch. Additionally, the SDK is not primarily intended for logging; it’s more suited for interacting with AWS services. Option B: Download the CloudWatch agent to the on-premises server. Configure the agent to use IAM user credentials with permissions for CloudWatch. - Pros: The CloudWatch agent is designed for this exact scenario. It can be easily installed on the on-premises server to collect logs and metrics. The agent can securely send logs to CloudWatch and is fully supported by AWS. - Cons: The setup involves configuring IAM user credentials, but this is a straightforward task with AWS’s managed IAM features. - Reason for Selection: This option is the most direct and efficient for sending logs from on-premises to CloudWatch. The CloudWatch agent is designed specifically to collect and forward logs and metrics from on-prem...

Author: Emma · Last updated May 18, 2026

An Amazon Kinesis Data Firehose delivery stream is receiving customer data that contains personally identifiable information. A developer needs to remove pattern-based customer identifiers from the data and store the m...

To meet the requirement of removing pattern-based customer identifiers from the data and storing it in an Amazon S3 bucket, the solution needs to be efficient, cost-effective, and manageable. Let's analyze each option: Option A: Implement Kinesis Data Firehose data transformation as an AWS Lambda function. Configure the function to remove the customer identifiers. Set an Amazon S3 bucket as the destination of the delivery stream. - Pros: - Purpose-built solution: Kinesis Data Firehose integrates well with AWS Lambda, allowing you to process and transform the data before it is delivered to the destination. - Efficient: AWS Lambda is highly scalable and managed, which makes it a good fit for real-time data processing. - No additional infrastructure: Lambda functions are serverless and require no maintenance of additional resources. - Direct delivery: Data can be directly stored in Amazon S3, which is exactly what is required here. - Cons: There are some limits on the size of data that can be processed by Lambda functions (6 MB synchronous, 256 KB asynchronous), but these limits are typically sufficient for many use cases. - Reason for Selection: This is the most appropriate solution as it directly integrates with Kinesis Data Firehose, performs the required transformation (removal of identifiers), and delivers the data to Amazon S3 with minimal additional setup. Option B: Launch an Amazon EC2 instance. Set the EC2 instance as the destination of the delivery stream. Run an application on the EC2 instance to remove the customer identifiers. Store the transformed data in an Amazon S3 bucket. - Pros: EC2 instances can process the data and perform the necessary transformations. - Cons: - Complexity: You need to manage the EC2 instance, which involves more operational overhead, such as instance maintenance, scaling, and monitoring. - Cost: EC2 instances are typically more expensive compared to serverless solutions like Lambda, especially if the processing is continuous. - Scalability: Scaling the EC2 instance to handle large amounts of data may require additional configuration and may not be as efficient as Lambda. - Reason for Rejection: This option introduces unnecessary complexity and operational overhead. It's not as efficient or cost-effective compared to Lambd...

Author: NebulaEagle11 · Last updated May 18, 2026

A developer is using an AWS Lambda function to generate avatars for profile pictures that are uploaded to an Amazon S3 bucket. The Lambda function is automatically invoked for profile pictures that are saved under the /original/ S3 prefix. The developer notices that some pictures cause the Lambda function to time out. The developer wants to implement a fallback ...

To implement a fallback mechanism for the Lambda function that generates avatars, the solution should allow for minimal development effort while providing an effective way to handle failures (such as Lambda timeouts). Let's evaluate each option: Option A: Set the image resize Lambda function as a destination of the avatar generator Lambda function for the events that fail processing. - Pros: - Simple integration: Lambda destinations can automatically trigger another Lambda function upon failure, providing an easy way to implement a fallback. - Cons: - Limited configuration: While Lambda destinations are an efficient mechanism for failure handling, they don't allow for complex error handling or retries. It is a straightforward solution but may not be as flexible as other methods. - Failure scope: Only specific errors are captured and forwarded to the fallback function, and there may be limitations on retry logic and processing control. - Reason for Rejection: This option is simple but may not offer the best flexibility if you need more complex error handling or additional processing capabilities. However, for simple error forwarding, this could be an option. Option B: Create an Amazon Simple Queue Service (Amazon SQS) queue. Set the SQS queue as a destination with an on failure condition for the avatar generator Lambda function. Configure the image resize Lambda function to poll from the SQS queue. - Pros: - Asynchronous processing: SQS allows for decoupling and asynchronous retry mechanisms. - Scalability: If the failure rate increases, SQS can handle backpressure by queuing failed events. - Cons: - Increased complexity: Implementing SQS requires managing the queue, ensuring proper Lambda polling, and handling retries manually. - Latency: This introduces additional steps—messages are first placed in SQS, and the resize function then polls and processes the data. This adds more time to the workflow, which could be undesirable. - Reason for Rejection: While SQS can handle retry logic and failures efficiently, the added complexity and latency make it a less optimal choice compared to other options. Option C: Create an AWS Step Functions state machine that invokes the avatar generator Lambda function and uses the image resize Lambda function as a fallback. Create an Amazon EventBridge rule that ma...

Author: IronLion88 · Last updated May 18, 2026

A developer needs to migrate an online retail application to AWS to handle an anticipated increase in traffic. The application currently runs on two servers: one server for the web application and another server for the database. The web server renders webpages and manages session state in memory. The database server hosts a MySQL database that contains order details. When traffic to the application is heavy, the memory usage for the web server approaches 100% and the application slows down considerably. The developer has found that most of the memory increase and performance decrease is related to the load of managing additiona...

To address the performance issues caused by heavy traffic and high memory usage on the web server, the developer needs to optimize the handling of user sessions and manage database traffic more efficiently. Let's evaluate each option based on the requirements. Option A: Use an EC2 instance to host the MySQL database. Store the session data and the application data in the MySQL database. - Pros: - Simple setup for managing both application and session data in a single database. - Cons: - Performance issue: Storing session data in the same database as the application data increases load on the database server. Since session data is often read and written frequently, storing it in MySQL could increase the load on the database, leading to performance degradation. - Scalability: EC2 instances for databases may not scale as efficiently as managed database services like Amazon RDS, especially under high traffic loads. - Reason for Rejection: Storing session data in the MySQL database would add unnecessary load to the database, which is likely already a performance bottleneck. This option does not address the core issue of high memory usage and slowdowns on the web server. Option B: Use Amazon ElastiCache for Memcached to store and manage the session data. Use an Amazon RDS for MySQL DB instance to store the application data. - Pros: - Session management: ElastiCache for Memcached is a fast, in-memory caching service that is well-suited for managing session data. It offloads session management from the web server and reduces memory usage. - Scalability: Amazon RDS for MySQL is a fully managed service that automatically handles scaling and performance optimizations for the MySQL database, improving reliability and performance. - Improved performance: By using ElastiCache to handle session data, the web server can focus on rendering pages, and session data can be stored in a high-performance, low-latency cache. - Cons: - Complexity: Introducing both ElastiCache and RDS introduces some complexity in the architecture but provides significant benefits in performance and scalability. - Reason for Selection: This solution effectively addresses the core issue of managing session data separately from the application data. Using ElastiCache for session data allows the web servers to scale more efficiently, while RDS handles the application database, providing both performance improvements and scalability. ...

Author: Aria · Last updated May 18, 2026

An application uses Lambda functions to extract metadata from files uploaded to an S3 bucket; the metadata is stored in Amazon DynamoDB. The application starts behaving unexpectedly, and the developer wants to examine the logs of the Lambda...

In this scenario, the developer is looking for logs related to the behavior of Lambda functions. Let's analyze each option to determine where the Lambda logs can be found: Option A: Amazon S3 - Pros: S3 is the storage location for the uploaded files, but it does not handle Lambda function logs or errors directly. - Cons: S3 does not store logs generated by Lambda functions. It only stores files that are uploaded by the application. - Reason for Rejection: The logs related to Lambda function execution errors will not be found in S3. S3 is just the source of the files being processed, not where Lambda function logs are stored. Option B: AWS CloudTrail - Pros: CloudTrail logs API calls and events related to AWS services, including Lambda invocations. - Cons: While CloudTrail can provide logs of Lambda invocations (e.g., when the function was triggered), it does not capture detailed logs of Lambda function execution or errors (such as specific code errors or log outputs). - Reason for Rejection: CloudTrail is useful for tracking AWS service API calls but not for capturing detailed logs of the Lambda function's internal operations or errors. Option C: Amazon CloudWatch - Pros: AWS Lambda automatically integr...

Author: Ethan · Last updated May 18, 2026

A company is using an AWS Lambda function to process records from an Amazon Kinesis data stream. The company recently observed slow processing of the records. A developer notices that the iterator age metric for the function is increasing and that the Lambda run duration...

To increase the processing speed of an AWS Lambda function that is processing records from an Amazon Kinesis data stream, we should focus on improving the throughput of the Lambda function and its ability to process records faster. Let's go through each option and explain the reasoning behind selecting or rejecting each one. A) Increase the number of shards of the Kinesis data stream. - Reasoning: Kinesis data streams are divided into shards, and each shard can support a limited number of records per second. If the iterator age is increasing, it suggests that the Lambda function cannot process the records fast enough. By increasing the number of shards, more records can be processed concurrently, which would help the Lambda function process records faster and reduce the iterator age. - Selected: This is a good option because it increases the concurrency of the stream processing, allowing the Lambda function to consume and process more records in parallel. B) Decrease the timeout of the Lambda function. - Reasoning: Decreasing the timeout is not a viable solution to improving performance. In fact, reducing the timeout could cause the Lambda function to terminate prematurely, which would lead to more unprocessed records and a higher iterator age. The problem here is not the timeout but rather the function’s ability to process records quickly. - Rejected: This option would likely exacerbate the issue, so it is not a good choice. C) Increase the memory that is allocated to the Lambda function. - Reasoning: Increasing the memory allocated to a Lambda function can improve its processing speed. Lambda functions have a CPU allocation ...

Author: Max · Last updated May 18, 2026