Amazon Practice Questions, Discussions & Exam Topics by our Authors

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

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

Author: Sophia Clark · Last updated Jul 14, 2026

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

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

Author: Abigail · Last updated Jul 14, 2026

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

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

Author: MysticJaguar44 · Last updated Jul 14, 2026

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

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

Author: VenomousSerpent42 · Last updated Jul 14, 2026

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

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

Author: Arjun · Last updated Jul 14, 2026

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

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

Author: Kunal · Last updated Jul 14, 2026

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

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

Author: Grace · Last updated Jul 14, 2026

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

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

Author: Leah Davis · Last updated Jul 14, 2026

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

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

Author: Maya · Last updated Jul 14, 2026

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

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

Author: Ava · Last updated Jul 14, 2026

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

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

Author: Emily · Last updated Jul 14, 2026

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

Author: Evelyn · Last updated Jul 14, 2026

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

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

Author: Mia · Last updated Jul 14, 2026

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

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

Author: Aditya · Last updated Jul 14, 2026

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

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

Author: Sophia Clark · Last updated Jul 14, 2026

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

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

Author: Ravi Patel · Last updated Jul 14, 2026

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

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

Author: Ahmed · Last updated Jul 14, 2026

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

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

Author: William · Last updated Jul 14, 2026

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

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

Author: Kunal · Last updated Jul 14, 2026

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

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

Author: Evelyn · Last updated Jul 14, 2026

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

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

Author: Benjamin · Last updated Jul 14, 2026

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

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

Author: Aria · Last updated Jul 14, 2026

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

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

Author: Ethan · Last updated Jul 14, 2026

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

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

Author: Abigail · Last updated Jul 14, 2026

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

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

Author: Liam · Last updated Jul 14, 2026

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

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

Author: Leo · Last updated Jul 14, 2026

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

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

Author: Carlos Garcia · Last updated Jul 14, 2026

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

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

Author: Ella · Last updated Jul 14, 2026

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

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

Author: Daniel · Last updated Jul 14, 2026

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

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

Author: Liam123 · Last updated Jul 14, 2026

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

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

Author: Liam · Last updated Jul 14, 2026

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

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

Author: BlazingPhoenix22 · Last updated Jul 14, 2026

A developer is building an application that will use an Amazon API Gateway API with an AWS Lambda backend. The team that will develop the frontend requires immediate access to the API endpoints to build the UI. To prepare the backend application for integration, the developer needs to set up endpoints. The endpoints need to return predefined HTTP sta...

The developer's goal is to set up API endpoints that return predefined HTTP status codes and JSON responses for the frontend team. The API should simulate the backend behavior before the actual Lambda function is implemented. Let's evaluate each option: A) Set the integration type to AWS_PROXY. Provision Lambda functions to return hardcoded JSON data. - Rejected: The AWS_PROXY integration type is designed to allow full control of the request and response by the Lambda function. However, this approach requires implementing actual Lambda functions to return data. This goes beyond the scope of simply simulating endpoints with hardcoded responses. It doesn't align with the requirement to simulate API responses quickly before implementing the Lambda functions. B) Set the integration type to MOCK. Configure the method's integration request and integration response to associate JSON responses with specific HTTP status codes. - Selected: The MOCK integration type allows the API Gateway to return predefined responses without invoking any backend services like Lambda. This is perfect for simulating the behavior of the backend for frontend development. The developer can easily configure HTTP status codes and JSON responses that the frontend team can use to build their UI. This is the most efficient approach for setting up mock endpoints with hardcoded responses quickly. C) Set the integration type to HTTP_PROXY. Configure API Gateway ...

Author: Emma · Last updated Jul 14, 2026

A developer is migrating an application to Amazon Elastic Kubernetes Service (Amazon EKS). The developer migrates the application to Amazon Elastic Container Registry (Amazon ECR) with an EKS cluster. As part of the application migration to a new backend, the developer creates a new AWS account. The developer makes configuration changes to the application to point the application to the new AWS account and to use new backend resources. The developer successfully tests the changes within the application by deploying the pipeline. The Docker image build and the pipeline deployment are successful, but the application is sti...

The issue at hand is that the application is still connecting to the old backend, even though the Docker image build and pipeline deployment were successful. The developer has made configuration changes to point the application to the new AWS account and backend resources, but the application isn't reflecting these changes. Let's analyze each option: A) The developer did not successfully create the new AWS account. - Rejected: The scenario specifies that the developer has successfully migrated the application to a new AWS account. The application works as expected in terms of the Docker image build and pipeline deployment. This suggests that the AWS account creation is not the issue. The problem lies with the application configuration or the way it's referencing backend resources, not with the creation of the new account. B) The developer added a new tag to the Docker image. - Rejected: Adding a new tag to the Docker image wouldn't directly cause the application to reference the old backend. The tag change is not relevant to the connection between the application and the backend resources. The application's issue lies with its internal configuration, not the image tag itself. C) The developer did not update the Docker image tag to a new version. - Selected: This is the most likely explanation. If the application is still referencing the old backend, it might be b...

Author: Emma · Last updated Jul 14, 2026

A developer is creating an application that reads and writes to multiple Amazon S3 buckets. The application will be deployed to an Amazon EC2 instance. The developer wants to make secure API requests from the EC2 instances without the need to manage the security credentials for the a...

The developer's goal is to securely make API requests from an EC2 instance to multiple Amazon S3 buckets while following the principle of least privilege. The solution must avoid managing security credentials manually and ensure the application only has the necessary permissions to perform its tasks. Let's evaluate each option: A) Create an IAM user. Create access keys and secret keys for the user. Associate the user with an IAM policy that allows `s3:` permissions. - Rejected: While creating an IAM user with access keys and associating an `s3:` policy will grant the necessary permissions, it requires manual management of access keys and secret keys. This is not ideal because it introduces the risk of key exposure or mismanagement. Additionally, using access keys on EC2 instances is not recommended because it can lead to security vulnerabilities if not handled properly. B) Associate the EC2 instance with an IAM role that has an IAM policy that allows `s3:ListBucket` and `s3:Object` permissions for specific S3 buckets. - Selected: This is the most secure and appropriate option. By associating an IAM role with the EC2 instance, the EC2 instance can use temporary security credentials that AWS automatically rotates, thus eliminating the need for manual management of credentials. The role is granted specific permissions (e.g., `s3:ListBucket` and `s3:Object`) to only the necessary S3 buckets, following the principle of least privilege. This solution allows secure API access without exposing ...

Author: Michael · Last updated Jul 14, 2026

A developer is writing an application that will retrieve sensitive data from a third-party system. The application will format the data into a PDF file. The PDF file could be more than 1 MB. The application will encrypt the data to disk by using AWS Key Management Service (AWS KMS). The application will decrypt the file when a user requests to download it. The retrieval and formatting portions of the application are complete. The developer needs to use the GenerateDataKey ...

To meet the developer's requirements of securely encrypting a PDF file using AWS Key Management Service (AWS KMS) and enabling decryption later, the developer needs to use the `GenerateDataKey` API to generate both a plaintext data key and an encrypted data key. The plaintext key will be used to encrypt the PDF file, while the encrypted key will be stored securely for later decryption. Let's evaluate each option: A) Write the encrypted key from the GenerateDataKey API to disk for later use. Use the plaintext key from the GenerateDataKey API and a symmetric encryption algorithm to encrypt the file. - Selected: This is the correct approach. When using the `GenerateDataKey` API, AWS KMS returns both an encrypted data key and a plaintext data key. The plaintext data key is used to encrypt the sensitive data (in this case, the PDF file) using a symmetric encryption algorithm. The encrypted data key is stored securely (e.g., in a database or another secure location) and can be used later to decrypt the file. This approach ensures that the plaintext key is never exposed after encryption and can be securely decrypted using the encrypted data key when needed. B) Write the plain text key from the GenerateDataKey API to disk for later use. Use the encrypted key from the GenerateDataKey API and a symmetric encryption algorithm to encrypt the file. - Rejected: Storing the plaintext key on disk is a security risk, as it exposes the key in an unsecured way. The plaintext key should never be written to disk, as it could be ac...

Author: Max · Last updated Jul 14, 2026

A company runs an application on Amazon EC2 instances. The EC2 instances open connections to an Amazon RDS for SQL Server database. A developer needs to store and access the credentials and wants to automatically rotate the credentials. The developer does not want to store...

To determine the most secure and efficient way to handle credentials and rotate them automatically, let's evaluate each option: A) Create an IAM role that has permissions to access the database. Attach the IAM role to the EC2 instances. - Reasoning: This option suggests using an IAM role for EC2 instances to access the database, but IAM roles are typically used for granting AWS service permissions rather than storing and rotating database credentials. For Amazon RDS SQL Server, IAM-based authentication is not supported out of the box like it is for certain other AWS services (e.g., RDS for MySQL, PostgreSQL). - Rejected: This solution doesn't meet the requirement to store database credentials securely or automate their rotation for RDS SQL Server, since IAM roles aren't the right tool for storing credentials for SQL Server. B) Store the credentials as secrets in AWS Secrets Manager. Create an AWS Lambda function to update the secrets and the database. Retrieve the credentials from Secrets Manager as needed. - Reasoning: AWS Secrets Manager is a managed service specifically designed for securely storing and rotating credentials, including database credentials. It provides an automated mechanism for rotating secrets (e.g., database passwords) without needing to modify the code. AWS Lambda can be used to update the secrets in Secrets Manager and interact with the database, ensuring the credentials are always fresh. - Selected Option: This is the most secure and convenient solution. It meets the requirement of storing the credentials securely, automating the credential rotation, and accessing the credentials dynamically from the application code without hardcoding them. C) Store the credentials in an encrypted text file in an Amazon S3 bucket. Configure the EC2 instance launch template to download the...

Author: RadiantPhoenixX · Last updated Jul 14, 2026

A company wants to test its web application more frequently. The company deploys the application by using a separate AWS CloudFormation stack for each environment. The company deploys the same CloudFormation template to each stack as the application progresses through the development lifecycle. A developer needs to build in notifications for the quality assurance (QA)...

To meet the requirements of notifying the QA team upon new deployments in the final preproduction environment, let's evaluate each option based on its relevance to the problem: A) Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the QA team to the Amazon SNS topic. Update the CloudFormation stack options to point to the SNS topic in the pre-production environment. - Reasoning: This option suggests creating an SNS topic, but there is no direct integration between CloudFormation and SNS for notifications about stack updates. You would need to manually integrate CloudFormation stack updates with SNS, which could be cumbersome and error-prone. CloudFormation provides native ways to send notifications, such as via CloudFormation Events or through other AWS services like Lambda, so this is not the most automated or scalable approach. - Rejected: This solution lacks automation and direct integration with CloudFormation events. Other solutions provide better integration with AWS CloudFormation for notifications. B) Create an AWS Lambda function that notifies the QA team. Create an Amazon EventBridge rule to invoke the Lambda function on the default event bus. Filter the events on the CloudFormation service and on the CloudFormation stack Amazon Resource Name (ARN). - Reasoning: This approach uses Amazon EventBridge to listen for CloudFormation events, which is a good fit. EventBridge is a serverless event bus that integrates well with AWS services. You can filter CloudFormation events for specific stacks, such as the preproduction environment, and trigger a Lambda function to notify the QA team. This solution offers strong flexibility and automation, as well as direct integration with CloudFormation. - Selected Option: This is the most appropriate solution, as it integrates well with CloudFormation, provides the required notification automation, and allows for specific filtering by stack ARN, ensuring notifications are sent only for the desired environment (preproduction). ...

Author: Ethan · Last updated Jul 14, 2026

A developer manages three AWS accounts. Each account contains an Amazon RDS DB instance in a private subnet. The developer needs to define users in each database in a consistent way. The developer must ensure that the same users are created and updated lat...

To determine the most efficient solution for creating and updating users in Amazon RDS DB instances across three AWS accounts, let's evaluate each option: A) Create an AWS CloudFormation template. Declare the users in the template. Attach the users to the database. Deploy the template in each account. - Reasoning: This approach suggests using CloudFormation to declare and deploy users in the databases. While CloudFormation can be used to manage resources across accounts, it doesn’t natively handle the creation or management of users inside databases like RDS. Additionally, if the users need to be created or updated dynamically, CloudFormation templates may not be flexible enough for regular updates. - Rejected: CloudFormation is primarily for managing infrastructure and doesn’t provide the flexibility needed to directly manage database users in a dynamic and consistent way across multiple accounts. B) Create an AWS CloudFormation template that contains a custom resource to create the users in the database. Deploy the template in each account. - Reasoning: This option enhances CloudFormation by using a custom resource to create the users within the database. This solution allows for better flexibility than the previous one by leveraging a Lambda function within the custom resource. The Lambda function would be responsible for creating and updating users in the database. This option ensures that the process is automated and can be consistent across accounts. - Selected Option: This is the most operationally efficient approach. The use of a custom resource in CloudFormation provides the flexibility to create and manage users dynamically while still using CloudFormation to deploy and manage resources. Additionally, this allows for easy updates and a consistent approach across accounts. C) Write a script that creates the users. Deploy an Am...

Author: Ethan · Last updated Jul 14, 2026

A company is building a new application that runs on AWS and uses Amazon API Gateway to expose APIs. Teams of developers are working on separate components of the application in parallel. The company wants to publish an API without an integrated backend so that teams that depend on the application backen...

The company needs a solution where an API is exposed via Amazon API Gateway but doesn’t yet have an integrated backend. This allows the teams working on the backend to continue their work while allowing other teams that depend on the API to proceed with development. Let’s evaluate each option: A) Create API Gateway resources and set the integration type value to MOCK. Configure the method integration request and integration response to associate a response with an HTTP status code. Create an API Gateway stage and deploy the API. - Reasoning: This option suggests using API Gateway with a "MOCK" integration type. With this setup, the API Gateway can return pre-configured mock responses for requests, which is useful for simulating API calls without the need for an actual backend. This allows the development of the front-end or client applications to proceed without waiting for the backend to be ready. - Selected Option: This is the most suitable and efficient solution. Using the MOCK integration type allows for seamless development by providing static, predefined responses that mimic the behavior of the backend. It's easy to implement and requires minimal setup. It’s also highly scalable and does not require provisioning or managing additional resources (like Lambda or EC2) for mocking. B) Create an AWS Lambda function that returns mocked responses and various HTTP status codes. Create API Gateway resources and set the integration type value to AWS_PROXY. Deploy the API. - Reasoning: This approach involves creating an AWS Lambda function to return mocked responses, with API Gateway using the AWS_PROXY integration type. While this would work, it introduces unnecessary complexity since AWS_PROXY is used for direct integration with Lambda functions for dynamic backends, which is not needed for mocking. The mock responses could be returned more simply using the MOCK integration type. - Rejected: This solution is over-complicated for the given use case. The Lambda function ad...

Author: Zara · Last updated Jul 14, 2026

An application that runs on AWS receives messages from an Amazon Simple Queue Service (Amazon SQS) queue and processes the messages in batches. The application sends the data to another SQS queue to be consumed by another legacy application. The legacy system can take up to 5 minutes to process some transaction data. A developer wants to ensure that there are...

The problem involves ensuring that messages are processed in order and without out-of-order updates in the legacy system, while adhering to the constraint that the legacy system takes up to 5 minutes to process some transaction data. The key requirement is to preserve the order of the messages as they are transferred from one queue to another. Let's evaluate each option: A) Use an SQS FIFO queue. Configure the visibility timeout value. - Reasoning: An SQS FIFO (First-In-First-Out) queue guarantees the order in which messages are processed, which is critical for this scenario. The visibility timeout ensures that a message is not processed by another consumer until the current consumer finishes processing. This would ensure that messages are processed in the correct order, and no messages are processed out of order. However, the visibility timeout value should be carefully set to ensure that it is long enough for the legacy system to process the message without it being considered available for reprocessing. - Selected Option: This is the best solution. Using a FIFO queue guarantees message order, and the visibility timeout can be adjusted to match the maximum processing time of the legacy system (5 minutes). This will ensure that messages are not processed out of order while the legacy system is processing them. B) Use an SQS standard queue with a SendMessageBatchRequestEntry data type. Configure the DelaySeconds values. - Reasoning: SQS standard queues do not guarantee message order, so using this queue type is not appropriate for ensuring that the legacy system processes the messages in order. Additionally, configuring `DelaySeconds` will introduce a fixed delay before messages are delivered, but this does not guarantee that messages will be processed in order by the legacy system, which is a key requirement. - Rejected: A standard queue does not guarantee message order, which is essential in this ca...

Author: Emily · Last updated Jul 14, 2026

A company is building a compute-intensive application that will run on a fleet of Amazon EC2 instances. The application uses attached Amazon Elastic Block Store (Amazon EBS) volumes for storing data. The Amazon EBS volumes will be created at time of initial deployment. The application will process sensitive information. All ...

Solution Explanation: A) Configure the fleet of EC2 instances to use encrypted EBS volumes to store data. - Pros: - Amazon EBS supports encryption at rest, which can protect sensitive information. - Encryption of the EBS volumes is done seamlessly at the hardware level, without requiring additional configurations from the application side. - Performance impact is minimal, as Amazon EBS encryption leverages hardware acceleration (AES-256 encryption). - Managed solution that is native to AWS and integrates well with EC2 instances. - Cons: - Slight performance overhead compared to unencrypted volumes, but it’s minimal and should not have a significant impact for compute-intensive applications. - Why it’s the best option: - The solution provides both encryption and minimal performance impact, which meets the requirement of encrypting sensitive data without significant overhead. The EBS volumes are specifically designed to work with EC2 instances and ensure data is encrypted automatically. B) Configure the application to write all data to an encrypted Amazon S3 bucket. - Pros: - Amazon S3 supports server-side encryption, which protects the data. - Amazon S3 is designed to scale well and can be used to store data efficiently. - Cons: - The data needs to be accessed over the network, which could introduce latency and performance overhead for compute-intensive applications that require fast access to large amounts of data. - Writing to S3 is not directly integrated with EBS, meaning additional management for syncing data between S3 and EC2 could be required. - Why it’s rejected: - For a compute-intensive application, storing data on S3 would add unnecessary network latency, making it unsuitable for applications that require low-latency access to data. C) Configure a custom encryption algorithm for the application that will en...

Author: William · Last updated Jul 14, 2026

A developer is updating the production version of an AWS Lambda function to fix a defect. The developer has tested the updated code in a test environment. The developer wants to slowly roll out the updates to a small subset of production users before rolling out the changes to all users. On...

Explanation: The goal is to slowly roll out the new Lambda code to a small subset of users, starting with 10% of users being exposed to the new code. The most efficient and secure way to achieve this is by using Lambda versions and aliases, which are designed for controlled traffic shifting. Let's analyze each option: --- A) Update the Lambda code and create a new version of the Lambda function. Create a Lambda function trigger. Configure the traffic weights in the trigger between the two Lambda function versions. Send 90% of the traffic to the production version, and send 10% of the traffic to the new version. - Cons: - Lambda triggers (such as API Gateway, S3 events, etc.) are typically associated with a single function version. While you can configure traffic routing with some event sources, this approach isn't the typical pattern for version-based traffic shifting within Lambda. - The mechanism for configuring traffic weight on triggers is not straightforward and may not work in the way this solution suggests. - Conclusion: This solution is not the most appropriate because Lambda triggers themselves do not have a native feature to route traffic based on versioning. --- B) Create a new Lambda function that uses the updated code. Create a Lambda alias for the production Lambda function. Configure the Lambda alias to send 90% of the traffic to the production Lambda function, and send 10% of the traffic to the test Lambda function. - Cons: - This solution suggests creating a new Lambda function rather than working with Lambda versions and aliases of the same function. Creating a completely new Lambda function would involve more resources and maintenance overhead. - Managing traffic distribution across entirely separate Lambda functions is more complex than working with versions of the same function. - Conclusion: This option is overly complicated, as it involves managing two separate Lambda functions and would requ...

Author: Lucas · Last updated Jul 14, 2026

A developer is creating an AWS Lambda function that consumes messages from an Amazon Simple Queue Service (Amazon SQS) standard queue. The developer notices that the Lambda function processes some mes...

Solution Explanation: A) Change the Amazon SQS standard queue to an Amazon SQS FIFO queue by using the Amazon SQS message deduplication ID. - Pros: - FIFO queues are designed to ensure that messages are processed exactly once and in the exact order they are sent. - Using message deduplication IDs helps prevent processing the same message multiple times within a 5-minute deduplication interval. - Cons: - SQS FIFO queues are typically more expensive than standard queues. - Changing from a standard queue to a FIFO queue may not be necessary, as the issue might be better addressed with other solutions that don’t require such a change. - If the order of message processing is not important, using a FIFO queue could be an over-engineered solution and could incur unnecessary cost increases. - Why it’s rejected: - While FIFO queues prevent message duplication, they come with higher costs and complexity, especially when the requirement is to prevent multiple processing of messages rather than ensuring ordered message processing. B) Set up a dead-letter queue. - Pros: - A dead-letter queue (DLQ) allows you to capture messages that failed processing after multiple attempts, helping to isolate problematic messages. - Useful for debugging and monitoring message processing failures. - Cons: - A DLQ doesn't directly prevent a message from being processed multiple times; it only helps to isolate messages that can't be processed after retrying. - If Lambda keeps processing the same message multiple times, simply using a DLQ won’t fix the root cause (which is typically due to message visibility timeout or Lambda concurrency issues). - Why it’s rejected: - This approach helps with failure management but doesn't prevent multiple processing of messages. It’s more of a recovery strategy, not a prevention measure for duplicate processing. C) Set the maximum concurrency limit of the AWS Lambda function to 1. - Pros: - By setting the Lambda concurrency to 1, you ensure that only one instance of the Lambda function can process messages at a time. - This effectively serializes the processing of messages, eliminating the possibility of multiple...

Author: Kai · Last updated Jul 14, 2026

A developer is optimizing an AWS Lambda function and wants to test the changes in production on a small percentage of all traffic. The Lambda function serves requests to a RE ST API in Amazon API Gateway. The developer needs to deploy their changes and per...

Analysis of Each Option: The goal is to test changes to the Lambda function in production by directing a small percentage of traffic to the new version of the function while keeping the rest of the traffic on the existing production version, all without changing the API Gateway URL. --- A) Define a function version for the currently deployed production Lambda function. Update the API Gateway endpoint to reference the new Lambda function version. Upload and publish the optimized Lambda function code. On the production API Gateway stage, define a canary release and set the percentage of traffic to direct to the canary release. Update the API Gateway endpoint to use the $LATEST version of the Lambda function. Publish the API to the canary stage. - Pros: - Canary releases are specifically designed for rolling out changes gradually by shifting a portion of the traffic to a new Lambda version. This is exactly what is needed for the use case. - You can direct a percentage of the traffic to the new Lambda version, making it ideal for testing in production. - Cons: - The part about updating the API Gateway to reference `$LATEST` and using the canary release is somewhat contradictory. If you're using a canary release, the API Gateway stage should reference an alias, not `$LATEST`, as `$LATEST` always points to the latest deployed version of the Lambda function. - Conclusion: This option is close to being correct but requires adjustments, particularly around the use of `$LATEST` and canary releases. --- B) Define a function version for the currently deployed production Lambda function. Update the API Gateway endpoint to reference the new Lambda function version. Upload and publish the optimized Lambda function code. Update the API Gateway endpoint to use the $LATEST version of the Lambda function. Deploy a new API Gateway stage. - Cons: - Updating the API Gateway to use `$LATEST` contradicts the intention of testing a specific Lambda version. `$LATEST` always points to the most recent version of the function, so using it would make it difficult to control traffic to the production and test versions. - Creating a new API Gateway stage is unnecessary and doesn't address the core goal of testing the changes incrementally in production. - Conclusion: This approach adds unnecessary complexity and doesn't provide the fine-grained traffic control required for the test. --- C) Define an alias on the $LATEST ve...

Author: NebulaEagle11 · Last updated Jul 14, 2026

A company notices that credentials that the company uses to connect to an external software as a service (SaaS) vendor are stored in a configuration file as plaintext. The developer needs to secure the API credentials and enforce automatic...

Solution Explanation: A) Use AWS Key Management Service (AWS KMS) to encrypt the configuration file. Decrypt the configuration file when users make API calls to the SaaS vendor. Enable rotation. - Pros: - AWS KMS can provide encryption for sensitive data and protect API credentials stored in the configuration file. - Cons: - Encrypting the configuration file with KMS only secures the data at rest. However, this solution does not address the need for automatic rotation of the credentials on a regular basis (quarterly). While KMS encryption is secure, manual processes would still be required for credential rotation, making it a less optimal solution. - Handling key management and decryption manually could add complexity and increase the risk of human error. - Why it’s rejected: - KMS is more suitable for encrypting data at rest but does not offer the native ability to rotate credentials automatically, which is a key requirement. B) Retrieve temporary credentials from AWS Security Token Service (AWS STS) every 15 minutes. Use the temporary credentials when users make API calls to the SaaS vendor. - Pros: - Temporary credentials can be used to improve security, and they have a limited lifespan, reducing the impact of a compromised credential. - Cons: - This solution does not address the use case for the external SaaS vendor. AWS STS is typically used to provide temporary credentials for AWS resources, not for external SaaS integration. - Using temporary AWS credentials doesn’t directly solve the issue of securing and rotating API credentials for a third-party SaaS application. - Why it’s rejected: - This option is not applicable to the external SaaS integration, as STS is designed for use within AWS services, not for external services. C) Store the credentials in AWS Secrets Manager and enable rotation. Configure the API to have Secrets Manager access. - Pros: - Best solution for automatic credential rotation: AWS Secrets Manager is designed ...

Author: SilverBear · Last updated Jul 14, 2026

A company has an application that is hosted on Amazon EC2 instances. The application stores objects in an Amazon S3 bucket and allows users to download objects from the S3 bucket. A developer turns on S3 Block Public Access for the S3 bucket. After this change, users report errors when they attempt to download objects. The developer needs to implement a solution so that only users who...

The goal is to allow only authenticated users to access objects in the S3 bucket while ensuring secure access. Let’s evaluate each option to meet the requirement in the most secure way. Option A: Create an EC2 instance profile and role with an appropriate policy. Associate the role with the EC2 instances. - Reasoning: This option ensures that the EC2 instances, which host the application, can access the S3 bucket. The instance role would have an IAM policy that allows access to the S3 bucket, enabling secure access for the application. This option follows best practices for securing access by using IAM roles and instance profiles, instead of embedding credentials directly in the EC2 instances. - Why it's selected: It's a secure way to provide the necessary permissions for EC2 instances to interact with the S3 bucket without hardcoding credentials. Option B: Create an IAM user with an appropriate policy. Store the access key ID and secret access key on the EC2 instances. - Reasoning: Storing access keys directly on EC2 instances is not a best practice, as it introduces security risks (e.g., potential key exposure or compromise). IAM roles should be used instead of IAM users for EC2 instance access, which eliminates the need for hardcoded credentials. - Why it's rejected: Storing credentials on EC2 instances is not recommended because of the potential for credential leaks. Option C: Modify the application to use the S3 GeneratePresignedUrl API call. - Reasoning: The `GeneratePresignedUrl` API call creates a temporary URL that grants time-limited access to an object in S3. This ensures that users can only access the object for a limited period, which is useful for allowing specific users to d...

Author: Leah · Last updated Jul 14, 2026

An Amazon Simple Queue Service (Amazon SQS) queue serves as an event source for an AWS Lambda function. In the SQS queue, each item corresponds to a video file that the Lambda function must convert to a smaller resolution. The Lambda function is timing out on longer video files, but the Lambda function's tim...

In this scenario, the issue is that the Lambda function is timing out when processing longer video files, even though the timeout setting for the function has already been set to its maximum value. The goal is to avoid timeouts without adding additional code, meaning the solution should focus on improving the function's ability to process the video files without exceeding the Lambda execution time. Let’s evaluate each option: Option A: Increase the memory configuration of the Lambda function. - Reasoning: Increasing the memory allocated to the Lambda function can improve its processing speed. AWS Lambda allocates CPU power proportional to the memory, meaning that more memory can result in faster processing of tasks. For tasks like video conversion, where computation power is important, increasing the memory might allow the Lambda function to complete the task more quickly, thus avoiding timeouts. - Best Use Case: This is a relevant option because allocating more memory to Lambda can reduce processing time and help prevent timeouts. - Explanation: Given that the video processing task is taking too long, increasing memory may help speed up the operation and finish the task within the timeout. Option B: Increase the visibility timeout on the SQS queue. - Reasoning: The visibility timeout on the SQS queue determines how long a message remains hidden from other consumers after it has been retrieved by a Lambda function. However, increasing the visibility timeout will not help with Lambda timeouts. It is useful for ensuring that messages are not processed multiple times while the Lambda function is still working on them, but it does not affect the function's execution time. - Rejection: This will not resolve the Lambda function’s time...

Author: NightmareDragon2025 · Last updated Jul 14, 2026

A company is building an application on AWS. The application's backend includes an Amazon API Gateway REST API. The company's frontend application developers cannot continue work until the backend API is ready for integration. The company needs a solution that will allow the frontend applicat...

In this scenario, the company needs a way for the frontend developers to continue their work while the backend API is being developed. This can be done by providing mock responses for the API methods so the frontend developers can test and integrate the frontend components. Let’s evaluate each option: Option A: Configure mock integrations for API Gateway API methods. - Reasoning: Mock integrations in Amazon API Gateway allow you to define responses directly in API Gateway without needing to set up any backend systems (like Lambda functions). You can configure mock responses for any HTTP status code, which can mimic the backend behavior. This will allow the frontend developers to work with predefined responses without the backend being fully implemented. - Best Use Case: This is the most operationally efficient solution because it provides the mock behavior of the API without additional code, such as Lambda functions or backend services. The mock integration can quickly simulate the API endpoints, allowing frontend developers to continue their work without delays. - Explanation: Mock integrations do not require backend systems or additional infrastructure, making them highly efficient for this type of scenario. Option B: Integrate a Lambda function with API Gateway and return a mocked response. - Reasoning: You can integrate a Lambda function with API Gateway and have the Lambda return a mocked response. While this solution would work, it involves setting up and managing a Lambda function, which adds extra complexity and is not as operationally efficient as the mock integration. - Rejection: Although this will work, it requires more setup (creating a Lambda function), which is...

Author: StarlightBear · Last updated Jul 14, 2026

A company is preparing to migrate an application to the company's first AWS environment. Before this migration, a developer is creating a proof-of-concept application to validate a model for building and deploying container-based applications on AWS. Which combination of steps should ...

In this scenario, the developer needs to deploy a containerized proof-of-concept application to AWS with the least operational effort. The key factors to consider include the simplicity of the deployment, minimal management overhead, and avoiding manual infrastructure management. Let's break down each option: Option A: Package the application into a .zip file by using a command line tool. Upload the package to Amazon S3. - Reasoning: This option describes packaging the application as a ZIP file and uploading it to Amazon S3. While Amazon S3 is excellent for storage, this is not the best solution for deploying a containerized application. Containerized applications are typically packaged into Docker images, not ZIP files, and stored in container registries like Amazon Elastic Container Registry (Amazon ECR) for deployment. - Rejection: Packaging the application into a ZIP file is not appropriate for container-based applications, as it doesn't align with containerization best practices (which involve Docker images). Additionally, using S3 would require more manual steps to deploy the application, which goes against the goal of minimizing operational effort. Option B: Package the application into a container image by using the Docker CLI. Upload the image to Amazon Elastic Container Registry (Amazon ECR). - Reasoning: This option aligns with best practices for containerized application deployment. By packaging the application as a Docker image and uploading it to Amazon ECR (which is AWS's managed container registry), the developer can use the image to deploy to various container services like Amazon ECS or EKS. - Best Use Case: This is the correct and most efficient step in container-based application deployments, as it follows the standard workflow for building and storing Docker images on AWS. ECR simplifies storing and versioning container images and integrates well with ECS or EKS. Option C: Deploy the application to an Amazon EC2 instance by using AWS CodeDeploy. - Reasoning: Deploying to an EC2 instance directly and using AWS CodeDeploy involves managing the infrastructure for EC2 instances, which increases the operational effort. For a containerized application, it is more efficient to use container orchestration services like Amazon ECS or EKS, which abstract away the need to manage i...

Author: Ahmed97 · Last updated Jul 14, 2026