Amazon Practice Questions, Discussions & Exam Topics by our Authors
A developer is creating an AWS Serverless Application Model (AWS SAM) template. The AWS SAM template contains the definition of multiple AWS Lambda functions, an Amazon S3 bucket, and an Amazon CloudFront distribution. One of the Lambda functions runs on Lambda@Edge in the CloudFront distribution. The S3 bucket is configured as an origin for the CloudFront distribution.
When...
Let's break down each option and see which one explains why the stack creation fails:
A) CloudFront distributions can be created only in the us-east-1 Region.
- Why it's not ideal:
- CloudFront is a global service and can be created in any AWS region. However, CloudFront distributions themselves are global, meaning they are not tied to a specific region, and their resources (like S3 origins) can reside in any region.
- So, this option is incorrect because CloudFront distributions are not limited to the us-east-1 region.
B) Lambda@Edge functions can be created only in the us-east-1 Region.
- Why it’s the correct option:
- Lambda@Edge functions must be created in the us-east-1 region because this is the only region where Lambda@Edge functions can be deployed. After being created in us-east-1, the function can then be associated with CloudFront distributions globally.
- The issue in the SAM template is likely that the Lambda function intended to run on Lambda@Edge was defined in the eu-west-1 region (or another region), causing the creation of the stack to fail. You need to c...
Author: Sara · Last updated Jul 14, 2026
A developer is integrating Amazon ElastiCache in an application. The cache will store data from a database. The cached data must populate real-time da...
To determine the best caching strategy for this scenario, we need to consider the characteristics of the data, how the cache will interact with the database, and how it will support real-time dashboards.
Key factors to consider:
1. Real-time dashboard requirements – The cached data must be up-to-date and accurately reflect the latest data from the database.
2. Cache population – The cache needs to be populated with data from the database and updated in a way that ensures data freshness.
3. Performance – The strategy should reduce load on the database and provide fast access to data for the dashboard.
Let's evaluate each option:
---
A) Read-through cache:
- How it works: The cache automatically loads data from the database when a cache miss occurs, and once the data is fetched, it's stored in the cache for future use.
- Advantages:
- Simplifies cache management.
- Ensures that the cache always has the most recent data when accessed, as it will always pull from the database on a cache miss.
- Disadvantages:
- This can introduce latency on a cache miss because data must be fetched from the database before the cache is populated.
Conclusion: While it simplifies cache management, the latency on cache misses may not be ideal for real-time dashboards.
---
B) Write-behind cache:
- How it works: Updates to the cache are written asynchronously to the database, usually in batches.
- Advantages:
- Improves write performance since writes to the cache are not immediately reflected in the database.
- Disadvantages:
- Not suitable for real-time scenarios where the data in the cache must always be in sync with the database.
- If the cache is updated, but the database write is delayed or fails, the data could become inconsistent.
Conclusion: Since the requirement is for real-time dashboards, write-behind cache is unsuitable as it can introduce delays and...
Author: Kai · Last updated Jul 14, 2026
A developer is creating an AWS Lambda function. The Lambda function needs an external library to connect to a third-party solution. The external library is a collection of files with a total size of 100 MB. The developer needs to make the external library available to the Lambda execution envir...
To determine the best solution, we need to consider key factors such as operational overhead, performance, and best practices for integrating external libraries into AWS Lambda.
Key factors to consider:
- Operational overhead: Minimizing the effort to configure, maintain, and manage the solution.
- Lambda deployment size: Lambda packages have a size limit (50 MB for direct uploads, 250 MB for deployment through Amazon S3), and large libraries need to be handled efficiently to fit within these limits.
- Execution time and efficiency: Solutions that allow Lambda functions to run quickly and efficiently are preferred.
Let's evaluate the options:
---
A) Create a Lambda layer to store the external library. Configure the Lambda function to use the layer.
- How it works: A Lambda layer is a distribution mechanism for libraries, custom runtimes, and other function dependencies. The external library can be packaged in the layer, which is then added to the Lambda function.
- Advantages:
- Least operational overhead: Once created, the layer can be reused across multiple Lambda functions. Lambda layers allow the external library to be stored separately from the function's code, reducing the deployment package size.
- Fits within Lambda's limits: Lambda layers can be up to 250 MB in size, allowing for the 100 MB library to be stored.
- Performance: Lambda layers are designed to be loaded efficiently and minimize function startup time.
- Disadvantages:
- The only operational overhead is creating and managing the layer, but this is minimal.
Conclusion: This is the most suitable option for the given scenario because it minimizes operational overhead, fits within Lambda's limits, and is designed specifically for this use case.
---
B) Create an Amazon S3 bucket. Upload the external library into the S3 bucket. Mount the S3 bucket folder in the Lambda function. Import the library by using the proper folder in the mount point.
- How it works: The external library is stored in an S3 bucket, and the Lambda function would access it from there by mounting the S3 bucket as a filesystem.
- Advantages:
- Scalability: S3 is highly scalable and can store large amounts of data.
- Disadvantages:
- Increased operational complexity: Lambda does not natively support mounting S3 buckets as a filesystem, so the developer would need to handle the library loading logic manually.
- Performance concerns: Accessing S3 directly introduces I/O latency, which could affect the Lambda function’s execution time.
- Not ideal for real-time access: Lambda functions would need to retrieve the library from S3 at runtime, which could result in slower star...
Author: IceDragon2023 · Last updated Jul 14, 2026
A company has a front-end application that runs on four Amazon EC2 instances behind an Elastic Load Balancer (ELB) in a production environment that is provisioned by AWS Elastic Beanstalk. A developer needs to deploy and test new application code while updating the Elastic Beanstalk platform from the current version ...
Let's evaluate each option based on the need to ensure zero downtime while deploying the new application code and updating the platform to a newer version of Node.js. We'll consider factors such as risk mitigation, downtime prevention, and testing flexibility:
Option A: Clone the production environment to a different platform version. Deploy the new application code, and test it. Swap the environment URLs upon verification.
- Pros: Cloning the environment creates an isolated testing environment, which ensures the production system remains unaffected. The environment can be tested without impacting the users.
- Cons: This approach involves managing two environments, which could be more resource-intensive. It also introduces some complexity in ensuring the new environment behaves identically to the production system.
- Risk: There's a potential for issues during the URL swap or configuration drift between the two environments, which could lead to downtime if not handled carefully.
- Suitability: This solution is ideal when you want to test the new platform and application code in isolation without affecting the production environment. However, it requires careful URL management and might not be the simplest solution.
Option B: Deploy the new application code in an all-at-once deployment to the existing EC2 instances. Test the code. Redeploy the previous code if verification fails.
- Pros: Simple to implement. Deploying the new code all at once is a quick way to apply changes.
- Cons: This approach introduces significant downtime during the update as the application will be unavailable until the new code is deployed and verified. If verification fails, there’s a need to roll back, which also creates a period of instability.
- Risk: This violates the zero-downtime requirement as it requires taking down the application while updating and testing. The "all-at-once" deployment can lead to user disruption.
- Suitability: Best for quick changes in non-production environments or where downtime is acceptable. Not suitable for production environments requiring zero downtime.
Option C: Perform an immutable update to deploy the new application code to new EC2 instances. Serve traffic ...
Author: Elijah · Last updated Jul 14, 2026
A developer is creating an AWS Lambda function. The Lambda function will consume messages from an Amazon Simple Queue Service (Amazon SQS) queue. The developer wants to integrate unit testing as part of the function's continuous i...
To determine the best way for a developer to unit test an AWS Lambda function consuming messages from an Amazon Simple Queue Service (SQS) queue as part of a CI/CD process, let's evaluate the options in terms of practicality, speed, and suitability for unit testing.
Key factors to consider:
1. Unit testing: The solution must focus on testing the logic of the Lambda function in isolation (unit tests should not require dependencies like live SQS queues, if possible).
2. CI/CD integration: The testing solution should be easily integrated into the CI/CD pipeline, running automatically as part of the process.
3. Test isolation: The solution should allow for independent testing without relying on live AWS resources (like SQS or Lambda) during unit testing.
4. Efficiency: The unit tests should be fast to run and not require full deployments of AWS infrastructure.
Evaluation of options:
---
A) Create an AWS CloudFormation template that creates an SQS queue and deploys the Lambda function. Create a stack from the template during the CI/CD process. Invoke the deployed function. Verify the output.
- How it works: This option involves using AWS CloudFormation to deploy both the Lambda function and the SQS queue, then invoking the function to verify its output.
- Advantages:
- Real environment testing: This ensures that the Lambda function works with real AWS resources (an actual SQS queue).
- Disadvantages:
- Not unit testing: This approach is more of an integration test, where the Lambda function is tested in a live environment rather than isolated from the SQS service.
- Slow and costly: Deploying resources during each CI/CD run can be time-consuming and incur additional AWS costs. It also doesn't focus on testing just the Lambda function's logic.
- Not suitable for fast unit testing: The goal is unit testing, not full-stack deployment testing.
Conclusion: This option is best suited for integration or end-to-end testing rather than unit testing. It introduces unnecessary complexity and overhead for unit tests.
---
B) Create an SQS event for tests. Use a test that consumes messages from the SQS queue during the function's CI/CD process.
- How it works: In this approach, the function consumes messages from an actual or mock SQS queue as part of the CI/CD process and tests the Lambda's logic.
- Advantages:
- Tests real Lambda behavior: The Lambda function consumes messages from SQS, similar to how it will work in production.
- Disadvantages:
- Not unit testing: Again, this is more of an integration test because the test depends on the actual SQS queue.
- External dependency: The test depends on an SQS queue, which means it introduces external dependencies and doesn't isolate the Lambda function for testing.
- Slower and more complex: Managing the SQS events and ensuring the Lambda function can consume the messages during testing adds unnecessary complexity and may increase test time.
Conclusion: This approach involv...
Author: Grace · Last updated Jul 14, 2026
A developer is working on a web application that uses Amazon DynamoDB as its data store. The application has two DynamoDB tables: one table that is named artists and one table that is named songs. The artists table has artistName as the partition key. The songs table has songName as the partition key and artistName as the sort key.
The table usage patterns include the retrieval of multiple songs and artists in a single database operat...
Let's evaluate each option based on the key requirements: retrieving multiple songs and artists in a single database operation with minimal network traffic and optimal performance.
A) Perform a BatchGetItem operation that returns items from the two tables. Use the list of songName/artistName keys for the songs table and the list of artistName key for the artists table.
- Pros:
- BatchGetItem allows you to retrieve multiple items from multiple tables in a single request, which is efficient and minimizes network traffic.
- This method allows you to use songName/artistName as composite keys for songs, and artistName for the artists table, efficiently retrieving data.
- This is an optimal solution for the requirement of reducing network traffic while still accessing both tables in one operation.
- Cons:
- No significant drawbacks in this case, as this option is designed to work for retrieving multiple items efficiently from multiple tables.
B) Create a local secondary index (LSI) on the songs table that uses artistName as the partition key. Perform a query operation for each artistName on the songs table that filters by the list of songName. Perform a query operation for each artistName on the artists table.
- Pros:
- LSI allows you to query by artistName, which can help in some cases where querying the songs by artistName is useful.
- Cons:
- Multiple queries per artist: This solution requires performing multiple query operations (one for each artistName), which leads to higher network overhead and complexity.
- Additional cost and complexity in maintaining the LSI and ensuring its correct usage.
- This is not as efficient as a BatchGetItem operation, as it requires multiple queries and more application logic.
C) Perform a BatchGetItem operation on the songs table that uses the songName/artistName keys. Perfor...
Author: CrimsonViperX · Last updated Jul 14, 2026
A company is developing an ecommerce application that uses Amazon API Gateway APIs. The application uses AWS Lambda as a backend. The company needs to test the code in a dedicated, monitored test environment before the company...
Let's break down each option based on the requirements:
1. Requirement: Test code in a dedicated, monitored test environment before releasing to production.
Option A: Use a single stage in API Gateway. Create a Lambda function for each environment. Configure API clients to send a query parameter that indicates the environment and the specific Lambda function.
- Problem with this option: Using a single stage does not differentiate between environments (test and production) and could lead to confusion or misrouting. While query parameters can specify the environment, this approach lacks control and does not leverage API Gateway's built-in features for environment segregation. Additionally, the routing would rely heavily on the client to send the correct query parameter, which introduces potential issues with reliability and security.
- Rejected for: Lack of structured environment isolation and potential for human error in environment selection.
Option B: Use multiple stages in API Gateway. Create a single Lambda function for all environments. Add different code blocks for different environments in the Lambda function based on Lambda environment variables.
- Problem with this option: A single Lambda function for all environments complicates the code management, as you would have to embed environment-specific logic within the Lambda code. This could lead to higher complexity in maintenance and testing since environment-specific logic and potential bugs would reside in the same function. Moreover, adding logic for environment determination can lead to harder-to-debug scenarios.
- Rejected for: Higher complexity, harder to test, and manage environment-specific code in a single Lambda function.
Option C: Use multiple stages in API Gateway. Create a Lambda function for each environ...
Author: IronLion88 · Last updated Jul 14, 2026
A developer creates an AWS Lambda function that retrieves and groups data from several public API endpoints. The Lambda function has been updated and configured to connect to the private subnet of a VPC. An internet gateway is attached to the VPC. The VPC uses the default network ACL and security group configurations.
The developer finds that the Lambda function can no longer access the publi...
Let's evaluate each option in relation to the situation where the Lambda function, which is configured to run inside a VPC (with a private subnet), can no longer access a public API.
Option A: Ensure that the network ACL allows outbound traffic to the public internet.
- Analysis: While the Network ACL (Access Control List) does control traffic at the subnet level, AWS Lambda functions in a private subnet cannot connect to the internet directly unless there is proper routing and a NAT solution in place. Even if the network ACL allows outbound traffic, the lack of a NAT gateway or an internet gateway (for a private subnet) would still prevent the Lambda function from reaching the public API. This option is necessary, but it alone wouldn't resolve the issue.
- Rejected for: Inadequate routing; outbound access alone isn't enough without proper NAT configuration for private subnets.
Option B: Ensure that the security group allows outbound traffic to the public internet.
- Analysis: The default security group for Lambda functions allows all outbound traffic by default. While this option sounds correct for controlling traffic, it doesn't address the core issue. The problem lies with the routing of traffic from the private subnet, which cannot connect to the public internet unless there is a NAT gateway or internet gateway to handle the traffic from private subnets.
- Rejected for: Lambda's default security group already allows outbound traffic, so the issue is not with security group configuration but with routing for private subnets.
Option C: Ensure that outbound traffic from the private subnet is routed to a public NAT gateway.
- Analysis: This option directly addresses the problem. A pri...
Author: Andrew · Last updated Jul 14, 2026
A developer needs to store configuration variables for an application. The developer needs to set an expiration date and time for the configuration. The developer wants to receive notifications before the configuratio...
Let's evaluate each option based on the requirements:
Key Requirements:
1. Store configuration variables.
2. Set an expiration date and time.
3. Receive notifications before expiration.
4. Minimize operational overhead.
Option A: Create a standard parameter in AWS Systems Manager Parameter Store. Set Expiration and ExpirationNotification policy types.
- Analysis: AWS Systems Manager Parameter Store allows you to store configuration parameters. However, standard parameters do not support expiration and notification policies. These features are only available for advanced parameters. Therefore, this option does not meet the requirements as it doesn't support setting an expiration with notifications for standard parameters.
- Rejected for: Standard parameters don’t support expiration or expiration notifications.
Option B: Create a standard parameter in AWS Systems Manager Parameter Store. Create an AWS Lambda function to expire the configuration and to send Amazon Simple Notification Service (Amazon SNS) notifications.
- Analysis: This option suggests using a Lambda function to handle expiration and notifications. While this is technically feasible, it introduces extra complexity and operational overhead. The developer would need to create, deploy, and maintain the Lambda function, configure the SNS notification, and manage the expiration logic. This increases the operational burden.
- Rejected for: Additional complexity with a Lambda function and manual management of expiration logic.
Option C: Create an advanced parameter in AWS Systems Manager Parameter Store. Set Expi...
Author: Siddharth · Last updated Jul 14, 2026
A company is developing a serverless application that consists of various AWS Lambda functions behind Amazon API Gateway APIs. A developer needs to automate the deployment of Lambda function code. The developer will deploy updated Lambda functions with AWS CodeDeploy. The deployment must minimize the exposure of potential errors to end users. When the application is in production, the applic...
Let's analyze each option with respect to the key requirements:
Key Requirements:
1. Automate Lambda function deployments: The developer is using AWS CodeDeploy to automate deployments.
2. Minimize exposure of potential errors to end users: This means controlling the traffic shift and minimizing the chance that users will experience issues due to deployment errors.
3. No downtime outside of the maintenance window: The deployment should happen within a specified maintenance window, meaning it should avoid causing disruptions to the production environment.
Option A: Use the AWS CodeDeploy in-place deployment configuration for the Lambda functions. Shift all traffic immediately after deployment.
- Analysis: With in-place deployment, CodeDeploy will replace the old version of the Lambda function with the new version and immediately shift all traffic to the new version. This might cause potential issues if there are errors in the new version because it exposes all users to the new function immediately, which increases risk.
- Rejected for: This option does not provide a safeguard against errors because all traffic is shifted at once. It also doesn't align with the requirement to minimize the exposure of errors to end users.
Option B: Use the AWS CodeDeploy linear deployment configuration to shift 10% of the traffic every minute.
- Analysis: Linear deployment shifts traffic incrementally (in this case, 10% every minute) to the new Lambda function. While this configuration minimizes the exposure to errors and allows for a more controlled rollout, it might still take time, especially if a large volume of traffic needs to be shifted (in this case, potentially 10 minutes or more to shift all traffic). This can lead to longer deployment times than necessary, which could be a problem if the company needs the deployment to complete quickly within the maintenance window.
- Rejected for: Although...
Author: Isabella · Last updated Jul 14, 2026
A company created four AWS Lambda functions that connect to a relational database server that runs on an Amazon RDS instance. A security team requires the company to automatically change the database...
Let's evaluate each option with respect to the security requirements of the scenario:
Key Requirements:
1. Automatically change the database password every 30 days.
2. Use the most secure solution.
3. Minimize operational overhead.
Option A: Store the database credentials in the environment variables of the Lambda function. Deploy the Lambda function with the new credentials every 30 days.
- Analysis: Storing credentials in environment variables is a common practice but can be insecure. Environment variables are stored in plaintext within the Lambda configuration and could be exposed if not handled carefully. Additionally, manually updating Lambda functions with new credentials every 30 days adds unnecessary operational overhead, requiring redeployment of Lambda functions.
- Rejected for: Lack of security for storing credentials in plaintext in environment variables and the operational overhead of redeploying Lambda functions every 30 days.
Option B: Store the database credentials in AWS Secrets Manager. Configure a 30-day rotation schedule for the credentials.
- Analysis: AWS Secrets Manager is a service specifically designed for managing and rotating sensitive information like database credentials. It provides automatic credential rotation and integrates seamlessly with other AWS services (e.g., RDS). You can configure Secrets Manager to automatically rotate credentials every 30 days with no manual intervention required. This solution ensures that the credentials are securely stored and automatically rotated, minimizing both security risks and operational overhead.
- Selected for: This option is the most secure and efficient solution. It leverages AWS's built-in rotation capabilities and minimizes operational overhead while securely managing database credentials.
Option C: Store the database credentials in AWS Systems Manager Paramet...
Author: CrystalWolfX · Last updated Jul 14, 2026
A developer is setting up a deployment pipeline. The pipeline includes an AWS CodeBuild build stage that requires access to a database to run integration tests. The developer is using a buildspec.yml file to configure the database connection. Company policy requires a...
Let's analyze each option:
A) Retrieve the credentials from variables that are hardcoded in the buildspec.yml file. Configure an AWS Lambda function to rotate the credentials.
- Why it's not the best option: Hardcoding credentials in the `buildspec.yml` file violates best practices for security. Storing sensitive information in source files can lead to unintentional exposure, especially if the repository is compromised. AWS Lambda can be used to rotate credentials, but this still doesn’t address the core issue of securely handling the credentials in the build pipeline.
- Security risk: Hardcoded credentials in the pipeline could be exposed to unauthorized personnel or services.
B) Retrieve the credentials from an environment variable that is linked to a SecureString parameter in AWS Systems Manager Parameter Store. Configure Parameter Store for automatic rotation.
- Why it's not the best option: AWS Systems Manager Parameter Store does support storing credentials securely with encryption, and automatic rotation is possible via Lambda, but it is not as seamless or optimized as AWS Secrets Manager when it comes to managing sensitive credentials like database passwords. Additionally, Parameter Store's rotation feature is more complex to implement compared to Secrets Manager.
- Security: SecureString encryption offers a high level of security, but for automatic and streamlined credential rotation, Secrets Manager is the better option.
C) Retrieve the credentials from an environment variable that is linked to an AWS Secrets Manager secret. Configure Secrets Manager for automatic rotation.
- Why this is the best option: AWS Secrets Manager is specifically designed for securely storing and rotating sensitive credentials, including database passwords. It supports automatic credential rotation without...
Author: IceDragon2023 · Last updated Jul 14, 2026
A company is developing a serverless multi-tier application on AWS. The company will build the serverless logic tier by using Amazon API Gateway and AWS Lambda.
While the company builds the logic tier, a developer who works on the frontend of the application must develop integration tests. The tests must cover both positive an...
Let's analyze the options based on the least effort, simplicity, and best practices.
A) Set up a mock integration for API methods in API Gateway. In the integration request from Method Execution, add simple logic to return either a success or error based on HTTP status code. In the integration response, add messages that correspond to the HTTP status codes.
- Why it's not the best option: This option leverages a mock integration in API Gateway, but it requires the developer to manually configure status codes and response messages in the API Gateway itself. It’s not ideal for testing real Lambda functions, as the mock integration doesn’t actually run the Lambda code or test any of the business logic.
- Security and Scalability: Mock integrations only simulate responses and do not test actual Lambda execution, making it unsuitable for testing real functionality.
B) Create two mock integration resources for API methods in API Gateway. In the integration request, return a success HTTP status code for one resource and an error HTTP status code for the other resource. In the integration response, add messages that correspond to the HTTP status codes.
- Why it's not the best option: Similar to option A, this involves using mock integrations. While separating success and error scenarios into different resources may provide more granularity, it still does not execute real Lambda functions or test the actual logic. It’s not a good fit for comprehensive integration testing.
- Scalability: This approach also lacks the flexibility needed for dynamic testing of Lambda functions, which are part of the actual application logic.
C) Create Lambda functions to perform tests. Add simple logic to return either success or error, based on the HTTP status codes. Build an API Gateway Lambda integration. Select appropriate Lambda functions that correspond to the HTTP status codes.
- Why it's not ...
Author: Leah Davis · Last updated Jul 14, 2026
Users are reporting errors in an application. The application consists of several microservices that are deployed on Amazon Elastic Container Service (Amazon ECS) with AWS Fargate.
Wh...
Let’s analyze the options and determine the best combination of steps for troubleshooting errors in a microservices application deployed on ECS using Fargate.
A) Deploy AWS X-Ray as a sidecar container to the microservices. Update the task role policy to allow access to the X-Ray API.
- Why it’s a good choice: Deploying AWS X-Ray as a sidecar container is a best practice for monitoring microservices running on ECS, particularly in serverless environments like Fargate. The sidecar container collects trace data from the application and sends it to X-Ray, providing end-to-end visibility of requests as they flow through the microservices.
- Reasoning: Updating the task role policy to allow X-Ray API access is essential to enable the ECS tasks to send trace data to X-Ray. This combination allows the developer to get detailed insights into the application, such as where errors are occurring.
- Advantages: This approach is well-suited for production environments with microservices running in containers, as it enables tracing without modifying the application code.
B) Deploy AWS X-Ray as a daemonset to the Fargate cluster. Update the service role policy to allow access to the X-Ray API.
- Why it’s not ideal: DaemonSets are a Kubernetes concept, and they are not applicable to Amazon ECS or AWS Fargate, which is not Kubernetes-based. Fargate uses containers without the need to manage nodes like you would in an Amazon EKS cluster.
- Reasoning: Since ECS does not use DaemonSets, this approach will not work for your ECS Fargate deployment. The concept of DaemonSets doesn't align with how Fargate manages infrastructure.
C) Instrument the application by using the AWS X-Ray SDK. Update the application to use the PutXrayTrace API call to communicate with the X-Ray API.
- Why it’s not the best choice: While instrumenting the application with the AWS X-Ray SDK is a useful step for custom tracing, directly using the PutXrayTrace API is not necessary. The X-Ray SDK automatically handles the communication with the X-Ray service and does not require manual API calls.
- Reasoning: This option involves more complex...
Author: Isabella · Last updated Jul 14, 2026
A developer is creating an application for a company. The application needs to read the file doc.txt that is placed in the root folder of an Amazon S3 bucket that is named DOC-EXAMPLE-BUCKET. The company=E2=80=99s security team requires the principle of least privilege to be...
To meet the principle of least privilege, the IAM policy for the application must grant only the necessary permissions to access the specific file `doc.txt` in the S3 bucket `DOC-EXAMPLE-BUCKET`. The principle of least privilege dictates that the application should be granted only the minimum permissions necessary to accomplish its task, which in this case is reading a specific file.
IAM Policy Statement Structure:
- The policy should allow `s3:GetObject` permission, which is needed to read the file from an S3 bucket.
- The policy should specifically target the file `doc.txt` in the bucket, rather than granting access to all objects in the bucket.
- The scope should be restricted to the `DOC-EXAMPLE-BUCKET` bucket and the specific object `doc.txt`.
Sample IAM Policy for Least Privilege:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/doc.txt"
}
]
}
```
Explanation of the Selected Option:
- Action: `s3:GetObject` is the necessary action to read an object from an S3 bucket...
Author: Evelyn · Last updated Jul 14, 2026
A company has an application that uses AWS CodePipeline to automate its continuous integration and continuous delivery (CI/CD) workflow. The application uses AWS CodeCommit for version control. A developer who was working on one of the tasks did not pull the most recent changes from the main branch. A week later, the develop...
To resolve the merge conflicts with the least development effort, let's evaluate each option:
A) Clone the repository. Create a new branch. Update the branch with the changes.
- Why this is not ideal: This option involves creating an entirely new branch and then manually bringing in the changes from the main branch. While this approach may work, it introduces unnecessary steps and a lot of manual work. The developer would have to copy over changes from the previous branch to the new one and resolve conflicts manually.
- Development Effort: This requires unnecessary rework and doesn't directly address the core issue of resolving the merge conflict in the original branch.
B) Create a new branch. Apply the changes from the previous branch.
- Why this is not ideal: This approach also creates a new branch and then attempts to apply the changes from the previous branch. This adds complexity, as it might not be a straightforward application of changes—there's a risk of missing or incorrectly applying changes, leading to errors. The main issue is that this approach doesn’t resolve the merge conflict directly in the existing branch.
- Development Effort: While it may resolve the issue, this method introduces more steps than necessary and doesn’t directly address the original merge conflict.
C) Use the Commit Visualizer view to compare the commits when a feature was added. Fix the merge conflicts.
- Why this is not ideal: The Commit Visualizer in AWS CodeCommit is useful for visualizing the history of commits, but it does not directly help in resolving merge conflicts. The pr...
Author: RadiantJaguar56 · Last updated Jul 14, 2026
A developer wants to add request validation to a production environment Amazon API Gateway API. The developer needs to test the changes before the API is deployed to the production environment. For the test, the developer will send test requests to the A...
The key factors for evaluating these options are:
1. Operational Overhead: The solution should involve minimal manual steps and resources to manage.
2. Testing Environment: The tests should not interfere with the production API, so they must be isolated.
3. Simplicity: The process should be simple and quick to implement.
Option A: Export the existing API to an OpenAPI file. Create a new API. Import the OpenAPI file. Modify the new API to add request validation. Perform the tests. Modify the existing API to add request validation. Deploy the existing API to production.
- Reason for Rejection: This approach requires the export and import of OpenAPI files, which adds complexity and time-consuming steps. Additionally, modifying the existing API post-testing introduces more steps than necessary.
- Scenario Use: This could be used if the goal was to completely redesign the API, but it’s more labor-intensive than necessary for simple validation testing.
Option B: Modify the existing API to add request validation. Deploy the updated API to a new API Gateway stage. Perform the tests. Deploy the updated API to the API Gateway production stage.
- Reason for Rejection: While this option creates a separate stage for testing, it involves modifying the live API, which could disrupt production. Having to test in a new stage before deploying to production adds operational o...
Author: Deepak · Last updated Jul 14, 2026
An online food company provides an Amazon API Gateway HTTP API to receive orders for partners. The API is integrated with an AWS Lambda function. The Lambda function stores the orders in an Amazon DynamoDB table.
The company expects to onboard additional partners. Some of the partners require additional Lambda functions to receive orders. The company has created an Amazon S3 bucket. The company needs to store ...
Key factors in evaluation:
1. Minimal Development Effort: The solution should minimize the need for additional coding or configuration.
2. Scalability: The solution should be capable of handling updates from multiple partners.
3. Efficiency: The solution should make use of existing AWS services to meet the requirements efficiently.
Option A: Create a new Lambda function and a new API Gateway API endpoint. Configure the new Lambda function to write to the S3 bucket. Modify the original Lambda function to post updates to the new API endpoint.
- Reason for Rejection: This option introduces unnecessary complexity. It requires creating a new API Gateway endpoint and modifying the existing Lambda function to interact with it, adding significant development overhead. It also doesn't align with the goal of minimal effort and scalability, especially as the company adds more partners.
- Scenario Use: This approach would be used if the API needed to handle complex or highly customizable interactions with multiple Lambda functions but is too complicated for this case.
Option B: Use Amazon Kinesis Data Streams to create a new data stream. Modify the Lambda function to publish orders to the data stream. Configure the data stream to write to the S3 bucket.
- Reason for Rejection: This option involves setting up a data stream (Kinesis), which adds unnecessary complexity for simply storing orders in S3. It introduces an extra service (Kinesis) for something that can be accomplished using DynamoDB Streams, which is more directly tied to the current system.
- Scenario Use: This could be considered for high-throughput systems that require more granular control over data fl...
Author: IceDragon2023 · Last updated Jul 14, 2026
A company=E2=80=99s website runs on an Amazon EC2 instance and uses Auto Scaling to scale the environment during peak times. Website users across the world are experiencing high latency due to static content on the EC2 instance, eve...
Key factors in evaluating the solution:
1. Reduce latency for static content: The solution should address the high latency due to static content.
2. Scalability: The solution should scale efficiently during peak and non-peak hours.
3. Cost-effective: The solution should be a feasible, cost-effective approach for handling static content.
Option A: Double the Auto Scaling groups maximum number of servers.
- Reason for Rejection: While increasing the number of EC2 instances could help during peak times, it doesn’t specifically address the high latency caused by static content. More servers may reduce load but will not necessarily help with the efficiency of delivering static content across the globe.
- Scenario Use: This could be helpful if the problem was due to CPU or memory bottlenecks but doesn't directly resolve static content delivery latency.
Option B: Host the application code on AWS Lambda.
- Reason for Rejection: While AWS Lambda is great for scaling backend processing, moving the application code to Lambda would require significant architectural changes and wouldn’t directly address static content latency. Lambda is not ideal for serving static assets like images, CSS, and JavaScript files.
- Scenario Use: This could be beneficial if the issue was related to backend processing or serverless architecture, but it doesn't resolve static content latency.
Option C: Scale vertically by resizing the EC2 instances.
- Reason for Rejection: Scaling vertically (i.e., resizing to larger EC2 instances) may not be the most efficient approach for static content. Larger instances might reduce load but won’t add...
Author: ElectricLionX · Last updated Jul 14, 2026
A company has an Amazon S3 bucket containing premier content that it intends to make available to only paid subscribers of its website. The S3 bucket currently has default permissions of all objects being private to prevent inadvertent exposure of the premier content to non-paying website vi...
Key factors in evaluating the solution:
1. Restrict access to paid subscribers only: The solution should ensure that only authenticated or authorized users (i.e., paid subscribers) can access the premier content.
2. Security: The solution should avoid exposing content to non-paying users while ensuring secure access for paying users.
3. Simplicity: The solution should be straightforward to implement and manage, particularly regarding access control.
Option A: Apply a bucket policy that allows anonymous users to download the content from the S3 bucket.
- Reason for Rejection: Allowing anonymous access to the bucket contradicts the requirement to restrict access to paid subscribers. This would expose the content to anyone, which is not what the company desires.
- Scenario Use: This option is unsuitable for scenarios where content must be protected and only available to specific users, such as paid subscribers.
Option B: Generate a pre-signed object URL for the premier content file when a paid subscriber requests a download.
- Selected Reason: A pre-signed URL is a secure way to allow time-limited access to a specific object in an S3 bucket. By generating a pre-signed URL when a paid subscriber requests a file, the company can provide exclusive access to the content without exposing it to non-subscribers. The pre-signed URL can also be customized to have an expiration, ensuring that access is temporary.
- Scenario Use: This approach is ideal for controllin...
Author: CrimsonViperX · Last updated Jul 14, 2026
A developer is creating an AWS Lambda function that searches for items from an Amazon DynamoDB table that contains customer contact information. The DynamoDB table items have the customer=E2=80=99s email_address as the partition key and additional properties such as customer_type, name and job_title.
The Lambda function runs whenever a user types a new character into the customer_type text input. The developer wants the search to return partia...
Key factors in evaluating the solution:
1. Partial Matching: The solution should allow partial matches of the `email_address` property.
2. No Table Redesign: The developer does not want to recreate the DynamoDB table.
3. Efficient Querying: The query should be efficient and work well with the given structure of the table.
4. DynamoDB Query Restrictions: The solution must adhere to DynamoDB’s query limitations, particularly with regard to partition and sort keys.
Option A: Add a global secondary index (GSI) to the DynamoDB table with customer_type as the partition key and email_address as the sort key. Perform a query operation on the GSI by using the `begins_with` key condition expression with the email_address property.
- Reason for Rejection: Using `begins_with` on the `email_address` in this configuration would not work effectively because DynamoDB’s `begins_with` condition only applies to the sort key, not to the partition key. The search would be limited to querying based on customer type, and partial matches for the `email_address` would not be easily achievable with this setup.
- Scenario Use: This setup may work for exact matches or simple prefix queries but does not meet the requirement of partial email matches.
Option B: Add a global secondary index (GSI) to the DynamoDB table with email_address as the partition key and customer_type as the sort key. Perform a query operation on the GSI by using the `begins_with` key condition expression with the email_address property.
- Reason for Rejection: This option suggests making `email_address` the partition key, which would result in a very high cardinality for the partition key (as each email address is likely to be unique). This could result in inefficient querying and data distribution across partitions. It would also not allow for querying based on `customer_type` in a straightforward manner.
- Scenario Use: This structure would be useful for looking up a specific email address but does not meet the need to filter ...
Author: Aarav · Last updated Jul 14, 2026
A developer is building an application that uses AWS API Gateway APIs, AWS Lambda functions, and AWS DynamoDB tables. The developer uses the AWS Serverless Application Model (AWS SAM) to build and run serverless applications on AWS. Each time the developer pushes changes for only to the Lambda functions, all the artifacts in the application are rebuilt.
The developer w...
Let's evaluate each command and its suitability for the task at hand:
1. A) sam deploy --force-upload
- Explanation: This command forces a re-upload of all the application artifacts, including Lambda functions, regardless of whether or not they have changed. It's useful when you need to force the upload of all components even if only one or a few functions have changed.
- Why it's rejected: This is not an efficient option when the goal is to only redeploy the Lambda functions that have changed, as it rebuilds and uploads all components, not just the Lambda functions.
- Scenario for use: This would be used when there is a need to force a complete redeployment of the whole application, regardless of changes.
2. B) sam deploy --no-execute-changeset
- Explanation: This command deploys the changes but doesn’t execute the change set, meaning it will prepare the deployment but will not apply the changes.
- Why it's rejected: While useful in some scenarios, this command doesn't solve the problem of deploying only the changed Lambda functions; it prevents the execution of any deployment changes, including Lambda functions, so it is not relevant to the scenario.
- Scenario for use: This would be used when you want to inspect the changes before actually applying them to your environment.
3. C) sam package...
Author: FrozenWolf2022 · Last updated Jul 14, 2026
A developer is building an application that gives users the ability to view bank accounts from multiple sources in a single dashboard. The developer has automated the process to retrieve API credentials for these sources. The process invokes an AWS Lambda function that is associated with an AWS CloudFormation custom resource.
The developer wants a...
Let's evaluate each option to determine the best solution based on security, operational overhead, and how it aligns with the developer's requirements.
A) Add an AWS Secrets Manager GenerateSecretString resource to the CloudFormation template. Set the value to reference new credentials for the CloudFormation resource.
- Explanation: AWS Secrets Manager is designed to securely store, manage, and rotate secrets such as API credentials. It integrates seamlessly with other AWS services and provides built-in security features such as encryption at rest, access control, and automated secret rotation.
- Why it's selected: This option offers the most secure and efficient solution for storing API credentials, as Secrets Manager is purpose-built for this task. It minimizes operational overhead with built-in features like automatic credential rotation and secure access control. It also supports CloudFormation and can be directly referenced within the template.
- Scenario for use: This is ideal when you need a highly secure, scalable, and easy-to-manage solution for storing API credentials with minimal operational overhead.
B) Use the AWS SDK ssm:PutParameter operation in the Lambda function from the existing custom resource to store the credentials as a parameter. Set the parameter value to reference the new credentials. Set the parameter type to SecureString.
- Explanation: This solution involves using AWS Systems Manager Parameter Store with the SecureString type to store the API credentials. SecureString provides encryption at rest using AWS Key Management Service (KMS).
- Why it's rejected: While this approach is secure, it doesn't provide the same level of operational management features as Secrets Manager, such as automatic rotation. Parameter Store is suitable for storing sensitive information, but Secrets Manager is a more specialized service for secret management.
- Scenario for use: This option is suitable if you only need basic secret management without the additional features like automated rotation and advanced access controls provided by Secrets Manager.
C) Add an AWS Systems Manager Parameter Store resource to the CloudFormation template. Set the CloudFormation resource value to reference the new credenti...
Author: Scarlett · Last updated Jul 14, 2026
A developer is trying to get data from an Amazon DynamoDB table called demoman-table. The developer configured the AWS CLI to use a specific IAM user=E2=80=99s credentials and ran the following command:
aws dynamodb get-item --table-name demoman-table --key '{"id": {"N"...
Let's analyze each option carefully to determine the most likely cause of the issue:
A) The command is incorrect; it should be rewritten to use put-item with a string argument.
- Explanation: The `get-item` command is correctly used to retrieve data from a DynamoDB table. The error is not because of using the wrong command (`put-item` is used for adding items to a table, while `get-item` is correct for retrieving data).
- Why it's rejected: The `get-item` command is correct in the context, so this option is not valid.
- Scenario for use: This would be applicable if the developer mistakenly used `put-item` instead of `get-item` but this is not the case here.
B) The developer needs to log a ticket with AWS Support to enable access to the demoman-table.
- Explanation: While AWS Support can help with troubleshooting, the issue is most likely not with enabling access to the table, but with the IAM permissions associated with the IAM user performing the operation. The IAM user could lack the necessary permissions to perform the `get-item` action on the DynamoDB table.
- Why it's rejected: It’s unlikely that access needs to be explicitly "enabled" from AWS Support. This is more of a permissions issue that can be resolved by adjusting IAM policies.
- Scenario for use: This would be relevant if there were a service outage or an unusual issue with the AWS account itself, but it’s more likely related to IAM permissions.
C) Amazon DynamoDB cannot be accessed from the AWS CLI and needs to be called via the REST API.
- Explanation: This is incorrect because Amazon Dyna...
Author: Benjamin · Last updated Jul 14, 2026
An organization is using Amazon CloudFront to ensure that its users experience low-latency access to its web application. The organization has identified a need to encrypt all traffic between users and CloudFront, and all traff...
To meet the organization's requirement to encrypt all traffic between users and CloudFront, and between CloudFront and the web application, we need to consider the appropriate methods to enforce encryption in both directions. Let’s evaluate each option:
A) Use AWS KMS to encrypt traffic between CloudFront and the web application.
- Explanation: AWS KMS (Key Management Service) is used to manage encryption keys for encrypting data at rest and in transit. However, KMS itself doesn’t directly encrypt traffic between CloudFront and the origin. Traffic encryption in this case is handled by using HTTPS rather than using KMS directly.
- Why it's rejected: This option is not directly applicable for encrypting traffic between CloudFront and the web application, as encryption is managed through the protocol (HTTPS) rather than KMS.
- Scenario for use: This could be used to encrypt data at rest (such as in S3 buckets or databases) but not directly for encrypting transit traffic.
B) Set the Origin Protocol Policy to "HTTPS Only".
- Explanation: The Origin Protocol Policy is used to control how CloudFront communicates with your origin. By setting it to "HTTPS Only", CloudFront will always use HTTPS to fetch content from the web application (origin). This ensures that the traffic between CloudFront and the web application is encrypted.
- Why it's selected: This ensures that the communication between CloudFront and the web application is encrypted via HTTPS, meeting the requirement for encrypting traffic between CloudFront and the web application.
- Scenario for use: This is appropriate when you want to ensure encrypted communication between CloudFront and the origin.
C) Set the Origins HTTP Port to 443.
- Explanation: The HTTP port of 443 corresponds to HTTPS traffic, which is encrypted. However, simply setting the port does not enforce encryption; you also need to ensure that CloudFront is configured to use HTTPS (by setting the Origin Protocol Policy).
- Why it's rejected: This setting alone does not guarantee encrypted tr...
Author: Zain · Last updated Jul 14, 2026
A developer is planning to migrate on-premises company data to Amazon S3. The data must be encrypted, and the encryption keys must support automatic annual rotation. The company must use AWS Key Management Service (AWS KMS)...
To meet the requirements of encrypting data in Amazon S3 with AWS Key Management Service (AWS KMS) and ensuring that the encryption keys support automatic annual rotation, let's analyze the options:
A) Amazon S3 managed keys
- Explanation: Amazon S3 managed keys (SSE-S3) are simple to use because S3 handles the encryption and key management automatically. However, SSE-S3 keys are not associated with KMS, and thus they do not provide the capability for key rotation via AWS KMS. They are suitable for basic encryption needs, but they do not meet the requirement for key rotation via KMS.
- Why it's rejected: This option does not provide automatic key rotation with KMS. Therefore, it does not meet the requirement of having encryption keys that support automatic annual rotation.
- Scenario for use: This would be useful for simpler use cases where key management and rotation are not a concern.
B) Symmetric customer managed keys with key material that is generated by AWS
- Explanation: Symmetric customer managed keys with key material generated by AWS are ideal for encrypting data in Amazon S3 with AWS KMS. These keys can be automatically rotated by AWS every year (as long as the automatic rotation is enabled in KMS). This option allows the developer to have full control over key usage and provides automatic rotation.
- Why it's selected: This option meets all the requirements: the data will be encrypted using AWS KMS, and the keys can be automatically rotated annually by AWS. It fits perfectly with the requirement for automatic key rotation and strong encryption.
- Scenario for use: This is the recommended approach when you need AWS to handle key material creation, encryption, and automatic rotation.
C) Asymmetric customer managed keys with key material that is generated by AWS
- Explanation: Asymmetric keys in KMS are used for public and private key pairs, where the private key is used to decrypt data, and the public key is used for e...
Author: Layla · Last updated Jul 14, 2026
A team of developers is using an AWS CodePipeline pipeline as a continuous integration and continuous delivery (CI/CD) mechanism for a web application. A developer has written unit tests to programmatically test the functionality of the application code. The unit tests produce a test report that shows the results of each individual check. The develop...
Let's analyze each option based on operational effort, integration simplicity with AWS CodePipeline, and the overall CI/CD flow:
Option A: Git Pre-commit Hook
- Description: The tests are run before each commit, requiring each developer to install a pre-commit hook locally. Developers review the test report and resolve any issues before pushing the changes to AWS CodeCommit.
- Key Issues:
- Local Dependency: This requires developers to configure and maintain the pre-commit hook locally. This adds complexity because it introduces the need for consistent setup on each developer's machine.
- Inconsistent Execution: Not all developers may remember to run the tests before committing, leading to potential integration issues.
- Lack of Integration: It doesn’t integrate well with AWS CodePipeline, as the tests are not run within the pipeline itself. This can lead to gaps where the pipeline doesn’t automatically check test results as part of its flow.
Rejected because: The operational effort is high, and it doesn't fit neatly within the automated CI/CD pipeline workflow.
Option B: CodeBuild Stage After Deployment to Test Environment
- Description: Add a CodeBuild stage after the deployment stage to run unit tests. If any test fails, the CodeBuild stage fails, and the test report is integrated into CodeBuild’s console.
- Key Issues:
- Execution Flow: This would mean that tests are run after the deployment to the test environment, which is not ideal. Any issues found in tests will already be in the deployed test environment, which could waste time and resources.
- Operational Overhead: There is additional effort required to troubleshoot and fix issues after deployment. This leads to potential delays in the pipeline.
Rejected because: The tests should ideally be run before deploying to the test environment to catch issues early, avoiding the unnecessary deployment of faulty code.
Option C: CodeBuild Stage Before Deployment to Test Environment
- Description: Add a CodeBuild stage before the deployme...
Author: Ravi Patel · Last updated Jul 14, 2026
A company has multiple Amazon VPC endpoints in the same VPC. A developer needs to configure an Amazon S3 bucket policy so users can access an S3 bucket only by usi...
Let's analyze each option based on the requirement to restrict access to the S3 bucket only through specific VPC endpoints:
Option A: Create multiple S3 bucket policies by using each VPC endpoint ID that have the `aws:SourceVpce` value in the `StringNotEquals` condition.
- Description: This would involve creating multiple policies, each corresponding to a specific VPC endpoint. The policy would use the `aws:SourceVpce` condition key to limit access to specific VPC endpoints.
- Key Issues:
- Overcomplication: Managing multiple bucket policies increases complexity, as each VPC endpoint would require its own policy, and it would be difficult to maintain if the number of VPC endpoints changes or grows.
- Operational Effort: Adding new VPC endpoints would require the creation of additional policies.
Rejected because: The approach introduces complexity with multiple policies, making it harder to manage as the number of VPC endpoints grows.
Option B: Create a single S3 bucket policy that has the `aws:SourceVpc` value and in the `StringNotEquals` condition to use VPC ID.
- Description: This policy would restrict access based on the VPC ID, not the VPC endpoint ID. The `aws:SourceVpc` condition allows access only from a specific VPC.
- Key Issues:
- Incorrect Condition Key: The requirement is to restrict access by VPC endpoints, not by the VPC itself. The `aws:SourceVpc` condition key refers to the VPC, not the VPC endpoint. This would allow traffic from any source within the specified VPC, not necessarily from the endpoints.
Rejected because: The `aws:SourceVpc` condition is incorrect in this scenario, as it applies to the VPC and not the VPC endpoi...
Author: Isabella1 · Last updated Jul 14, 2026
A company uses a custom root certificate authority certificate chain (Root CA Cert) that is 10 KB in size to generate SSL certificates for its on-premises HTTPS endpoints. One of the company=E2=80=99s cloud-based applications has hundreds of AWS Lambda functions that pull data from these endpoints. A developer updated the trust store of the Lambda execution environment to use the Root CA Cert when the Lambda execution environment is initialized. The developer bundled the Root CA Cert as a text file in the Lambda deployment bundle.
After 3 months of development, the Root CA Cert is no longer valid and must be updated. The developer needs a more efficient solution to update the Root CA Cert for all deployed Lambda functions. The solution must not include re...
Let’s break down the options based on the requirement to efficiently update the Root CA Cert for all deployed Lambda functions without rebuilding or updating the Lambda functions themselves:
Option A: Store the Root CA Cert as a secret in AWS Secrets Manager. Create a resource-based policy. Add IAM users to allow access to the secret.
- Description: Storing the Root CA Cert in Secrets Manager would allow centralized management and retrieval of the certificate, and it could be easily updated when needed. A resource-based policy could control access to the secret.
- Key Issues:
- Not Ideal for Lambda: Although Secrets Manager is useful for sensitive data like API keys or database passwords, it isn't optimized for certificates. Additionally, pulling the certificate from Secrets Manager at runtime would require additional Lambda function logic and can introduce more overhead in terms of secret retrieval and managing the access permissions.
- Complexity: Secrets Manager is not ideal for certificates, and adding complex IAM permissions for Lambda to access the secret might add unnecessary operational overhead.
Rejected because: While possible, this approach is less cost-effective and slightly more complex than other options.
Option B: Store the Root CA Cert as a SecureString parameter in AWS Systems Manager Parameter Store. Create a resource-based policy. Add IAM users to allow access to the policy.
- Description: Storing the Root CA Cert in Systems Manager Parameter Store is another viable option. You can store the certificate as a SecureString, ensuring that the certificate is stored securely. Access control can be managed with IAM policies, and Lambda functions can fetch the certificate as needed.
- Key Issues:
- Relatively Simple: Systems Manager Parameter Store is cost-effective, supports versioning, and integrates seamlessly with Lambda. It's a good choice for managing smaller configuration items like certificates.
- Retrieval: The Lambda function would need to pull the certificate at runtime, which may introduce latency. However, it’s more straightforward than Secrets Manager and better suited for configuration data like certificates.
Selected because: This is a cost-effective and straightforward solution for managing certificates in a secure and centralized way, with easy updates without requiring Lambda function redeployment.
Option C: Store the Root CA Cert in an Amazon S3 bucket. Create a resource-based policy to allow access to the bucket.
- Description: You could store the Root CA Cert in S3, using a resource-based policy to control access.
- Key Issues:
- R...
Author: Leah · Last updated Jul 14, 2026
A developer maintains applications that store several secrets in AWS Secrets Manager. The applications use secrets that have changed over time. The developer needs to identify required secrets that are still in use. The developer does n...
To determine which approach the developer should take, let’s analyze each option in detail based on the requirement of identifying which secrets are still in use without causing application downtime.
Option A: Configure an AWS CloudTrail log file delivery to an Amazon S3 bucket. Create an Amazon CloudWatch alarm for the GetSecretValue Secrets Manager API operation requests.
- Reasoning:
- CloudTrail logs track every API call, including `GetSecretValue` requests made to AWS Secrets Manager. By configuring an alarm on these logs, the developer can identify which secrets are being accessed over time.
- Non-intrusive: This option does not affect the applications because it only involves logging and monitoring API calls.
- Pro: It provides visibility into which secrets are accessed by applications and allows tracking over time.
- Con: Requires setting up proper CloudWatch metrics and alarms, but no application downtime occurs.
- Best Use Case: This option is ideal for identifying secrets in use across different applications and services, especially when you want to ensure that no application downtime occurs.
Option B: Create a secretsmanager-secret-unused AWS Config managed rule. Create an Amazon EventBridge rule to initiate notifications when the AWS Config managed rule is met.
- Reasoning:
- AWS Config manages configuration compliance but may not be ideal for directly tracking API usage like `GetSecretValue`. AWS Config does not specifically monitor how secrets are accessed or utilized in real time.
- Pro: AWS Config provides compliance checks, but it is more focused on resource configurations rather than the runtime behavior of applications.
- Con: This rule would not directly track usage of secrets in terms of API requests. This would not give real-time insights into which secrets are still being accessed.
- Best Use Case: AWS Config can be useful for configuration compliance, but it’s less suitable for tracking real-time API operations related to secret access.
Option C: Deactivate the appli...
Author: Isabella1 · Last updated Jul 14, 2026
A developer is writing a serverless application that requires an AWS Lambda function to be invoked every 10 minutes.
What is ...
Let’s evaluate each option for the goal of invoking a Lambda function every 10 minutes in an automated and serverless manner:
Option A: Deploy an Amazon EC2 instance based on Linux, and edit its /etc/crontab file by adding a command to periodically invoke the Lambda function.
- Description: This option involves deploying an EC2 instance, using a cron job to invoke the Lambda function periodically.
- Key Issues:
- Not Serverless: This option requires managing an EC2 instance, which contradicts the serverless requirement of the application. EC2 introduces operational overhead, such as patching, scaling, and managing the instance.
- Inefficient: It’s not automated in a way that scales with the serverless architecture. Additionally, there would be extra cost and complexity from the EC2 instance itself.
Rejected because: It’s not serverless and adds unnecessary overhead in terms of managing EC2 instances.
Option B: Configure an environment variable named PERIOD for the Lambda function. Set the value to 600.
- Description: This option suggests setting an environment variable that specifies a timer for the Lambda function.
- Key Issues:
- Not a valid invocation method: Lambda does not have a native feature that would allow it to periodically invoke itself based on environment variables. Environment variables are typically used to store configuration data and not for scheduling events or actions.
Rejected because: Lambda environment variables do not provide functionality for automated invocation at scheduled intervals.
Option C: Create an Amazon EventBridge rule that runs on a regular schedule to invoke the Lambda function.
- Description: Amazon EventBridge allows for the creation of rules based on a schedule (cron expressions or rate expressions), whic...
Author: Max · Last updated Jul 14, 2026
A company is using Amazon OpenSearch Service to implement an audit monitoring system. A developer needs to create an AWS CloudFormation custom resource that is associated with an AWS Lambda function to configure the OpenSearch Service domain. The Lambda function must access the OpenSearch Service domain by usin...
To select the most secure way to pass the OpenSearch Service domain’s internal master user credentials to the Lambda function, we must consider the security of storing, passing, and retrieving the credentials. Below, I will evaluate each option:
Option A:
- Approach: Pass the master user credentials using a CloudFormation parameter and set the NoEcho attribute to `true` so the value isn't shown in the CloudFormation logs.
- Analysis:
- While NoEcho prevents the parameter from being displayed in the logs, the credentials are still passed directly to the Lambda function as part of its environment variables. This means that the credentials will be available to anyone who has access to the Lambda environment, potentially exposing the credentials.
- Security Risk: Credentials are directly in the Lambda environment variables, and environment variables can be easily accessed by anyone who has sufficient access to the Lambda function, including through logs or other unintended means.
Option B:
- Approach: Use CloudFormation to pass credentials to OpenSearch Service's MasterUserOptions and also store them in AWS Systems Manager (SSM) Parameter Store, with encryption enabled. An IAM role with the `ssm:GetParameter` permission is granted to the Lambda function, and the parameter name is passed to the Lambda function as an environment variable to resolve at runtime.
- Analysis:
- Using SSM Parameter Store with encryption (via KMS) for storing sensitive data is a good practice because it allows fine-grained access control and the data can be encrypted in transit and at rest.
- However, SSM Parameter Store is generally not as specialized for secret management as AWS Secrets Manager, and it lacks some advanced features, like automatic rotation of credentials.
- Security Risk: While this is better than Option A, it still involves passing sensitive credentials as an environment variable to the Lambda function, albeit via a parameter store, which increases the overall security but is not as ideal as Secrets Manager.
Option C:
-...
Author: Sam · Last updated Jul 14, 2026
An application runs on multiple EC2 instances behind an ELB.
Where is the session data best written so that it...
When deciding where session data should be stored in an application running on multiple EC2 instances behind an ELB (Elastic Load Balancer), we need to consider factors such as reliability, scalability, persistence, and accessibility across all instances. Here's the analysis of each option:
Option A: Write data to Amazon ElastiCache
- Approach: ElastiCache is a managed in-memory data store (such as Redis or Memcached), optimized for quick retrieval and persistence of session data.
- Analysis:
- Scalability: ElastiCache is designed to handle large amounts of data and traffic, making it ideal for applications running on multiple EC2 instances. It scales easily to accommodate traffic spikes and the need for high availability.
- Reliability: Since it is a distributed service, the session data is accessible by any EC2 instance, ensuring session consistency even if traffic is directed to different instances.
- Performance: Being an in-memory store, ElastiCache offers low-latency and high-throughput, making it very efficient for session data storage.
- Use case: This is the best solution for session data when running applications on multiple EC2 instances behind a load balancer, as it ensures data is consistently accessible to all instances.
Option B: Write data to Amazon Elastic Block Store (EBS)
- Approach: EBS provides block-level storage that can be attached to EC2 instances. Data stored here persists even after instance termination.
- Analysis:
- Scalability: EBS volumes are attached to specific EC2 instances, meaning that only the instance to which the volume is attached can access the data. This creates problems in a load-balanced setup, as session data would not be available to other EC2 instances if the request is routed to a different instance.
- Reliability: While EBS is durable and persistent, it is not suitable for shared access across multiple EC2 instances unless using networked file systems (like EFS), but even then, it's not ideal for session data due to performance concerns.
- Use case: EBS is not appropriate for session data storage in a load-balanced environment because it requi...
Author: Rohan · Last updated Jul 14, 2026
An ecommerce application is running behind an Application Load Balancer. A developer observes some unexpected load on the application during non-peak hours. The developer wants to analyze patterns for the client IP addre...
In order to analyze the client IP addresses that are making requests to your application, the developer should focus on the HTTP header that contains the client’s original IP address. Below is the analysis of each option:
Option A: The X-Forwarded-Proto header
- Purpose: This header indicates the protocol (HTTP or HTTPS) that the client used to connect to the load balancer.
- Relevance: The X-Forwarded-Proto header does not provide any information about the client's IP address. It only reflects the protocol used in the original request, which is not useful for analyzing client IPs.
- Use case: This header is useful when you need to determine if the original request was over HTTP or HTTPS, but it does not help in tracking client IPs.
Option B: The X-Forwarded-Host header
- Purpose: This header shows the original host header from the client, which is typically the domain name that the client requested.
- Relevance: The X-Forwarded-Host header contains the original host information (e.g., the domain name), but it doesn't contain any client IP address information.
- Use case: This header is useful when you need to identify the host that the client initially intended to connect to, but it doesn't provide client IP addresses for load analysis.
Option C: The X-Forwarded-For header
- Purpose: This header contains the originating IP address of the client making the request to the Application Load Balancer (ALB), fo...
Author: Liam · Last updated Jul 14, 2026
A developer migrated a legacy application to an AWS Lambda function. The function uses a third-party service to pull data with a series of API calls at the end of each month. The function then processes the data to generate the monthly reports. The function has been working with no issues so far.
The third-party service recently issued a restriction to allow a fixed number of API calls each minute and each day. If the API calls exceed the limit for each minute or each day, then the service will produce errors. The API also provides the minute limit and daily limit in the response header....
In this case, the application needs to manage API calls efficiently to ensure that the total number of API calls does not exceed the fixed limits set by the third-party service. The developer wants to refactor the serverless application to make sure the API calls stay within the service's minute and daily limits, while also ensuring that the process is efficient and operationally manageable. Here's a breakdown of the options:
Option A: Use an AWS Step Functions state machine to monitor API failures. Use the Wait state to delay calling the Lambda function.
- Approach: AWS Step Functions can be used to create workflows with delays (using the Wait state) between Lambda function invocations, allowing the process to adhere to the API's rate limits.
- Analysis:
- Scalability and Efficiency: Step Functions are well-suited to managing complex workflows. The Wait state can pause execution until the minute or daily API call limit is reset, but this could lead to inefficiencies if the process spans several days.
- Operational Overhead: Although effective for sequential workflows, Step Functions might introduce some complexity in monitoring API call failures, especially if there are multiple retries, delays, and conditional logic. This option also requires careful management of the state machine and could result in long delays between retries.
- Use Case: This option is useful if the developer needs strict sequential control over Lambda invocations and if the workflow needs to pause and resume based on the API limits. However, it's more complex compared to other solutions.
Option B: Use an Amazon Simple Queue Service (Amazon SQS) queue to hold the API calls. Configure the Lambda function to poll the queue within the API threshold limits.
- Approach: SQS can hold the API calls as messages, and the Lambda function can poll the queue. The API call rate can be controlled by adjusting the rate at which Lambda pulls from the queue.
- Analysis:
- Scalability: SQS is highly scalable and can manage large queues of API calls. By controlling the Lambda function's polling rate, you can ensure the API call limits are respected, as Lambda will only process a limited number of calls per minute or day.
- Operational Efficiency: This approach decouples the process, allowing the Lambda function to process calls at a controlled rate. It efficiently manages the API limits without needing complex workflows.
- Use Case: This is an efficient and scalable solution that balances the need to stay within API rate limits and manage execution without introducing significant delays. It's suitable when you want to ensure...
Author: Lucas Carter · Last updated Jul 14, 2026
A developer must analyze performance issues with production-distributed applications written as AWS Lambda functions. These distributed Lambda applications invoke other components that make up the applications.
How should...
To troubleshoot the root cause of performance issues in distributed AWS Lambda applications, we need a solution that provides detailed insights into the performance of Lambda functions and their interactions with other components. Below is an analysis of each option:
Option A: Add logging statements to the Lambda functions, then use Amazon CloudWatch to view the logs.
- Approach: Adding logging statements inside the Lambda functions would allow tracking of specific events, errors, or performance metrics. These logs can then be viewed using Amazon CloudWatch.
- Analysis:
- Limitations: While CloudWatch logs are useful for basic debugging and seeing what happens within a function (such as tracing specific variables or errors), they do not provide a comprehensive view of how Lambda functions interact with other services, nor do they show performance issues related to the execution time, latencies, or distributed tracing.
- Scalability: In a distributed application with multiple Lambda functions invoking other services, CloudWatch logs can become cumbersome and hard to correlate without additional context.
- Use Case: This approach might be useful for simple troubleshooting or tracking individual Lambda function performance, but it does not offer deep visibility into distributed interactions.
Option B: Use AWS CloudTrail and then examine the logs.
- Approach: CloudTrail provides API activity logs for AWS services, which can be useful for auditing and tracking AWS resource interactions.
- Analysis:
- Limitations: CloudTrail logs focus on AWS API calls and resource activity, not on performance metrics or tracing the execution of Lambda functions and their downstream services. It doesn't offer visibility into Lambda-specific performance characteristics, like execution duration or internal errors.
- Use Case: CloudTrail is useful for auditing purposes (e.g., tracking when API calls were made), but it does not provide performance insights necessary for identifying the root cause of Lambda function issues in production.
Option C: Use AWS X-Ray, then examine the segments and errors.
- Approach: AWS X-Ray provides end-to-end tracing for requests as they flow through various ser...
Author: Isabella · Last updated Jul 14, 2026
A developer wants to deploy a new version of an AWS Elastic Beanstalk application. During deployment, the application must maintain full capacity and avoid service interruption. Additionally, the developer must minimize the cost of additional resources...
To meet the requirements of maintaining full capacity, avoiding service interruption, and minimizing the cost of additional resources during an AWS Elastic Beanstalk deployment, we should carefully analyze the available deployment methods:
Option A: All at once
- Pros: Simple and quick deployment.
- Cons: This option is not suitable for maintaining full capacity or avoiding service interruptions. When the deployment happens "all at once," the existing instances are replaced, which causes downtime, making it unsuitable for high availability.
- Use Case: This might be used in situations where downtime is acceptable, or the application is not mission-critical.
- Rejected because: It does not maintain full capacity or avoid downtime.
Option B: Rolling with additional batch
- Pros: Allows the deployment to be done in batches, ensuring that a part of the application remains active while the deployment occurs. It also includes the option to add a batch of extra instances, reducing the likelihood of downtime or capacity loss.
- Cons: It can incur additional costs due to the extra instances required to maintain full capacity during deployment. The extra batch is used only during deployment.
- Use Case: This method is a good choice when there’s a need to keep the application running during the deployment but may cause some cost overhead due to the additional resources.
- Rejected because: While it maintains capacity and minimizes service disruption, the additional cost may be higher than necessary for certain applications where other methods could achieve similar goals.
Option C: Blue/Green
- Pros: The Blue/Green deployment method involves running two environments—one for the current version (Blue) and one for the new version (Green). It ensures there is zero downtime because traffic can be switched between the two environments, allowing you to keep the old environment running while the new one is deployed. Once the...
Author: Krishna · Last updated Jul 14, 2026
A developer has observed an increase in bugs in the AWS Lambda functions that a development team has deployed in its Node.js application. To minimize these bugs, the developer wants to implement automated testing of Lambda functions in an environment that closely simulates the Lambda environment.
The developer needs to give other developers the ability to run the tests locally. The developer also needs to integrate the tests into t...
Let's analyze each of the options based on the requirements:
The developer needs:
- To simulate the Lambda environment locally.
- To allow other developers to run tests locally.
- To integrate the tests into the CI/CD pipeline before the AWS CDK deployment.
Option A: Create sample events based on the Lambda documentation. Create automated test scripts that use the cdk local invoke command to invoke the Lambda functions. Check the response. Document the test scripts for the other developers on the team. Update the CI/CD pipeline to run the test scripts.
- Pros: Using the `cdk local invoke` command would allow local invocation of Lambda functions. The test scripts can be shared easily across developers and the CI/CD pipeline can invoke them.
- Cons: The `cdk local invoke` command does not provide a perfect simulation of the Lambda environment. It could be limited in mimicking the actual Lambda runtime, and developers may need to manually set up and configure testing environments, which can lead to inconsistencies.
- Use Case: This option could be used, but it’s not the most efficient approach as it may not provide a complete simulation of the Lambda environment.
Option B: Install a unit testing framework that reproduces the Lambda execution environment. Create sample events based on the Lambda documentation. Invoke the handler function by using a unit testing framework. Check the response. Document how to run the unit testing framework for the other developers on the team. Update the CI/CD pipeline to run the unit testing framework.
- Pros: Unit testing frameworks, such as Jest or Mocha, can provide a clean environment for testing Lambda functions. They are simple to set up and can be integrated with existing test tools.
- Cons: Unit testing frameworks may not closely reproduce the Lambda environment. They do not simulate the Lambda runtime environment and lifecycle, which can lead to discrepancies between local testing and real AWS Lambda behavior. This could result in missing certain edge cases related to Lambda's execution model (like event-driven invocations).
- Use Case: While it’s good for testing function logic in isolation, it doesn’t simulate the real Lambda environment well.
Option C: Install the AWS Serverless Application Model (AWS SAM) CLI tool. Use the `sam local generate-event` command to generate sample events for the automated t...
Author: Emily · Last updated Jul 14, 2026
A developer is troubleshooting an application that uses Amazon DynamoDB in the us-west-2 Region. The application is deployed to an Amazon EC2 instance. The application requires read-only permissions to a table that is named Cars. The EC2 instance has an attached IAM role that contains the following IAM policy:
...
Author: ShadowWolf101 · Last updated Jul 14, 2026
When using the AWS Encryption SDK, how does the developer keep track of the data encryption keys use...
To answer the question about how a developer can keep track of the data encryption keys (DEK) when using the AWS Encryption SDK, we need to look at the options carefully:
Option A: The developer must manually keep track of the data encryption keys used for each data object.
- Reasoning: This would mean that the developer is responsible for storing and managing the DEKs manually. This is error-prone and could lead to security vulnerabilities if the keys are not handled properly.
- Cons: This is not recommended because it defeats the purpose of using a managed SDK that is designed to simplify encryption and key management. Manual tracking increases the risk of key exposure or loss.
- Rejected because: It is cumbersome, error-prone, and insecure.
Option B: The SDK encrypts the data encryption key and stores it (encrypted) as part of the returned ciphertext.
- Reasoning: The AWS Encryption SDK follows a key management model where the data encryption key (DEK) used to encrypt the data is itself encrypted using a master key (often stored in AWS Key Management Service - KMS). The encrypted DEK is then stored along with the ciphertext. This allows the encrypted DEK to be decrypted later when needed to decrypt the data.
- Cons: There are no significant downsides to this approach. It is the intended and secure way to handle encryption keys, as the SDK manages key storage and retrieval securely.
- Selected because: This is the correct and intended behavior of the AWS Encryption SDK, which simplifies key management and enhances security by automatically encrypting and storing ...
Author: Carlos Garcia · Last updated Jul 14, 2026
An application that runs on AWS Lambda requires access to specific highly confidential objects in an Amazon S3 bucket. In accordance with the principle of least privilege, a company grants access to the S3 bucket by using only tem...
Let's analyze the options based on security best practices and the principle of least privilege, which emphasizes providing only the permissions necessary for the task at hand and using temporary credentials whenever possible.
Option A: Hardcode the credentials that are required to access the S3 objects in the application code. Use the credentials to access the required S3 objects.
- Reasoning: Hardcoding credentials in application code is a highly insecure practice. If the credentials are exposed or the code is compromised, an attacker gains access to sensitive data. Moreover, this method doesn't support temporary credentials, which are required for highly secure access.
- Cons: This method exposes credentials directly in the code and does not follow the principle of least privilege. It makes key rotation and management harder, increasing the risk of compromise.
- Rejected because: Hardcoding credentials is insecure, difficult to manage, and violates best practices.
Option B: Create a secret access key and access key ID with permission to access the S3 bucket. Store the key and key ID in AWS Secrets Manager. Configure the application to retrieve the Secrets Manager secret and use the credentials to access the S3 objects.
- Reasoning: Using AWS Secrets Manager to store credentials securely is a good practice because Secrets Manager helps manage, rotate, and securely retrieve credentials. However, this still relies on long-lived static credentials, which are not temporary and do not fully align with the requirement to use temporary credentials.
- Cons: While storing credentials securely in Secrets Manager is a good practice, this approach still involves managing static credentials, which is not ideal when the application needs temporary credentials.
- Rejected because: The solution uses static credentials instead of temporary ones, which doesn't fully meet the security requirement.
Option C: Create a Lambda function execution role. Attach a policy to the role that grants access to specific objects in the S3 bucket.
- Reasoning: This is the most se...
Author: Manish · Last updated Jul 14, 2026
A developer has code that is stored in an Amazon S3 bucket. The code must be deployed as an AWS Lambda function across multiple accounts in the same AWS Region as the S3 bucket. An AWS CloudFormation template that runs for each account will deploy the Lamb...
To determine the most secure way to allow CloudFormation to access the Lambda code in the S3 bucket, we need to consider the following key factors:
1. Minimizing unnecessary permissions: Granting only the required permissions minimizes the security risk of over-permissioning.
2. Principal limitations: Limiting the principal to a specific AWS account or service is a best practice for security, as it avoids broad access.
3. Correct scoping of permissions: Permissions should be applied as narrowly as possible to the specific resource or action.
Option Analysis:
A) Grant the CloudFormation service role the S3 ListBucket and GetObject permissions. Add a bucket policy to Amazon S3 with the principal of “AWS”: [account numbers].
- Why it could be chosen: This option grants the CloudFormation service role the necessary permissions (ListBucket and GetObject) on the S3 bucket. By adding a bucket policy with a restricted principal (i.e., specifying account numbers), it limits access to specific accounts that are allowed to deploy the Lambda function.
- Why this is recommended: It ensures that only the CloudFormation service role from the allowed accounts has access to the S3 bucket. It also minimizes permissions to the specific required actions for CloudFormation.
B) Grant the CloudFormation service role the S3 GetObject permission. Add a bucket policy to Amazon S3 with the principal of “”.
- Why it could be chosen: This approach gives CloudFormation the permission to retrieve the Lambda code, but it adds a significant security risk because the bucket policy would grant access to any principal (denoted by ``), making the bucket publicly accessible to anyone.
- Why this is rejected: Using `` in the bucket policy means that the Lambda code could potentially be accessed by any AWS account, exposing the code to a broader audien...
Author: Amira99 · Last updated Jul 14, 2026
A developer at a company needs to create a small application that makes the same API call once each day at a designated time. The company does not have infrastructure in the AWS Cloud yet, but the company wants to implement this functi...
To determine the most operationally efficient solution for running a small application that makes an API call once each day, we need to consider the following key factors:
1. Simplicity of setup and maintenance: A solution that is easy to set up and requires minimal ongoing management will provide operational efficiency.
2. Scalability and infrastructure requirements: The solution should scale based on demand, without requiring a significant infrastructure setup.
3. Cost-effectiveness: The solution should be cost-efficient for a small application, avoiding over-provisioning resources.
4. Automation and reliability: The solution should handle scheduling and execution automatically without the need for manual intervention.
Option Analysis:
A) Use a Kubernetes cron job that runs on Amazon Elastic Kubernetes Service (Amazon EKS).
- Why it could be chosen: Kubernetes cron jobs are a powerful tool for scheduling tasks, and Amazon EKS offers a managed Kubernetes service that scales well for large applications.
- Why this is rejected: Setting up Amazon EKS to manage a small application adds unnecessary complexity. Kubernetes requires setup, configuration, and ongoing management, which may not be ideal for such a simple task like making a single API call once a day. This also incurs higher costs and overhead for a use case that doesn't require the scalability or complexity of Kubernetes.
B) Use an Amazon Linux crontab scheduled job that runs on Amazon EC2.
- Why it could be chosen: A crontab job on an Amazon EC2 instance can schedule a task to run at a specific time each day.
- Why this is rejected: Managing an EC2 instance for such a small task is inefficient. It requires provisioning, maintaining, and securing the EC2 instance...
Author: CrystalWolfX · Last updated Jul 14, 2026
A developer is building a serverless application that is based on AWS Lambda. The developer initializes the AWS software development kit (SDK) outside of the La...
To determine the primary benefit of initializing the AWS SDK outside of the Lambda handler function, we need to understand the behavior and performance characteristics of AWS Lambda, specifically regarding execution environment reuse and resource initialization.
Option Analysis:
A) Improves legibility and stylistic convention
- Why this is rejected: While moving SDK initialization outside of the handler might make the code more readable by centralizing initialization, this is not the primary benefit in the context of Lambda performance. The main purpose of doing this is to leverage Lambda's execution environment reuse, not just to improve code style. Improving legibility is secondary to performance concerns in this context.
B) Takes advantage of runtime environment reuse
- Why it is selected: AWS Lambda reuses the execution environment for multiple invocations, which means that the initialization of resources, such as the AWS SDK, is not repeated with each new invocation. Initializing the SDK outside the handler allows the SDK instance to be reused across invocations within the same environment. This is more efficient because it avoids the overhead of re-initializing the SDK every time a function is invoked, improving performance by reducing initialization time and resource consumption.
- Why this is the primary benefi...
Author: Aarav2020 · Last updated Jul 14, 2026
A company is using Amazon RDS as the backend database for its application. After a recent marketing campaign, a surge of read requests to the database increased the latency of data retrieval from the database. The company has decided to implement a caching layer in front of the dat...
To determine which solution will meet the requirements for caching with encryption and high availability in front of an Amazon RDS database, we need to consider the following factors:
1. Encryption: The cached content needs to be encrypted, both at rest and in transit.
2. High Availability: The solution must provide high availability, ensuring that the cache can scale and remain operational even in the event of failures.
3. Caching for RDS: The solution should be appropriate for use as a caching layer in front of Amazon RDS to reduce database load and improve response times.
Option Analysis:
A) Amazon CloudFront
- Why it could be chosen: Amazon CloudFront is a content delivery network (CDN) service that can cache content at edge locations around the world. It does support encryption (both in transit and at rest).
- Why it is rejected: While CloudFront is great for caching static content (e.g., images, videos, and web assets), it is not designed as a general-purpose caching layer for dynamic database queries. It works best for content that can be cached for longer periods and has predefined expiration policies, but it is not suitable for caching database results where high availability and low-latency access to frequently changing data are required.
B) Amazon ElastiCache for Memcached
- Why it could be chosen: Memcached is a widely-used, in-memory caching system that could help offload read traffic from the RDS database.
- Why it is rejected: Although ElastiCache for Memcached offers in-memory caching, Memcached does not support encryption at rest. This is a key requirement in the question. While you can enable encryption in transit, Memcached is not des...
Author: Stella · Last updated Jul 14, 2026
A developer at a company recently created a serverless application to process and show data from business reports. The application=E2=80=99s user interface (UI) allows users to select and start processing the files. The UI displays a message when the result is available to view. The application uses AWS Step Functions with AWS Lambda functions to process the files. The developer used Amazon API Gateway and Lambda functions to create an API to support the UI.
The company=E2=80=99s UI team reports that the request to process a file is often returning timeout errors because of the size or complexity of the files. The UI team wants the API to provide an immed...
To address the requirements of providing an immediate response from the API while processing the files asynchronously, the solution needs to ensure that the backend process can continue running without blocking the API and also notify the user when the report is complete.
Key factors to consider:
1. Immediate response for the UI: The UI must receive an immediate response so that it can display a message, even while the file processing continues in the background.
2. Asynchronous file processing: The file processing must be handled asynchronously without causing timeouts in the API.
3. Email notification upon completion: Once the file processing is complete, an email must be sent as a notification.
Option Analysis:
A) Change the API Gateway route to add an X-Amz-Invocation-Type header with a static value of 'Event' in the integration request. Deploy the API Gateway stage to apply the changes.
- Why it could be chosen: Adding the `X-Amz-Invocation-Type` header with the value `Event` allows for asynchronous invocation of the Lambda function. This would ensure that the API responds immediately, without waiting for the file processing to complete.
- Why it is selected: This is the correct solution because it ensures that the Lambda function is invoked asynchronously. This allows the API to respond immediately while the processing continues in the background. The invocation type `Event` means that the Lambda function will process the request asynchronously, and the API will return a response right away.
B) Change the configuration of the Lambda function that implements the request to process a file. Configure the maximum age of the event so that the Lambda function will run asynchronously.
- Why it could be chosen: Configuring the Lambda function to run asynchronously is a valid approach. However, this option does not address the need for the API Gateway to respond immediately. It only focuses on Lambda's configuration.
- Why it is rejected: This...
Author: RadiantPhoenixX · Last updated Jul 14, 2026
A developer has an application that is composed of many different AWS Lambda functions. The Lambda functions all use some of the same dependencies. To avoid security issues, the developer is constantly updating the dependencies of all of the Lambda functions. The result is duplicated effort for each ...
To solve this problem, the goal is to reduce the duplicated effort of updating shared dependencies in multiple AWS Lambda functions, while minimizing additional complexity.
Option A: Define a maintenance window for the Lambda functions to ensure that the functions get updated copies of the dependencies.
- Explanation: A maintenance window is a scheduled period when updates or maintenance tasks are performed. It could be used to update dependencies manually across all Lambda functions.
- Reason for rejection: This option introduces a lot of manual work, which leads to inefficiency and is prone to human error. It's not an automated solution, and the developer would still have to individually update each Lambda function. It adds unnecessary complexity when there's a more effective method to handle dependencies.
Option B: Upgrade the Lambda functions to the most recent runtime version.
- Explanation: Upgrading Lambda functions to the latest runtime ensures that the functions benefit from the latest performance improvements and security fixes provided by AWS.
- Reason for rejection: While upgrading to the latest runtime is beneficial for security and performance, it doesn't specifically address the issue of shared dependencies. The developer would still need to manually update dependencies in each Lambda function, which doesn't reduce duplication of effort.
Option C: Define a Lambda layer that contains all of the shared dependencies.
- Explanation: A Lambda layer is a distribution mechanism for libraries, custom runtimes, or other function dependencies. By defining a shared Lambda layer with the necessary dependencies, the developer can attach this layer to multiple Lambda functions. This way, the functions don’t need to include the dependencies in their individual deployment packages, a...
Author: Andrew · Last updated Jul 14, 2026
A mobile app stores blog posts in an Amazon DynamoDB table. Millions of posts are added every day, and each post represents a single item in the table. The mobile app requires only recent posts. Any post that is older than 48 hours ...
Option A: For each item, add a new attribute of type String that has a timestamp that is set to the blog post creation time. Create a script to find old posts with a table scan and remove posts that are older than 48 hours by using the BatchWriteItem API operation. Schedule a cron job on an Amazon EC2 instance once an hour to start the script.
- Explanation: This option requires maintaining an EC2 instance to run a cron job that scans the table and deletes old posts every hour.
- Reason for rejection: Using an EC2 instance introduces significant costs, both for the instance itself and for managing it. The need for frequent scans and the use of BatchWriteItem adds complexity and can lead to additional operational overhead. It's not cost-effective compared to the alternatives, especially since it requires handling infrastructure and resource management.
Option B: For each item, add a new attribute of type String that has a timestamp that is set to the blog post creation time. Create a script to find old posts with a table scan and remove posts that are older than 48 hours by using the BatchWriteItem API operation. Place the script in a container image. Schedule an Amazon Elastic Container Service (Amazon ECS) task on AWS Fargate that invokes the container every 5 minutes.
- Explanation: This option involves packaging the script in a container image and running it on AWS Fargate, which abstracts away the underlying infrastructure management.
- Reason for rejection: While Fargate eliminates the need for managing EC2 instances, running tasks every 5 minutes may still result in unnecessary complexity and cost, especially when there is no need to run the task this frequently. Fargate can incur more cost than other options for a task that needs to run only once an hour or so. This level of frequency and infrastructure overhead is excessive for the problem at hand.
Option C: For each item, add a new attribute of type Date that has a timestamp that is set to 48 hours after the blog post creation time. Create a global secondary index (GSI) that uses the new attribute as a sort key. Create an AWS Lambda function that references the GSI and removes expired items by using the BatchWriteItem API operation. Schedule the function with an Amazon CloudWatch even...
Author: Emma · Last updated Jul 14, 2026
A developer is modifying an existing AWS Lambda function. While checking the code, the developer notices hardcoded parameter values for an Amazon RDS for SQL Server user name, password, database, host, and port. There are also hardcoded parameter values for an Amazon DynamoDB table, an Amazon S3 bucket, and an Amazon Simple Notification Service (Amazon SNS) topic.
The developer wants to securely store the parameter values outside the code in an encrypted format and wants to turn on rotation for the credentials. The de...
To meet the requirements of securely storing parameter values outside the code in an encrypted format, enabling automatic rotation for credentials, and minimizing operational overhead, let's analyze each option:
Option A: Create an RDS database secret in AWS Secrets Manager. Set the user name, password, database, host, and port. Turn on secret rotation. Create encrypted Lambda environment variables for the DynamoDB table, S3 bucket, and SNS topic.
- Explanation: This option stores the RDS credentials in AWS Secrets Manager with automatic rotation enabled. However, it still requires hardcoding other parameters (DynamoDB, S3, and SNS) in the Lambda environment variables, which isn't ideal from a maintenance or security perspective.
- Reason for rejection: While Secrets Manager is a good choice for securely storing RDS credentials, storing the other parameters as encrypted environment variables in Lambda doesn't meet the goal of having all configuration values centrally managed and easily reusable. It also requires manual handling of the rotation of these values.
Option B: Create an RDS database secret in AWS Secrets Manager. Set the user name, password, database, host, and port. Turn on secret rotation. Create SecureString parameters in AWS Systems Manager Parameter Store for the DynamoDB table, S3 bucket, and SNS topic.
- Explanation: This option uses AWS Secrets Manager for RDS credentials with rotation and stores the other parameters (DynamoDB, S3, SNS) as SecureString parameters in AWS Systems Manager Parameter Store.
- Reason for selection: This approach ensures that all credentials are stored securely and can be rotated automatically where applicable (RDS credentials in Secrets Manager). Using Systems Manager Parameter Store for other configuration values allows them to be securely stored, encrypted, and easily reused across applications. Additionally, using Parameter Store eliminates the need to hardcode values, making it easier to update parameters without changing code. This also minimizes operational overhead compared to writing custom Lambda functions for credential rotation.
Option C: Create RDS database parameters in AWS Systems Manager Parameter Store for the user name, password, database, host, and port. Create encrypted Lambda environment variables for the DynamoDB table, S3 bucket, and SNS topic. Create a Lambda funct...
Author: Ethan · Last updated Jul 14, 2026
A developer accesses AWS CodeCommit over SSH. The SSH keys configured to access AWS CodeCommit are tied to a user with the following permissions:
The developer needs to create/delete branches.
Wh...
To ensure the developer can create and delete branches while adhering to the principle of least privilege, we need to grant the specific permissions necessary for these actions. Let's evaluate the options:
Option A: "codecommit:CreateBranch", "codecommit:DeleteBranch"
- Explanation: These permissions directly relate to creating and deleting branches within an AWS CodeCommit repository.
- Reason for selection: This option grants exactly the permissions needed for the developer to perform the required actions (creating and deleting branches). It follows the principle of least privilege because it only includes the permissions needed for these specific tasks and does not grant any unnecessary permissions.
Option B: "codecommit:Put"
- Explanation: This permission would allow the developer to perform any action related to "putting" resources in CodeCommit (e.g., pushing changes, committing files).
- Reason for rejection: While this permission could grant access to modify the repository, it is broader than necessary and includes permissions that the developer doesn't need, such as pushing code. Granting more permissions than necessary violates the principle of least privilege.
Option C: "codecommit:Update"
- Explanation: This permission would allow the developer to update resources in CodeCommit, such as updating repository se...
