Amazon Practice Questions, Discussions & Exam Topics by our Authors
A developer is writing unit tests for a new application that will be deployed on AWS. The developer wants to validate all pull requests with unit tests and merge the code with the main branch only when all tests pass.
The developer stores the code in AWS CodeCommit and sets up AWS CodeBuild to run the unit tests. The developer creates an AWS Lambda function to start the CodeBuild task. The developer needs to identify the...
To address the requirement of invoking the Lambda function when a pull request is created or updated in AWS CodeCommit, we need to focus on the appropriate CodeCommit event in Amazon EventBridge that will trigger the Lambda function based on the pull request activity.
Possible Events from AWS CodeCommit:
1. CodeCommit PullRequestCreated: This event occurs when a pull request is created.
2. CodeCommit PullRequestMerged: This event occurs when a pull request is merged.
3. CodeCommit PullRequestUpdated: This event occurs when a pull request is updated (e.g., new commits are added or other updates are made to the pull request).
4. CodeCommit CommitCreated: This event occurs when a new commit is pushed to a repository (not specific to pull requests).
5. CodeCommit ReferenceCreated: This event occurs when a new reference (branch, tag, etc.) is created.
6. CodeCommit ReferenceUpdated: This event occurs when an existing reference (branch or tag) is updated.
Selecting the Appropriate Event:
- PullRequestCreated and PullRequestUpdated events are most relevant to the developer’s use case, as these events trigger when changes are made to a pull re...
Author: VenomousSerpent42 · Last updated Jul 14, 2026
A developer deployed an application to an Amazon EC2 instance. The application needs to know the public IPv4 address of the inst...
To get the public IPv4 address of an Amazon EC2 instance, the application should query the instance metadata service, which provides various details about the instance, including the public IP address.
Let's break down each option:
- A) Query the instance metadata from http://169.254.169.254/latest/meta-data/:
This is the correct approach. The EC2 instance metadata service at this address provides detailed information about the instance, including the public IPv4 address (`http://169.254.169.254/latest/meta-data/public-ipv4`). The metadata is directly accessible from within the instance and is the proper method to obtain such information.
- B) Query the instance user data from http://169.254.169.254/latest/user-data/:
The instance user data contains initialization information provided at the time of the instance launch. While this can include custom data, it does not include dynamic data such as the public IP address. Thus, this option isn't suitable for retrieving the public IPv4 address.
- C) Query the Amazon M...
Author: Scarlett · Last updated Jul 14, 2026
An application under development is required to store hundreds of video files. The data must be encrypted within the application prior to storage, with a unique key...
The developer needs to ensure that the video files are encrypted within the application prior to storage, with a unique key for each video file. Let's analyze each option:
A) Use the KMS Encrypt API to encrypt the data. Store the encrypted data key and data.
- The KMS Encrypt API is used to encrypt data using a specified encryption key, but it doesn't involve generating a unique encryption key for each video file. This option is not ideal because it does not meet the requirement of creating a unique key for each file.
- Additionally, the KMS Encrypt API directly encrypts the data, but it doesn’t provide a way to manage multiple unique encryption keys for different files at scale.
B) Use a cryptography library to generate an encryption key for the application. Use the encryption key to encrypt the data. Store the encrypted data.
- This option allows the developer to generate an encryption key within the application and use it for encrypting the video file. While this gives full control over the encryption process, it does not leverage AWS KMS for key management and could be more complex to manage (e.g., securely storing and rotating the encryption keys). Additionally, the application would need to securely manage and store the keys, which introduces potential security risks.
C) Use the KMS GenerateDataKey API to get a data key. Encrypt the data with the data key. Store the encrypted data key and data.
- This option is the best choice. AWS KMS provides the GenerateDataKey API to generate a unique data key for each video file. The data key is used to en...
Author: Mia · Last updated Jul 14, 2026
A company is planning to deploy an application on AWS behind an Elastic Load Balancer. The application uses an HTTP/HTTPS listener and must access the client IP ...
The application needs to access the client IP addresses while being deployed behind an Elastic Load Balancer using an HTTP/HTTPS listener. Let's examine each option:
A) Use an Application Load Balancer and the X-Forwarded-For headers.
- Application Load Balancer (ALB) is specifically designed for HTTP/HTTPS traffic. ALBs automatically add the X-Forwarded-For header to the incoming requests, which contains the client’s IP address. This allows the application to access the real client IP address behind the load balancer. This is a straightforward and common solution for HTTP/HTTPS-based applications that need to retain the original client IP.
B) Use a Network Load Balancer (NLB). Enable proxy protocol support on the NLB and the target application.
- Network Load Balancer (NLB) operates at Layer 4 (Transport Layer) and can forward TCP traffic. It doesn’t handle HTTP/HTTPS headers natively, but it supports Proxy Protocol for forwarding the client IP address. Enabling Proxy Protocol on both the NLB and the target application is required for the application to receive the client’s IP. This is a viable option, but it adds complexity as Proxy Protocol support must be explicitly enabled on the application, which is typically more involved than using ALB's built-in features like X-Forwarded-For.
C) Use an Application Load Balancer. Register the targets by the instance ID.
- While Application Load Balancer (ALB) is a good choice for HTTP/HTTPS traffic, registering the targets by instance ID is not directly r...
Author: Lucas Carter · Last updated Jul 14, 2026
A developer wants to debug an application by searching and filtering log data. The application logs are stored in Amazon CloudWatch Logs. The developer creates a new metric filter to count exceptions in the application logs. However, no ...
Let's break down each option and analyze why no results are being returned when using a CloudWatch Logs metric filter:
A) A setup of the Amazon CloudWatch interface VPC endpoint is required for filtering the CloudWatch Logs in the VPC.
- Incorrect. A CloudWatch VPC endpoint is used to securely connect CloudWatch Logs to resources in a VPC, but it is not necessary for creating metric filters or filtering log data. CloudWatch Logs can be filtered without requiring a VPC endpoint. This option does not address the issue of missing filtered results.
B) CloudWatch Logs only publishes metric data for events that happen after the filter is created.
- Correct. This is the reason why no results are being returned. CloudWatch Logs metric filters only process and publish metric data for events that occur after the metric filter is created. If the filter was created but no new log entries matching the filter have been recorded, no results will be returned. Therefore, the filter won’t capture any past log data — only data generated after the filter was set up will be included in the results.
C) The log group for CloudWatch Logs should be first streamed to Amazon OpenSearch Service before metric filtering returns the results.
- Incorrect. While Amazon OpenSearch Service can be used to analyz...
Author: Carlos Garcia · Last updated Jul 14, 2026
A company is planning to use AWS CodeDeploy to deploy an application to Amazon Elastic Container Service (Amazon ECS). During the deployment of a new version of the application, the company initially must expose only 10% of live traffic to the new version of the deployed application. Then, after 15 minutes elapse, the company must route all t...
Let's analyze each predefined configuration in the context of the company's deployment requirements using AWS CodeDeploy to ECS:
Requirement Summary:
- Expose 10% of live traffic to the new version initially.
- After 15 minutes, route the remaining 90% of the traffic to the new version.
A) CodeDeployDefault.ECSCanary10Percent15Minutes
- Correct. This predefined configuration is specifically designed for ECS deployments where 10% of the traffic is initially routed to the new version, and the remaining 90% is shifted to the new version after 15 minutes. This exactly matches the company's requirements, as it implements a canary deployment pattern, which is ideal for testing new versions with a small subset of users before full rollout.
B) CodeDeployDefault.LambdaCanary10Percent5Minutes
- Incorrect. This is a Lambda-specific deployment strategy, not for ECS. It applies to Lambda functions, not ECS services, and the traffic is routed in a canary deployment pattern (10% at first) with a 5-minute wait time, which doesn't align with the 15-minute wait time requirement. Therefore, it doesn't meet the ECS-specific need and the correct timing.
C) CodeDeployDefault.LambdaCanary10Percent15Minutes
- Incorrect. While this configuration has a 15-minute wait time, it is speci...
Author: FlamePhoenix2025 · Last updated Jul 14, 2026
A company hosts a batch processing application on AWS Elastic Beanstalk with instances that run the most recent version of Amazon Linux. The application sorts and processes large datasets.
In recent weeks, the application's performance has decreased significantly during a peak period for traffic. A developer suspects that the application issues are related to the memory usage. The developer checks t...
To address the issue of memory usage not being tracked on the AWS Elastic Beanstalk instances, the developer should focus on gathering more detailed and relevant data specifically related to memory performance.
Option Breakdown:
A) Configure the Amazon CloudWatch agent to push logs to Amazon CloudWatch Logs by using port 443:
- Why it's rejected: Pushing logs to CloudWatch Logs is useful for log aggregation, but it doesn't directly address tracking memory usage. The application performance issue is suspected to be related to memory, so pushing logs doesn't provide the necessary memory metrics or insights.
- When it can be used: If the developer wanted to aggregate logs from the application for troubleshooting or debugging, this would be useful, but it doesn't directly help with memory tracking.
B) Configure the Elastic Beanstalk .ebextensions directory to track the memory usage of the instances:
- Why it's rejected: The `.ebextensions` directory is used for configuring the environment for Elastic Beanstalk, but it does not have built-in mechanisms to track memory usage. This option could help configure other aspects of the environment but would not provide an easy way to gather memory metrics for performance issues.
- When it can be used: If the goal is to customize the environment with additional settings, but not for directly tracking memory usage.
C) Configure the Amazon CloudWatch agent to track the memory usage of the instances:
- Why it's selected: The CloudWatch agent can be configured to collect detailed system me...
Author: FlamePhoenix2025 · Last updated Jul 14, 2026
A developer is building a highly secure healthcare application using serverless components. This application requires writing temporary data to /tmp storage on a...
To encrypt data written to the /tmp storage in an AWS Lambda function, the developer needs to ensure that the temporary data is securely encrypted during its use and storage. Let's analyze the options in detail.
Option Breakdown:
A) Enable Amazon EBS volume encryption with an AWS KMS key in the Lambda function configuration so that all storage attached to the Lambda function is encrypted:
- Why it's rejected: AWS Lambda does not use Amazon EBS volumes for its temporary storage. Lambda's /tmp storage is ephemeral and resides in the instance’s local disk, which is not encrypted by default and cannot be directly encrypted using EBS volume encryption. This option is not applicable for Lambda functions.
- When it can be used: This would apply if the storage used was EBS volumes or if Lambda used persistent storage in some way, but not for ephemeral /tmp storage.
B) Set up the Lambda function with a role and key policy to access an AWS KMS key. Use the key to generate a data key used to encrypt all data prior to writing to /tmp storage:
- Why it's selected: This is the most appropriate solution. The developer can configure the Lambda function to use AWS Identity and Access Management (IAM) roles and policies to access a KMS (AWS Key Management Service) key. Using the KMS key, a data key can be generated to encrypt the data before it is written to the /tmp storage. The encryption and decryption operations will be securely managed, and the key will never be stored directly in the Lambda environment, ensuring a high level of security.
- When it can be used: This is the ideal solution for encrypting data on Lambda functions that require high security, as KMS is designed for managing encryption keys and ensuring compliance.
C) Use OpenSSL to generate a symmetric encryption key on Lambda sta...
Author: Grace · Last updated Jul 14, 2026
A developer has created an AWS Lambda function to provide notification through Amazon Simple Notification Service (Amazon SNS) whenever a file is uploaded to Amazon S3 that is larger than 50 MB. The developer has deployed and tested the Lambda function by using the CLI. However, when the event notification is added to the S3 bucket and a 3,000 M...
The problem described here involves a Lambda function that should be triggered when an object is uploaded to an S3 bucket, specifically if the object is larger than 50 MB. However, the Lambda function is not being triggered when a 3,000 MB file is uploaded.
Option Breakdown:
A) The S3 event notification does not activate for files that are larger than 1,000 MB:
- Why it's rejected: There is no limit of 1,000 MB for triggering S3 events. Amazon S3 can trigger events for objects of any size, including those greater than 1,000 MB. This option is incorrect because the size of the object does not prevent the event notification from being triggered.
- When it can be used: This scenario would be relevant if S3 had a hard size limit for triggering events, but such a limit does not exist.
B) The resource-based policy for the Lambda function does not have the required permissions to be invoked by Amazon S3:
- Why it's selected: This is the most likely cause of the issue. For S3 to invoke a Lambda function, the Lambda function must have a resource-based policy that allows the S3 service to trigger it. If the policy is missing or misconfigured, S3 will not be able to invoke the Lambda function when the event occurs. In this case, the Lambda function might be working when manually tested with the CLI because the permissions are correctly set for that test, but the event trigger from S3 lacks the required permissions.
- When it can be used: This option is correct when the Lambda function isn't invoked b...
Author: Stella · Last updated Jul 14, 2026
A developer is creating a Ruby application and needs to automate the deployment, scaling, and management of an environment without requiring knowledge of the under...
Option Breakdown:
A) AWS CodeDeploy:
- Why it's rejected: AWS CodeDeploy is a deployment service that automates the deployment of applications to various compute resources (like EC2, Lambda, or on-premises instances). However, CodeDeploy focuses on deployment rather than managing the entire environment. It does not automate scaling or full environment management, making it less suited for the task described.
- When it can be used: CodeDeploy is ideal for automated application deployments but not for automating infrastructure management or scaling.
B) AWS CloudFormation:
- Why it's rejected: AWS CloudFormation is an Infrastructure as Code (IaC) service that allows you to define and provision AWS infrastructure using templates. While CloudFormation automates the setup and management of infrastructure, it requires deep knowledge of AWS resources and configurations. It is not designed for managing application-level tasks such as deployment, scaling, and environment management without manually specifying all the infrastructure components.
- When it can be used: CloudFormation is useful for creating and managing complex AWS infrastructure at a very granular level. However, for an application-level environment without requiring knowledge of underlying infrastructure, CloudFormation is too complex for this task.
C) AWS OpsWorks:
- Why it's rejected: AWS OpsWorks is a configuration management service that provides automation of application deployment, scaling, and management through Chef or Puppet. While it is useful for managing more customized environments, it still requires more in-depth knowledge about infrastructure management. It’s ideal for configurations that re...
Author: Julian · Last updated Jul 14, 2026
A company has a web application that is deployed on AWS. The application uses an Amazon API Gateway API and an AWS Lambda function as its backend.
The application recently demonstrated unexpected behavior. A developer examines the Lambda function code, finds an error, and modifies the code to resolve the problem. Before deploying the change to production, the developer needs to run tests to validate that the application operates properly.
The application has only a production environment available. The developer must create a new development environ...
Option Breakdown:
A) Create a new resource in the current stage. Create a new method with Lambda proxy integration. Select the Lambda function. Add the hotfix alias. Redeploy the current stage. Test the backend.
- Why it's rejected: Creating a new resource and method in the current stage is not the most appropriate approach when you need to create a separate development environment. Modifying the current stage risks affecting the production environment, and redeploying the stage could result in other developers overwriting changes or causing issues during testing. Additionally, testing directly within the production stage can lead to errors and disruptions.
- When it can be used: This could be useful if you were testing within the same stage without concerns about environment isolation, but it is not ideal for a safe, isolated test.
B) Update the Lambda function in the API Gateway API integration request to use the hotfix alias. Deploy the API Gateway API to a new stage named hotfix. Test the backend.
- Why it's selected: This approach effectively isolates the test environment. By creating a new stage (like `hotfix`), you can deploy the API Gateway API with the updated Lambda function code while ensuring the production environment remains unaffected. The hotfix alias allows you to test the code changes safely in a separate environment.
- When it can be used: This is a good option when you need to test new changes without affecting the production environment. It isolates the changes and prevents other developers from overwriting the test cycle.
C) Modify the Lambda function by fixing the code. Test the Lambda function. Create the alias hotfix. Point the alias to the $LATEST version.
- Why it's rejected: This option focuses on modifying the Lambda function and pointing an alias to the latest version but does not provide a solution for the application’s API Gateway integration in a separate development environment. It also doesn’t handle the necessary deployment of the API Gateway for isolated testing.
- When it can be used: This might work if you are only concerned with testing the Lambda function itself, but it mis...
Author: Amelia · Last updated Jul 14, 2026
A developer is implementing an AWS Cloud Development Kit (AWS CDK) serverless application. The developer will provision several AWS Lambda functions and Amazon API Gateway APIs during AWS CloudFormation stack creation. The developer's workstation has the AWS Serverless Applicat...
To test a specific AWS Lambda function locally in the context of an AWS CDK serverless application, let's break down each option based on key factors such as testing locally, interaction with AWS CDK and SAM, and the capabilities of the tools involved.
Option A:
- Run the sam package and sam deploy commands. Create a Lambda test event from the AWS Management Console. Test the Lambda function.
- Explanation: This option is primarily about deploying the Lambda to AWS and testing it from the AWS Management Console. It's not about testing the Lambda locally. `sam deploy` is used for deployment, which isn’t ideal for local testing.
- Rejected Reason: This option does not allow for local testing of the Lambda function; it is more focused on deployment and cloud-based testing.
Option B:
- Run the cdk synth and cdk deploy commands. Create a Lambda test event from the AWS Management Console. Test the Lambda function.
- Explanation: The `cdk synth` command generates the CloudFormation template from the CDK code. However, `cdk deploy` is used for deploying the application to AWS, and testing it from the AWS Management Console is also cloud-based. It does not support testing locally.
- Rejected Reason: Like Option A, this approach is not suitable for local testing because it focuses on deploying the application and testing it in the cloud.
Option C:
- Run the cdk synth and sam local invoke commands with the function construct identifier and the path to the synthesized CloudFormation template.
- Explanation: `cdk synth`...
Author: IronLion88 · Last updated Jul 14, 2026
A company's new mobile app uses Amazon API Gateway. As the development team completes a new release of its APIs, a developer must safely and transparently roll out the API change.
What is the SIMPLEST solution for the devel...
To choose the simplest solution for rolling out a new API version to a limited number of users through Amazon API Gateway, let's analyze each option and its suitability for the task:
Option A:
- Create a new API in API Gateway. Direct a portion of the traffic to the new API using an Amazon Route 53 weighted routing policy.
- Explanation: This approach would involve creating a completely new API in API Gateway and managing traffic routing at the DNS level using Route 53's weighted routing policy. While this can provide control over traffic distribution, it introduces additional complexity and manual intervention, especially with DNS management.
- Rejected Reason: This option is more complex because it involves creating a new API and managing DNS routing, which is not as seamless or simple as using built-in deployment strategies within API Gateway.
Option B:
- Validate the new API version and promote it to production during the window of lowest expected utilization.
- Explanation: This option suggests a manual process of validating and promoting the new version during a low-traffic period. While this can work, it lacks the flexibility and automation needed for controlled, gradual rollouts and can potentially disrupt service if the validation or deployment process is not smooth.
- Rejected Reason: It is not automated, lacks control over traffic distribution, and could lead to service interruptions if issues are not detected quickly. It is not the simplest approach to gradually roll out the new API.
Option C:
- Implement an Amazon CloudWatch alarm to trigger a rollback if the observed HTTP 5...
Author: ThunderBear · Last updated Jul 14, 2026
A company caches session information for a web application in an Amazon DynamoDB table. The company wants an automated way to delete old i...
To automatically delete old items from a DynamoDB table, let’s analyze the different options based on simplicity, efficiency, and the best use of AWS-native features.
Option A:
- Write a script that deletes old records; schedule the script as a cron job on an Amazon EC2 instance.
- Explanation: This approach requires setting up an EC2 instance and writing a script to periodically check for and delete old items from the DynamoDB table. The script could be scheduled to run at specified intervals using a cron job.
- Rejected Reason: While this method would work, it introduces additional complexity in terms of managing an EC2 instance, maintaining the script, and ensuring reliability. It is not as simple or cost-effective as other solutions, especially considering AWS provides services that automate these tasks.
Option B:
- Add an attribute with the expiration time; enable the Time To Live (TTL) feature based on that attribute.
- Explanation: The Time to Live (TTL) feature in DynamoDB allows you to automatically delete items after a specified time. You simply add a `TTL` attribute to your items with a timestamp indicating when the item should expire. DynamoDB automatically deletes expired items, reducing the need for custom scripts or manual processes.
- Selected Option Reasoning: This is the simplest and most efficient solution. TTL is an AWS-native feature designed specifically for this purpose. Once you set up TTL, it is fully automated and requires no additional infrastructure. It is cost-effective an...
Author: Evelyn · Last updated Jul 14, 2026
A company is using an Amazon API Gateway REST API endpoint as a webhook to publish events from an on-premises source control management (SCM) system to Amazon EventBridge. The company has configured an EventBridge rule to listen for the events and to control application deployment in a central AWS account. The company needs to receive the sam...
To ensure that the events are sent to multiple receiver AWS accounts without changing the SCM system configuration, let's examine each option based on how it handles cross-account event forwarding, simplicity, and the specific requirements.
Option A:
- Deploy the API Gateway REST API to all the required AWS accounts. Use the same custom domain name for all the gateway endpoints so that a single SCM webhook can be used for all events from all accounts.
- Explanation: This would involve setting up multiple API Gateway instances across each AWS account and using a custom domain name to route traffic to the correct account. This approach still requires the SCM system to be modified to handle the multi-account deployment, which conflicts with the requirement of not changing the SCM system configuration.
- Rejected Reason: It requires multiple API Gateway deployments in each account, which adds unnecessary complexity and would require changes in the SCM system. This is not a simple solution.
Option B:
- Deploy the API Gateway REST API to all the receiver AWS accounts. Create as many SCM webhooks as the number of AWS accounts.
- Explanation: This approach requires creating a separate webhook for each AWS account. The SCM system would need to be modified to send events to multiple webhook endpoints, which again contradicts the requirement of not changing the SCM system configuration.
- Rejected Reason: This solution also involves modifying the SCM system to create multiple webhooks, which is not desirable since the company doesn't want to alter the SCM configuration.
Option C:
- Grant permission to the central AWS acco...
Author: Suresh · Last updated Jul 14, 2026
A company moved some of its secure files to a private Amazon S3 bucket that has no public access. The company wants to develop a serverless application that gives its employees the ability to log in and securely share the files wi...
To securely share and access files in a private S3 bucket in a serverless application, let's evaluate each option:
Option A: Amazon Cognito user pool
- Explanation: Amazon Cognito user pools provide authentication and manage user registration, login, and access. It’s a good choice for handling user sign-ups and authentication.
- Rejected Reason: While Amazon Cognito user pools can manage authentication, they do not directly handle access control to specific resources like S3 files. You would still need additional mechanisms to control access to S3.
Option B: S3 presigned URLs
- Explanation: S3 presigned URLs allow you to generate a temporary URL that gives limited-time access to a specific S3 object. This can be used to securely share files with specific users without making the entire S3 bucket public.
- Selected Option Reasoning: S3 presigned URLs are an excellent choice for sharing files securely. The URLs can be generated dynamically by the application (after user authentication) and provide temporary, time-limited access to specific files in the private S3 bucket. This allows secure sharing without exposing the S3 bucket itself.
Option C: S3 bucket policy
- Explanation: S3 bucket policies are used to de...
Author: Ming88 · Last updated Jul 14, 2026
A company needs to develop a proof of concept for a web service application. The application will show the weather forecast for one of the company's office locations. The application will provide a REST endpoint that clients can call. Where possible, the application should use caching features provided by AWS to limit the number of requests to the backend service. The application...
To determine the most cost-effective option for this web service application, we need to consider a few key factors:
1. Traffic Volume: The application will receive a small amount of traffic during testing, which means it needs to scale easily and efficiently without incurring unnecessary costs for underused resources.
2. Caching Needs: The application needs to cache data to limit the number of requests to the backend service. AWS provides services like API Gateway caching and CloudFront caching, which can be used to reduce the number of direct calls to the backend.
3. Simplicity: Since the application is only a proof of concept (PoC), the solution should be simple, with minimal infrastructure overhead, while still meeting the requirements.
Let's evaluate each option:
A) Create a container image. Deploy the container image by using Amazon Elastic Kubernetes Service (Amazon EKS). Expose the functionality by using Amazon API Gateway.
- Cost Considerations: Amazon EKS requires a Kubernetes cluster, which involves setting up nodes, maintaining infrastructure, and additional overhead in managing clusters. This is more complex and likely to incur higher costs compared to serverless or containerized solutions that don’t require managing a cluster.
- Use Case: Best suited for more complex applications requiring advanced orchestration and high scalability needs.
- Rejected Reason: The complexity and cost of EKS would be excessive for a small-scale, proof-of-concept application with low traffic.
B) Create an AWS Lambda function by using the AWS Serverless Application Model (AWS SAM). Expose the Lambda functionality by using Amazon API Gateway.
- Cost Considerations: AWS Lambda is a serverless compute service, meaning you only pay for actual usage (requests and execution time). Coupled with API Gateway, this solution can be cost-effective for low traffic, as there are no charges for idle time. Additionally, API Gateway offers caching, which would help reduce backend requests and improve efficiency.
- Use Case: Ideal for small-scale applications with low to moderate traffic where minimal management is ne...
Author: Sam · Last updated Jul 14, 2026
An e-commerce web application that shares session state on-premises is being migrated to AWS. The application must be fault tolerant, natively highly scalable, and any service interruption should n...
To determine the best option for storing session state in a fault-tolerant, highly scalable, and resilient way, we need to consider the following factors:
1. Scalability and Fault Tolerance: The solution must be capable of automatically scaling with the application traffic and provide high availability with minimal downtime.
2. Session State Persistence: Since the application is migrating from on-premises and needs to maintain user sessions, the session state should be stored in a way that allows quick access and persistence across multiple application instances.
3. User Experience: Any service interruption should not negatively affect user experience, so the session state should be accessible even if certain parts of the system fail or need to scale.
Let's evaluate each option:
A) Store the session state in Amazon ElastiCache.
- Cost Considerations: ElastiCache is a managed caching service that supports both Redis and Memcached. It is designed for low-latency, highly available storage. Redis, in particular, supports persistence options to store session data, and it can replicate data across multiple availability zones to ensure high availability.
- Fault Tolerance: ElastiCache can be configured to provide fault tolerance through replication and automatic failover, ensuring that session data is always available even in the event of a failure.
- Scalability: ElastiCache can scale easily and is well-suited for handling session state in a distributed, highly scalable environment.
- Selected Reason: This is the best option because it provides fast, reliable access to session state with high availability and fault tolerance. It also scales automatically with the application traffic and is commonly used in web applications for session management.
B) Store the session state in Amazon CloudFront.
- Cost Considerations: CloudFront is a Content Delivery Network (CDN) that caches content at edge locations. It is not designed to store dynamic session data.
- Fault Tolerance: While CloudFront is fault-tolerant for caching static content (e.g., images, CSS files), it is not suited for dynamic session state storage as it doesn’t offer the capabilities of managing or persisting session data.
- Scalability: CloudFront is scala...
Author: Zain · Last updated Jul 14, 2026
A developer is building an application that uses Amazon DynamoDB. The developer wants to retrieve multiple specific items from the database with a single API call.
Which DynamoDB ...
To retrieve multiple specific items from Amazon DynamoDB with the minimum impact on the database, we need to consider the efficiency, cost, and impact on database performance of each option.
Let's evaluate each option:
A) BatchGetItem
- Purpose: `BatchGetItem` allows you to retrieve up to 100 items (or 16 MB of data) from one or more DynamoDB tables in a single API call. This is efficient for retrieving multiple specific items by their primary key (Partition Key and optionally the Sort Key).
- Impact on Database: It minimizes the number of calls to DynamoDB by allowing you to retrieve multiple items in one request. It ensures that the request only reads the requested items and does not scan the entire table, making it efficient.
- Cost: `BatchGetItem` costs are based on the number of items retrieved, making it more cost-effective for retrieving specific items.
- Selected Reason: This is the most appropriate choice for retrieving multiple specific items in a single call with the least impact on the database. It is designed specifically for this use case and avoids unnecessary database scanning.
B) GetItem
- Purpose: `GetItem` is used to retrieve a single item from a table by specifying its primary key. It retrieves an individual item with high performance and low latency.
- Impact on Database: `GetItem` is efficient for retrieving a single item, but it requires one call per item. If multiple items need to be retrieved, multiple `GetItem` requests would be needed, which would result in more calls to the database.
- Cost: Each `GetItem` incurs a separate cost, so retrieving multiple items would be more expensive and would increase the impact on the database due to multiple calls.
- Rejected Reason: Not suitable for retrieving multiple items in a single API call. It's efficient for single item retrieval but not for batch operations.
C) Scan
- Purpose: `Scan` reads all items in a table a...
Author: Vikram · Last updated Jul 14, 2026
A developer has written an application that runs on Amazon EC2 instances. The developer is adding functionality for the application to write objects to an Amazon S3 bucket.
Which ...
To allow Amazon EC2 instances to write objects to an Amazon S3 bucket, the EC2 instances need the proper permissions through an IAM role. Let's evaluate the given options based on which policy must be modified:
Option Evaluation:
A) The IAM policy that is attached to the EC2 instance profile role
- Purpose: The IAM role attached to an EC2 instance is responsible for defining what actions the instance can perform on AWS resources. This IAM role can have policies that grant permissions to interact with various services, including Amazon S3.
- Action: For the EC2 instance to write to an S3 bucket, the IAM policy attached to the EC2 instance profile role must explicitly grant the `s3:PutObject` permission on the target S3 bucket.
- Explanation: This is the correct option because the EC2 instance profile role controls the permissions of the EC2 instances, and an IAM policy on that role can grant the necessary permissions to write to an S3 bucket.
- Selected Reason: The IAM policy attached to the EC2 instance profile role directly controls the permissions for the EC2 instance, making this the correct place to modify permissions for writing objects to an S3 bucket.
B) The session policy that is applied to the EC2 instance role session
- Purpose: Session policies are temporary policies that are applied to a specific session. They are usually used in scenarios where temporary security credentials are required (for example, when using AWS STS). Session policies typically come into play for short-lived sessions or cross-account access.
- Explanation: While session policies can be used in certain contexts (e.g., temporary credentials), they are not the primary mechanism for controlling the EC2 instance’s permissions for tasks like writing to an S3 bucket.
- Rejected Reason: This option is less relevant for the typical use case of assigning long-term permissions for EC2 instances. It adds complexity without being the correct place to modify permissions for accessing S3.
C) The AWS...
Author: Emma · Last updated Jul 14, 2026
A developer is leveraging a Border Gateway Protocol (BGP)-based AWS VPN connection to connect from on-premises to Amazon EC2 instances in the developer's account. The developer is able to access an EC2 instance in subnet A, but is unable to access an EC2 instance in...
In this scenario, the developer is unable to access an EC2 instance in subnet B, but can access an EC2 instance in subnet A, which suggests a potential issue with routing, security groups, or network ACLs affecting the traffic to subnet B. The developer needs to verify whether the traffic is actually reaching subnet B, and which logs would provide the most insight into the path and handling of this traffic.
Evaluation of each option:
A) VPN logs
- Purpose: VPN logs contain information about the VPN connection status, including any issues with establishing or maintaining the VPN tunnel. They also provide details on whether the VPN connection is up and operational.
- Explanation: While VPN logs can provide insight into the overall status of the VPN tunnel, they do not provide specific details on whether traffic is reaching particular subnets or EC2 instances within the VPC. These logs focus more on the connection's health rather than the actual flow of traffic to specific resources inside the VPC.
- Rejected Reason: VPN logs are useful for diagnosing connectivity issues at the tunnel level, but they do not show if traffic reaches specific subnets like subnet B.
B) BGP logs
- Purpose: BGP logs show the Border Gateway Protocol (BGP) routing information exchanged between the on-premises network and AWS. These logs provide details on how routes are being advertised and learned by the VPN connection.
- Explanation: BGP logs can indicate whether the routing for the VPC subnets is correctly established between the on-premises network and AWS. However, BGP logs focus on route advertisements rather than on the actual traffic flow reaching specific subnets or instances. They may help identify issues with routing, but not necessarily whether traffic to a specific subnet is reaching its destination.
- Rejected Reason: While BGP logs provide insights into routing, they do not provide vis...
Author: Jack · Last updated Jul 14, 2026
A developer is creating a service that uses an Amazon S3 bucket for image uploads. The service will use an AWS Lambda function to create a thumbnail of each image. Each time an image is uploaded, the service needs to send an email notification and create the thumbnail. The develop...
Let's break down each option in detail to determine the best solution based on the given requirements.
Requirements:
1. Image upload in S3.
2. Lambda function to create thumbnails of images.
3. Email notifications upon each image upload.
Option A:
- Create an Amazon SNS topic.
- Configure S3 event notifications to trigger on image uploads, sending events to SNS.
- Subscribe the Lambda function to the SNS topic, so the Lambda function will execute on each image upload.
- Create an email notification subscription to SNS, so an email notification will be sent upon image upload.
Pros:
- Simple architecture with direct communication.
- Lambda can trigger directly from SNS, ensuring that the image processing starts immediately.
- SNS handles the email notifications easily.
Cons:
- In this solution, both the Lambda function and email subscription rely on the same SNS topic. There's no separation between the Lambda processing and the notification system. Though this isn't a significant issue, it could be less flexible if the system needs further customization or scaling in the future.
Option B:
- Create an Amazon SNS topic.
- Configure S3 event notifications to trigger on image uploads and send events to SNS.
- Subscribe the Lambda function to the SNS topic.
- Create an SQS queue and subscribe it to the SNS topic.
- Create an email notification subscription to the SQS queue.
Pros:
- Using both SNS and SQS introduces redundancy and buffering. If there is a high volume of image uploads, SQS can help buffer events and avoid overload in case the system can't process images as fast as they're uploaded.
Cons:
- The email notification is now sent through an SQS queue, which adds unnecessary complexity. SQS isn't needed for the email notification in this use case because SNS can directly handle the email notifications.
- This setup adds an extra layer that is redundant for this specific scenario. It complicates the architecture ...
Author: Noah · Last updated Jul 14, 2026
A developer has designed an application to store incoming data as JSON files in Amazon S3 objects. Custom business logic in an AWS Lambda function then transforms the objects, and the Lambda function loads the data into an Amazon DynamoDB table. Recently, the workload has experienced sudden and significant changes in traffic. The flow of data to the DynamoDB table is becoming throttled.
The deve...
Let's evaluate each option based on the key requirements: eliminating throttling, ensuring consistent data loading, and handling the sudden changes in traffic.
A) Refactor the Lambda function into two functions. Configure one function to transform the data and one function to load the data into the DynamoDB table. Create an Amazon Simple Queue Service (Amazon SQS) queue in between the functions to hold the items as messages and to invoke the second function.
- Pros:
- By decoupling the transformation and loading logic, you can handle traffic spikes more efficiently.
- SQS can act as a buffer between the two Lambda functions, helping to smooth out spikes in the data flow. This prevents throttling by allowing the second Lambda function to process messages at a manageable rate.
- SQS also ensures durability, so if there's a failure, the data can be retried.
- Cons:
- The added complexity of managing an SQS queue and two Lambda functions could introduce more overhead.
- This solution does not directly address the root cause of the throttling, which is related to the DynamoDB write capacity.
B) Turn on auto scaling for the DynamoDB table. Use Amazon CloudWatch to monitor the table's read and write capacity metrics and to track consumed capacity.
- Pros:
- Auto scaling in DynamoDB automatically adjusts read and write capacity units based on traffic, which could help alleviate throttling issues caused by sudden traffic spikes.
- CloudWatch can help monitor the table's performance and make adjustments in real-time.
- Cons:
- Auto scaling might take some time to react to sudden bursts of traffic, potentially leading to temporary throttling while capacity increases.
- This solution doesn't decouple the workload from the Lambda function, meaning if the Lambda function is the bottleneck, it won't fully address the issue.
C) Create an alias for the Lambda function. Configure provisioned concurrency for the application to use.
- Pros:
- Provisioned concurrency ensures that a set number of Lambda function instances are ready t...
Author: FlamePhoenix2025 · Last updated Jul 14, 2026
A developer is creating an AWS Lambda function in VPC mode. An Amazon S3 event will invoke the Lambda function when an object is uploaded into an S3 bucket. The Lambda function will process the object and produce some analytic results that will be recorded into a file. Each processed object will also generate a log entry that will be recorded into a file.
Other Lambda functions, AWS services, and on-premises resources must have access to the result files and log file. Each log entry mus...
Requirements Recap:
- Lambda function must store result and log files.
- Log file needs to be shared across Lambda functions, AWS services, and on-premises resources.
- The log file should be appendable by new log entries from different Lambda executions.
Let's break down each option and its suitability:
Option A: Amazon Elastic File System (Amazon EFS)
- Create an Amazon EFS file system, mount it to the Lambda function, and store both the result and log files in the mounted file system.
- The log entries can be appended to the log file since EFS allows shared access to the same file by multiple consumers (such as multiple Lambda functions).
Pros:
- Shared file system: EFS provides a fully managed NFS file system that can be mounted onto Lambda functions and shared among them. This means all Lambda functions, other AWS services, and on-premises systems can access the result files and log file consistently.
- Appends are supported: EFS can handle append operations on log files efficiently.
- Scalable and accessible: EFS scales automatically with usage and can be accessed from multiple sources concurrently.
Cons:
- Requires setting up VPC access for Lambda and the EFS file system. This adds some initial setup complexity, especially with security groups and access control.
Best for: Scenarios requiring a shared file system for multiple Lambda functions or AWS resources, especially when data needs to be appended and shared across multiple consumers.
Option B: Amazon Elastic Block Store (EBS) Multi-Attach Volume
- Create an Amazon EBS Multi-Attach enabled volume and attach it to all Lambda functions.
- Each Lambda function would download the log file, append log entries, and upload it back to EBS.
Pros:
- EBS allows for persistent storage and is durable, which is useful for storing results or logs.
Cons:
- EBS multi-attach is a new feature that is limited in functionality and works primarily with EC2 instances, not Lambda functions.
- Lambda cannot natively attach to an EBS volume in the same way EC2 instances can. The process of downloading, appending, and uploading files would introduce extra latency and complexity.
- EBS is not easily shareable between services and would not allow for seamless access from other AWS services or on-premises resources unless additional steps are taken (such as s...
Author: ElectricLionX · Last updated Jul 14, 2026
A company has an AWS Lambda function that processes incoming requests from an Amazon API Gateway API. The API calls the Lambda function by using a Lambda alias. A developer updated the Lambda function code to handle more details related to the incoming requests. The developer wants to deploy the new Lambda function for more testing by o...
Requirements Recap:
- The developer wants to deploy the updated Lambda function for testing purposes without affecting the production environment (i.e., customer-facing API calls).
- The solution should involve the least operational overhead, meaning it should be easy to set up and manage.
Let's break down each option and its suitability:
Option A: Create a new version of the Lambda function, create a new stage on API Gateway
- Create a new version of the Lambda function.
- Create a new stage in API Gateway that integrates with the new Lambda version.
- Use the new stage to test the updated Lambda function without impacting the existing production stage.
Pros:
- Simple and straightforward approach: By creating a new stage, you ensure that the production API remains unaffected while other developers can test the new version of the Lambda function through the new stage.
- Isolated testing: This method allows you to test the updated function without impacting the production environment.
- Minimal changes: It requires minimal changes to the current infrastructure (just adding a new stage in API Gateway and associating it with the new Lambda version).
Cons:
- Additional configuration in API Gateway, although it's relatively simple.
Best for: Scenarios where you want isolated testing without affecting the live traffic, and the operational overhead is kept to a minimum.
Option B: Update the existing Lambda alias to use a weighted alias
- Update the Lambda alias to use a weighted alias.
- Add the new Lambda version with a weight of 10% and use the same API Gateway stage.
Pros:
- This allows you to gradually shift traffic to the new Lambda version, which can be useful for testing in a production-like environment.
Cons:
- This introduces potential risk to customers as even 10% of the traffic will be routed to the new Lambda version. This goes against the requirement of testing without impacting customer traffic.
- It introduces more complexity than Option A for testing purposes since you're mixing live traffic with testing traffic, which can have unintended consequence...
Author: CrimsonViperX · Last updated Jul 14, 2026
A company uses AWS Lambda functions and an Amazon S3 trigger to process images into an S3 bucket. A development team set up multiple environments in a single AWS account.
After a recent production deployment, the development team observed that the development S3 buckets invoked the production environment Lambda functions. These invocations caused unwanted execution of development S3 files by using p...
Requirements:
- Prevent development S3 buckets from invoking production Lambda functions.
- Ensure security best practices are followed.
- Ensure that the correct Lambda function (production or development) processes the respective S3 files.
Let's evaluate each option based on these requirements:
Option A: Update the Lambda execution role for the production Lambda function to allow access only to the production S3 bucket
- This option suggests adding a policy to the Lambda execution role that limits its permissions to the production S3 bucket.
Pros:
- Restricting Lambda execution permissions ensures that the Lambda function can only interact with the production S3 bucket and not any other buckets.
- Security best practices are followed by restricting Lambda access to only what it needs.
Cons:
- Does not prevent S3 triggers: This solution addresses what the Lambda can access after it is invoked, but it does not address the root cause of the problem: the S3 event trigger itself. The S3 event trigger could still originate from the development bucket.
- This option only limits the Lambda execution role but does not prevent the wrong S3 bucket from triggering the Lambda.
Best for: Ensuring the Lambda function has restricted permissions after it is invoked, but not for solving the event trigger problem.
Option B: Move the development and production environments into separate AWS accounts and use Lambda resource policies
- This option suggests moving the environments into separate AWS accounts and adding a resource policy to each Lambda function to allow invocation only from S3 buckets within the same account.
Pros:
- Separation of environments: Moving environments to separate AWS accounts adds a layer of isolation, making it easier to manage access and security.
- Resource policy enforcement: By using Lambda resource policies, you can ensure that only the appropriate S3 buckets can invoke the respective Lambda functions.
Cons:
- Increased complexity: Moving environments to separate accounts can introduce significant operational overhead. You would need to manage multiple accounts and resources, which may not be necessary for every use case.
- More effort: Although this is a secure solution, it may require more setup and maintenance due to the increased number of accounts and inter-account permissions management.
Best for: Situations where a strict separation of environments is required, but might be overkill for si...
Author: Ryan · Last updated Jul 14, 2026
A developer is creating an application. New users of the application must be able to create an account and register by using their own social media accounts.
Which AWS...
To meet the requirement of allowing users to create accounts and register using their own social media accounts, the most suitable AWS service is Amazon Cognito user pools. Here's an explanation of why this option is selected and why the others are rejected:
A) IAM role
- Reason for rejection: IAM (Identity and Access Management) roles are used to manage permissions for AWS resources. While IAM roles are important for securing and controlling access to AWS resources, they are not designed to manage user authentication or social media logins for application users.
- Use case: IAM roles are suitable for granting permissions to AWS services or users for accessing AWS resources, not for managing user authentication.
B) Amazon Cognito identity pools
- Reason for rejection: While Amazon Cognito Identity Pools can integrate with social identity providers and enable federated authentication (allowing users to sign in using social media accounts), they are primarily used to grant temporary AWS credentials to authenticated users. This service is often used in conjunction with Cognito User Pools for a more comprehensive user authentication system, but on its own, it does not provide the full set of features needed for managing user accounts and registration.
- Use case: Identity pools are useful when you need to allow authenticated users to access AWS resources, but not for managing user registration, sign-in, and user pool features.
C) Amazon Cognito user pools
- R...
Author: Ella · Last updated Jul 14, 2026
A social media application uses the AWS SDK for JavaScript on the frontend to get user credentials from AWS Security Token Service (AWS STS). The application stores its assets in an Amazon S3 bucket. The application serves its content by using an Amazon CloudFront distribution with the origin set to the S3 bucket.
The credentials for the role that the application assumes to make the SDK calls are stored in plaintext in a JSON file within the application code. The deve...
To address the requirement of allowing the application to retrieve user credentials without having hardcoded credentials in the code, the best solution is to avoid storing credentials in plaintext and instead securely retrieve them dynamically. Here's an analysis of each option:
A) Add a Lambda@Edge function to the distribution. Invoke the function on viewer request. Add permissions to the function's execution role to allow the function to access AWS STS. Move all SDK calls from the frontend into the function.
- Reason for selection: Lambda@Edge allows you to run functions in response to CloudFront events (like viewer requests). By moving the SDK calls and the credentials retrieval logic into the Lambda function, you can securely call AWS STS without exposing credentials in the frontend code. Lambda@Edge has a global distribution, so it can serve the request from a location close to the user, optimizing performance.
- Key advantage: It allows the separation of credentials and SDK calls from the frontend code, thereby enhancing security. The permissions for Lambda to access AWS STS can be securely controlled.
- Use case: This is ideal for scenarios where you want to perform backend logic securely (like fetching credentials) without exposing any sensitive data on the frontend.
B) Add a CloudFront function to the distribution. Invoke the function on viewer request. Add permissions to the function's execution role to allow the function to access AWS STS. Move all SDK calls from the frontend into the function.
- Reason for rejection: CloudFront functions are lightweight, fast, and designed for basic manipulation of HTTP requests and responses. However, they have significant limitations when compared to Lambda@Edge, such as execution time and resource constraints. CloudFront functions cannot perform SDK calls or access complex AWS services like STS because they are intended for simpler tasks like modifying headers, URL rewrites, etc.
- Use case: This option would be useful for lightweight operati...
Author: MoonlitPantherX · Last updated Jul 14, 2026
An ecommerce website uses an AWS Lambda function and an Amazon RDS for MySQL database for an order fulfillment service. The service needs to return order confirmation immediately.
During a marketing campaign that caused an increase in the number of orders, the website's operations team noticed errors for =E2=80=9Ctoo many connections=E2=80=9D from Amaz...
To address the issue of "too many connections" from Amazon RDS, we need a solution that efficiently manages database connections, especially during traffic spikes. Here’s an analysis of each option:
A) Initialize the database connection outside the handler function. Increase the max_user_connections value on the parameter group of the DB cluster. Restart the DB cluster.
- Reason for rejection: While this approach could increase the number of allowed connections, it doesn’t resolve the underlying issue of inefficient or excessive connections being opened and closed with each Lambda invocation. Increasing the maximum connections setting could also lead to resource contention in the long term, which would not scale well as traffic increases. Restarting the DB cluster also introduces unnecessary downtime.
- Use case: This might be useful in some cases for quickly increasing connection limits, but it doesn’t address connection management in a more scalable way.
B) Initialize the database connection outside the handler function. Use RDS Proxy instead of connecting directly to the DB cluster.
- Reason for selection: RDS Proxy is specifically designed to help manage and pool database connections in serverless environments like AWS Lambda. It helps by reducing the number of concurrent connections to the database, enabling better reuse of connections across multiple Lambda invocations, and improves the overall scalability of the application. Moving to RDS Proxy will allow the Lambda function to scale efficiently without running into connection issues, even during high traffic.
- Key advantage: RDS Proxy improves performance by efficiently managing database connections and reducing the overhead caused by opening and closing connections frequently, thus resolving the "too many connections" error.
- Use case: This is the ideal solution when you need to handle a large number of database connections efficiently in a serverless environment, especially for Lambda fu...
Author: Noah · Last updated Jul 14, 2026
A company stores its data in data tables in a series of Amazon S3 buckets. The company received an alert that customer credit card information might have been exposed in a data table on one of the company's public applications. A developer needs to identi...
To identify potential exposures of sensitive customer data such as credit card information within the application environment, the solution needs to scan the S3 buckets for such sensitive information. The ideal service to use for this type of detection is Amazon Macie, which is specifically designed for discovering, classifying, and protecting sensitive data in Amazon S3. Here’s an analysis of each option:
A) Use Amazon Athena to run a job on the S3 buckets that contain the affected data. Filter the findings by using the SensitiveData:S3Object/Personal finding type.
- Reason for rejection: Amazon Athena is a powerful query service for running SQL queries on data stored in S3, but it is not specifically designed to detect sensitive data. While Athena can be used to analyze data, it requires manual setup of queries and does not natively provide the ability to classify sensitive information like credit card data. It would not automatically identify and classify sensitive data as efficiently as Amazon Macie.
- Use case: Athena is useful for querying large datasets, but it is not the right tool for discovering sensitive information automatically.
B) Use Amazon Macie to run a job on the S3 buckets that contain the affected data. Filter the findings by using the SensitiveData:S3Object/Ficial finding type.
- Reason for rejection: The SensitiveData:S3Object/Ficial finding type is not appropriate for identifying customer credit card information. This finding type would be more relevant for detecting financial data or other types of structured data that are not categorized as personal sensitive information like credit card numbers. Therefore, it would not help in the search for credit card data specifically.
- Use case: This could be used if you were looking for financial data, but it doesn't fit the need to detect personal sensitive information like credit card numbers.
C) Use Amazon Macie to ru...
Author: Aditya · Last updated Jul 14, 2026
A software company is launching a multimedia application. The application will allow guest users to access sample content before the users decide if they want to create an account to gain full access. The company wants to implement an authentication process that can identify users who have already created an account. The company also needs to...
To meet the requirements of allowing guest users to access sample content, tracking when they create accounts, and identifying users who have already created an account, the best solution involves the integration of Amazon Cognito for user authentication and identity management. Here's the breakdown of the options:
A) Create an Amazon Cognito user pool. Configure the user pool to allow unauthenticated users. Exchange user tokens for temporary credentials that allow authenticated users to assume a role.
- Reason for rejection: Amazon Cognito user pools are designed primarily for authenticating users who have accounts. However, this option doesn’t fully meet the requirement of supporting guest users (unauthenticated users) without accounts. While it could handle authenticated users, it doesn't directly allow the management of unauthenticated guest users.
- Key issue: This option would be better suited if the focus were only on authenticated users, but it doesn’t handle the unauthenticated guest user requirement effectively.
B) Create an Amazon Cognito identity pool. Configure the identity pool to allow unauthenticated users. Exchange unique identity for temporary credentials that allow all users to assume a role.
- Reason for selection: Amazon Cognito identity pools are designed to handle both authenticated and unauthenticated users. An identity pool allows the system to assign a unique identity to unauthenticated users and also lets authenticated users assume a role with specific permissions. This setup allows guest users to access sample content and, once they register or log in, their identity is upgraded to authenticated status, ensuring the tracking of users who create accounts.
- Key advantage: Identity pools offer an efficient solution for handling guest users while providing a smooth transition to authenticated user status once the user creates an account. This is crucial for tracking and identifying users who move from the guest to the authenticated category.
C) Create an Amazon CloudFront distribution. Configure the distribution to allow unauthenticated users. Exchange user tokens for temporary credentials that allow all users to assume a role.
- Reason for rejection: While CloudFront can help serve content, it is not designed to manage user authentication and user tracking. CloudFront alone doesn’t provide a mechanism to differentiate between guest use...
Author: GlowingTiger · Last updated Jul 14, 2026
A company is updating an application to move the backend of the application from Amazon EC2 instances to a serverless model. The application uses an Amazon RDS for MySQL DB instance and runs in a single VPC on AWS. The application and the DB instance are deployed in a private subnet in the ...
In this scenario, the company wants to move the backend to a serverless model, and AWS Lambda will need to connect to an Amazon RDS for MySQL DB instance in a private subnet within a VPC. The key points to focus on when selecting the correct solution include Lambda's VPC connectivity, security policies, and how the Lambda function can access the RDS instance in a secure and controlled manner.
Option Analysis:
A) Create Lambda functions inside the VPC with the AWSLambdaBasicExecutionRole policy attached to the Lambda execution role. Modify the RDS security group to allow inbound access from the Lambda security group.
- Reason for Rejection:
- The AWSLambdaBasicExecutionRole policy does not provide the required permissions for Lambda to access resources inside a VPC (such as RDS).
- Lambda needs the AWSLambdaVPCAccessExecutionRole policy to allow access to the VPC. Without this role, Lambda functions cannot connect to resources in a VPC.
- This option is missing the necessary VPC access permissions.
B) Create Lambda functions inside the VPC with the AWSLambdaVPCAccessExecutionRole policy attached to the Lambda execution role. Modify the RDS security group to allow inbound access from the Lambda security group.
- Reason for Selection:
- This solution allows the Lambda function to be placed inside the VPC and grants the necessary permissions through AWSLambdaVPCAccessExecutionRole, enabling access to the RDS instance.
- Modifying the RDS security group to allow inbound access from the Lambda security group ensures that the Lambda functions can securely connect to the RDS database.
- This is a solid choice because it meets both connectivity and security requirements.
C) Create Lambda functions with the AWSLambdaBasicExecutionRole policy attached to the Lambda execution role. Create an interface VPC endpoint for the Lambda functions. Configure the interface...
Author: Deepak · Last updated Jul 14, 2026
A company has a web application that runs on Amazon EC2 instances with a custom Amazon Machine Image (AMI). The company uses AWS CloudFormation to provision the application. The application runs in the us-east-1 Region, and the company needs to deploy the application to the us-west-1 Region.
An attempt to create the AWS CloudFormation stack in us-west-1 fails. An error message states that the...
Solution Analysis:
The error message indicates that the AMI ID used in the CloudFormation template is specific to the us-east-1 region and does not exist in the us-west-1 region. The goal is to resolve this error with minimal operational overhead, which means finding a solution that requires as little manual intervention as possible and avoids creating significant new operational complexity.
Option Analysis:
A) Change the AWS CloudFormation templates for us-east-1 and us-west-1 to use an AWS AMI. Relaunch the stack for both Regions.
- Reason for Rejection:
- This option does not directly address the issue of using a custom AMI across regions. Changing the AMI to a standard AWS AMI (such as Amazon Linux or Windows) may bypass the problem temporarily, but it doesn’t resolve the long-term need for using a custom AMI that was originally created in us-east-1.
- This option doesn’t meet the requirement of using a custom AMI, so it’s not a permanent solution.
B) Copy the custom AMI from us-east-1 to us-west-1. Update the AWS CloudFormation template for us-west-1 to refer to the AMI ID for the copied AMI. Relaunch the stack.
- Reason for Selection:
- This option directly addresses the problem and ensures that the custom AMI from us-east-1 is available in us-west-1. AMI IDs are region-specific, so copying the custom AMI to us-west-1 allows the AWS CloudFormation stack in that region to reference the correct AMI ID.
- This solution requires minimal changes to the existing CloudFormation template and ensures the AMI is available in the target region.
- Once the AMI is copied and the CloudFormation tem...
Author: Victoria · Last updated Jul 14, 2026
A developer is updating several AWS Lambda functions and notices that all the Lambda functions share the same custom libraries. The developer wants to centralize all the libraries, update the libraries in a convenient way, and keep the ...
Solution Analysis:
The developer wants to centralize custom libraries, manage versions, and update them conveniently with minimal development effort. Let’s review the options and evaluate the least effort approach for meeting these requirements:
Option Analysis:
A) Create an AWS CodeArtifact repository that contains all the custom libraries.
- Reason for Rejection:
- AWS CodeArtifact is a fully managed artifact repository service that can store various types of packages (e.g., Maven, npm, PyPI, etc.), and it can indeed store and version libraries.
- However, integrating CodeArtifact with AWS Lambda is more complex compared to using Lambda Layers. Lambda would need to pull from CodeArtifact manually or via additional CI/CD pipelines, which increases the development effort for managing the custom libraries across multiple Lambda functions.
- This option introduces unnecessary overhead for a simple Lambda function use case, especially when Lambda Layers are a more native solution.
B) Create a custom container image for the Lambda functions to save all the custom libraries.
- Reason for Rejection:
- A custom container image is a powerful solution that allows you to define all dependencies in a Docker image, including custom libraries. However, this requires you to manage container images, push them to Amazon ECR, and configure each Lambda function to use the image.
- While this solution is flexible, it adds significant complexity and overhead for maintaining the custom libraries when Lambda Layers offer a simpler and more specialized solution.
- It is best suited for scenarios where you need full control over the runtime environment of Lambda, but this is not required for simply managing shared custom libraries.
C) Create a Lambda layer that contains all the custom libraries.
- Reason for Selection...
Author: Leah Davis · Last updated Jul 14, 2026
A developer wants to use AWS Elastic Beanstalk to test a new version of an application in a test environment.
Whi...
Solution Analysis:
The developer wants to test a new version of an application in a test environment and is concerned about deployment speed. Let’s evaluate each Elastic Beanstalk deployment method and select the one that offers the fastest deployment.
Option Analysis:
A) Immutable
- Reason for Rejection:
- The Immutable deployment method involves creating a new environment with the updated application version. Once the new environment is successfully deployed and verified, traffic is switched to it.
- While this method offers high availability and low risk because the old environment remains running during the deployment, it is the slowest deployment method because it involves creating and verifying a completely new environment.
- This method is ideal for minimizing risk in production environments but is not the fastest deployment option for testing purposes.
B) Rolling
- Reason for Rejection:
- In the Rolling deployment method, Elastic Beanstalk deploys the new version of the application in batches. It updates a few instances at a time, waits for them to become healthy, and then proceeds to the next batch.
- While this method minimizes downtime and ensures the application remains available throughout the deployment, it is slower than All at once because it involves updating the instances in a step-by-step manner rather than in one go.
- Rolling deployments are typically used for production environments to ensure availability, but they are slower tha...
Author: Aarav · Last updated Jul 14, 2026
A company is providing read access to objects in an Amazon S3 bucket for different customers. The company uses IAM permissions to restrict access to the S3 bucket. The customers can access only their own files.
Due to a regulation requirement, the company needs...
Solution Analysis:
The company needs to enforce encryption in transit for interactions with Amazon S3 while allowing customers to access only their own files. The regulation requires that all access to objects in the S3 bucket must be encrypted during transit, meaning the communication between customers and S3 should occur over HTTPS (Secure Transport).
Let’s evaluate the options based on this requirement:
Option Analysis:
A) Add a bucket policy to the S3 bucket to deny S3 actions when the aws:SecureTransport condition is equal to false.
- Reason for Selection:
- The aws:SecureTransport condition key in the S3 bucket policy allows enforcing the use of HTTPS (Secure Transport) for interactions with the S3 bucket.
- If the request is made using HTTP instead of HTTPS (i.e., when aws:SecureTransport = false), the action will be denied.
- This solution directly meets the regulation requirement to enforce encryption in transit by ensuring that all access to the S3 bucket is via HTTPS.
- This approach is the simplest and most effective method to enforce encryption in transit at the S3 bucket level.
B) Add a bucket policy to the S3 bucket to deny S3 actions when the s3:x-amz-acl condition is equal to public-read.
- Reason for Rejection:
- This policy restricts public access to the S3 objects by denying actions where the x-amz-acl is set to public-read.
- While it helps to prevent objects from being publicly accessible, it does not enforce encryption in transit (HTTPS) and is not related to the regu...
Author: CrystalWolfX · Last updated Jul 14, 2026
A company has an image storage web application that runs on AWS. The company hosts the application on Amazon EC2 instances in an Auto Scaling group. The Auto Scaling group acts as the target group for an Application Load Balancer (ALB) and uses an Amazon S3 bucket to store the images for sale.
The company wants to develop a feature to test system requests. The feature wil...
Let’s break down each of the options based on key factors such as simplicity, cost, and effort required to implement the solution:
Option A: Create a new Auto Scaling group and target group for the beta version of the application. Update the ALB routing rule with a condition that looks for a cookie named version that has a value of beta. Update the test system code to use this cookie to test the beta version of the application.
- Analysis: This option allows the ALB to direct traffic to the beta target group based on the presence of a specific cookie. This solution is relatively simple because the ALB already supports routing based on request conditions like cookies. Additionally, the effort required to update the test system code is minimal, since only the cookie logic needs to be added to the system.
- Pros: Least complexity, uses existing ALB features, minimal changes to application logic.
- Cons: Requires updating the test system code to handle cookies.
Option B: Create a new ALB, Auto Scaling group, and target group for the beta version of the application. Configure an alternate Amazon Route 53 record for the new ALB endpoint. Use the alternate Route 53 endpoint in the test system requests to test the beta version of the application.
- Analysis: This option requires creating a completely new ALB and configuring a Route 53 record, which involves setting up a new domain and ensuring that requests to the beta version are routed properly. While this is feasible, it introduces more complexity due to the need for managing separate ALBs and DNS records.
- Pros: Clear separation of traffic between the production and beta environments.
- Cons: More setup effort (creating a new ALB, Route 53 configuration), and adds potential operational overhead.
Option C: Create a new ALB, Auto Scaling group, and target group ...
Author: ShadowWolf101 · Last updated Jul 14, 2026
A team is developing an application that is deployed on Amazon EC2 instances. During testing, the team receives an error. The EC2 instances are unable to access an Amazon S3 bucket....
Let's go through the options step by step, considering the context and reasoning for selecting the best troubleshooting steps:
Option A: Check whether the policy that is assigned to the IAM role that is attached to the EC2 instances grants access to Amazon S3.
- Analysis: This is a crucial step because EC2 instances typically access resources like S3 through IAM roles. The IAM role must have appropriate permissions to allow the EC2 instances to interact with S3 (e.g., `s3:GetObject`, `s3:PutObject`). If the IAM role does not have the right permissions, access to the S3 bucket will be blocked.
- Pros: Directly checks the permissions that are required for the EC2 instance to interact with S3.
- Cons: None; it's an essential check for IAM-based access issues.
Option B: Check the S3 bucket policy to validate the access permissions for the S3 bucket.
- Analysis: The S3 bucket policy can restrict or allow access to specific users, roles, or IP addresses. If the bucket policy denies access based on the IAM role or other conditions, the EC2 instance won’t be able to access the bucket. This is another critical place to check for access issues.
- Pros: This ensures that even if the EC2 instance has correct IAM permissions, the S3 bucket policy doesn't explicitly deny access.
- Cons: None; this is an important check to verify that the bucket is configured to allow the necessary access.
Option C: Check whether the policy that is assigned to the IAM user that is attached to the EC2 instances grants access to Amazon S3.
- Analysis: This is not relevant. EC2 instances access resources via IAM roles, not IAM users. The IAM user permissions would apply to human users or applications using the AWS SDK with specific credentials, not EC2 instances running on the role.
- Pros: None, as it doesn’t apply to ...
Author: IceDragon2023 · Last updated Jul 14, 2026
A developer is working on an ecommerce website. The developer wants to review server logs without logging in to each of the application servers individually. The website runs on multiple Amazon EC2 instances, is written in Python, and needs to be highl...
Let’s evaluate each option based on key factors like effort, impact, and alignment with the requirements for minimum changes and high availability:
Option A: Rewrite the application to be cloud-native and to run on AWS Lambda, where the logs can be reviewed in Amazon CloudWatch.
- Analysis: This option involves a significant rewrite of the application to transition from EC2-based infrastructure to AWS Lambda. This would require major code changes, modifications to the application architecture, and a complete shift to serverless technology. While Lambda could allow easier access to logs via CloudWatch, this option is not suitable given the requirement for minimum changes and would likely introduce unnecessary complexity.
- Pros: Logs can be centrally managed in CloudWatch; scalable solution.
- Cons: High effort, significant changes to the application, and not aligned with the goal of minimum changes.
Option B: Set up centralized logging by using Amazon OpenSearch Service, Logstash, and OpenSearch Dashboards.
- Analysis: This option suggests a centralized logging solution using a more complex stack of OpenSearch, Logstash, and Dashboards. While OpenSearch is a powerful tool for searching and analyzing logs, it introduces complexity by requiring setting up multiple components (OpenSearch, Logstash, Dashboards) that might be overkill for the current requirement of minimum changes.
- Pros: Offers powerful logging and search capabilities.
- Cons: Involves more setup and operational complexity than necessary for simple log aggregation, and it does not align with the need for minimal changes.
Option C: Scale down the application to one larger EC2 instance where only one instance is recording logs.
- Analysis: This option suggests consolidating the application onto a single larger EC2 instanc...
Author: Arjun · Last updated Jul 14, 2026
A company is creating an application that processes .csv files from Amazon S3. A developer has created an S3 bucket. The developer has also created an AWS Lambda function to process the .csv files from the S3 bucket.
Which combinat...
Let’s evaluate each option step by step based on the goal of invoking the Lambda function when a `.csv` file is uploaded to the S3 bucket:
Option A: Create an Amazon EventBridge rule. Configure the rule with a pattern to match the S3 object created event.
- Analysis: This is a correct and common approach. Amazon EventBridge allows you to create rules based on events from AWS services, such as S3. You can configure an EventBridge rule to listen for an S3 event (e.g., when a `.csv` file is uploaded to the S3 bucket) and trigger the Lambda function accordingly. This setup is fully event-driven and fits well with the goal of invoking a Lambda function on a file upload.
- Pros: EventBridge can efficiently capture events from S3 and invoke Lambda functions.
- Cons: None; this is a valid and widely used approach.
Option B: Schedule an Amazon EventBridge rule to run a new Lambda function to scan the S3 bucket.
- Analysis: This approach involves scheduling an EventBridge rule to invoke a Lambda function on a regular schedule (e.g., every minute). While this is a valid use of EventBridge, it is not an event-driven solution to trigger a Lambda function when a `.csv` file is uploaded. This is less efficient than triggering the Lambda directly from the S3 event since it involves unnecessary polling and can create delays.
- Pros: Allows periodic Lambda function invocations.
- Cons: It doesn’t directly react to file uploads and could introduce unnecessary overhead. This approach is not efficient for this use case, which specifically requires reacting to an S3 event.
Option C: Add a trigger to the existing Lambda function. Set the trigger type to EventBridge. Select the Amazon EventBridge rule.
- Analysis: While it sounds correct, this option is not accurate. Lambda functions can be triggered by EventBridge, but the correct way to trigger a Lambda function for an S3 event is through an S3 event notification, not through EventBridge in this context. S3 events shou...
Author: Isabella · Last updated Jul 14, 2026
A developer needs to build an AWS CloudFormation template that self-populates the AWS Region variable that deploys the CloudFormation template.
What is the MOST operationally e...
Let’s evaluate each option based on operational efficiency, simplicity, and best practices for determining the AWS Region where the CloudFormation template is deployed.
Option A: Use the AWS::Region pseudo parameter.
- Analysis: The `AWS::Region` pseudo parameter is a built-in parameter in AWS CloudFormation that automatically resolves to the AWS Region in which the CloudFormation stack is being deployed. It’s the simplest and most efficient way to reference the region, without needing to pass anything manually or create additional logic. Since it’s a CloudFormation pseudo parameter, there is no setup or external dependencies required.
- Pros:
- Simple and built-in.
- No additional configuration or input needed.
- Automatically populated.
- Cons: None; it’s the ideal choice for this requirement.
Option B: Require the Region as a CloudFormation parameter.
- Analysis: This option involves manually passing the region as a parameter when deploying the CloudFormation template. While this approach works, it requires the user to explicitly specify the region every time the template is deployed, which is not ideal. It also introduces room for error, as the region must be manually input.
- Pros: Allows the region to be set at deployment time.
- Cons:
- Increases the operational overhead, as users must remember to specify the region.
- Potential for mistakes or inconsistent region selection.
Option C: Find the Region from the AWS::StackId pseudo parameter by using the Fn::Split intrinsic function.
- Analysis:...
Author: Emma Brown · Last updated Jul 14, 2026
A company has hundreds of AWS Lambda functions that the company's QA team needs to test by using the Lambda function URLs. A developer needs to configure the authentication of the Lambda functions to allow access so that the QA IAM group ca...
To evaluate the best solution for this scenario, let's break down each option based on the requirements and AWS best practices.
Key factors:
1. Authentication Type for Lambda Function URLs: The Lambda function URL can be configured with either the `AWS_IAM` or `NONE` authentication type.
- AWS_IAM: This requires IAM authentication, meaning that an IAM identity (in this case, the QA IAM group) is authenticated and authorized to invoke the Lambda function.
- NONE: No authentication is required, which makes the function URL publicly accessible.
2. IAM Policies: The IAM policy must either be identity-based or resource-based to control access.
- Identity-Based Policy: This policy attaches to a specific IAM identity (like the QA IAM group) and allows them to perform actions (e.g., invoking Lambda functions).
- Resource-Based Policy: This policy attaches to the resource itself (in this case, the Lambda functions), and grants specific IAM users or groups permission to access the resource.
---
Option Analysis:
A) Create a CLI script that loops on the Lambda functions to add a Lambda function URL with the AWS_IAM auth type. Run another script to create an IAM identity-based policy that allows the lambda:InvokeFunctionUrl action to all the Lambda function Amazon Resource Names (ARNs). Attach the policy to the QA IAM group.
- Why it's valid: Using the `AWS_IAM` authentication type ensures that only authenticated IAM users (i.e., the QA group) can invoke the Lambda functions. An identity-based policy is appropriate here, as it directly grants permission to the IAM group to invoke Lambda functions.
- Why it’s good: The approach of using `AWS_IAM` for authentication ensures secure, controlled access. The identity-based policy is aligned with the best practice of managing permissions per user/group.
- Why it's preferred: This solution is scalable and maintains a high level of security by using IAM for authentication.
B) Create a CLI script that loops on the Lambda functions to add a Lambda function URL with the NONE auth type. Run another script to create an IAM resource-based policy that allows the lambda:InvokeFunctionU...
Author: Oscar · Last updated Jul 14, 2026
A developer maintains a critical business application that uses Amazon DynamoDB as the primary data store. The DynamoDB table contains millions of documents and receives 30-60 requests each minute. The developer needs to perform processing in near-real time on the documents when they are added or updated in ...
To evaluate the best solution for the developer's requirement of near-real-time processing of documents added or updated in DynamoDB, let’s break down each option based on the key factors and requirements.
Key Factors:
1. Real-Time Processing: The requirement is to process the documents in near-real time when they are added or updated.
2. Minimizing Changes to Existing Code: The solution should minimize changes to the existing application code.
3. Scalability: The solution should scale efficiently given that the application handles 30-60 requests per minute with millions of documents.
---
Option Analysis:
A) Set up a cron job on an Amazon EC2 instance. Run a script every hour to query the table for changes and process the documents.
- Why it’s not ideal: This approach relies on querying the table periodically (every hour), which means there is a delay between when the documents are updated and when they are processed. This does not provide near-real-time processing and introduces unnecessary complexity of managing an EC2 instance.
- Why rejected: The delay (hourly checks) does not meet the requirement of near-real-time processing, and the solution is more complex than needed.
B) Enable a DynamoDB stream on the table. Invoke an AWS Lambda function to process the documents.
- Why it’s ideal: DynamoDB Streams capture changes (insertions, updates, deletions) in real time. Enabling a stream allows you to track changes to the table and trigger a Lambda function for immediate processing. Lambda functions can handle real-time document processing efficiently and without managing servers.
- Why selected: This solution meets the requirement of near-real-time processing wi...
Author: Mia · Last updated Jul 14, 2026
A developer is writing an application for a company. The application will be deployed on Amazon EC2 and will use an Amazon RDS for Microsoft SQL Server database. The company's security team requires that database credentials are rotated...
To determine the best way to configure the database credentials for the application while meeting the security team's requirement of rotating credentials at least weekly, let’s analyze each option:
Key Factors:
1. Database Credentials Rotation: The primary requirement is to rotate the credentials automatically and securely at least weekly.
2. Security: The solution must ensure that the credentials are securely stored and managed.
3. Minimizing Manual Work: The solution should require as little manual intervention as possible and be easily automated.
---
Option Analysis:
A) Create a database user. Store the user name and password in an AWS Systems Manager Parameter Store secure string parameter. Enable rotation of the AWS Key Management Service (AWS KMS) key that is used to encrypt the parameter.
- Why it’s not ideal: AWS Systems Manager Parameter Store does allow for secure storage of parameters, but it does not support automatic password rotation out-of-the-box. You would need to implement a custom solution for rotation, which increases complexity and does not fully meet the requirement for automatic credential rotation.
- Why rejected: It requires custom logic for rotation and is not as seamless as other options that natively support credential rotation.
B) Enable IAM authentication for the database. Create a database user for use with IAM authentication. Enable password rotation.
- Why it’s not ideal: IAM authentication is an option for RDS for MySQL and PostgreSQL databases but not for Microsoft SQL Server (RDS for SQL Server does not support IAM authentication). Therefore, this solution is not feasible for an RDS for Microsoft SQL Server database.
- Why rejected: IAM authentication is not supported for Microso...
Author: Isabella1 · Last updated Jul 14, 2026
A real-time messaging application uses Amazon API Gateway WebSocket APIs with backend HTTP service. A developer needs to build a feature in the application to identify a client that keeps connecting to and disconnecting from the WebSocket connection. The developer also needs the ability to remove t...
To meet the requirements of identifying a client that keeps connecting and disconnecting from the WebSocket connection, and also being able to remove the client, let's break down each option.
Key Factors:
1. Real-time Client Identification: The application needs to track the state of clients connecting and disconnecting.
2. Client Removal: The developer needs a mechanism to identify and remove clients.
3. Minimal Changes to Existing Service: Ideally, the solution should be added with minimal disruption to the current setup.
---
Option Analysis:
A) Switch to HTTP APIs in the backend service.
- Why it’s not ideal: HTTP APIs are designed for stateless interactions and are not suitable for WebSocket-like persistent connections. The real-time nature of WebSocket APIs is essential for tracking client connections and disconnections, which HTTP APIs don't handle as they don’t support long-lived connections.
- Why rejected: HTTP APIs are not designed for the real-time WebSocket use case and would not meet the requirement of tracking clients that connect and disconnect frequently.
B) Switch to REST APIs in the backend service.
- Why it’s not ideal: REST APIs are also stateless and do not support long-lived connections like WebSockets. While REST APIs are useful for request/response interactions, they are not designed for maintaining a continuous connection to track client states in real time.
- Why rejected: Similar to HTTP APIs, REST APIs do not provide the persistent connection needed to track WebSocket clients' connect/disconnect events.
C) Use the callback URL to disconnect the client from the backend service.
- Why it’s not ideal: The callback URL functionality is not a standard feature of WebSocket API Gateway or the backend service. While callback URLs are commonly used in certain other integrations (e.g., for synchronous HTTP requests), they are not directly suited to WebSocket connection management...
Author: Liam · Last updated Jul 14, 2026
A developer has written code for an application and wants to share it with other developers on the team to receive feedback. The shared application code needs to be stored long-term with multipl...
To determine the best AWS service for storing the application code long-term, with versioning and batch change tracking, let’s analyze each option based on the requirements.
Key Factors:
1. Long-Term Storage: The application code needs to be stored for the long term.
2. Versioning: The service should support version control, so multiple versions of the code can be tracked.
3. Batch Change Tracking: The ability to track changes in the code, including when and by whom changes were made.
---
Option Analysis:
A) AWS CodeBuild
- Why it’s not ideal: AWS CodeBuild is a service for building and compiling code, not for storing code. While it integrates well with version control systems, it does not provide storage or versioning for long-term code management. Its primary purpose is to automate the build process, not to track and store multiple versions of code.
- Why rejected: CodeBuild does not offer version control or long-term code storage; it is mainly used for continuous integration and build automation.
B) Amazon S3
- Why it’s not ideal: Amazon S3 can be used to store application code, and it supports versioning on objects, but it is not designed for collaborative development or advanced code version control. Although S3 provides versioning for files, it lacks the features specifically designed for code management, like branching, merging, and commit history that a version control system offers.
- Why rejected: S3 is more suited for object storage rather than managing source code with features like batch change tracking and branching, ...
Author: Sam · Last updated Jul 14, 2026
A company's developer is building a static website to be deployed in Amazon S3 for a production environment. The website integrates with an Amazon Aurora PostgreSQL database by using an AWS Lambda function. The website that is deployed to production will use a Lambda alias that points to a specific version of the Lambda function.
The company must rotate the database credentials ...
Let's break down each option based on the company's requirements:
A) Store the database credentials in AWS Secrets Manager. Turn on rotation. Write code in the Lambda function to retrieve the credentials from Secrets Manager.
- Why it's a good option:
- Automatic Rotation: AWS Secrets Manager supports automatic rotation of credentials, which meets the company's requirement to rotate credentials every 2 weeks without manual intervention.
- Secure: Secrets Manager is a secure and AWS-native service for storing sensitive information like database credentials. It encrypts the credentials at rest and provides detailed access control policies for who can retrieve the secrets.
- Scalability: Once the credentials are rotated in Secrets Manager, the Lambda function can automatically retrieve the updated credentials each time it runs. It allows previous Lambda function versions to use the latest credentials when needed.
- Why other options are less suitable:
- B) Storing credentials as part of the Lambda function code is risky because it exposes sensitive information in the function code. While it can be updated per...
Author: Joseph · Last updated Jul 14, 2026
A developer is developing an application that uses signed requests (Signature Version 4) to call other AWS services. The developer has created a canonical request, has created the string to sign, and has calculated signing i...
Let’s analyze each option based on AWS Signature Version 4:
A) Add the signature to an HTTP header that is named Authorization.
- Why it’s a good option:
- The Authorization header is the correct place to include the signature when performing AWS Signature Version 4 signing. This header is used to carry the signed authorization information, including the signature, access key, and security token (if any). The signature itself is embedded within the Authorization header following the signature format specified in AWS documentation (e.g., `AWS4-HMAC-SHA256 Credential=access-key/region/date/aws-service/aws-request, SignedHeaders=headers, Signature=signature`).
- This is the most standard method and is supported by AWS when performing API requests.
B) Add the signature to a session cookie.
- Why it’s not ideal:
- AWS Signature Version 4 does not use session cookies for including the signature. The signature is a part of the HTTP request, specifically in the Authorization header, not in cookies.
- While session cookies might be used for session management in web applications, it is not part of AWS Signature Version 4 signing mechanism.
C) Add the signature to an HTTP header that is named Authentication.
- Why it’s not ideal:
- Authentication is not a valid header used for AWS Signature Version 4. The correct header is Aut...
Author: Max · Last updated Jul 14, 2026
A company must deploy all its Amazon RDS DB instances by using AWS CloudFormation templates as part of AWS CodePipeline continuous integration and continuous delivery (CI/CD) automation. The primary password for the DB instance must be automatically generated as ...
Let's evaluate the options based on the requirement to generate a secure password automatically during the deployment process, and the need for minimal development effort:
A) Create an AWS Lambda-backed CloudFormation custom resource. Write Lambda code that generates a secure string. Return the value of the secure string as a data field of the custom resource response object. Use the CloudFormation Fn::GetAtt intrinsic function to get the value of the secure string. Use the value to create the DB instance.
- Why it's not ideal:
- This option involves creating a Lambda-backed CloudFormation custom resource, which requires writing custom Lambda code to generate the password and then returning it as part of the resource response.
- This solution involves more development work because the Lambda function must be written, tested, and maintained, and it's not a fully managed service.
- There are more complex dependencies and management of the Lambda function, increasing overhead compared to other options.
B) Use the AWS CodeBuild action of CodePipeline to generate a secure string by using the following AWS CLI command: `aws secretsmanager get-random-password`. Pass the generated secure string as a CloudFormation parameter with the NoEcho attribute set to true. Use the parameter reference to create the DB instance.
- Why it's not ideal:
- While this solution involves using AWS CodeBuild to generate the password, it still requires passing that value as a CloudFormation parameter, and you would need to manage the security and lifecycle of the generated password within CodePipeline.
- This option requires more development work in terms of automating password generation via CLI within the build process and ensuring it integrates properly with CloudFormation.
- Although the `NoEcho` attribute hides the password, the password is still handled as a parameter, and not as securely as in a managed service like Secrets Manager.
C) Create an AWS Lambda-backed CloudFormation custom resource. Write Lambda code that generates a secure string. Return the value of the secure string as a data field of the custom resource response object. Use the CloudForm...
Author: Zara · Last updated Jul 14, 2026
An organization is storing large files in Amazon S3, and is writing a web application to display meta-data about the files to end-users. Based on the metadata a user selects an object to download. The organization needs a mechanism to index the files and provide s...
To meet the requirements of indexing files, providing metadata retrieval with single-digit millisecond latency, and supporting efficient object download selection, let’s evaluate each option:
A) Amazon DynamoDB
- Why it's the best option:
- Low-latency retrieval: Amazon DynamoDB is a fully managed NoSQL database designed to deliver single-digit millisecond response times for read and write operations. This aligns perfectly with the requirement for single-digit millisecond latency when retrieving metadata.
- Scalability: DynamoDB automatically scales to handle large amounts of data without manual intervention, which is crucial for storing and indexing large files efficiently.
- Integration with S3: DynamoDB can store metadata about the S3 files (e.g., file name, size, creation date, etc.) and can provide a fast way to query this metadata when users select files.
- Cost-effective for metadata indexing: Storing and retrieving metadata is ideal for a NoSQL database like DynamoDB, as it provides a cost-effective and fast way to index and query data.
B) Amazon EC2
- Why it's not ideal:
- EC2 instances are general-purpose compute resources, which could be used for any backend processing. However, EC2 doesn’t directly provide optimized indexing or low-latency data retrieval in the way DynamoDB does.
- To achieve the required latency, you would need to build and maintain your own indexing system (e.g., using an in-memory database like Redis) and handle scaling, performance, and availability concerns yourself. This would involve significantly more operational overhead compared to using DynamoDB.
C) AWS Lambda
- W...
