Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company runs an application on AWS. The application stores data in an Amazon DynamoDB table. Some queries are taking a long time to run. These slow queries involve an attribute that is not the table's partition key or sort key.
The amount of data that the application stores in the DynamoDB table is expecte...
Let's evaluate each option to determine the best approach for improving query performance in DynamoDB.
Option A: Increase the page size for each request by setting the Limit parameter to be higher than the default value. Configure the application to retry any request that exceeds the provisioned throughput.
- Pros:
- This option attempts to fetch more data per request.
- Cons:
- Does not optimize query performance: Increasing the page size will not necessarily speed up queries, especially if the underlying problem is inefficient access patterns (e.g., querying on non-indexed attributes).
- Retry mechanism for throughput: While configuring retries might help in case of provisioned throughput limits, it doesn’t address slow queries on non-key attributes.
- Worse performance: For slow queries, increasing the page size could actually result in longer response times as more data is fetched per request.
- When to use: This is not a suitable solution for optimizing queries on non-key attributes. The core issue is inefficient query design, not page size.
Option B: Create a global secondary index (GSI). Set the query attribute to be the partition key of the index.
- Pros:
- Optimizes for non-key attributes: A GSI allows you to create a secondary index on attributes that are not the primary partition key or sort key. By indexing the attribute involved in the slow queries, you can significantly speed up those queries.
- Increased performance: Queries that use the GSI will be faster since they will only look at the index, not the entire table.
- Cons:
- Increased storage cost: GSIs consume additional storage and can increase costs, as they maintain a copy of the indexed data.
- Writes may incur additional overhead: Adding a GSI can impact the performance of write operations, as DynamoDB must also update the index during writes.
- When to use: This is a highly suitable solution for improving performance when querying non-key attributes. A GSI would allow the application to query more efficiently based on the attribute that is not the partition or sort key.
Option C: Perform a parallel scan operation by issuing individual sc...
Author: Samuel · Last updated Jun 21, 2026
A company runs a payment application on Amazon EC2 instances behind an Application Load Balance. The EC2 instances run in an Auto Scaling group across multiple Availability Zones. The application needs to retrieve application secrets during the application startup and export the secrets as environment variables. These secrets m...
To address this requirement, let's evaluate each of the options based on the criteria provided:
A) Save the secrets in a text file and store the text file in Amazon S3. Provision a customer-managed key. Use the key for secret encryption in Amazon S3. Read the contents of the text file and read and export as environment variables. Configure S3 Object Lambda to rotate the text file every month.
Rejection Criteria:
- Encryption and Rotation: While this approach can use a customer-managed key for encryption, S3 itself doesn’t provide seamless integration for rotating secrets. Using S3 Object Lambda to automate the rotation adds unnecessary complexity and introduces extra layers of management.
- Development Effort: It requires manual management for the text file, encryption keys, and rotation automation via Lambda. This significantly increases the development overhead.
- Security Risks: Managing secrets as plain text files in S3, even with encryption, can present challenges in ensuring security and fine-grained access control.
B) Save the secrets as strings in AWS Systems Manager Parameter Store and use the default AWS KMS key. Configure an Amazon EC2 user data script to retrieve the secrets during the startup and export as environment variables. Configure an AWS Lambda function to rotate the secrets in Parameter Store every month.
Rejection Criteria:
- Rotation Automation: While AWS Systems Manager (SSM) Parameter Store is a good service for storing secrets with encryption, it doesn't provide automatic rotation out of the box. You would need to manually configure a Lambda function to handle the rotation, which adds development complexity.
- Development Effort: The manual Lambda configuration for rotating secrets requires custom code, which may introduce unnecessary complexity in this use case.
C) Save the secrets as base64 encoded environment variables in the application properties. Retrieve the secrets during the application startup....
Author: Liam · Last updated Jun 21, 2026
A company is using Amazon API Gateway to invoke a new AWS Lambda function. The company has Lambda function versions in its PROD and DEV environments. In each environment, there is a Lambda function alias pointing to the corresponding Lambda function version. API Gateway has one stage that is configured to point at the PROD alias.
The company wants to configure ...
To meet the requirement of enabling both the PROD and DEV Lambda function versions to be available simultaneously and distinctly in API Gateway, let's evaluate the options based on the following considerations:
A) Enable a Lambda authorizer for the Lambda function alias in API Gateway. Republish PROD and create a new stage for DEV. Create API Gateway stage variables for the PROD and DEV stages. Point each stage variable to the PROD Lambda authorizer to the DEV Lambda authorizer.
Rejection Criteria:
- Lambda Authorizer Focus: This option suggests using Lambda authorizers, which are used for controlling access to API Gateway endpoints based on the authorization logic. However, the core requirement is to route requests to distinct Lambda function versions in the PROD and DEV environments. The use of authorizers doesn't directly address the need to configure the Lambda function aliases for PROD and DEV.
- Unnecessary Complexity: Introducing authorizers unnecessarily complicates the solution because the primary goal is to route traffic to different Lambda versions, not to manage authorization.
B) Set up a gateway response in API Gateway for the Lambda function alias. Republish PROD and create a new stage for DEV. Create gateway responses in API Gateway for PROD and DEV Lambda aliases.
Rejection Criteria:
- Gateway Response Configuration: Gateway responses are typically used to manage HTTP responses (like error messages, success responses, etc.) from API Gateway, not to manage the Lambda function aliases or versions. This doesn't address the core requirement of directing API Gateway to different Lambda versions based on the environment (PROD vs. DEV).
- Irrelevant Configuration: The gateway response configuration is not suitable for routing Lambda invocations to specific versions of the Lambda function.
C) Use an environment variable for the Lambda function alias in API Gateway. Republish PROD and create ...
Author: Emma · Last updated Jun 21, 2026
A developer is working on an ecommerce platform that communicates with several third-party payment processing APIs. The third-party payment services do not provide a test environment.
The developer needs to validate the ecommerce platform's integration with the third-party payment processing APIs. The developer mus...
To address the developer's need for testing the ecommerce platform’s integration with third-party payment processing APIs without invoking the actual third-party APIs, we need a solution that simulates the behavior of these APIs. Let’s evaluate each option:
A) Set up an Amazon API Gateway REST API with a gateway response configured for status code 200. Add response templates that contain sample responses captured from the real third-party API.
Rejection Criteria:
- Limited Integration Simulation: This approach involves setting up a custom API Gateway to return a static status code of 200, which would not provide the flexibility required to fully mock the behavior of the third-party API.
- Basic Response: While it could return a "successful" response, it lacks the ability to simulate complex API responses, headers, and various API behaviors that are needed for comprehensive testing of the integration.
- Inadequate Mocking for Testing: This would not allow testing various scenarios and error conditions that the real payment APIs might trigger.
B) Set up an AWS AppSync GraphQL API with a data source configured for each third-party API. Specify an integration type of Mock. Configure integration responses by using sample responses captured from the real third-party API.
Rejection Criteria:
- GraphQL Context: AWS AppSync is designed for GraphQL APIs, which may not align well with the RESTful third-party payment APIs that the ecommerce platform uses.
- Overcomplication: Using AppSync for this use case would introduce unnecessary complexity, as it is more suited for managing GraphQL data sources and not a simple mock integration scenario.
- Irrelevant Technology Choice: It’s overkill to use a GraphQL API when the platform is working with REST APIs and only requires mocking the payment API responses.
C) Create an AWS Lambda function for each third-party API. Embed respons...
Author: David · Last updated Jun 21, 2026
A developer is storing many objects in a single Amazon S3 bucket. The developer needs to optimize the S3 bucket for high request rates.
How s...
To optimize an S3 bucket for high request rates, the developer needs to consider how S3 handles access to objects and how it can efficiently distribute requests across the available resources. Let's evaluate the options:
A) Store the objects by using S3 Intelligent-Tiering.
Rejection Criteria:
- Not Related to Request Rate Optimization: S3 Intelligent-Tiering is a storage class designed to optimize costs by automatically moving objects between two access tiers based on access patterns. While it helps manage cost-efficiency, it does not specifically address the optimization of request rates.
- Focus on Storage Costs: This option does not provide any particular benefit in terms of distributing requests across S3's infrastructure to handle high access rates.
B) Store the objects at the root of the S3 bucket.
Rejection Criteria:
- Single Prefix Issue: Storing all objects at the root of the S3 bucket means they would share the same prefix (i.e., the root), which could lead to hot spots where a large number of requests target the same location. This could result in performance bottlenecks and inefficient distribution of requests across S3's infrastructure.
- Limitations on High Request Rate Optimization: S3 is optimized for distributing requests across a large number of prefixes, and using a single prefix can limit this distribution, affecting performance under high request load.
C) Store the obj...
Author: Ming88 · Last updated Jun 21, 2026
A company deploys a new application to AWS. The company is streaming application logs to Amazon CloudWatch Logs. The company's development team must receive notification by email when the word "ERROR" appears in any log lines. A developer sets up an Amazon Simple Notification Service (Amazo...
To meet the requirement of notifying the development team when the word "ERROR" appears in any log lines, let's evaluate each option in detail:
A) Select the appropriate log group. Create a CloudWatch metric filter with "ERROR" as the search term. Create an alarm on this metric that notifies the SNS topic when the metric is 1 or higher.
Selection Criteria:
- Metric Filter and Alarm: A CloudWatch metric filter can be set up to search for the term "ERROR" in the log stream and convert it into a custom metric. Once this metric is created, an alarm can be set to trigger when the metric value is greater than or equal to 1, indicating that an "ERROR" has been logged.
- Notification Integration: This option integrates the SNS topic with the CloudWatch alarm, so when the alarm triggers, it will notify the development team.
- Scalable and Efficient: This approach efficiently meets the requirements, as it allows real-time monitoring and notification for each "ERROR" occurrence without needing to analyze the log lines manually.
- Optimal for Alerting: This is the most effective method to automate the process of monitoring log data and sending notifications based on specific content (like the word "ERROR").
B) In CloudWatch Logs Insights, select the appropriate log group. Create a metric query to search for the term "ERROR" in the logs. Create an alarm on this metric that notifies the SNS topic when the metric is 1 or higher.
Rejection Criteria:
- CloudWatch Logs Insights: While CloudWatch Logs Insights is useful for querying logs and generating insights, it is more suited for ad-hoc querying and analyzing logs rather than continuous monitoring and triggering alerts.
- Not Ideal for Continuous Monitoring: Logs Insights queries...
Author: Sofia · Last updated Jun 21, 2026
A company uses Amazon Simple Queue Service (Amazon SQS) to decouple its microservices architecture. Some messages in an SQS queue contain sensitive information. A developer must implement a soluti...
To meet the requirement of encrypting all the data at rest for sensitive messages in Amazon SQS, let's analyze the provided options:
A) Enable server-side encryption for the SQS queue by using an SQS managed encryption key (SSE-SQS).
- Explanation: Enabling SSE-SQS encrypts the data at rest automatically using Amazon's managed encryption keys (SSE-SQS). This option ensures that all messages in the SQS queue are encrypted as they are stored, meeting the requirement of securing sensitive information. This is a native and automatic feature of Amazon SQS, requiring minimal setup.
- Reasoning: This is the most direct and suitable solution for encrypting messages at rest in Amazon SQS, and it requires no additional manual steps. It leverages AWS-managed encryption keys, ensuring compliance and security without requiring further infrastructure management.
- Conclusion: This is the best option to achieve encryption at rest for SQS messages.
B) Use the aws:SecureTransport condition in the queue policy to ensure that only HTTPS (TLS) is used for all requests to the SQS queue.
- Explanation: This option focuses on ensuring that data is transmitted securely over HTTPS. While using HTTPS ensures that the data is encrypted in transit, it does not address the requirement for encrypting data at rest in the SQS queue. The sensitive information still resides unencrypted in the queue.
- Reasoning: This option protects data while it is in transit but does not meet the requirement of encrypting data when stored in SQS. It's a good practice for security in transit but doesn't solve the problem of encrypting the me...
Author: Evelyn · Last updated Jun 21, 2026
A company recently deployed a new serverless user portal. Users have reported that part of the portal is slow. The initial analysis found a single Amazon API Gateway endpoint that is responsible for the performance issues. The endpoint integrates with an AWS Lambda function. However, the Lambda function interacts wit...
To diagnose the source of the increased response time in the serverless user portal, we need to identify the source of the delay in the Lambda function that integrates with multiple APIs and AWS services. Let's evaluate each option in terms of effectiveness and alignment with best operational practices:
A) Update the Lambda function by adding logging statements with high-precision timestamps before and after each external request. Deploy the updated Lambda function. After accumulating enough usage data, examine the Amazon CloudWatch logs for the Lambda function to determine the likely sources for the increased response time.
- Explanation: Adding high-precision timestamps and custom logging inside the Lambda function could provide detailed insights into the duration of each external request. While this approach can help identify where time is being spent, it requires manual updates to the code and may not be as efficient as using a built-in monitoring tool.
- Reasoning: While logging is a helpful method for troubleshooting, it is less automated and doesn't provide a holistic, system-wide view. This could lead to more complexity and manual analysis, especially in serverless architectures where tracing end-to-end performance is critical.
- Conclusion: This approach is rejected because it requires custom code updates and lacks a comprehensive view of performance. It’s less efficient compared to other options that are designed specifically for performance monitoring.
B) Instrument the Lambda function with the AWS X-Ray SDK. Add HTTP and HTTPS interceptors and SDK client handlers. Deploy the updated Lambda function. Turn on X-Ray tracing. After accumulating enough usage data, use the X-Ray service map to examine the average response times to determine the likely sources.
- Explanation: AWS X-Ray is a powerful service for tracing and analyzing the performance of serverless applications, especially Lambda functions. By instrumenting the Lambda function with X-Ray, you can automatically trace requests, visualize performance bottlenecks, and identify the exact sources of delays. X-Ray provides detailed service maps, traces, and insights into the execution flow across services (including the Lambda function and external APIs).
- Reasoning: This is a highly effective and operationally efficient solution. AWS X-Ray provides an automatic and comprehensive way to trace requests, visualize latency, and drill ...
Author: MoonlitPantherX · Last updated Jun 21, 2026
A developer is building an event-driven application by using AWS Lambda and Amazon EventBridge. The Lambda function needs to push events to an EventBridge event bus. The developer uses an SDK to run the PutEvents EventBridge action and specifies no credentials in the code. After deploying the Lambda function, the developer ...
To resolve the AccessDeniedException error when the Lambda function is trying to push events to EventBridge, let's evaluate each option and its effectiveness:
A) Configure a VPC peering connection between the Lambda function and EventBridge.
- Explanation: VPC peering connects two Virtual Private Clouds (VPCs) so they can communicate. However, Amazon EventBridge is a fully managed service that is accessible over the public AWS infrastructure and does not require a VPC peering connection for communication. The issue here is related to permissions, not network connectivity.
- Reasoning: Since EventBridge doesn't need a VPC connection to be accessed by Lambda, this solution doesn't address the permission issue.
- Conclusion: This option is rejected because VPC peering is not necessary for accessing EventBridge, and it does not solve the permission-related issue.
B) Modify their AWS credentials to include permissions for the PutEvents EventBridge action.
- Explanation: AWS Lambda functions use an execution role (IAM role) that is assigned when the function is created or updated. The credentials for this role must grant sufficient permissions to access services like EventBridge. Modifying personal AWS credentials (such as those for the developer or their environment) would not address the permissions for the Lambda function itself.
- Reasoning: This option would only apply if the developer was invoking EventBridge from their personal credentials, which is not the case here. The issue is with the Lambda execution role, not the developer's credentials.
- Conclusion: This option is rejected because the credentials that need to be modified are those associated with the Lambda execution role, not the developer's AWS cred...
Author: John · Last updated Jun 21, 2026
A company's application has an AWS Lambda function that processes messages from IoT devices. The company wants to monitor the Lambda function to ensure that the Lambda function is meeting its required service level agreement (SLA).
A developer must implement a solution to determine the application's throughput in near real time. The throughput must be based on the number of messages that the Lambda function receives and processes in a given ti...
To meet the requirements of monitoring the Lambda function's throughput based on the number of messages it processes, while excluding the initialization and post-processing steps, let's evaluate the options:
A) Use the Lambda function's ConcurrentExecutions metric in Amazon CloudWatch to measure the throughput.
- Explanation: The `ConcurrentExecutions` metric measures the number of Lambda instances that are running at the same time, but it does not directly provide throughput based on the number of messages processed. It primarily helps with understanding resource usage, not throughput in terms of the number of messages processed.
- Reasoning: While `ConcurrentExecutions` is useful for monitoring Lambda concurrency, it doesn’t directly correlate to the number of messages processed. It’s not a valid metric for measuring throughput in the context of this scenario.
- Conclusion: This option is rejected because it does not measure the number of messages processed, which is the key metric for throughput.
B) Modify the application to log the calculated throughput to Amazon CloudWatch Logs. Use Amazon EventBridge to invoke a separate Lambda function to process the logs on a schedule.
- Explanation: While this approach could allow the developer to calculate throughput by analyzing logs, it introduces complexity and delays. Logs are not real-time metrics, and using EventBridge to invoke another Lambda function on a schedule adds unnecessary overhead and complexity, especially for a near-real-time requirement.
- Reasoning: This approach involves multiple services and steps, creating potential delays. It also doesn’t directly provide throughput metrics, and it requires additional resource management and scheduled processing.
- Conclusion: This option is rejected because it complicates the process and doesn't provide an efficient, real-time th...
Author: Suresh · Last updated Jun 21, 2026
A developer is using an AWS CodePipeline pipeline to provide continuous integration and continuous delivery (CI/CD) support for a Java application. The developer needs to update the pipeline to support the introduction of a new application dependency .jar file. The pipeline mu...
To meet the requirement of starting a build in AWS CodePipeline when a new version of a dependency `.jar` file becomes available, let's evaluate each option:
A) Create an Amazon S3 bucket to store the dependency .jar file. Publish the dependency .jar file to the S3 bucket. Use an Amazon Simple Notification Service (Amazon SNS) notification to start a CodePipeline pipeline build.
- Explanation: Storing the `.jar` file in an S3 bucket is a good option for versioning dependencies. Using an SNS notification when the file is updated in S3 can trigger the pipeline. However, SNS integration with CodePipeline is not as seamless as direct integration with AWS services like CodeCommit, ECR, or EventBridge. It requires setting up SNS notifications to trigger actions, which can add complexity.
- Reasoning: While this solution is feasible, it's not the most direct or optimal. It adds extra steps, as the SNS notification needs to trigger the pipeline. Additionally, managing file updates and versioning with SNS is less automated than other options.
- Conclusion: This option is rejected due to the additional complexity of SNS integration and lack of more native solutions for this scenario.
B) Create an Amazon Elastic Container Registry (Amazon ECR) private repository. Publish the dependency .jar file to the repository. Use an ECR source action to start a CodePipeline pipeline build.
- Explanation: Amazon ECR is optimized for container images and container-based workflows. While ECR supports storing Docker images, it is not designed for managing generic files such as `.jar` files. Therefore, using ECR for managing `.jar` dependencies is not appropriate because it's overkill and not its intended purpose.
- Reasoning: Using ECR for this scenario would be unnecessary and inefficient, as ECR is tailored for Docker images rather than files like `.jar` files.
- Conclusion: This option is rejected because ECR is not the right service for managin...
Author: Sofia2021 · Last updated Jun 21, 2026
A company with multiple branch locations has an analytics and reporting application. Each branch office pushes a sales report to a shared Amazon S3 bucket at a predefined time each day. The company has developed an AWS Lambda function that analyzes the reports from all branch offices in a single pass. The Lambda function stores the results in a datab...
To meet the company's requirement of analyzing sales reports at a specific time each day, let's evaluate the options based on cost-effectiveness, ease of implementation, and how well they meet the need for scheduling:
Option A: Configure an S3 event notification to invoke the Lambda function when a branch office uploads a sales report.
- Pros: This method ensures that the Lambda function runs immediately when a report is uploaded to the S3 bucket, providing real-time processing.
- Cons: The issue here is that the Lambda function will run each time a report is uploaded, which could be multiple times a day. This does not align with the requirement of triggering the analysis once per day at a specific time. It could lead to unnecessary Lambda executions and costs, which is not ideal.
- Rejected: This option would not meet the requirement of a daily, scheduled analysis.
Option B: Create an AWS Step Functions state machine that invokes the Lambda function once each day at the predefined time.
- Pros: AWS Step Functions could be used to orchestrate tasks, but setting it up to trigger the Lambda function on a daily schedule might add more complexity than necessary. It allows for more complex workflows if the process requires additional steps.
- Cons: Step Functions would incur additional costs, as you would be paying for the state machine executions, which may not be the most cost-effective approach if the requirement is just to run the Lambda function at a specific time each day.
- Rejected: While it is a powerful solution, it is more complex and le...
Author: FlamePhoenix2025 · Last updated Jun 21, 2026
A developer has an application that asynchronously invokes an AWS Lambda function. The developer wants to store messages that resulted in failed invocations of the Lambda function so that the application can retry the call la...
Let's evaluate each option based on the goal of storing failed invocation messages and enabling the application to retry the Lambda function with minimal operational overhead.
Option A: Set up Amazon CloudWatch Logs log groups to filter and store the messages in an Amazon S3 bucket. Import the messages in Lambda. Run the Lambda function again.
- Pros: CloudWatch Logs can capture logs from Lambda executions, and S3 can be used for storing messages.
- Cons: This approach would require manual intervention or custom code to import messages from S3 back into Lambda for retries. It adds unnecessary operational overhead because of the need for filtering, storing, and re-importing messages. It’s not an automated solution for retrying failed Lambda invocations.
- Rejected: This approach is more manual and involves significant operational complexity with custom logic for retries, which is not ideal for minimizing operational overhead.
Option B: Configure Amazon EventBridge to send the messages to Amazon Simple Notification Service (Amazon SNS) to initiate the Lambda function again.
- Pros: EventBridge and SNS can be used to handle events and trigger Lambda.
- Cons: While EventBridge can detect failed invocations, SNS alone does not handle message persistence for retries. It could be used to notify or alert on failures, but it doesn’t store failed messages in a way that supports retrying them efficiently. It would require further setup or manual intervention to store failed messages.
- Rejected: This approach is not focused on storing messages for retry later, as SNS is primarily used for notificat...
Author: Noah · Last updated Jun 21, 2026
A company is using AWS CloudFormation templates to deploy AWS resources. The company needs to update one of its AWS CloudFormation stacks.
What can the company do...
Let's evaluate each option to determine the most effective way to find out how the changes will impact the resources that are running:
Option A: Investigate the change sets.
- Pros: CloudFormation Change Sets allow you to preview the changes that will be applied to your stack before executing the update. A change set provides a detailed view of the resources that will be added, modified, or deleted, and helps to understand how the update might impact your current resources.
- Cons: There are no significant cons because this is the intended way to preview changes in CloudFormation before applying them.
- Selected: This is the best option because it allows you to assess the impact of changes before making any updates to the resources.
Option B: Investigate the stack policies.
- Pros: Stack policies protect resources from unintentional updates during a stack update by defining what changes are allowed for certain resources.
- Cons: While stack policies are useful for preventing certain changes from being applied, they do not provide a direct way to preview what changes will be made to resources in a stack. Stack policies only govern what CloudFormation is allowed to modify.
- Re...
Author: FlamePhoenix2025 · Last updated Jun 21, 2026
A company stores all personally identifiable information (PII) in an Amazon DynamoDB table named PII in Account A. Developers are working on an application that is running on Amazon EC2 instances in Account B. The application in Account B requires access to the PII table.
An administrator in Account A creates an IAM role named AccessPII that has permission to access the PII table. The administrator also creates a trust policy that speci...
To allow the application in Account B to access the PII table in Account A, we need to focus on how to properly set up permissions and ensure that the EC2 instances in Account B can assume the role in Account A to access the DynamoDB table.
Option A: Allow the EC2 IAM role the permission to assume the AccessPII role.
- Pros: This is required because the IAM role `AccessPII` in Account A needs to be assumed by the EC2 instances in Account B. The EC2 instances in Account B must be granted permission to assume the role in Account A.
- Cons: There are no significant cons. This step is necessary for the role assumption process to work properly.
- Selected: This step is essential for enabling the EC2 instances in Account B to assume the `AccessPII` role in Account A.
Option B: Allow the EC2 IAM role the permission to access the PII table.
- Pros: The EC2 instance in Account B needs permissions to access DynamoDB. This is necessary, but the real access to DynamoDB is granted once the EC2 role assumes the `AccessPII` role in Account A.
- Cons: This option is not sufficient on its own because the EC2 instance in Account B cannot directly access DynamoDB without assuming the `AccessPII` role first. Permissions to access the table must come from the assumed role, not directly from the EC2 IAM role.
- Rejected: This step is not needed because the actual permissions to access the DynamoDB table are granted via the role assumption from Account A, not directly by the EC2 IAM role in Account B.
Option C: Include the AWS API in the application code logic to obtain temporary credentials from the EC2 IAM role to access the PII table.
- Pros: The EC2 instance will automatically use the credentials associated wit...
Author: GlowingTiger · Last updated Jun 21, 2026
A gaming website gives users the ability to trade game items with each other on the platform. The platform requires both users' records to be updated and persisted in one transaction. If any update fails, the transaction must roll back.
Whic...
To meet the requirements of atomic, transactional operations, where both users' records need to be updated and persisted in one transaction, and the transaction should roll back if any part fails, we need to look for solutions that support transactions and rollback capabilities.
Option A: Amazon DynamoDB with operations made with the ConsistentRead parameter set to true
- Pros: DynamoDB supports strong consistency with `ConsistentRead`, ensuring that you read the most recent data. However, this option is about ensuring strong consistency in reads, not transactional writes with rollback functionality.
- Cons: DynamoDB does not natively support complex transactional operations with automatic rollback in the context described. While it supports conditional writes and atomic counters, it doesn't support full transactions for multi-item operations in the same way as relational databases or systems with explicit transaction support.
- Rejected: This does not fulfill the requirement of multi-record transactional operations with rollback capabilities across two users’ records in a trade scenario.
Option B: Amazon ElastiCache for Memcached with operations made within a transaction block
- Pros: ElastiCache is a distributed in-memory cache designed for fast read/write operations. It can support various caching patterns.
- Cons: ElastiCache does not provide transactional consistency or rollback capabilities for complex updates. It is primarily designed for caching, not transactional persistence. The idea of "transaction blocks" in ElastiCache doesn’t apply as it doesn't support atomic multi-key operations or rollback across operations in the way that a database system does.
- Rejected: ElastiCache is not suitable for transactional operations where rollback is needed for multiple updates.
Option C: Amazon DynamoDB with reads and writes made by using Transact operations
- Pros: DynamoDB's Transact operations (like `TransactWriteItems`) allow for multi-item, multi-table transactional writes. This feature ensures that all items in the transaction are either committed together or rolled back in the case of failure. This is highly suitable for the scenario where mult...
Author: Ava · Last updated Jun 21, 2026
A developer is deploying an application in the AWS Cloud by using AWS CloudFormation. The application will connect to an existing Amazon RDS database. The hostname of the RDS database is stored in AWS Systems Manager Parameter Store as a plaintext value. The developer needs to incorporate the database hostname into the CloudFormation templat...
In this scenario, the developer needs to reference the plaintext value of a database hostname stored in AWS Systems Manager Parameter Store within an AWS CloudFormation template. Let's evaluate each option:
A) Use the ssm dynamic reference
- Explanation: The `ssm` dynamic reference is used to reference parameters stored in the Systems Manager Parameter Store in a CloudFormation template. The `ssm` reference allows you to directly reference a parameter value, which can be plaintext or secure, using the parameter name.
- Suitability: This option is suitable because the database hostname is stored as a plaintext value in the Parameter Store, and using `ssm` dynamic references allows for the seamless retrieval of that parameter.
B) Use the Ref intrinsic function
- Explanation: The `Ref` intrinsic function is used to return the value of a resource or a parameter within a CloudFormation template. However, this function does not support direct access to parameter store values.
- Suitability: This option is not appropriate for accessing parameter store values. `Ref` is more suited for referring to CloudFormation resources like EC2 instances, se...
Author: Lucas · Last updated Jun 21, 2026
A company uses an AWS Lambda function to call a third-party service. The third-party service has a limit of requests each minute. If the number of requests exceeds the limit, the third-party service returns rate-limiting errors.
A developer needs to configure the Lambda functi...
To meet the requirement of avoiding rate-limiting errors from a third-party service when calling it via an AWS Lambda function, the solution should control the rate at which the Lambda function makes requests to the third-party service. Let's evaluate the options:
A) Set the reserved concurrency on the Lambda function to match the number of concurrent requests that the third-party service allows.
- Explanation: Reserved concurrency defines the maximum number of instances of the Lambda function that can run concurrently. By setting this value to match the number of requests that the third-party service can handle per minute, you can limit the number of concurrent invocations of the Lambda function, thus reducing the likelihood of exceeding the rate limit. However, this solution might not be ideal because it doesn't directly control the rate of requests over time (e.g., per minute). It only limits concurrent execution.
- Suitability: This could help to an extent but doesn't fully control the frequency of requests, and you might still hit rate limits if the Lambda invocations happen too rapidly within the minute.
B) Decrease the memory that is allocated to the Lambda function.
- Explanation: Memory allocation in Lambda impacts performance, such as CPU allocation and the function's execution speed. However, decreasing memory does not affect the rate of requests or how frequently the Lambda function is invoked. It would likely degrade the Lambda’s performance.
- Suitability: This option is irrelevant to controlling the request rate and is not helpful in addressing rate-limiting errors from the third-party service.
C) Set the provisioned concurrency on the Lambda function to match the number of concurrent requests that the third-part...
Author: Aarav2020 · Last updated Jun 21, 2026
A developer is building a new containerized application by using AWS Copilot. The developer uses the AWS Copilot command line interface (CLI) to deploy the application during development. The developer committed the application code to a new AWS CodeCommit repository. The developer must create an automated deployment process before ...
To automate the deployment process for the containerized application, the developer needs an efficient way to integrate the deployment steps (source, build, and deployment) while keeping operational overhead minimal. Let's evaluate each option:
A) Create a buildspec file that invokes the AWS Copilot CLI commands to build and deploy the application. Use the AWS Copilot CLI to create an AWS CodePipeline that uses the CodeCommit repository in the source stage and AWS CodeBuild in the build stage.
- Explanation: A `buildspec` file is typically used to define how CodeBuild should build and deploy an application. Using the Copilot CLI within CodeBuild can invoke the commands to build and deploy the application. However, this solution requires manually creating the CodePipeline and integrating it with CodeBuild. While this is functional, it adds complexity because the developer needs to manage the buildspec and the pipeline configuration manually.
- Suitability: This solution is feasible but not the most operationally efficient because it involves additional manual setup (e.g., buildspec) and custom configuration for pipeline creation.
B) Use the AWS Serverless Application Model (AWS SAM) CLI to bootstrap and initialize an AWS CodePipeline configuration. Use the CodeCommit repository as the source. Invoke the AWS Copilot CLI to build and deploy the application.
- Explanation: AWS SAM is typically used for serverless applications, particularly for AWS Lambda and API Gateway. While SAM could bootstrap a CodePipeline, it is not designed for containerized applications like those built with AWS Copilot. Integrating AWS SAM CLI with AWS Copilot is not the ideal combination, as it doesn't align with containerized workflows, which are better supported directly by Copilot.
- Suitability: This approach is not ideal because AWS SAM is not intended for containerized applications and wo...
Author: Amira99 · Last updated Jun 21, 2026
A developer is creating a new application for a pet store. The application will manage customer rewards points. The developer will use Amazon DynamoDB to store the data for the application. The developer needs to optimize query performance and limit partition overload before...
To optimize query performance and avoid partition overload in Amazon DynamoDB, the developer must choose a partition key that will help distribute the data evenly across partitions. This is crucial for ensuring that no single partition is overwhelmed by requests, leading to hot spots and degraded performance. Let’s analyze each option:
A) A randomly generated universally unique identifier (UUID)
- Explanation: A UUID is a random string, and when used as a partition key, it ensures that the data is evenly distributed across DynamoDB partitions. Since the UUID values are unique, it avoids data skew and helps prevent any single partition from becoming overloaded.
- Suitability: This option is highly effective for distributing traffic evenly, ensuring that there is no skew or hot spots on any specific partition. Using a UUID as a partition key guarantees even load distribution, which is ideal for optimizing performance and avoiding partition overload before performance analysis.
B) The customer's full name
- Explanation: Using the full name of the customer as the partition key could result in uneven distribution of data, especially if certain names are common (e.g., "John Smith"). This could lead to some partitions being overburdened, while others remain underutilized, causing performance bottlenecks.
- Suitability: This option is not ideal because it could cause skew in the distribution of data across p...
Author: Scarlett · Last updated Jun 21, 2026
A developer uses AWS IAM Identity Center (AWS Single Sign-On) to interact with the AWS CLI and AWS SDKs on a local workstation. API calls to AWS services were working when the SSO access was first configured. However, the developer is now receiving Access Denied errors. The developer has not changed any configurat...
In this scenario, the developer is receiving "Access Denied" errors after using AWS IAM Identity Center (AWS SSO) to interact with AWS services through the AWS CLI and SDKs. Since the configuration files or scripts have not changed, let's analyze each option to identify the most likely cause:
A) The access permissions to the developer's AWS CLI binary file have changed.
- Explanation: The permissions on the AWS CLI binary itself are unlikely to cause "Access Denied" errors when interacting with AWS services. If the binary had permission issues, the AWS CLI wouldn't work at all (e.g., the developer wouldn't be able to execute `aws` commands). The problem seems related to the AWS SSO authentication or the permissions associated with it, not the CLI binary file.
- Suitability: This is unlikely to be the cause of the issue. The developer is able to make API calls, but those calls are being denied, which points to an authentication or permission issue rather than a problem with the AWS CLI binary.
B) The permission set that is assumed by IAM Identity Center does not have the necessary permissions to complete the API call.
- Explanation: If the permission set assigned through AWS IAM Identity Center has been altered or doesn't include the necessary permissions to access the AWS services the developer is trying to use, it could result in "Access Denied" errors. However, if there has been no change to the permission set, this would not be the primary cause.
- Suitability: This option could be a potential cause if the IAM Identity Center permission set has been modified. However, if no changes were made...
Author: Ahmed · Last updated Jun 21, 2026
A company is building a serverless application. The application uses an API key to authenticate with a third-party application. The company wants to store the external API key as a part of an AWS Lambda configuration. The company needs to have full control over the AWS Key Management Service (AWS KMS) ke...
To meet the requirements of securely storing the API key with full control over the AWS Key Management Service (AWS KMS) keys and making it visible only to authorized entities, let's analyze each option:
A) Store the API key in AWS Systems Manager Parameter Store as a string parameter. Use the default AWS KMS key that AWS provides to encrypt the API key.
- Reasoning: While AWS Systems Manager Parameter Store is a secure service for storing sensitive information like API keys, using the default AWS KMS key limits the ability to fully control the encryption. The company would not have full control over the KMS key because the default KMS key is managed by AWS. This would not meet the requirement for full control over the KMS keys.
- Rejected because the company requires full control over the KMS key, which is not achieved when using the default AWS-managed key.
B) Store the API key in AWS Lambda environment variables. Create an AWS KMS customer-managed key to encrypt the API key.
- Reasoning: Storing the API key in Lambda environment variables is a good choice for serverless applications. By using a customer-managed KMS key, the company retains full control over the encryption and can restrict access to the API key as needed. This option gives full control over the KMS keys and is highly secure. Lambda also integrates well with KMS to encrypt environment variables.
- Selected option because it satisfies all the requireme...
Author: Matthew · Last updated Jun 21, 2026
A developer is writing an application to analyze the traffic to a fleet of Amazon EC2 instances. The EC2 instances run behind a public Application Load Balancer (ALB). An HTTP server runs on each of the EC2 instances, logging all requests to a log file.
The developer wants to capture the client public IP addresses. The developer analyzes...
To solve the problem of capturing the client public IP addresses in the log files on the EC2 instances, let's evaluate each option:
A) Add a Host header to the HTTP server log configuration file.
- Reasoning: The Host header in HTTP requests contains the domain name of the server that is being accessed. However, the Host header does not contain any information about the client's IP address. It is unrelated to logging the client's IP.
- Rejected because it does not help in capturing the client’s public IP address; it’s only useful for specifying the domain in a request.
B) Install the Amazon CloudWatch Logs agent on each EC2 instance. Configure the agent to write to the log file.
- Reasoning: Installing the CloudWatch Logs agent allows for centralized logging, but it doesn't inherently solve the issue of capturing the client IP. The CloudWatch Logs agent will log files, but without modifying how the client IP is captured, it will still log the IP address of the ALB (the proxy). This doesn't address the problem directly.
- Rejected because it does not resolve the issue of capturing the client’s public IP address from the ALB.
C) Install the AWS X-Ray daemon on each EC2 instance. Configure the daemon to write to the log file.
- Reasoning: AWS X-Ray is a distributed tracing service that can be used to ...
Author: GlowingTiger · Last updated Jun 21, 2026
A company is developing a serverless application by using AWS Lambda functions. One of the Lambda functions needs to access an Amazon RDS DB instance. The DB instance is in a private subnet inside a VPC.
The company creates a role that includes the necessary permissions to access the DB instance. The company then assigns the role to the Lambda function. ...
To provide the AWS Lambda function with access to an Amazon RDS DB instance that resides in a private subnet within a VPC, the developer needs to ensure that the Lambda function is correctly configured to access resources within the VPC and that appropriate security controls are in place.
A) Assign a public IP address to the DB instance. Modify the security group of the DB instance to allow inbound traffic from the IP address of the Lambda function.
- Reasoning: Amazon RDS instances in a private subnet should not have public IP addresses to maintain network isolation and security. Assigning a public IP address to the DB instance would compromise the security model by exposing it to the public internet.
- Rejected because the DB instance should remain in the private subnet, and it should not be publicly accessible.
B) Set up an AWS Direct Connect connection between the Lambda function and the DB instance.
- Reasoning: AWS Direct Connect provides a dedicated network connection between an on-premises network and AWS, which can be used to improve the performance of connections to AWS services. However, Direct Connect is not necessary or cost-effective for this use case where the Lambda function and the DB instance are both within the same AWS region. It is designed for hybrid cloud setups where on-premises systems need direct, dedicated connections to AWS.
- Rejected because Direct Connect is not required for accessing resources within a VPC; it is more appropriate for on-premises to AWS communication.
C) Configure an Amazon CloudFront distribution to create a secure connection between the Lamb...
Author: Emma Brown · Last updated Jun 21, 2026
A developer needs temporary access to resources in a second account.
What is the MOST secure way ...
To provide temporary access to resources in a second account in a secure and controlled way, let's analyze each option:
A) Use the Amazon Cognito user pools to get short-lived credentials for the second account.
- Reasoning: Amazon Cognito is typically used for managing user authentication in web and mobile apps, enabling users to sign up, sign in, and access resources. However, it's not the most suitable option for providing temporary access between AWS accounts. Cognito is not designed for inter-account access via roles or permissions in the AWS context.
- Rejected because Cognito is not intended for cross-account access and does not integrate directly with IAM roles for secure, temporary access between AWS accounts.
B) Create a dedicated IAM access key for the second account, and send it by mail.
- Reasoning: Creating an IAM access key and sending it by mail is insecure and highly discouraged. Access keys should not be shared via email or any unencrypted methods, as this can lead to accidental exposure and misuse. Additionally, this method does not provide temporary access; it would require the manual management of keys, which can become difficult to control and audit over time.
- Rejected because this is an insecure practice and lacks scalability, auditing, and control over temporary access.
C) Create a cross-account access role, and use sts:AssumeRole API to get short-lived credentials.
- Reasoning: This is the most secure and recommended approach. By creating a cross-...
Author: BlazingPhoenix22 · Last updated Jun 21, 2026
A company wants to migrate applications from its on-premises servers to AWS. As a first step, the company is modifying and migrating a non-critical application to a single Amazon EC2 instance. The application will store information in an Amazon S3 bucket. The company needs to follow security best practices ...
To follow security best practices when deploying the application on AWS and allowing it to interact with Amazon S3, we need to evaluate each option with a focus on security, ease of management, and scalability.
A) Create an IAM role that has administrative access to AWS. Attach the role to the EC2 instance.
- Reasoning: Granting administrative access to the EC2 instance is not a best practice because it provides excessive permissions. The principle of least privilege suggests that the EC2 instance should only have permissions necessary to interact with Amazon S3, not full administrative rights across all AWS services. This creates unnecessary security risks if the instance is compromised.
- Rejected because administrative access is too broad and should be avoided, as it exposes more resources than necessary.
B) Create an IAM user. Attach the AdministratorAccess policy. Copy the generated access key and secret key. Within the application code, use the access key and secret key along with the AWS SDK to communicate with Amazon S3.
- Reasoning: Using IAM users with AdministratorAccess is not recommended because it violates the principle of least privilege. Hardcoding the access key and secret key in the application code introduces security risks if the application code is ever exposed or accessed by unauthorized individuals. Managing keys in this way also makes rotation and revocation more difficult.
- Rejected because hardcoding credentials and granting overly broad permissions increases security risks.
C) Create an IAM role that has the necess...
Author: Emma · Last updated Jun 21, 2026
A company has an internal website that contains sensitive data. The company wants to make the website public. The company must ensure that only employees who authenticate through the company's OpenID Connect (OIDC) identity provider (IdP) can access the website. A developer needs to imp...
To meet the company's requirements of ensuring that only employees authenticated via OpenID Connect (OIDC) can access the website without modifying the website itself, the developer needs to use a combination of services that can enforce authentication before accessing the website.
Let's break down each option and assess them:
Option A: Create a public Network Load Balancer (NLB).
- Reasoning: A Network Load Balancer is best suited for handling low-latency, TCP traffic and operates at the connection level (Layer 4). It does not support advanced routing or the ability to perform authentication actions like OIDC-based authentication. Since the requirement is to authenticate users through an OIDC IdP, this option is not appropriate.
- Rejection: This option does not fit because it doesn't support the necessary authentication integration (OIDC).
Option B: Create a public Application Load Balancer (ALB).
- Reasoning: An Application Load Balancer is a better fit for this scenario because it operates at Layer 7 (application level), allowing for URL-based routing and integration with authentication services. ALBs support native authentication with OIDC and can be configured to trigger authentication actions before users reach the website.
- Selected: This is the correct choice because the ALB can handle the necessary authentication logic by integrating with the OIDC IdP.
Option C: Configure a listener for the load balancer that listens on HTTPS port 443. Add a default authenticate action providing the OIDC IdP configuration.
- Reasoning: This is a valid option for achieving authentication. By configuring an ALB to listen on HTTPS (port 443), the traffic is encrypted, ensuring security for the authentication flow. The default a...
Author: Emma · Last updated Jun 21, 2026
A developer is working on a web application that requires selective activation of specific features. The developer wants to keep the features hidden from end users until the feature...
To meet the developer’s requirement of selectively activating specific features in a web application while keeping them hidden from end users until they are ready, we need a solution that allows the management and toggling of feature states (e.g., enabling or disabling features) dynamically without redeploying the application. Let's break down each option:
Option A: Create a feature flag configuration profile in AWS AppSync. Store the feature flag values in the configuration profile. Activate and deactivate feature flags as needed.
- Reasoning: AWS AppSync is designed to handle real-time data syncing for GraphQL APIs, which is useful for interactive, real-time applications. While AppSync can manage the feature flags, it’s primarily built for data management and API synchronization rather than feature flag management. This solution might require additional work and complexity to integrate feature flag functionality.
- Rejection: AppSync is not the most appropriate tool for managing feature flags, especially considering that other AWS services are specifically built for this purpose. Therefore, this option is less efficient.
Option B: Store prerelease data in an Amazon DynamoDB table. Enable Amazon DynamoDB Streams in the table. Toggle between hidden and visible states by using DynamoDB Streams.
- Reasoning: DynamoDB is a NoSQL database and could technically store flags or data related to features. However, DynamoDB Streams is used for change data capture and real-time processing of table updates, not specifically for feature flag management. Using DynamoDB in this way would be inefficient and complex to manage feature toggling directly.
- Rejection: DynamoDB is not designed for managing feature flags, and using DynamoDB Streams for toggling feature visibility would be overly complicated, especially compared to more specia...
Author: Isabella · Last updated Jun 21, 2026
A developer at a company writes an AWS CloudFormation template. The template refers to subnets that were created by a separate AWS CloudFormation template that the company's network team wrote. When the developer attempts to launch the stack for the f...
Let's break down each option and evaluate it to identify the coding mistakes that could cause the failure.
Option A: The developer's template does not use the Ref intrinsic function to refer to the subnets.
- Reasoning: The `Ref` intrinsic function in CloudFormation is used to reference AWS resources in a template. However, in this case, the subnets were created by a separate template, so referring to them by `Ref` wouldn't work unless the subnets were created as part of the current template's resources. Since the subnets are created in a different template, simply using `Ref` won’t resolve them properly, especially if they are not explicitly imported into the developer’s template.
- Rejection: This option is incorrect because the subnets are not resources within the developer’s template, and thus `Ref` alone won’t resolve them.
Option B: The developer's template does not use the ImportValue intrinsic function to refer to the subnets.
- Reasoning: If the subnets are created in another CloudFormation stack (the network team's stack), they need to be exported from that stack to be imported into the developer's template. The `ImportValue` intrinsic function is used to reference exported values from other CloudFormation stacks. If the subnets are exported in the network team's stack, the developer must use `ImportValue` to refer to them in their template.
- Selected: This is the correct option because `ImportValue` is necessary to import values from another stack, such as subnets that were created separately.
Option C: The Mappings section of the developer's template does not refer to the subnets.
- Reasoning: The Mappings section of a CloudFormation template is used for creating static lookup tables based on keys and values, ofte...
Author: Siddharth · Last updated Jun 21, 2026
A developer is running an application on an Amazon EC2 instance. When the application tries to read an Amazon S3 bucket, the application fails. The developer notices that the associated IAM role is missing the S3 read permission. The developer needs to give the application ...
Let's break down each option and analyze how it aligns with the requirement of giving the application the ability to read from the S3 bucket with the least disruption to the application.
Option A: Add the permission to the role. Terminate the existing EC2 instance. Launch a new EC2 instance.
- Reasoning: This option involves terminating the existing EC2 instance and launching a new one after updating the IAM role. While this would solve the issue of the missing S3 permission, terminating the EC2 instance would lead to unnecessary downtime and application disruption, especially if it's a critical application.
- Rejection: This solution introduces significant disruption, as it requires terminating and restarting the instance, which can cause downtime.
Option B: Add the permission to the role so that the change will take effect automatically.
- Reasoning: When permissions are added to an IAM role, the changes take effect automatically for any EC2 instance that assumes the role. The EC2 instance does not need to be restarted, and the application will be able to access the S3 bucket as soon as the permission is granted. This is the least disruptive approach because it allows the application to continue running without needing to restart or re-launch any resources.
- Selected: This is the best solution because it applies the permission change without requiring any downtime or disruption. The instance will automatically have the updated permissions as soon as the IAM role is modified.
Option C: Add the permission to the role. Hiber...
Author: Max · Last updated Jun 21, 2026
A developer is writing a web application that is deployed on Amazon EC2 instances behind an internet-facing Application Load Balancer (ALB). The developer must add an Amazon CloudFront distribution in front of the ALB. The developer also must ensure that customer data from outside the VPC is encrypted in t...
To meet the requirements of ensuring customer data from outside the VPC is encrypted in transit while placing an Amazon CloudFront distribution in front of an Application Load Balancer (ALB), the developer needs to focus on settings that enforce HTTPS communication, ensuring secure data transmission.
Option A: Restrict viewer access by using signed URLs.
- Reasoning: Signed URLs in CloudFront allow you to control access to specific content, such as for private content or when access needs to be restricted based on certain conditions. However, restricting access using signed URLs is not necessary to meet the requirement of encrypting customer data in transit. This setting is more for security purposes related to controlling access rather than encrypting data.
- Rejection: This option is not necessary for ensuring encryption in transit, and it adds complexity that isn't required by the given scenario.
Option B: Set the Origin Protocol Policy setting to Match Viewer.
- Reasoning: The Origin Protocol Policy determines how CloudFront communicates with the origin (ALB in this case). Setting this to Match Viewer means that CloudFront will use HTTPS if the client uses HTTPS to connect. This setting ensures that the communication between CloudFront and the origin (ALB) will be encrypted if the client’s request is encrypted. It ensures that CloudFront respects the viewer's protocol and secures the data transit from the client to the ALB.
- Selected: This is the correct choice because it ensures that CloudFront respects the viewer's protocol and encrypts data between the viewer and the ALB, fulfilling the requirement of encryption in transit.
Option C: Enable field-level encryption.
- Reasoning: Field-level encryption is a security feature that encrypts specific data fields (such as user credentials or payment information) before sending them to the origin ser...
Author: Ava · Last updated Jun 21, 2026
A developer is implementing an AWS Lambda function that will be invoked when an object is uploaded to Amazon S3. The developer wants to test the Lambda function in a local development machine before publishing the function to a produc...
To meet the requirement of testing the AWS Lambda function locally before publishing it to the AWS production environment, we need to consider the simplicity of local testing with minimal overhead. Let's evaluate each option:
Option A: Upload an object to Amazon S3 using the `aws s3api put-object` CLI command. Wait for the local Lambda invocation from the S3 event.
- Reasoning: This option relies on invoking the Lambda function through an S3 event, which would occur in a live AWS environment. To trigger the event locally, the Lambda would need to be published in AWS and connected to an S3 bucket in the cloud. This defeats the purpose of local testing because the Lambda would only trigger once the object is uploaded to S3 in AWS. Additionally, waiting for such a trigger introduces latency and complicates the local testing process.
- Rejected: Not efficient for local testing because it requires interacting with AWS resources and does not minimize operational overhead.
Option B: Create a sample JSON text file for a `put-object` S3 event. Invoke the Lambda function locally. Use the `aws lambda invoke` CLI command with the JSON file and Lambda function name as arguments.
- Reasoning: This option is a step toward simulating the S3 event locally but does not fully emulate the environment where the event is triggered. It still assumes that Lambda is invoked through AWS CLI, which might not fully represent the actual AWS S3-to-Lambda integration. The Lambda function might be expecting specific triggers or context data related to the S3 service that would not be fully replicated in this scenario.
- Rejected: This is better than option A but still misses emulating a full event scenario with the minimal...
Author: Ravi Patel · Last updated Jun 21, 2026
A developer is publishing critical log data to a log group in Amazon CloudWatch Logs. The log group was created 2 months ago. The developer must encrypt the log data by using an AWS Key Management Service (AWS KMS) key so that future data can be encrypted to...
To meet the requirement of encrypting the log data with an AWS Key Management Service (AWS KMS) key, we need to consider the solution that offers the least operational overhead while ensuring future log data is encrypted with the KMS key.
Option A: Use the AWS Encryption SDK for encryption and decryption of the data before writing to the log group.
- Reasoning: The AWS Encryption SDK is a client-side encryption tool that would require the developer to manually encrypt log data before sending it to CloudWatch Logs. While it provides fine-grained control over encryption, it adds significant complexity and operational overhead because the developer must handle the encryption and decryption logic. This doesn't solve the issue of automatic encryption for log data.
- Rejected: This option requires manual intervention and would result in unnecessary complexity when automatic encryption can be enabled on CloudWatch Logs directly.
Option B: Use the AWS KMS console to associate the KMS key with the log group.
- Reasoning: While it is possible to configure the KMS key from the AWS Management Console, this is not the most efficient solution, especially for automation or large-scale changes. It requires manual intervention, and since the requirement is to do this for a log group that was created 2 months ago, this approach might not be the most practical in terms of ease of implementation, especially if more log groups need to be updated in the future.
- Rejected: Manual steps through the console would create extra effort, especially i...
Author: MoonlitPantherX · Last updated Jun 21, 2026
A developer is working on an app for a company that uses an Amazon DynamoDB table named Orders to store customer orders. The table uses OrderID as the partition key and there is no sort key. The table contains more than 100,000 records. The developer needs to add a functionality that will retrieve all Orders records tha...
To improve the user experience and efficiently retrieve the records with the `OrderSource` attribute set to `MobileApp`, we need to consider the most efficient way to perform the query operation on the DynamoDB table. Let's evaluate each option:
Option A: Perform a Scan operation on the Orders table. Provide a QueryFilter condition to filter to only the items where the OrderSource attribute is equal to the MobileApp value.
- Reasoning: A Scan operation will read all the items in the `Orders` table, which can be highly inefficient, especially since the table contains over 100,000 records. Using a `QueryFilter` would reduce the results, but the Scan still has to examine every item in the table, leading to significant performance issues and higher costs. This is not optimal for large tables.
- Rejected: A Scan is inefficient for large datasets, and it will lead to poor performance and high costs.
Option B: Create a local secondary index (LSI) with `OrderSource` as the partition key. Perform a Query operation by using `MobileApp` as the key.
- Reasoning: An LSI is created based on the table’s primary partition key and allows the use of alternate sort keys. However, the table already uses `OrderID` as the partition key and does not include `OrderSource` as part of the primary key. Using `OrderSource` as a partition key in an LSI does not make sense because it cannot be used to efficiently query for all items where the `OrderSource` is `MobileApp`—the index would have to include the `OrderID` as part of the partitioning logic, which doesn't align with the requirement.
- Rejected: An LSI with `OrderSource` as the partition key is not feasible because it would require a different structure and would not optimize the query for the required use case.
Option C: Create a global secondary index (GSI) with `OrderSource` as the sort key. Pe...
Author: Aarav · Last updated Jun 21, 2026
A company has an application that uses an AWS Lambda function to process data. A developer must implement encryption in transit for all sensitive configuration data, such as API keys, that is stored in the application. The developer creates an AWS Key Management...
To meet the encryption in transit requirement for sensitive configuration data such as API keys in the Lambda function, the developer needs to ensure that sensitive data is securely stored and encrypted while it is in transit to the Lambda function. Let’s evaluate each option:
Option A: Create parameters of the String type in AWS Systems Manager Parameter Store. For each parameter, specify the KMS key ID to encrypt the parameter in transit. Reference the GetParameter API call in the Lambda environment variables.
- Reasoning: AWS Systems Manager Parameter Store allows the storage of sensitive information, and the KMS key can be used to encrypt the parameters at rest. However, while it provides encryption of sensitive data, it does not inherently address encryption in transit. The use of `GetParameter` API call in the Lambda function allows for retrieval of parameters but does not ensure encryption during transit unless the communication itself is secured. So, encryption in transit is not fully addressed.
- Rejected: This option does not fully satisfy the encryption in transit requirement.
Option B: Create secrets in AWS Secrets Manager by using the customer managed KMS key. Create a new Lambda function and set up a Lambda layer. Configure the Lambda layer to retrieve the values from Secrets Manager.
- Reasoning: AWS Secrets Manager is a service designed for storing and managing sensitive data like API keys. It allows encryption of secrets using a KMS key, and communication between Lambda and Secrets Manager is encrypted using HTTPS, ensuring encryption in transit. Secrets Manager handles both encryption at rest and encryption in transit. The Lambda function can retrieve the secrets securely, and Lambda layers can be used for additional logic, though the use of a Lambda layer is optional. This is a robust solution.
- Selected: This is the best option because it addresses both encryption at rest (using the KMS key) and encryption in transit (using HTTPS). It ensures the sensitive data is securely retrieved an...
Author: Emily · Last updated Jun 21, 2026
A developer is building an ecommerce application. When there is a sale event, the application needs to concurrently call three third-party systems to record the sale. The developer wrote three AWS Lambda functions. There is one Lambda function for each third-party system, which contains complex integration logic.
These Lambda functions are all independent. The devel...
To meet the requirements of running each Lambda function independently, regardless of others' success or failure, and ensuring that each Lambda function is called concurrently during a sale event, we need to evaluate the solutions based on their ability to trigger all three Lambda functions without dependencies.
Option A: Publish the sale event from the application to an Amazon Simple Queue Service (Amazon SQS) queue. Configure the three Lambda functions to poll the queue.
- Reasoning: While SQS is useful for message queuing, having each Lambda function poll the same queue could introduce unnecessary complexity. The Lambda functions would need to manage how they handle messages independently and ensure they are processing the correct events. Additionally, this could result in the Lambda functions competing for the same event, which may lead to unnecessary processing delays. This solution would not guarantee that each Lambda function runs independently from others.
- Rejected: This approach does not provide concurrency and independent execution of Lambda functions efficiently.
Option B: Publish the sale event from the application to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the three Lambda functions to be triggered by the SNS topic.
- Reasoning: SNS is designed to trigger multiple subscribers concurrently. By publishing the sale event to an SNS topic and subscribing the three Lambda functions to it, all three Lambda functions can be triggered independently and concurrently, regardless of each other's success or failure. SNS allows each Lambda to process the sale event simultaneously and ensures that no function depends on the success or failure of the others.
- Selected: This is the best solution. SNS ensures concurrent, independent execution of all three Lambda functions with no dependencies. It is simple to configure and allows for scalability.
Option C: Publish the sale event from the appl...
Author: Henry · Last updated Jun 21, 2026
A developer is writing an application, which stores data in an Amazon DynamoDB table. The developer wants to query the DynamoDB table by using the partition key and a different sort key value. The developer needs the late...
To determine which option is best for querying the DynamoDB table, let's evaluate each option based on the following criteria:
1. Querying by partition key and a different sort key value: The developer wants to query by partition key (PK) and a different sort key value (SK), meaning they are trying to access data in a way that involves a different sort key than the primary one. This requires secondary indexes.
2. Latest data with all recent write operations: This indicates that the application needs the most up-to-date data, which may include the results of recent writes.
Option Analysis:
- A) Add a local secondary index (LSI) during table creation. Query the LSI by using eventually consistent reads.
- Local Secondary Index (LSI): This allows you to query the table with the same partition key but a different sort key. This fits the requirement of querying by partition key and a different sort key.
- Eventually Consistent Reads: These are less resource-intensive and faster but might not return the most recent data immediately after a write. Since the developer needs the latest data, this may be less appropriate in scenarios where the application needs to ensure that the results reflect the most recent write operations.
This option is rejected because eventually consistent reads might not ensure the latest write operations are reflected.
- B) Add a local secondary index (LSI) during table creation. Query the LSI by using strongly consistent reads.
- LSI is suitable for querying by a different sort key, as discussed.
- Strongly Consistent Reads: These ensure the query reflects the mos...
Author: Olivia · Last updated Jun 21, 2026
A developer manages an application that writes customer orders to an Amazon DynamoDB table. The orders use customer_id as the partition key, order_id as the sort key, and order_date as an attribute. A new access pattern requires accessing data by order_date and order_id. The developer needs to implement a new AWS Lambda fun...
Let's analyze each option to determine the most operationally efficient solution for supporting the new access pattern (accessing data by `order_date` and `order_id`).
Option Analysis:
- A) Add a new local secondary index (LSI) to the DynamoDB table that specifies `order_date` as the partition key and `order_id` as the sort key. Write the new Lambda function to query the new LSI index.
- LSI allows querying by a different sort key and uses the same partition key (`customer_id` in this case). However, for this use case, `order_date` would be the partition key in the new index, which would not work with the existing partition key (`customer_id`), as an LSI requires the same partition key as the base table.
- Limitations: LSI is only available during table creation or when adding it initially to the table. Additionally, LSI cannot support the required partition key change (`order_date`) for this specific query pattern. So, this option would not be suitable.
This option is rejected because the partition key constraint of LSI limits its ability to support the new access pattern.
- B) Write the new Lambda function to scan the DynamoDB table. In the Lambda function, write a method to retrieve and combine results by `order_date` and `order_id`.
- Scan is less efficient than using indexes because it will read every item in the table to find matching records. For large tables, this could be costly and time-consuming.
- Operational efficiency: Scanning the entire table is inefficient and could lead to high resource consumption, especially if the table grows in size.
- Limitations: While a scan might work for small datasets, it’s not operationally efficient for large-scale applications due to performance and cost concerns.
This option is rejected because a scan is inefficient and not scalable.
- C) Add a new global secondary index (GSI) to the DynamoDB table that specifies `order_date` as the partition key and `order_id` as the sort key. Write the new Lambda function to quer...
Author: Henry · Last updated Jun 21, 2026
A developer is creating a web application for a school that stores data in Amazon DynamoDB. The ExamScores table has the following attributes: student_id, subject_name, and top_score.
Each item in the ExamScores table is identified with student_id as the partition key and subject_name as the sort key. The web application needs to display the student _id for the top scores for each school subject. T...
Analyzing the Requirements:
- Goal: Retrieve the `student_id` for the top scorer in each school subject from the ExamScores table.
- Attributes in the table: The primary key consists of `student_id` (partition key) and `subject_name` (sort key). The table also has a `top_score` attribute.
The query needs to:
- Access data by `subject_name`.
- Retrieve the `student_id` for the highest score (`top_score`) in each subject.
Option Analysis:
- A) Create a local secondary index (LSI) with `subject_name` as the partition key and `top_score` as the sort key.
- LSI can only have the same partition key as the base table, which is `student_id`. However, this option proposes using `subject_name` as the partition key, which violates the requirement for an LSI because it must use the same partition key (`student_id`) as the base table.
- Limitations: Since LSI requires the same partition key as the base table, this option cannot meet the requirements because `subject_name` would not be allowed as the partition key in the LSI.
This option is rejected because the LSI's partition key must match the base table's partition key.
- B) Create a local secondary index (LSI) with `top_score` as the partition key and `student_id` as the sort key.
- LSI allows you to use different sort keys but requires the same partition key (`student_id`) as the base table. This option proposes `top_score` as the partition key, which is not valid for LSI because LSI requires the partition key to be the same as the base table’s partition key.
- Limitations: This option would not work because it incorrectly proposes `top_score` as the partition key, which is not allowed for an LSI.
This option is rejected because LSI cannot have `top_score` as the partition key.
- C) Create a global secondary index (GSI) with `s...
Author: Layla · Last updated Jun 21, 2026
A developer wrote an application that uses an AWS Lambda function to asynchronously generate short videos based on requests from customers. This video generation can take up to 10 minutes. After the video is generated, a URL to download the video is pushed to the customer's web browser. The custo...
Let's analyze each option based on the requirements:
Requirements:
- The Lambda function generates videos asynchronously, taking up to 10 minutes to complete.
- The customer should be able to access the videos for at least 3 hours after generation.
- A URL to download the video should be provided to the customer.
Option Analysis:
A) Store the video in the /tmp folder within the Lambda execution environment. Push a Lambda function URL to the customer.
- /tmp folder: The `/tmp` directory in Lambda has a 512 MB storage limit and is temporary. Lambda functions are stateless, so once the function execution finishes, the data in `/tmp` will be lost.
- Limitations: Since the video is generated asynchronously and can take up to 10 minutes, relying on the `/tmp` folder will cause issues. The temporary nature of `/tmp` means that the video won’t persist beyond the Lambda invocation.
Rejected: This option is unsuitable because the video cannot persist after the Lambda execution ends, and the customer would lose access to the video once the function finishes.
B) Store the video in an Amazon Elastic File System (Amazon EFS) file system attached to the function. Generate a pre-signed URL for the video object and push the URL to the customer.
- Amazon EFS: EFS provides scalable file storage for Lambda functions, which can be used to store data beyond the function execution. However, EFS is better suited for persistent storage and access to files by multiple services.
- Pre-signed URL: EFS does not directly support generating pre-signed URLs for access like Amazon S3 does. This solution would involve additional complexity to set up and manage.
Rejected: While EFS is useful for storing data that needs to be accessed by multiple services, it does not directly support pre-signed URLs and introduces unnecessary complexity for this specific use case.
C) Store the video in Amazon S3. Generate a pr...
Author: Leah · Last updated Jun 21, 2026
A developer is creating an AWS Lambda function that is invoked by messages to an Amazon Simple Notification Service (Amazon SNS) topic. The messages represent customer data updates from a customer relationship management (CRM) system
The developer wants the Lambda function to process only the messages that pertain to email address changes. Ad...
Solution Requirements:
- The Lambda function should only process messages related to email address changes.
- The solution should allow other subscribers to process the remaining messages (non-email changes).
- The goal is to minimize the development effort required to implement this solution.
Option Analysis:
A) Use Lambda event filtering to allow only messages that are related to email address changes to invoke the Lambda function.
- Lambda event filtering allows for filtering of events at the Lambda function level based on attributes in the incoming SNS message. This is a straightforward and efficient solution where you can specify filters that allow the Lambda function to only trigger on email-related messages.
- Minimal development: With event filtering, you can easily set conditions based on message attributes without needing custom code logic inside the Lambda function.
- Advantages: This approach offers a low-development overhead, is scalable, and directly integrates with SNS to filter messages at the subscription level before invoking the Lambda function.
Selected: This option is ideal because it uses built-in features to filter messages without additional code or infrastructure management, providing minimal development effort.
B) Use an SNS filter policy on the Lambda function subscription to allow only messages that are related to email address changes to invoke the Lambda function.
- SNS filter policy allows messages to be filtered based on message attributes. In this case, you could set a filter policy for the Lambda function subscription to only receive messages related to email address changes.
- Minimal development: This solution is simple to implement as you can define the filter directly in the SNS subscription. It avoids extra coding inside the Lambda function itself.
- Advantages: Like Lambda event filtering, this option allows SNS to filter the messages before they reach the Lambda function, making it efficient and straightforward.
- Comparison: This option is functionally similar to Option A, but using SNS filter policies is typically more efficient than using Lambda event filtering. It’s a direct, low-overhead solution that keeps the processing side of things minimal.
This option is also a valid choice and potentially even better than option A due to the filtering being done at the SNS level, before the Lambda function is invoked.
C) Subscribe an Amazon Simple Queue Service (Amazon S...
Author: Ahmed · Last updated Jun 21, 2026
A developer is designing a fault-tolerant environment where client sessions will be saved.
How can the developer ensure tha...
To ensure no client sessions are lost if an Amazon EC2 instance fails in a fault-tolerant environment, the developer needs to choose a solution that provides persistence, scalability, and fault tolerance for session data. Let's analyze each option:
A) Use sticky sessions with an Elastic Load Balancer target group.
- Analysis: Sticky sessions (also known as session affinity) allow requests from a client to be consistently routed to the same EC2 instance for the duration of a session. This method does not ensure session persistence in case the instance fails, as the session data is tied to a single instance.
- Why rejected: If the EC2 instance fails or is terminated, all session data for that instance is lost since it is stored locally on the instance. Sticky sessions are not a suitable solution for fault tolerance in this case.
B) Use Amazon SQS to save session data.
- Analysis: Amazon SQS is a messaging queue service used for decoupling systems and buffering requests. It is not inherently designed to store and manage session data.
- Why rejected: While SQS can be used for message passing, it’s not ideal for storing sessions. Session data typically requires fast access and should be persisted with low-latency reads, which SQS does not provide.
C) Use Amazon DynamoDB to perform scalable session handling.
- Analysis: DynamoDB is a fully managed, NoSQL database service that ca...
Author: CrystalWolfX · Last updated Jun 21, 2026
A developer is creating AWS CloudFormation templates to manage an application's deployment in Amazon Elastic Container Service (Amazon ECS) through AWS CodeDeploy. The developer wants to automatically deploy new versions of the application to a percentage of users before t...
To manage the deployment of new versions of an application to a percentage of users before rolling out to all users, the key requirement is implementing a blue-green deployment strategy. This strategy allows the developer to deploy the new version to a subset of users and gradually shift traffic to the new version, ensuring a controlled rollout and minimizing the impact of potential issues.
Let's analyze each option in detail:
A) Modify the CloudFormation template to include a Transform section and the AWS::CodeDeploy::BlueGreen hook.
- Analysis: The `AWS::CodeDeploy::BlueGreen` hook allows for the blue-green deployment strategy, which is exactly what is needed here. This option allows the deployment of new application versions in a controlled manner by initially routing traffic to the old version (blue) and gradually shifting traffic to the new version (green) as it passes tests or meets certain criteria.
- Why selected: The `AWS::CodeDeploy::BlueGreen` hook is a native solution to manage blue-green deployments in ECS. It allows the gradual deployment to a percentage of users, which perfectly matches the developer's goal. This approach provides a simple and effective way to ensure controlled and fault-tolerant application updates.
B) Deploy the new version in a new CloudFormation stack. After testing is complete, update the application's DNS records for the new stack.
- Analysis: This option requires deploying a completely new stack for each new version of the application, which is not an efficient approach for managing frequent application updates. Updating DNS records manually after testing adds complexity and potential for errors.
- Why rejected: While DNS switching can be used for rolling out updates, it's less efficient and does not provide the same level of fine-grained control as a blue-green deployment. It also lacks automated inte...
Author: IronLion88 · Last updated Jun 21, 2026
A developer has written a distributed application that uses microservices. The microservices are running on Amazon EC2 instances. Because of message volume, the developer is unable to match log output from each microservice to a specific transaction. The developer needs to analyze the message ...
To help the developer analyze the message flow and debug the distributed microservices application, the goal is to trace the flow of requests through each microservice and link them together so that the developer can track the complete transaction. AWS X-Ray is a suitable service for this purpose, as it allows for tracing requests across distributed systems, including microservices, providing insights into how requests move through the system.
A) Download the AWS X-Ray daemon. Install the daemon on an EC2 instance. Ensure that the EC2 instance allows UDP traffic on port 2000.
- Analysis: The AWS X-Ray daemon collects trace data from your microservices and sends it to the X-Ray service for analysis. To use AWS X-Ray in a custom EC2 setup, the daemon must be installed on EC2 instances. The daemon listens for UDP traffic on port 2000 and forwards trace data to the X-Ray service.
- Why selected: This is a necessary step in setting up X-Ray for distributed tracing on EC2 instances. Installing the daemon enables microservices to send their trace data to X-Ray for processing and visualization.
B) Configure an interface VPC endpoint to allow traffic to reach the global AWS X-Ray daemon on TCP port 2000.
- Analysis: While interface VPC endpoints provide private connections to AWS services, in this case, AWS X-Ray does not require setting up a dedicated interface VPC endpoint for the daemon, as X-Ray uses the standard service endpoint rather than a specialized VPC endpoint.
- Why rejected: The configuration of a VPC endpoint is unnecessary for this use case, as the X-Ray daemon can communicate with the X-Ray service over the internet without requiring a special endpoint.
C) Enable AWS X-Ray. Configure Amazon CloudWatch to push logs to X-Ray.
- Analysis: AWS X-Ray is primarily used for tracing requests and analyzing their flow through microservices. However, it does not handle the direct integration of CloudWatch logs for pushing them...
Author: Ethan · Last updated Jun 21, 2026
A company is working on a new serverless application. A developer needs to find an automated way to deploy AWS Lambda functions and the dependent infrastructure with minimum coding effort. The application also needs to ...
To meet the requirement of automating the deployment of AWS Lambda functions and dependent infrastructure with minimal coding effort while ensuring reliability, we need to consider options that offer ease of management, reduced operational overhead, and the ability to deploy Lambda functions alongside their infrastructure in a reliable way.
Let's break down each option:
A) Build the application by using shell scripts to create .zip files for each Lambda function. Manually upload the .zip files to the AWS Management Console.
- Analysis: This approach requires manually creating `.zip` files and manually uploading them via the AWS Management Console. While this works for small, ad-hoc deployments, it is error-prone and does not scale well as the application grows. It also introduces manual overhead in terms of deploying functions, making it less automated and reliable for production use.
- Why rejected: This option involves significant manual work, lacks automation, and is not efficient for deploying at scale. It does not meet the requirement for minimal coding effort and reliable, automated deployments.
B) Build the application by using the AWS Serverless Application Model (AWS SAM). Use a continuous integration and continuous delivery (CI/CD) pipeline and the SAM CLI to deploy the Lambda functions.
- Analysis: AWS SAM (Serverless Application Model) is a framework specifically designed to manage serverless applications. It allows the developer to define Lambda functions, APIs, and other AWS resources as code (in a `template.yaml` file). With SAM, you can automate deployments with minimal coding effort, integrate with CI/CD pipelines, and manage serverless infrastructure in a consistent and reliable manner.
- Why selected: SAM provides an easy way to manage and deploy serverless applications with minimal coding. It simplifies the process of defining and deploying Lambda functions and their associated resources (e.g., API Gateway, DynamoDB). Using SAM with a CI/CD pipeline provides automated, repeatable, and reliable deployments with minimal operational overhead. This is the most suitable option for the given requirements.
C) Build the application by using shell scripts to create .zip files for each Lambda functi...
Author: ThunderBear · Last updated Jun 21, 2026
A developer needs to modify an application architecture to meet new functional requirements. Application data is stored in Amazon DynamoDB and processed for analysis in a nightly batch. The system analysts do not want to wait until the next day to view the processed data and have asked to have it...
To meet the requirement of processing the application data in near-real time instead of waiting for a nightly batch, the architecture must allow for immediate processing as data is received. The system analysts need the processed data available quickly, so we need an architecture that can process data as it is ingested.
Let’s analyze the options:
A) Event driven
- Analysis: An event-driven architecture allows data to be processed immediately when an event occurs. In this case, when new data is written to Amazon DynamoDB, an event (such as a DynamoDB Streams event) can trigger an AWS Lambda function or an AWS Step Functions workflow to process the data in near-real time. This architecture is highly scalable, decouples components, and processes data immediately as it is ingested, which directly meets the requirement of processing data as soon as it is available.
- Why selected: Event-driven architectures are perfect for near-real-time processing because they allow the application to react to incoming data as it happens. By leveraging services like DynamoDB Streams with Lambda, you can ensure that the system reacts to new data as it is received and processes it instantly.
B) Client-server driven
- Analysis: In a client-server driven architecture, clients interact with servers to process requests. While this can work for traditional applications, it is not inherently designed for near-real-time data processing. A client-server architecture does not guarantee immediate processing of data as it is ingested; rather, it might involve batching or waiting for client requests, which is not ideal for this use case.
- Why rejected: This architecture is not optimized for near-real-time processing. It would not ensure that the data is processed as ...
Author: Mia · Last updated Jun 21, 2026
A company hosts its application in the us-west-1 Region. The company wants to add redundancy in the us-east-1 Region.
The application secrets are stored in AWS Secrets Manager in us-west-1. A developer n...
Let's evaluate each of the options in the context of the goal: to replicate application secrets from AWS Secrets Manager in us-west-1 to us-east-1.
Option A:
Configure secret replication for each secret. Add us-east-1 as a replication Region. Choose an AWS Key Management Service (AWS KMS) key in us-east-1 to encrypt the replicated secrets.
- Explanation: This option allows for the direct replication of secrets from one region to another using AWS Secrets Manager. By configuring replication, the secrets in us-west-1 can be replicated to us-east-1. The replication can also use a KMS key in the destination region (us-east-1) for encryption. This approach ensures that the secrets are copied to the secondary region and encrypted with the key of that region.
- Key Reasoning: This is the correct approach as AWS Secrets Manager natively supports cross-region secret replication, and this option correctly uses the necessary encryption settings.
Option B:
Create a new secret in us-east-1 for each secret. Configure secret replication in us-east-1. Set the source to be the corresponding secret in us-west-1. Choose an AWS Key Management Service (AWS KMS) key in us-west-1 to encrypt the replicated secrets.
- Explanation: This option is partially correct but introduces a redundancy of creating new secrets in us-east-1. AWS Secrets Manager doesn’t require manually creating a secret in the destination region before replication, as it can handle the replication directly. This approach may lead to an unnecessary setup of secrets in the destination region before ena...
Author: Isabella · Last updated Jun 21, 2026
A company runs an ecommerce application on AWS. The application stores data in an Amazon Aurora database.
A developer is adding a caching layer to the application. The caching strategy must ensure that the application always us...
Let's analyze each caching strategy in the context of ensuring that the application always uses the most recent value for each data item.
Option A:
Implement a TTL strategy for every item that is saved in the cache.
- Explanation: The Time-to-Live (TTL) strategy sets an expiration time for each cached item. While this ensures that cached items are eventually refreshed after the TTL expires, it does not guarantee that the cache will always contain the most recent data. The cache could contain stale data until it expires, even if the underlying data in Aurora changes.
- Key Reasoning: This option may not be ideal since it doesn't actively ensure that the cache reflects the most recent changes immediately. TTL is primarily useful for data that does not change frequently and doesn't require real-time synchronization between the cache and the database.
Option B:
Implement a write-through strategy for every item that is created and updated.
- Explanation: In a write-through cache strategy, when an item is created or updated in the database, it is simultaneously written to the cache. This ensures that the cache always contains the most recent data for the created or updated item.
- Key Reasoning: This is a suitable strategy for ensuring the most recent value is in the cache because every write to the database is mirrored in the cache. This strategy guarantees consistency between the cache and the database for writes, which meets the requirement of always having the most recent data. However, it could introduce additional latency since every write involves both the database and the cache.
Option C:
Implement a lazy loading strategy for every item that is loaded.
- Explanation: With lazy loading, t...
Author: Sam · Last updated Jun 21, 2026
A company has a serverless application that uses Amazon API Gateway backed by AWS Lambda proxy integration. The company is developing several backend APIs. The company needs a landing page to provide an overview of navigation to the APIs.
A developer creates a new/LandingPage r...
Let’s break down each option in the context of providing a landing page that offers navigation to the backend APIs for a serverless application using Amazon API Gateway with AWS Lambda proxy integration.
Option A:
Configure the integration request mapping template with Content-Type of text/html and statusCode of 200. Configure the integration response mapping template with Content-Type of application/json. In the integration response mapping template, include the LandingPage HTML code that references the APIs.
- Explanation: The integration request mapping template determines how incoming requests are processed before reaching the backend. The integration response mapping template is for formatting the response. This option is incorrect because the request mapping template should handle how data is sent from the client (typically in JSON), not in `text/html`. Additionally, using `application/json` for the response is not suitable for a landing page, which needs to be served as HTML.
- Key Reasoning: This option misconfigures the content types in the wrong places, making it unsuitable for returning an HTML page.
Option B:
Configure the integration request mapping template with Content-Type of application/json. In the integration request mapping template, include the LandingPage HTML code that references the APIs. Configure the integration response mapping template with Content-Type of text/html and statusCode of 200.
- Explanation: In API Gateway, the request mapping template should not contain static HTML. The `application/json` content type is typically used for JSON payloads, not HTML. Also, the response should be set to `text/html` to serve an HTML page correctly. However, the request mapping template incorrectly places HTML in the request section, which is not appropriate.
- Key Reasoning: This option misplaces HTML content in the request template, making it incompatible with the expected API Gateway request/response flow.
Option C:
Configure the integration request ma...
Author: FlamePhoenix2025 · Last updated Jun 21, 2026
A developer creates an AWS Lambda function that is written in Java. During testing, the Lambda function does not work how the developer expected. The developer wants to use tracing capabilities to troubles...
Let’s evaluate each service in the context of troubleshooting an AWS Lambda function and understanding how to use tracing for troubleshooting.
Option A:
AWS Trusted Advisor
- Explanation: AWS Trusted Advisor provides best practice recommendations for optimizing AWS environments in terms of cost, security, fault tolerance, performance, and service limits. However, it does not provide tracing or detailed diagnostic information for Lambda functions. Trusted Advisor focuses on general environment optimization rather than function-level troubleshooting.
- Key Reasoning: This option is not suitable for tracing Lambda functions as it does not offer specific insights into Lambda behavior or logs.
Option B:
Amazon CloudWatch
- Explanation: Amazon CloudWatch is a monitoring service that collects and visualizes logs, metrics, and events for AWS resources. It is useful for viewing Lambda logs, monitoring Lambda performance (such as invocation count, duration, and errors), and setting alarms based on metrics. While CloudWatch can help identify issues through logs, it doesn’t provide detailed tracing to track the flow and performance of Lambda functions in the way required for debugging.
- Key Reasoning: CloudWatch is beneficial for logging, but tracing the path of a Lambda execution with precise insights is better handled by a different service, specifically AWS X-Ray.
Option C:
AWS X-Ray
- Explanation: AWS X-Ray provides distributed tracing, which is ideal for troubleshooting performance...
