Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company is using AWS CodePipeline to automate its release pipeline. AWS CodeDeploy is being used in the pipeline to deploy an application to Amazon Elastic Container Service (Amazon ECS) using the blue/green deployment model. The company wants to implement scripts to test the green version of the application before shifting traffic. These scripts will com...
To implement a strategy for testing the green version of an application before shifting traffic and rolling back in case of errors, let's evaluate each option based on the requirement that the tests complete within 5 minutes or less, and errors should trigger a rollback.
A) Add a stage to the CodePipeline pipeline between the source and deploy stages. Use AWS CodeBuild to create a runtime environment and build commands in the buildspec file to invoke test scripts. If errors are found, use the aws deploy stop-deployment command to stop the deployment.
- Explanation: This option adds a stage in CodePipeline that uses AWS CodeBuild to run test scripts before deploying the application. CodeBuild can run the test scripts, and if errors are found, it can invoke the `aws deploy stop-deployment` command to stop the deployment.
- Key Factors:
- CodeBuild can effectively create a runtime environment and run tests, but it may not be the most seamless way to integrate with the blue/green deployment model. CodeBuild runs independently from the deployment process.
- Stopping the deployment using the `aws deploy stop-deployment` command requires managing this manually in the pipeline after CodeBuild finishes testing.
- Why Rejected: This method introduces unnecessary complexity by involving a separate build stage and manual rollback mechanism. It is not as tightly integrated with the CodeDeploy deployment lifecycle.
B) Add a stage to the CodePipeline pipeline between the source and deploy stages. Use this stage to invoke an AWS Lambda function that will run the test scripts. If errors are found, use the aws deploy stop-deployment command to stop the deployment.
- Explanation: Similar to option A, this option involves adding a stage in the pipeline to run test scripts using AWS Lambda. If any errors are found, the `aws deploy stop-deployment` command is triggered to halt the deployment.
- Key Factors:
- AWS Lambda is a better choice for running test scripts in this case as it can run quickly (within the 5-minute limit) and integrate seamlessly with the pipeline.
- However, stopping the deployment manually using `aws deploy stop-deployment` after Lambda runs the test script can be cumbersome, and doesn't align perfectly with the built-in rollback functionality provided by CodeDeploy.
- Why Rejected: While AWS Lambda is a good choice for testing, this method requires manual intervention to stop the deployment, which isn't as efficient or integrated into the blue/green deployment process compared to CodeDeploy lifecycle events.
C) Add a hooks section to the CodeDeploy AppSpec file. Use the AfterAllowTestTraf...
Author: StarryEagle42 · Last updated Jul 20, 2026
A company uses AWS Storage Gateway in file gateway mode in front of an Amazon S3 bucket that is used by multiple resources. In the morning when business begins, users do not see the objects processed by a third party the previous evening. When a DevOps engineer looks directly at the S3 bucket, the data is the...
To address the issue where updated third-party files are visible directly in the Amazon S3 bucket but not in the Storage Gateway, we need to ensure that the Storage Gateway reflects the most recent updates from the S3 bucket. Let's evaluate each option to find the best solution:
A) Configure a nightly Amazon EventBridge event to invoke an AWS Lambda function to run the RefreshCache command for Storage Gateway.
- Explanation: The `RefreshCache` command can be used to ensure that the cache in the Storage Gateway is refreshed, reflecting the latest changes made in the underlying S3 bucket. By setting up a nightly event via EventBridge to invoke the `RefreshCache` command, we ensure that the updated files in S3 are available in the Storage Gateway at the beginning of the workday.
- Key Factors:
- This solution directly addresses the issue of ensuring updated files are available in the Storage Gateway by refreshing its cache.
- A scheduled refresh ensures that the updated files, such as those processed by the third party the previous evening, are accessible when users begin work in the morning.
- The solution is straightforward and automated, providing a reliable way to ensure the cache is synchronized with the latest files.
- Why Selected: This approach is a targeted solution to ensure the Storage Gateway cache reflects the most recent changes in the S3 bucket, making it the most appropriate choice for this scenario.
B) Instruct the third party to put data into the S3 bucket using AWS Transfer for SFTP.
- Explanation: AWS Transfer for SFTP is a service that allows the third party to securely upload files to S3 using the SFTP protocol. However, this does not address the issue with the Storage Gateway, as it would still be a matter of caching. The files would be correctly placed in the S3 bucket, but they still would not be immediately visible in the Storage Gateway unless the cache is refreshed.
- Key Factors:
- While AWS Transfer for SFTP is a good method for securely transferring files, it doesn’t directly address the synchronization issue between S3 and Storage Gateway.
- Why Rejected: This approach does not resolve the core issue of ensuring that the updated files in S3 are ...
Author: Vikram · Last updated Jul 20, 2026
A DevOps engineer needs to back up sensitive Amazon S3 objects that are stored within an S3 bucket with a private bucket policy using S3 cross-Region replication functionality. The objects need to be copied to a target bucket in a different AWS Regio...
To enable cross-Region replication for sensitive Amazon S3 objects between two AWS accounts, the following actions need to be performed:
1. A) Create a replication IAM role in the source account
This action is required because S3 uses the replication IAM role to allow the source bucket to perform the replication of objects to the target bucket. The replication IAM role in the source account should have the necessary permissions to read from the source bucket and write to the target bucket in the destination region and account.
2. C) Add statements to the source bucket policy allowing the replication IAM role to replicate objects
The source bucket policy must allow the replication IAM role to access the objects for replication. These permissions are essential to ensure that the replication IAM role can read from the source bucket and replicate objects to the target bucket.
3. D) Add statements to the target bucket policy allowing the replication IAM role to replicate objects
The target bucket must allow the replication IAM role to write objects into it. This is done by modifying the target bucket policy to grant the replication IAM role in the source account the necessary write permissions.
Explanation of rejected options:
- B) Create a replication IAM role in the target account
This i...
Author: Emma · Last updated Jul 20, 2026
A company has multiple member accounts that are part of an organization in AWS Organizations. The security team needs to review every Amazon EC2 security group and their inbound and outbound rules. The security team wants to programmatically retrieve this information from the member accounts using an AWS Lambda fu...
To programmatically retrieve Amazon EC2 security group information from member accounts in an AWS Organization, the following combination of access changes will meet the requirements:
Selected Options:
- B) Create a trust relationship that allows users in the management account to assume the IAM roles of the member accounts.
This option is essential because the Lambda function in the management account will need to assume IAM roles in the member accounts to retrieve EC2 security group information. By setting up the trust relationship, the management account will have the necessary permissions to assume the IAM roles in member accounts.
- C) Create an IAM role in each member account that has access to the AmazonEC2ReadOnlyAccess managed policy.
This option ensures that the IAM role in each member account has sufficient permissions to read EC2 security group information. The `AmazonEC2ReadOnlyAccess` policy provides the necessary permissions to list and view EC2 security groups and their inbound and outbound rules without granting full administrative privileges.
- E) Create an IAM role in the management account that allows the sts:AssumeRole action against the member account IAM role's ARN.
This option is required because the Lambda function in the management account will need the ability to assume the IAM roles of the member accounts. By setting this permission, the management account is allowed to perform the `sts:AssumeRole` action and retrieve EC2 security group data from the member accou...
Author: Amira · Last updated Jul 20, 2026
A space exploration company receives telemetry data from multiple satellites. Small packets of data are received through Amazon API Gateway and are placed directly into an Amazon Simple Queue Service (Amazon SQS) standard queue. A custom application is subscribed to the queue and transforms the data into a standard format.
Because of inconsistencies in the data that the satellites produce, the application is occasionally unable to transform the data. In these cases, the messages remain ...
To meet the requirements of retaining failed messages for future review and processing by scientists, let's analyze the possible options:
Option A: Configure AWS Lambda to poll the SQS queue and invoke a Lambda function to check whether the queue messages are valid. If validation fails, send a copy of the data that is not valid to an Amazon S3 bucket so that the scientists can review and correct the data. When the data is corrected, amend the message in the SQS queue by using a replay Lambda function with the corrected data.
- Why it's selected: This option involves using AWS Lambda to poll the SQS queue and handle invalid data. If validation fails, the invalid data is stored in an Amazon S3 bucket, which is an ideal location for scientists to review and manually correct the data. Additionally, the data can be reprocessed later. This approach provides flexibility and visibility for scientists and ensures that the data is not lost.
- Why others are rejected: Although this solution requires more configuration, it offers the flexibility to store the problematic data in a centralized location (S3), which is easier to manage and review. Reprocessing can be done later, providing full control over failed messages.
Option B: Convert the SQS standard queue to an SQS FIFO queue. Configure AWS Lambda to poll the SQS queue every 10 minutes by using an Amazon EventBridge schedule. Invoke the Lambda function to identify any messages with a SentTimestamp value that is older than 5 minutes, push the data to the same location as the application's output location, and remove the messages from the queue.
- Why it’s rejected: Converting to a FIFO queue might not be necessary because the problem described does not require strict ordering, and FIFO queues are typically used for scenarios where message order is critical. Additionally, pushing data to the same output location might not be ideal for review purposes, as it doesn’t address the need for scientists to review invalid data separately. Also, this option doesn't provide an easy way to reprocess the data after it’s been corrected.
Option C: Create an SQS dead-let...
Author: IceDragon2023 · Last updated Jul 20, 2026
A company wants to use AWS CloudFormation for infrastructure deployment. The company has strict tagging and resource requirements and wants to limit the deployment to two Regions. Developers will need to deploy multiple versions of th...
To ensure that resources are deployed in accordance with company policy, let's evaluate the options based on the given requirements: strict tagging, resource requirements, and deployment limitations to two Regions.
Option A: Create AWS Trusted Advisor checks to find and remediate unapproved CloudFormation StackSets.
- Why it's rejected: AWS Trusted Advisor provides recommendations for best practices across various AWS services, but it is not directly designed to enforce deployment constraints like region limitations, tagging requirements, or resource approval. Trusted Advisor can give insights on some misconfigurations but cannot restrict or enforce deployment policies during infrastructure deployment. It is more about post-deployment checks and not proactive deployment control.
Option B: Create a CloudFormation drift detection operation to find and remediate unapproved CloudFormation StackSets.
- Why it's rejected: CloudFormation drift detection is a valuable tool to detect when the actual configuration of resources managed by CloudFormation deviates from the configuration defined in the CloudFormation template. However, it only identifies drifts in existing resources, not the constraints related to deployments (such as limiting to two Regions or enforcing tags during initial deployment). It is reactive rather than preventive, making it unsuitable for this scenario.
Option C: Create CloudFormation StackSets with approved CloudFormation templates.
- Why it's selected: CloudFormation StackSets allow you to deploy CloudFormation templates across multiple accounts and Regions. By using StackSets, you can control deployments to only the two Regions that are allowed. You can define ap...
Author: Olivia · Last updated Jul 20, 2026
A company requires that its internally facing web application be highly available. The architecture is made up of one Amazon EC2 web server instance and one NAT instance that provides outbound internet access for updates and accessing public data.
Which c...
To achieve high availability for the company's internally facing web application, let's analyze the options based on the need for redundancy, fault tolerance, and scalability.
Option A: Add the NAT instance to an EC2 Auto Scaling group that spans multiple Availability Zones. Update the route tables.
- Why it’s selected: Adding the NAT instance to an EC2 Auto Scaling group that spans multiple Availability Zones ensures that the NAT instance is highly available. If one Availability Zone becomes unavailable, the Auto Scaling group will launch a new instance in a healthy zone to replace the failed one. This ensures that outbound internet access for updates and public data access remains available. This solution improves the availability of the NAT instance, which is critical for the EC2 instances that require outbound access.
- Why other options are rejected: This approach directly addresses the need for redundancy and ensures high availability of the NAT instance, which is important since it's a single point of failure in the architecture.
Option B: Create additional EC2 instances spanning multiple Availability Zones. Add an Application Load Balancer to split the load between them.
- Why it’s selected: Spanning EC2 instances across multiple Availability Zones and using an Application Load Balancer (ALB) ensures that the web application is fault-tolerant and scalable. If one EC2 instance fails or becomes unavailable, the ALB will distribute the traffic to healthy instances in other Availability Zones. This ensures high availability for the web application itself, providing fault tolerance in case of instance or AZ failure.
- Why other options are rejected: Adding just a single EC2 instance limits availability because it creates a single point of failure. The web application needs to be deployed in multiple instances across different Availability Zones for high availability, which is what this option achieves.
Option C: Configure an Application Load Balancer in front of the EC2 instance. Configure Amazon CloudWatch alarms to recover the EC2 instance upon host failure.
- Why it’s rejected: Although using an ALB in front of the EC2 instance provides load balancing, it doesn’t add...
Author: Zain · Last updated Jul 20, 2026
A DevOps engineer is building a multistage pipeline with AWS CodePipeline to build, verify, stage, test, and deploy an application. A manual approval stage is required between the test stage and the deploy stage. The development team uses a custom chat tool with webhook support that requires near-real-time notifi...
To determine the best solution, let's evaluate the options based on the requirements and the reasoning behind each one.
A) Create an Amazon CloudWatch Logs subscription that filters on CodePipeline Pipeline Execution State Change. Publish subscription events to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the chat webhook URL to the SNS topic, and complete the subscription validation.
- Pros:
- CloudWatch Logs can capture detailed pipeline activity, and SNS is a good way to notify external systems.
- The SNS subscription can trigger real-time notifications, ensuring near-real-time updates.
- Simple to set up and does not require modifying the pipeline's code.
- Cons:
- Relies on CloudWatch Logs, which may require careful management of log retention and potential costs associated with high log volume.
- Adds complexity in maintaining the subscription infrastructure.
B) Create an AWS Lambda function that is invoked by AWS CloudTrail events. When a CodePipeline Pipeline Execution State Change event is detected, send the event details to the chat webhook URL.
- Pros:
- Lambda can be triggered by CloudTrail events to handle specific events like pipeline state changes, offering flexibility for custom processing.
- Lambda gives flexibility in how the event is formatted and sent to the chat tool.
- Cons:
- More complex to set up than simply subscribing to an SNS topic.
- CloudTrail logs may introduce delays, making it less ideal for near-real-time notifications.
- Introducing Lambda requires more management overhead for function execution and error handling.
C) Create an Amazon EventBridge rule that filters on CodePipeline Pipeline Execution State Change. Publish the events to an Amazon Simple Notification Service (Amazon SNS) topic. Create an AWS Lambda function that sends event details to the chat webhook URL. Subscribe the function to the SNS topic.
- Pros:
- EventBridge provides a robust wa...
Author: Sophia Clark · Last updated Jul 20, 2026
A company's application development team uses Linux-based Amazon EC2 instances as bastion hosts. Inbound SSH access to the bastion hosts is restricted to specific IP addresses, as defined in the associated security groups. The company's security team wants to receive a notification if the securi...
To meet the requirement of notifying the security team if the security group rules are modified to allow SSH access from any IP address, let's evaluate each option carefully.
A) Create an Amazon EventBridge rule with a source of aws.cloudtrail and the event name AuthorizeSecurityGroupIngress. Define an Amazon Simple Notification Service (Amazon SNS) topic as the target.
- Pros:
- CloudTrail tracks API calls related to AWS resource changes, including security group modifications.
- The `AuthorizeSecurityGroupIngress` event specifically captures changes to inbound security group rules, including changes to allow SSH access.
- EventBridge can trigger an SNS notification, ensuring real-time alerts.
- Highly targeted to the requirement of detecting changes to security group rules.
- Cons:
- Needs to ensure the EventBridge rule is configured to detect only the relevant changes (e.g., opening SSH access to all IPs).
- Not as automated for other checks or broader configuration management, but it's still a direct match for the requirement.
B) Enable Amazon GuardDuty and check the findings for security groups in AWS Security Hub. Configure an Amazon EventBridge rule with a custom pattern that matches GuardDuty events with an output of NON_COMPLIANT. Define an Amazon Simple Notification Service (SNS) topic as the target.
- Pros:
- GuardDuty detects suspicious activity and can monitor for security risks such as open ports.
- Cons:
- GuardDuty is more focused on detecting actual threats and unusual activity, not configuration changes.
- This option would not be ideal for tracking specific security group rule modifications (e.g., allowing SSH from any IP), as GuardDuty would not trigger for a routine configuration change but more for malicious or unauthorized activity.
- It's a broader security monitoring tool, not a precise solution for the specific task of alerting on changes to security group rules.
C) Create an AWS Config rule by using the restricted-ssh managed rule to check ...
Author: NightmareDragon2025 · Last updated Jul 20, 2026
A DevOps team manages an API running on-premises that serves as a backend for an Amazon API Gateway endpoint. Customers have been complaining about high response latencies, which the development team has verified using the API Gateway latency metrics in Amazon CloudWatch. To identify the cause, the team nee...
To identify the cause of high response latencies without introducing additional latency, the team needs to focus on efficient and real-time monitoring solutions that do not significantly add overhead to the system. Let's analyze the options:
A) Install the CloudWatch agent server side and configure the agent to upload relevant logs to CloudWatch.
- Pros:
- Installing the CloudWatch agent can collect system-level metrics and logs from the on-premises environment, which may give insight into the server performance.
- Cons:
- This solution adds potential overhead and latency, as the agent needs to periodically upload logs and metrics to CloudWatch, which could slightly affect performance.
- It may not provide the granularity of tracing for individual API requests, making it less useful for pinpointing specific latency issues related to the API itself.
- The CloudWatch agent would typically monitor system performance and logs, which is not as focused as tracing the API calls specifically.
B) Enable AWS X-Ray tracing in API Gateway, modify the application to capture request segments, and upload those segments to X-Ray during each request.
- Pros:
- AWS X-Ray is a powerful tool for tracing requests through a distributed system and can provide detailed insight into the latency and performance of each request.
- Modifying the application to capture request segments and sending them to X-Ray directly can help trace the root cause of latencies at the application level.
- Cons:
- Uploading segments directly from the application could introduce some additional overhead during request processing, which goes against the goal of minimizing latency.
- While useful, this approach is slightly more intrusive than other solutions, as it requires application modifications to handle tracing.
C) Enable AWS X-Ray tracing in API Gateway, modify the application to capture request segments, and use the X-Ray daemon to upload segments to X-Ray.
- Pros:
- X-Ray tracing provides detailed insights into the request flow and can help identify bottlenecks in both the API Gateway and the on-premises application.
- The X-Ray daemon is designed to ef...
Author: Emma · Last updated Jul 20, 2026
A company has an application that is using a MySQL-compatible Amazon Aurora Multi-AZ DB cluster as the database. A cross-Region read replica has been created for disaster recovery purposes. A DevOps engineer wants to automate the promotion of the replica...
To automate the promotion of a cross-Region read replica in the event of a failure and ensure minimal downtime, the solution must be efficient, scalable, and maintainable. Let's go over each option:
A) Configure a latency-based Amazon Route 53 CNAME with health checks so it points to both the primary and replica endpoints. Subscribe an Amazon SNS topic to Amazon RDS failure notifications from AWS CloudTrail and use that topic to invoke an AWS Lambda function that will promote the replica instance as the primary.
- Pros:
- The latency-based Route 53 CNAME can ensure that traffic is routed to the primary database or the replica based on latency.
- Using SNS and Lambda to promote the replica is an automation strategy that fits well with the requirement for disaster recovery.
- Cons:
- This solution requires setting up multiple components (Route 53, SNS, CloudTrail, Lambda) to work together, which can be complex and error-prone.
- AWS CloudTrail does not directly notify about RDS failovers, so additional monitoring might be needed to trigger the SNS notifications.
- The complexity of managing Route 53 records for this scenario could introduce unnecessary delays or failures if the DNS change does not propagate quickly.
B) Create an Aurora custom endpoint to point to the primary database instance. Configure the application to use this endpoint. Configure AWS CloudTrail to run an AWS Lambda function to promote the replica instance and modify the custom endpoint to point to the newly promoted instance.
- Pros:
- The Aurora custom endpoint provides a dynamic way to always point to the current primary database instance, simplifying application configuration.
- The Lambda function can automate the promotion of the replica and modify the custom endpoint to reflect the new primary.
- Cons:
- Configuring CloudTrail to run a Lambda function based on RDS failure events is tricky because CloudTrail does not directly capture RDS failover events. Additional event detection and monitoring would be required.
- This option does not provide as smooth a failover process as directly monitoring for Aurora-specific failovers with EventBridge or other native methods.
C) Create an AWS Lambda function to modify the application's AWS CloudFormation template to promote the replica, apply t...
Author: BlazingPhoenix22 · Last updated Jul 20, 2026
A company hosts its staging website using an Amazon EC2 instance backed with Amazon EBS storage. The company wants to recover quickly with minimal data losses in the event of network connectivity issu...
To determine the best solution for minimizing data loss and recovering quickly from issues such as network connectivity or power failures, let's analyze each option:
A) Add the instance to an EC2 Auto Scaling group with the minimum, maximum, and desired capacity set to 1.
- Pros:
- This would automatically launch a new instance if the original one fails.
- Cons:
- While the Auto Scaling group would ensure a new instance is launched in case of failure, it does not address the issue of preserving data. If the EC2 instance fails, the data on the instance could be lost unless it's backed by persistent storage, and the Auto Scaling group wouldn't restore the previous state of the EBS volume.
- This approach is suitable for scaling but doesn't specifically target fast recovery with minimal data loss.
B) Add the instance to an EC2 Auto Scaling group with a lifecycle hook to detach the EBS volume when the EC2 instance shuts down or terminates.
- Pros:
- The lifecycle hook would allow for detaching the EBS volume before the instance is terminated, which ensures that data is preserved.
- Cons:
- While detaching the EBS volume could preserve data, it doesn't address the issue of recovering the instance itself. The instance would still need to be re-launched manually or by a separate process, and the state of the system would not be fully restored.
- This could be useful for preserving data but doesn't meet the goal of quick recovery.
C) Create an Amazon CloudWatch alarm for the StatusCheckFailed System metric and select the EC2 action to recover the instance.
- Pros:
- The StatusCheckFailed System metric checks the overall health of the EC2 instance, including issues like network connectivity and...
Author: VioletCheetah55 · Last updated Jul 20, 2026
A company wants to use AWS development tools to replace its current bash deployment scripts. The company currently deploys a LAMP application to a group of Amazon EC2 instances behind an Application Load Balancer (ALB). During the deployments, the company unit tests the committed application, stops and starts services, unregisters and re-registers instances with the load balancer, and update...
Let’s evaluate each option based on the requirements provided:
Key requirements:
1. Test the application (unit tests).
2. Restart services.
3. Unregister and re-register instances with the Application Load Balancer (ALB).
4. Update file permissions.
Option A:
- AWS CodeBuild is used for testing the application (unit tests).
- AWS CodeDeploy is used with bash scripts in the `appspec.yml` file for restarting services, and unregistering/re-registering the instances.
- The appspec.yml file handles updating file permissions without a custom script.
Evaluation:
- Pros: Using AWS CodeBuild for testing and AWS CodeDeploy for deployment is a standard and common approach. The bash scripts invoked in the `appspec.yml` allow full control over service management and instance registration.
- Cons: The use of bash scripts in the `appspec.yml` adds complexity, and the handling of ALB registrations within bash scripts might not be the most efficient approach, especially since CodeDeploy does not have built-in features for managing ALB registration. Additionally, manually writing scripts for services could be error-prone.
Option B:
- AWS CodePipeline is used to move the application from AWS CodeCommit to AWS CodeDeploy.
- AWS CodeDeploy deployment group is used for testing the application, restarting services, and unregistering/re-registering instances with the ALB.
- The appspec.yml file handles file permissions updates without a custom script.
Evaluation:
- Pros: CodePipeline integrates well with CodeCommit and CodeDeploy, providing a streamlined CI/CD workflow. CodeDeploy provides a built-in mechanism for restarting services, and integration with ALB is straightforward through the deployment group.
- Cons: CodeDeploy does not natively provide unit testing capabilities, and it’s unclear how it would handle ALB registrations. Without integration with CodeBuild, testing is lacking in this solution. Therefore, this option may miss the ...
Author: Ming88 · Last updated Jul 20, 2026
A company runs an application with an Amazon EC2 and on-premises configuration. A DevOps engineer needs to standardize patching across both environments. Company policy dictates that patching only happens during no...
To standardize patching across both Amazon EC2 and on-premises systems, the solution must enable the management of both environments with minimal complexity while adhering to the company’s requirement of performing patching during non-business hours.
Option Breakdown:
A) Add the physical machines into AWS Systems Manager using Systems Manager Hybrid Activations.
- Reasoning: This is the appropriate method for managing on-premises servers with AWS Systems Manager. The Hybrid Activations allow you to integrate and manage on-premises servers like EC2 instances. This step is necessary to bring the on-premises machines under Systems Manager's control, which is critical for patching.
- Selected: Yes, this is required for integrating on-premises servers.
B) Attach an IAM role to the EC2 instances, allowing them to be managed by AWS Systems Manager.
- Reasoning: EC2 instances must have an IAM role attached with the necessary permissions to allow AWS Systems Manager to manage them. This is a basic requirement for all EC2 instances managed via Systems Manager, enabling patching and other automation tasks.
- Selected: Yes, this is necessary for enabling EC2 management by Systems Manager.
C) Create IAM access keys for the on-premises machines to interact with AWS Systems Manager.
- Reasoning: While IAM access keys can authenticate on-premises machines to interact with AWS services, this is not the recommended method for Systems Manager. Instead, Hybrid Activations (Option A) are the more secure and efficient way to manage on-premises servers. IAM keys might lead to unnecessary complexity and potential security risks.
- Rejected: No, this is not the best method for managing on-premises machines, and it’s less secure than using Hybrid Activations.
D) Run an AWS Systems Manag...
Author: Maya · Last updated Jul 20, 2026
A company has chosen AWS to host a new application. The company needs to implement a multi-account strategy. A DevOps engineer creates a new AWS account and an organization in AWS Organizations. The DevOps engineer also creates the OU structure for the organization and sets up a landing zone by using AWS Control Tower.
The DevOps engineer must implement a solution that automatically deploys resources for new accounts that users create through AWS Control Tower Account Factory. When a user creates a new account, the solution must apply AWS CloudFormation templates and...
To implement the solution in the most automated way and meet the requirement to automatically deploy resources for new accounts that users create through AWS Control Tower Account Factory, we need to focus on automation for both resource provisioning and policy enforcement (SCPs).
Option Breakdown:
A) Use AWS Service Catalog with AWS Control Tower. Create portfolios and products in AWS Service Catalog. Grant granular permissions to provision these resources. Deploy SCPs by using the AWS CLI and JSON documents.
- Reasoning: AWS Service Catalog helps manage and provision resources in a controlled and repeatable manner, but it does not natively integrate well with the automatic deployment of SCPs when new accounts are created. The need for manual deployment of SCPs via the AWS CLI makes this solution less automated and more complex than necessary.
- Rejected: This solution requires manual intervention for SCPs, which is not fully automated as per the requirements.
B) Deploy CloudFormation stack sets by using the required templates. Enable automatic deployment. Deploy stack instances to the required accounts. Deploy a CloudFormation stack set to the organizations management account to deploy SCPs.
- Reasoning: CloudFormation StackSets are ideal for deploying resources across multiple accounts automatically. StackSets allow CloudFormation templates to be deployed to multiple accounts and regions in AWS Organizations. This solution also supports the automatic application of resources and policies to new accounts. However, deploying StackSets requires configuration, and deploying SCPs using StackSets is less direct compared to other options specifically for SCP management.
- Selected: Yes, this is an effective solution for deploying resources automatically across multiple accounts. It can be set up for automatic deployments, but it requires additional configuration for SCP deployment.
C) Creat...
Author: Max · Last updated Jul 20, 2026
An online retail company based in the United States plans to expand its operations to Europe and Asia in the next six months. Its product currently runs on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Amazon EC2 Auto Scaling group across multiple Availability Zones. All data is stored in an Amazon Aurora database instance.
When the product is deployed in multiple regions, the company wants a single product catalog across all...
To meet the company’s requirements, the solution must allow for a single product catalog across multiple regions while ensuring that customer information and purchases are kept regional for compliance purposes. Additionally, the solution should minimize the amount of application changes.
Key factors to consider:
1. Single Product Catalog Across Regions: The product catalog should be available globally, meaning it should be accessible across all regions without requiring complex synchronization.
2. Regional Data Compliance: Customer information and purchases should be kept within their respective regions to comply with legal and regulatory requirements.
3. Minimal Application Changes: The solution should require the least amount of change to the existing application architecture and workflows.
Option A: Use Amazon Redshift for the product catalog and Amazon DynamoDB tables for the customer information and purchases.
- Reasoning: While Redshift is excellent for large-scale data analytics, it is not ideal for managing a product catalog that requires low-latency read and write operations. DynamoDB is a suitable choice for regional customer data, but using Redshift for the product catalog adds complexity and may require significant changes to the application. Redshift is not typically used for serving a product catalog in real-time; it’s more suited for analytics workloads.
- Rejected: No, this option requires unnecessary changes and introduces complexity without aligning with the operational requirements of a product catalog.
Option B: Use Amazon DynamoDB global tables for the product catalog and regional tables for the customer information and purchases.
- Reasoning: DynamoDB global tables provide multi-region, fully replicated databases, which are perfect for a globally accessible product catalog. Regional DynamoDB tables can be used for customer information and purchases, keeping the data compliant within the respective regions. This option ensures minimal changes to the application, especially if the product catalog is already using DynamoDB.
- Selected: Yes, this i...
Author: Michael · Last updated Jul 20, 2026
A company is implementing a well-architected design for its globally accessible API stack. The design needs to ensure both high reliability and fast response times for users located in North America and Europe.
The API stack contains the following three t...
To implement a globally accessible API stack with high reliability and fast response times for users in North America and Europe, the solution must efficiently route traffic to the closest region, ensure high availability, and minimize latency. The stack involves Amazon API Gateway, AWS Lambda, and Amazon DynamoDB.
Key considerations:
1. High Reliability: The solution must ensure that both regions (North America and Europe) can handle traffic and continue functioning in the event of an issue in one region.
2. Fast Response Times: Requests should be routed to the nearest region to minimize latency.
3. DynamoDB Data Access: The solution should handle data access in a way that minimizes latency for both regions, especially since DynamoDB is region-specific unless using global tables.
Option A: Configure Amazon Route 53 to point to API Gateway APIs in North America and Europe using health checks. Configure the APIs to forward requests to a Lambda function in that Region. Configure the Lambda functions to retrieve and update the data in a DynamoDB table in the same Region as the Lambda function.
- Reasoning: This option allows the routing of traffic to the nearest API Gateway region. By using health checks, it ensures that traffic is only routed to healthy regions. However, it uses region-specific DynamoDB tables, which could cause issues if there is a need to share data between North America and Europe.
- Rejected: No, using region-specific DynamoDB tables means data would not be shared between the regions, creating potential issues with consistency and data duplication across regions.
Option B: Configure Amazon Route 53 to point to API Gateway APIs in North America and Europe using latency-based routing and health checks. Configure the APIs to forward requests to a Lambda function in that Region. Configure the Lambda functions to retrieve and update the data in a DynamoDB global table.
- Reasoning: This option uses latency-based routing to ensure that requests are routed to the nearest region. It also utilizes DynamoDB global tables, which replicate data across regions, allowing both North America and Europe to access the same data with low latency and high availability.
- Selected: Yes, this option ensures high availability a...
Author: Matthew · Last updated Jul 20, 2026
A rapidly growing company wants to scale for developer demand for AWS development environments. Development environments are created manually in the AWS Management Console. The networking team uses AWS CloudFormation to manage the networking infrastructure, exporting stack output values for the Amazon VPC and all subnets. The development environments have common standards, such as Application Load Balancers, Amazon EC2 Auto Scaling groups, security groups, and Amazon DynamoDB tables.
To keep up with demand, the DevOps engineer wants to automate the creation of development environments. Because the infrastructure required to support the applicati...
To solve this problem, let's review each option based on the key requirements: automation, scalability, consistent environments, and ease of updates.
Option A:
- Fn::ImportValue in the Resources section to retrieve VPC and subnet values from the networking stack is possible, but using it in the Resources section might not be ideal as it's meant for resource definitions, not fetching parameters.
- CloudFormation StackSets can help in scaling development environments across multiple accounts or regions, which is beneficial for larger, growing organizations.
- However, StackSets require managing the same template across multiple stacks and managing updates can be more complex. StackSets would require careful management of changes to prevent inconsistency or failures.
- UpdateStackSet is useful for updating multiple environments, but the use of the Count input parameter isn’t directly related to easily managing updates or ensuring consistent environments.
Rejected Reason: The use of StackSets for managing individual developer environments might add unnecessary complexity and overhead. Furthermore, importing values in the wrong section (Resources) is not ideal.
Option B:
- Nested stacks are used to define reusable common infrastructure components, which fits well with the standardization and automation required.
- TemplateURL references the networking team's template, allowing the root template to reference the VPC and subnet values.
- Using Fn::ImportValue in the Parameters section is a better choice because parameters are intended for this use, and it ensures that values can be accessed correctly by different parts of the template.
- CreateChangeSet and ExecuteChangeSet commands allow for controlled updates to existing development environments.
Selected Option (Reasoning): This option strikes a good balance between modularity, reusabil...
Author: Sofia · Last updated Jul 20, 2026
A company uses AWS Organizations to manage multiple accounts. Information security policies require that all unencrypted Amazon EBS volumes be marked as non-compliant. A DevOps engineer needs to automatically deploy the soluti...
Option A:
- CloudFormation Template with AWS Inspector Rule:
- AWS Inspector is used for security assessments, and although it can scan EC2 instances, it is not designed for continuous compliance monitoring in terms of EBS volume encryption.
- The solution would require you to store the template in an S3 bucket and update the account creation script to reference this. While it might work, it would not automatically enforce compliance, and AWS Inspector is more for one-off assessments, not ongoing enforcement.
Rejected Reason: AWS Inspector is not a continuous compliance tool, and this approach would require manual intervention to enforce compliance, which is less efficient for automation.
Option B:
- AWS Config Organizational Rule:
- AWS Config is designed for continuous compliance monitoring. You can set an organizational rule to check whether EBS encryption is enabled, which will automatically monitor and flag non-compliant EBS volumes across multiple accounts in an AWS Organization.
- Deploying the rule using AWS CLI automates the deployment process, and applying an SCP (Service Control Policy) to prevent stopping and deleting AWS Config ensures that the compliance checks will persist, even if someone tries to disable them.
Selected Option (Reasoning): This option directly addresses the need for continuous monitoring and automatic enforcement of compliance using AWS Config. It ensures that all accounts are checked for EBS encryption, and applying an SCP prevents the disabling of Config. This solution is robust, scalable, and works across all accounts in an AWS Organization.
Option C:
- SCP with EC2 Instance Launch Prevention:
- An SCP could theoretically prevent the launch of EC2 instances without encrypted EBS volumes by using a conditio...
Author: Deepak · Last updated Jul 20, 2026
A company is performing vulnerability scanning for all Amazon EC2 instances across many accounts. The accounts are in an organization in AWS Organizations. Each account's VPCs are attached to a shared transit gateway. The VPCs send traffic to the internet through a central egress VPC. The company has enabled Amazon Inspector in a delegated administrator account and has enabled scanning for all member accounts.
A DevOps engineer disc...
To resolve the issue of EC2 instances being listed in the "not scanning" tab in Amazon Inspector, the problem is most likely related to the EC2 instances not being properly configured to communicate with Amazon Inspector, especially if they are not being properly managed or accessible via AWS Systems Manager (SSM). The following actions are needed to ensure Amazon Inspector can scan the EC2 instances.
Option A: Verify that AWS Systems Manager Agent is installed and is running on the EC2 instances that Amazon Inspector is not scanning.
- Amazon Inspector relies on the AWS Systems Manager Agent (SSM Agent) to perform the vulnerability scanning. If the SSM Agent is not installed or running on the EC2 instances, they cannot be scanned.
- This is the first step to check because if the agent is missing or not functioning, the instance cannot be scanned.
Selected Reasoning: The SSM Agent is a prerequisite for Amazon Inspector, so verifying its presence and proper functioning is a necessary step.
Option B: Associate the target EC2 instances with security groups that allow outbound communication on port 443 to the AWS Systems Manager service endpoint.
- Port 443 is required for secure communication with the AWS Systems Manager service, which Amazon Inspector uses for vulnerability scanning.
- Ensuring the security group associated with the EC2 instances allows outbound traffic on this port will ensure that the SSM Agent can communicate with AWS Systems Manager for the scanning process.
Selected Reasoning: Without the proper security group configuration allowing outbound traffic to AWS Systems Manager, the EC2 instance won't be able to communicate with the scanning service, leading to it being listed as "not scanning."
Option E: Associate the target EC2 instances with instance profiles that grant permissions to communicate with AWS Systems Manager.
- The instance profile (IAM role) associated with EC2 instances must include permissions to interact with AWS Systems Manager. Without the correct IAM role, the EC2 instances will not have the necessary permissions to send data to AWS Systems Manager or receive commands from Amazon Inspector.
- This is a key action to ensure that the EC2 instances are correctly authorized for scanning.
Selected Reasoning: The instance profile must have the appropriate permissions to enable ...
Author: Layla · Last updated Jul 20, 2026
A development team uses AWS CodeCommit for version control for applications. The development team uses AWS CodePipeline, AWS CodeBuild. and AWS CodeDeploy for CI/CD infrastructure. In CodeCommit, the development team recently merged pull requests that did not pass long-running tests in the code base. The development team needed to perform rollbacks to branches in the codebase, resulting in lost time and wasted effort.
A DevOps engineer must automate testing o...
To meet the requirement of automating testing for pull requests in AWS CodeCommit and ensuring that reviewers can easily see the results of automated tests during their review, let's evaluate each option:
Option A:
- EventBridge Rule on pullRequestStatusChanged Event:
- This rule would be triggered when the status of a pull request changes.
- A Lambda function would invoke a CodePipeline pipeline to run tests using CodeBuild and post the CodeBuild badge as a comment on the pull request.
- The badge is typically a visual representation of the build status, but it may not provide detailed information about the actual test results, which could be more helpful to reviewers.
Rejected Reason: While posting a badge is useful, it doesn’t directly show the test results, which could be crucial for developers to understand the cause of the failure. Detailed results are more informative than just a badge.
Option B:
- EventBridge Rule on pullRequestCreated Event:
- This event triggers when a new pull request is created.
- A Lambda function triggers CodePipeline and CodeBuild to run tests and posts the test results as a comment on the pull request when the tests are completed.
- This option ensures that tests are run as soon as a pull request is created, and reviewers can see the detailed results once the tests are done.
Selected Reasoning: This option meets the requirement by running tests when the pull request is created and providing detailed test results to reviewers via a comment on the pull request. This helps ensure that the pull request is properly reviewed and tested before being merged.
Option C:
- EventBridg...
Author: Oliver · Last updated Jul 20, 2026
A company has deployed an application in a production VPC in a single AWS account. The application is popular and is experiencing heavy usage. The company's security team wants to add additional security, such as AWS WAF, to the application deployment. However, the application's product manager is concerned about cost and does not want to approve the change unless the security team can prove that additional security is necessary.
The security team believes that some of the application's demand might come from users that have IP addresses that are on a deny list. The security team provides the deny list to a DevOps engineer. If any of the IP addresses on the deny list access the application, the security team wants to re...
To meet the requirement of automating the process of detecting if users from a deny list access the application and notifying the security team in near real-time, let's evaluate the options based on the following key criteria:
- Cost-effectiveness: The solution should minimize costs while still providing the necessary functionality.
- Real-time or near real-time notification: The solution should allow the security team to be notified quickly when an IP on the deny list accesses the application.
- Simplicity and ease of maintenance: The solution should be easy to set up and maintain, avoiding unnecessary complexity or overhead.
Option A:
- CloudWatch Logs with Metric Filters and SNS:
- This option captures accepted traffic using VPC flow logs, sends it to CloudWatch Logs, and then creates a metric filter to check for deny list IP addresses.
- A CloudWatch alarm is created that triggers based on the metric filter and sends a notification to the security team via SNS.
- This solution is simple, cost-effective, and provides near real-time notifications. CloudWatch Logs and SNS are efficient for this use case, and metric filters can process the log data quickly.
Selected Reasoning: This option is cost-effective because it uses CloudWatch Logs and SNS, which are relatively inexpensive compared to other services like OpenSearch or Athena. It also provides near real-time notifications, which satisfies the requirement for timely alerts.
Option B:
- S3 Bucket, Athena, and QuickSight:
- The VPC flow logs are sent to an S3 bucket. Athena is used to query the logs for deny list IPs, and QuickSight is used to display the results as a dashboard.
- While this solution would provide visibility into the traffic, it is more complex and expensive because Athena queries are chargeable, and QuickSight adds additio...
Author: Ahmed97 · Last updated Jul 20, 2026
A DevOps engineer has automated a web service deployment by using AWS CodePipeline with the following steps:
1. An AWS CodeBuild project compiles the deployment artifact and runs unit tests.
2. An AWS CodeDeploy deployment group deploys the web service to Amazon EC2 instances in the staging environment.
3. A CodeDeploy deployment group deploys the web service to EC2 instances in the production environment.
The quality assurance (QA) team requests permission to inspect the build artifact before the deployment to the production environment occ...
In this case, the QA team wants the ability to manually test the build artifact before it is deployed to the production environment. This request implies that an approval or manual intervention step must be added to the pipeline between the staging and production deployment steps.
Let's evaluate each option:
- A) Insert a manual approval action between the test actions and deployment actions of the pipeline.
- Reasoning: AWS CodePipeline supports manual approval actions. This would allow the QA team to inspect the artifact and run their internal penetration testing tool before the deployment to production. This is a valid choice because it directly supports the request for manual inspection and testing.
- Why it’s selected: Inserting a manual approval step allows the QA team to approve or reject the build before it is deployed to production, fulfilling their requirement.
- Why others are rejected:
- B) `Modify the buildspec.yml file for the compilation stage`: This option doesn't address the need for a manual approval or testing before deployment. The `buildspec.yml` file controls the build process, but it doesn't handle the pipeline’s approval or testing flow for staging vs. production environments.
- C) `Update the CodeDeploy deployment groups to requir...
Author: Isabella · Last updated Jul 20, 2026
A company is hosting a web application in an AWS Region. For disaster recovery purposes, a second region is being used as a standby. Disaster recovery requirements state that session data must be replicated between regions in near-real time and 1% of requests should route to the secondary region to continuously verify system functionality. Additionally, if there is a disruption in service in the main region, traffic sh...
Let's break down the scenario and evaluate the options one by one.
Key Requirements:
1. Session data replication in near-real-time: Session data should be replicated between regions almost instantly to ensure continuity in the event of a disaster.
2. 1% of requests routed to the secondary region: This requirement implies the need for traffic distribution across regions to constantly verify functionality.
3. Automatic failover: In the event of disruption in the main region, traffic should automatically route to the secondary region, which must scale to handle all the traffic.
Option A: Deploy the application on AWS Elastic Beanstalk and use Amazon DynamoDB global tables for session data. Use an Amazon Route 53 weighted routing policy with health checks to distribute the traffic across the regions.
- DynamoDB global tables provide near-real-time data replication between regions, which aligns with the requirement for session data replication.
- Elastic Beanstalk simplifies application deployment, scaling, and management in both regions, which would help with handling the traffic load in both regions.
- Route 53 weighted routing allows routing a percentage of traffic to different regions, which satisfies the 1% traffic routing requirement for verifying the secondary region’s functionality. Health checks in Route 53 will help ensure that traffic is routed to the correct region based on health status.
- Automatic failover is supported by Route 53 health checks. If the main region becomes unavailable, Route 53 can automatically route traffic to the secondary region.
Why it’s selected: This option meets all the requirements:
- Session data replication: DynamoDB global tables handle near-real-time replication.
- Traffic distribution: Route 53 weighted routing policy for 1% traffic.
- Automatic failover: Route 53 health checks allow for automatic traffic redirection to the secondary region.
- Scalability: Elastic Beanstalk handles auto-scaling automatically.
Option B: Launch the application in Auto Scaling groups and use DynamoDB for session data. Use a Route 53 failover routing policy with health checks to distribute the traffic across the regions.
- DynamoDB can be used for session data, but global tables are not explicitly mentioned, which could affect near-real-time replication of session data. DynamoDB Global Tables would be a better choice.
- Auto Scaling groups can automatically scale in both regions based on traffic.
- Route 53 failover routing can automatically route traffic to the secondary region if the main region becomes unavailable. However, failover routing is typically a disaster recovery option and does not provide ongoing 1% traffic routing to the secondary region for testing purposes.
Why rejected: This option doesn't support the 1% traffic routing to the secondary region for continuous verification of system functionality. Additionally, the l...
Author: RadiantJaguar56 · Last updated Jul 20, 2026
A company runs an application on Amazon EC2 instances. The company uses a series of AWS CloudFormation stacks to define the application resources. A developer performs updates by building and testing the application on a laptop and then uploading the build output and CloudFormation stack templates to Amazon S3. The developer's peers review the changes before the developer performs the CloudFormation stack update and installs a new version of the application onto the EC2 instances.
The deployment process is prone to errors and is time-consuming when the developer updates each EC2 instance with the new application. The company wants to automate as much of the application deployment process as possible while retaining a final manual approval step before the mod...
Let's go through each option and evaluate them in the context of the requirements:
Key Requirements:
1. Automate application deployment: We need to automate the application deployment process to reduce manual effort.
2. Retain manual approval step: The process should allow for a final manual approval step before the deployment of the application or modification of resources.
3. Update EC2 instances efficiently: The deployment should be streamlined to update EC2 instances without the current time-consuming manual process.
Option A: Create an application group and a deployment group in AWS CodeDeploy. Install the CodeDeploy agent on the EC2 instances.
- Reasoning: This option introduces AWS CodeDeploy, which is a good choice for automating the deployment process to EC2 instances. CodeDeploy can automate the update of the application on EC2 instances by installing the CodeDeploy agent.
- Why rejected: Although CodeDeploy is part of the solution, this option doesn't address the entire process, especially the steps for approving the deployment before the modification of resources, nor does it detail how the stack update would be automated (e.g., how the EC2 instances would be associated with CloudFormation).
Option B: Create an application revision and a deployment group in AWS CodeDeploy. Create an environment in CodeDeploy. Register the EC2 instances to the CodeDeploy environment.
- Reasoning: This option goes deeper into CodeDeploy by creating an environment for the EC2 instances. However, it still doesn't cover the need for the manual approval step or how the CloudFormation stack update would be integrated into the workflow.
- Why rejected: This option is incomplete because it doesn’t address the need for CloudFormation stack updates, nor does it incorporate a manual approval step.
Option C: Use AWS CodePipeline to invoke the CodeBuild job, run the CloudFormation update, and pause for a manual approval step. After approval, start the AWS CodeDeploy deployment.
- Reasoning: This option leverages AWS CodePipeline to automate the build and deploy process. CodePipeline can invoke CodeBuild to build and test the application, then it can trigger a CloudFormation update. Afterward, it pauses for manual approval. Once approved, CodeDeploy is used to deploy the application to EC2 instances.
- Why selected: This approach aligns with the company's desire to automate the application deployment while reta...
Author: StarryEagle42 · Last updated Jul 20, 2026
A DevOps engineer manages a web application that runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances run in an EC2 Auto Scaling group across multiple Availability Zones. The engineer needs to implement a deployment strategy that:
Launches a second fleet of instances with the same capacity as the original fleet.
Maintains the original fleet unchanged while the second fleet is launched.
Transitions...
Let's evaluate each option in the context of the requirement:
Key Requirements:
1. Launch a second fleet of instances with the same capacity as the original fleet.
2. Maintain the original fleet unchanged while the second fleet is launched.
3. Transition traffic to the second fleet when fully deployed.
4. Terminate the original fleet 1 hour after transition.
Option A: Use an AWS CloudFormation template with a retention policy for the ALB set to 1 hour. Update the Amazon Route 53 record to reflect the new ALB.
- Reasoning: A CloudFormation template could be used to deploy infrastructure, but this option focuses on ALB retention and Route 53 updates. While CloudFormation can automate the launching of a second fleet of EC2 instances, it doesn't inherently handle the blue/green deployment process (launching, transitioning traffic, and terminating the original fleet). Additionally, the retention policy and Route 53 update are more related to DNS management rather than EC2 Auto Scaling deployment strategies.
- Why rejected: This approach does not explicitly address the deployment flow or the termination of the original fleet after transitioning traffic. It lacks the necessary automation for blue/green deployment, and Route 53 is not the most appropriate tool for handling the EC2 fleet transition.
Option B: Use two AWS Elastic Beanstalk environments to perform a blue/green deployment from the original environment to the new one. Create an application version lifecycle policy to terminate the original environment in 1 hour.
- Reasoning: AWS Elastic Beanstalk provides a straightforward way to manage blue/green deployments. The environments can be swapped, which achieves the requirement of maintaining the original fleet while the second fleet is deployed. After transitioning traffic, the lifecycle policy can help terminate the original fleet.
- Why rejected: Elastic Beanstalk environments are typically used for application-level deployments (not directly managing EC2 Auto Scaling groups and load balancing configurations), and the requirement specifically involves an EC2 Auto Scaling group behind an ALB. Elastic Beanstalk may not provide the fine-grained control over the Auto Scaling groups and ALB as needed here. Also, managing instance-level scaling isn't as seamless in Beanstalk as it is with direct EC2 Auto Scaling and ALB configurations.
Option C: Use AWS CodeDeploy with a deployment gr...
Author: StarlightBear · Last updated Jul 20, 2026
A video-sharing company stores its videos in Amazon S3. The company has observed a sudden increase in video access requests, but the company does not know which videos are most popular. The company needs to identify the general access pattern for the video files. This pattern includes the number of users who access a certain file on a g...
Let’s evaluate each option based on the company's needs to identify the general access pattern for video files stored in Amazon S3, which includes determining which videos are most popular, the number of users who access each video on a given day, and the number of pull requests.
Key Requirements:
1. Track file access: The company needs to track which videos are accessed and how often.
2. Easy analysis: The company needs a way to analyze these access patterns efficiently.
3. Minimal effort: The solution should require the least amount of manual effort and maintenance.
Option A: Activate S3 server access logging. Import the access logs into an Amazon Aurora database. Use an Aurora SQL query to analyze the access patterns.
- Reasoning: S3 server access logging provides detailed logs about requests made to the S3 bucket. These logs can be imported into an Amazon Aurora database for analysis using SQL queries.
- Why rejected: This option requires a multi-step process: activating server access logging, setting up Aurora, importing the logs, and manually querying the database. Although this method will work, it is more complex than necessary. Managing the logs in Aurora and setting up queries adds operational overhead, and it requires more manual effort for data import and ongoing management.
Option B: Activate S3 server access logging. Use Amazon Athena to create an external table with the log files. Use Athena to create a SQL query to analyze the access patterns.
- Reasoning: S3 server access logs can be stored in S3, and Athena can be used to query the logs directly without needing to import the data into a database. Athena is a serverless query service that can handle large-scale log analysis efficiently.
- Why selected: This is the most efficient option in terms of effort and scalability. By using Athena, the company can directly query the S3 access logs without needing to import data into a database like Aurora. This reduces the operational overhead, and queries can be written in SQL, making the analysis process simpler. It also scales automatically based on the amount of data.
Option C: Invoke an AWS ...
Author: Chloe · Last updated Jul 20, 2026
A development team wants to use AWS CloudFormation stacks to deploy an application. However, the developer IAM role does not have the required permissions to provision the resources that are specified in the AWS CloudFormation template. A DevOps engineer needs to implement a solution that allows the devel...
Let's analyze each option:
A) Create an IAM policy that allows the developers to provision the required resources. Attach the policy to the developer IAM role.
- Pros: This option would grant developers the necessary permissions to provision resources directly through their own role.
- Cons: Granting permissions to the developer IAM role violates the principle of least privilege. Developers should not be given broad permissions unless they absolutely need them. This could result in overly permissive access to resources outside the scope of the CloudFormation deployment.
- Conclusion: This option is not ideal because it does not follow the least privilege principle.
B) Create an IAM policy that allows full access to AWS CloudFormation. Attach the policy to the developer IAM role.
- Pros: This would provide the developer role with full access to CloudFormation, ensuring they can deploy stacks.
- Cons: This grants more permissions than necessary, as the developers likely do not need full access to all CloudFormation features or resources, which also violates the least privilege principle.
- Conclusion: This option is not ideal because it provides excessive permissions and is not least-privilege compliant.
C) Create an AWS CloudFormation service role that has the required permissions. Grant the developer IAM role a cloudformation: action. Use the new service role during stack deployments.
- Pros: Using a...
Author: Chloe · Last updated Jul 20, 2026
A production account has a requirement that any Amazon EC2 instance that has been logged in to manually must be terminated within 24 hours. All applications in the production account are using Auto Scaling gr...
Let's evaluate each option:
A) Create a CloudWatch Logs subscription to an AWS Step Functions application. Configure an AWS Lambda function to add a tag to the EC2 instance that produced the login event and mark the instance to be decommissioned. Create an Amazon EventBridge rule to invoke a second Lambda function once a day that will terminate all instances with this tag.
- Pros: This approach involves automating the tagging and termination of instances using a combination of AWS services. Using AWS Step Functions adds structure to the workflow, and the EventBridge rule can automate the termination of tagged instances.
- Cons: The use of Step Functions introduces unnecessary complexity. AWS Step Functions are useful for more complex workflows, but in this case, a simpler solution could be more efficient.
- Conclusion: Although functional, the inclusion of AWS Step Functions is unnecessary for this use case, making it more complicated than needed.
B) Create an Amazon CloudWatch alarm that will be invoked by the login event. Send the notification to an Amazon Simple Notification Service (Amazon SNS) topic that the operations team is subscribed to, and have them terminate the EC2 instance within 24 hours.
- Pros: This solution relies on CloudWatch alarms and SNS to notify the operations team, ensuring manual termination of EC2 instances within the required time.
- Cons: This solution introduces a manual step, which contradicts the requirement for automation. The operations team must take action to terminate instances, which is error-prone and may not meet the 24-hour deadline every time.
- Conclusion: This option is not ideal because it requires manual intervention, which is not the goal of autom...
Author: Noah · Last updated Jul 20, 2026
A company has enabled all features for its organization in AWS Organizations. The organization contains 10 AWS accounts. The company has turned on AWS CloudTrail in all the accounts. The company expects the number of AWS accounts in the organization to increase to 500 during the next year. The company plans to use multiple OUs for these accounts.
The company has enabled AWS Config in each existing AWS account in the organization. A D...
Let's analyze each option in the context of the requirement to enable AWS Config automatically for all future AWS accounts created in the organization:
A) In the organization's management account, create an Amazon EventBridge rule that reacts to a CreateAccount API call. Configure the rule to invoke an AWS Lambda function that enables trusted access to AWS Config for the organization.
- Pros: Using an EventBridge rule to detect the `CreateAccount` API call can trigger an automated Lambda function to enable AWS Config for newly created accounts. Lambda is a flexible solution for implementing custom logic like enabling AWS Config.
- Cons: While this approach works well, it requires manually configuring the Lambda function to enable AWS Config for the account. It adds some operational overhead because the Lambda function must be designed and maintained.
- Conclusion: This option is viable but introduces complexity due to the need to manage the Lambda function and ensure the correct configuration of AWS Config in each new account.
B) In the organization's management account, create an AWS CloudFormation stack set to enable AWS Config. Configure the stack set to deploy automatically when an account is created through Organizations.
- Pros: Using AWS CloudFormation stack sets provides a way to ensure that AWS Config is enabled across all accounts automatically. Once configured, the stack set can deploy the configuration consistently across all accounts in the organization, including future accounts.
- Cons: This option requires setting up CloudFormation stack sets, which can add complexity in managing templates and deployments. Stack sets also require sufficient permissions to execute in new accounts, and this approach might not handle automatic enablement of AWS Config as seamlessly as other approaches.
- Conclusion: This approach works, but it introduces more complexity than needed for simply enabling AWS Config, especially if the org...
Author: Sophia · Last updated Jul 20, 2026
A company has many applications. Different teams in the company developed the applications by using multiple languages and frameworks. The applications run on premises and on different servers with different operating systems. Each team has its own release protocol and process. The company wants to reduce the complexity of the release and maintenance of these applications.
The company is migrating its technology stacks, including these applications, to AWS. The company wants centrali...
Let's evaluate each option based on the company's goals of reducing complexity, ensuring a consistent delivery pipeline, and minimizing maintenance:
A) Create one AWS CodeCommit repository for all applications. Put each application's code in a different branch. Merge the branches, and use AWS CodeBuild to build the applications. Use AWS CodeDeploy to deploy the applications to one centralized application server.
- Pros: This option centralizes the repository, which could simplify code management for small teams. It uses AWS CodeBuild and CodeDeploy, which are appropriate for CI/CD pipelines.
- Cons: Combining all applications in a single repository can create complexity in managing different applications with various frameworks and languages. It also leads to difficulties in isolating issues for specific applications, and conflicts could arise when merging code from different teams. Deploying to one centralized application server adds additional maintenance complexity, as it may become a bottleneck or a single point of failure.
- Conclusion: While feasible for a small number of applications, this option does not meet the need for flexibility and scalability with diverse applications across teams.
B) Create one AWS CodeCommit repository for each of the applications. Use AWS CodeBuild to build the applications one at a time. Use AWS CodeDeploy to deploy the applications to one centralized application server.
- Pros: This option isolates the code for each application in separate repositories, which allows each team to work independently, and provides better modularity.
- Cons: Using a centralized application server still introduces potential bottlenecks and challenges in scaling the infrastructure. Deploying all applications to a single server increases maintenance complexity and can lead to issues if multiple applications are not compatible with the same environment. This does not fully reduce complexity in deployment.
- Conclusion: This approach offers better separation of concerns but still faces the same scalability and maintenance challenges due to the reliance on a centralized server.
C) Create one AWS CodeCommit repository for each of the applications. Use AWS CodeBuild to build the applications one at a ti...
Author: MysticJaguar44 · Last updated Jul 20, 2026
A company's application is currently deployed to a single AWS Region. Recently, the company opened a new office on a different continent. The users in the new office are experiencing high latency. The company's application runs on Amazon EC2 instances behind an Application Load Balancer (ALB) and uses Amazon DynamoDB as the database layer. The instances run in an EC2 Auto Scaling group across multiple Availability Zones. A DevOps engineer is tas...
Let's analyze each option to determine the best course of action to address the latency issues and improve availability:
A) Create a new DynamoDB table in the new Region with cross-Region replication enabled.
- Pros: This could potentially reduce latency by replicating data closer to the users in the new Region. Cross-Region replication would allow the application to access the data from a local DynamoDB table, minimizing the time it takes to retrieve data.
- Cons: Cross-Region replication could add some complexity in managing two separate DynamoDB tables. It's not as efficient or scalable as using a global DynamoDB table. It would also require more manual synchronization management, which could introduce issues in keeping data in sync between regions.
- Conclusion: This is not the optimal choice because managing two separate tables with cross-Region replication is more complex than using a global table.
B) Create new ALB and Auto Scaling group global resources and configure the new ALB to direct traffic to the new Auto Scaling group.
- Pros: This solution would help by scaling the application across multiple regions, ensuring better performance and availability. The ALB can distribute traffic effectively across the Auto Scaling group in the new region.
- Cons: AWS does not currently support the creation of global ALBs. ALBs are region-specific, and you would need to use Amazon Route 53 or other techniques to distribute traffic between regions. This option alone would not address the full latency issue, especially since you cannot directly create global ALBs.
- Conclusion: This option is rejected due to the current limitations of ALB not supporting global resources.
C) Create new ALB and Auto Scaling group resources in the new Region and configure the new ALB to direct traffic to the new Auto Scaling group.
- Pros: By creating an ALB and Auto Scaling group in the new Region, you can improve application performance for users in that region by handling their requests locally. It reduces latency for users by placing infrastructure closer to them.
- Cons: This option alone does not solve the latency problem for users in both regions. You would need to set up traffic routing (such as using Route 53) to intelligently route traffic to the appropriate region based on latency or health checks.
- Conclusion: This option is part of a broader solution, but it does not provide the complete answer on its own. It addresses ...
Author: Elijah · Last updated Jul 20, 2026
A DevOps engineer needs to apply a core set of security controls to an existing set of AWS accounts. The accounts are in an organization in AWS Organizations. Individual teams will administer individual accounts by using the AdministratorAccess AWS managed policy. For all accounts. AWS CloudTrail and AWS Config must be turned on in all available AWS Regions. Individual account administrators must not be able to edit or delete any of the baseline resources. However...
To determine the most operationally efficient solution for the given requirements, let's break down the problem and assess each option.
Key Requirements:
1. CloudTrail and AWS Config must be enabled across all available AWS regions.
2. Individual account administrators should not be able to edit or delete baseline resources, but should have the ability to manage their own CloudTrail trails and AWS Config rules.
3. Security: Use security controls to prevent unauthorized changes.
4. Operational Efficiency: The solution should minimize manual intervention and ensure compliance across all accounts with minimal overhead.
Option Analysis:
A) Create an AWS CloudFormation template that defines the standard account resources. Deploy the template to all accounts from the organization's management account by using CloudFormation StackSets. Set the stack policy to deny Update:Delete actions.
- Strengths: CloudFormation StackSets is a powerful tool for deploying resources across multiple accounts. Setting a stack policy to prevent the deletion of resources is effective.
- Weaknesses: This method would not provide the flexibility required for individual account administrators to modify their own CloudTrail trails and AWS Config rules. The stack policy would block them from modifying anything, including their own CloudTrail or AWS Config resources, which contradicts the requirement of allowing them to manage their own configurations.
- Conclusion: This option is not suitable because it is too restrictive for individual account administrators.
B) Enable AWS Control Tower. Enroll the existing accounts in AWS Control Tower. Grant the individual account administrators access to CloudTrail and AWS Config.
- Strengths: AWS Control Tower is designed to manage multi-account AWS environments with governance, security, and compliance controls. It can enforce best practices and provides a comprehensive management dashboard.
- Weaknesses: While AWS Control Tower simplifies management, it does not provide fine-grained control over individual account administrators' permissions for CloudTrail and AWS Config resources. It might also not meet the requirement of preventing deletions of baseline resources while allowing the administrators to manage their own configurations (e.g., CloudTrail trails or AWS Config rules).
- Conclusion: While Control Tower is a good tool for overall governance, it does not completely satisfy the specific requirements around fine-grained control of CloudTrail and AWS Config resources. Therefore, this is not the best solution.
C) ...
Author: SolarFalcon11 · Last updated Jul 20, 2026
A company has its AWS accounts in an organization in AWS Organizations. AWS Config is manually configured in each AWS account. The company needs to implement a solution to centrally configure AWS Config for all accounts in the organization The solution also must record resource changes to...
To meet the requirements of centrally configuring AWS Config and recording resource changes to a central account, the DevOps engineer needs to ensure that AWS Config is properly set up across all accounts in the AWS Organization. The solution should allow a central account to record and aggregate the data for all accounts.
Key Requirements:
1. Centrally configure AWS Config: The solution needs to apply AWS Config settings across all accounts in the organization.
2. Record resource changes to a central account: All changes across accounts need to be recorded centrally.
Option Analysis:
A) Configure a delegated administrator account for AWS Config. Enable trusted access for AWS Config in the organization.
- Strengths: A delegated administrator account allows the management of AWS Config across all accounts in the organization, and trusted access enables AWS Config to work across the AWS Organization. This is necessary to ensure that all accounts are centrally configured.
- Weaknesses: While this is essential for managing AWS Config at the organization level, it doesn't directly set up the aggregation of resource change data into a central account. This step is foundational but requires additional actions for data aggregation.
- Conclusion: This is a necessary step for enabling central management but doesn't fully meet the need for recording resource changes to a central account.
B) Configure a delegated administrator account for AWS Config. Create a service-linked role for AWS Config in the organization's management account.
- Strengths: A delegated administrator account can manage AWS Config in all accounts in the organization. Creating a service-linked role for AWS Config allows AWS Config to interact with other services across the organization. However, creating the role in the management account doesn't directly help in recording resource changes centrally or aggregating the data.
- Weaknesses: This setup lacks the central aggregation of resource change data from all accounts. It doesn't address the full requirement.
- Conclusion: This option is helpful for permissions but doesn't directly meet the requirement for central recording and aggregation of resource changes.
C) Create an AWS CloudFormation template to create an AWS Config aggregator. Configure a CloudFormation stack set to deploy the template to all accounts in the organization.
- Strengths: Using CloudFormation StackSets to deploy a Config aggregator across all accounts ensures that all accounts are consistently configured for AWS Config. However, an aggregator itself doesn't collect the data centrally unless it's specificall...
Author: IceDragon2023 · Last updated Jul 20, 2026
A company wants to migrate its content sharing web application hosted on Amazon EC2 to a serverless architecture. The company currently deploys changes to its application by creating a new Auto Scaling group of EC2 instances and a new Elastic Load Balancer, and then shifting the traffic away using an Amazon Route 53 weighted routing policy.
For its new serverless application, the company is planning to use Amazon API Gateway and AWS Lambda. The company will need to update its deployment processes to work with ...
To migrate the content-sharing web application to a serverless architecture while retaining the ability to test new features on a small number of users before rolling out changes to the entire user base, the company should select a deployment strategy that works with Amazon API Gateway and AWS Lambda. The strategy needs to support canary releases, gradual traffic shifts, and updates to API and Lambda functions.
Option Analysis:
A) Use AWS CDK to deploy API Gateway and Lambda functions. When code needs to be changed, update the AWS CloudFormation stack and deploy the new version of the APIs and Lambda functions. Use a Route 53 failover routing policy for the canary release strategy.
- Strengths: The AWS CDK is a modern tool that simplifies infrastructure management using code. It allows for deployment of API Gateway and Lambda, which fits the serverless architecture. A Route 53 failover routing policy can be used to direct a small percentage of traffic to new versions, enabling canary releases.
- Weaknesses: Route 53 failover routing typically directs traffic between two endpoints (e.g., primary and secondary), and while it can be used for canary releases, it is not as seamless or integrated for gradual traffic shifting compared to other services. Additionally, managing deployments through CloudFormation and the CDK might not provide the most efficient way to manage Lambda versions and promote canary releases specifically for Lambda functions.
- Conclusion: While valid, Route 53 failover routing may not be the most efficient and flexible tool for canary deployments, especially when compared to options specifically designed for that purpose.
B) Use AWS CloudFormation to deploy API Gateway and Lambda functions using Lambda function versions. When code needs to be changed, update the CloudFormation stack with the new Lambda code and update the API versions using a canary release strategy. Promote the new version when testing is complete.
- Strengths: This solution allows for deployment using Lambda function versions and CloudFormation, providing full control over the deployment process. Using a canary release strategy with API Gateway and Lambda versions allows gradual traffic shifting to test the new feature on a small subset of users before promoting it to production.
- Weaknesses: The deployment process through CloudFormation can be slower and more cumbersome compared to modern deployment strategies, especially when managing frequent updates to Lambda functions and API versions. However, the use of Lambda versions and a canary rel...
Author: Ethan Smith · Last updated Jul 20, 2026
A development team uses AWS CodeCommit, AWS CodePipeline, and AWS CodeBuild to develop and deploy an application. Changes to the code are submitted by pull requests. The development team reviews and merges the pull requests, and then the pipeline builds and tests the application.
Over time, the number of pull requests has increased. The pipeline is frequently blocked because of failing tests. To pr...
Problem Overview:
The development team is experiencing blockages in their CI/CD pipeline because of failing tests. To resolve this issue, they want to run unit and integration tests before merging pull requests to ensure that only passing code is merged, preventing pipeline blockages.
Key Requirements:
1. Run tests on pull requests before merging to ensure that only valid code is merged.
2. Avoid blocking the entire pipeline due to failing tests, ideally automating the process with minimal manual intervention.
Option Analysis:
A) Create a CodeBuild project to run the unit and integration tests. Create a CodeCommit approval rule template. Configure the template to require the successful invocation of the CodeBuild project. Attach the approval rule to the project's CodeCommit repository.
- Strengths: This option allows the use of a CodeCommit approval rule, which enforces a successful build as a precondition before merging pull requests. The CodeBuild project will run unit and integration tests, and only successful tests will allow the pull request to be merged.
- Weaknesses: While the approval rule ensures the pull request cannot be merged until tests pass, it doesn't run tests automatically when the pull request is created or updated. The team would still need to manually trigger builds after each update to the pull request, which could be cumbersome and doesn't fully meet the goal of preventing blockages before merging.
- Conclusion: This solution is close but doesn't fully automate the testing process for each pull request before merging, which may not be ideal for this use case.
B) Create an Amazon EventBridge rule to match pullRequestCreated events from CodeCommit. Create a CodeBuild project to run the unit and integration tests. Configure the CodeBuild project as a target of the EventBridge rule that includes a custom event payload with the CodeCommit repository and branch information from the event.
- Strengths: This option provides an automated mechanism where Amazon EventBridge listens for pullRequestCreated events in CodeCommit and triggers CodeBuild to run unit and integration tests. This approach directly addresses the need to test pull requests automatically before merging and ensures that failing tests do not cause a blockage in the pipeline.
- Weaknesses: This solution involves setting up an EventBridge rule and custom event payloads, which could require additional configuration. However, the automation makes it a powerful solution.
- Conclusion: This is a highly suitable option because it automates the te...
Author: Vikram · Last updated Jul 20, 2026
A company has an application that runs on a fleet of Amazon EC2 instances. The application requires frequent restarts. The application logs contain error messages when a restart is required. The application logs are published to a log group in Amazon CloudWatch Logs.
An Amazon CloudWatch alarm notifies an application engineer through an Amazon Simple Notification Service (Amazon SNS) topic when the logs contain a large number of restart-related error messages. The application engineer manually restarts the application on the instances after the application engineer receives a noti...
Problem Overview:
The application logs contain error messages when a restart is required. Currently, an application engineer receives notifications via an Amazon SNS topic when the logs show a large number of error messages and manually restarts the application. The goal is to automate the application restart process without restarting the EC2 instances, making the solution more operationally efficient.
Key Requirements:
1. Automate application restarts without requiring manual intervention.
2. Respond to log errors automatically when the application logs indicate a restart is needed.
3. Ensure the solution is operationally efficient and does not involve restarting the EC2 instances.
Option Analysis:
A) Configure an AWS Systems Manager Automation runbook that runs a script to restart the application on the instances. Configure the SNS topic to invoke the runbook.
- Strengths: AWS Systems Manager Automation is designed for automating tasks on EC2 instances. You can create a runbook to execute scripts that restart the application. Configuring the SNS topic to invoke the runbook allows automatic execution based on the alarm triggered by the logs.
- Weaknesses: The SNS topic cannot directly trigger a Systems Manager Automation runbook. Therefore, this solution requires an additional step or intermediary to invoke the runbook.
- Conclusion: This option is not ideal because SNS topics cannot directly invoke Systems Manager Automation runbooks without an intermediary like a Lambda function or EventBridge.
B) Create an AWS Lambda function that restarts the application on the instances. Configure the Lambda function as an event destination of the SNS topic.
- Strengths: AWS Lambda can be used to run a script that restarts the application. The SNS topic can be configured to trigger the Lambda function, which will execute automatically when the alarm is triggered.
- Weaknesses: Lambda has limited access to EC2 instances directly, and it requires specific permissions to interact with the instances (e.g., using EC2 RunCommand). While Lambda could work, it is not as efficient or straightforward as using Systems Manager for managing EC2 instance operations.
- Conclusion: This solution is possible but not optimal, as it introduces additional complexity when S...
Author: Aria · Last updated Jul 20, 2026
A DevOps engineer at a company is supporting an AWS environment in which all users use AWS IAM Identity Center (AWS Single Sign-On). The company wants to immediately disable credentials of any new IAM user and wants the security team to receive a notific...
To meet the requirements of disabling the credentials of any new IAM user and notifying the security team, let's break down each step and reason through the options:
Option A: Create an Amazon EventBridge rule that reacts to an IAM CreateUser API call in AWS CloudTrail.
- This option is appropriate because the "CreateUser" event in CloudTrail will trigger whenever a new IAM user is created. The EventBridge rule can listen to this event, enabling the automatic response for disabling credentials and notifying the security team.
- Selected: This is necessary as it allows the event of creating a new user to be caught, which is the first step in the process.
Option B: Create an Amazon EventBridge rule that reacts to an IAM GetLoginProfile API call in AWS CloudTrail.
- This option is not ideal because the "GetLoginProfile" event occurs when there’s a request to view the login profile of a user. This is generally not when a new user is created, but more about interacting with a user's login profile after they’ve been created. Hence, it wouldn't effectively trigger on new user creation.
- Rejected: It is not suitable for reacting to user creation, only login profile access.
Option C: Create an AWS Lambda function that is a target of the EventBridge rule. Configure the Lambda function to disable any access keys and delete the login profiles that are associated with the IAM user.
- This option is ideal. The Lambda function would be triggered by the EventBridge rule (from Option A), and the function can disable the access keys and delete the login profiles associated with the newly created IAM user.
- Selected: This fulfills the requirement to immediately disable credentials and remove access for new users.
Option D: Create an AWS ...
Author: Victoria · Last updated Jul 20, 2026
A company wants to set up a continuous delivery pipeline. The company stores application code in a private GitHub repository. The company needs to deploy the application components to Amazon Elastic Container Service (Amazon ECS). Amazon EC2, and A...
To meet the company's requirements of setting up a continuous delivery pipeline for deployment to Amazon ECS, EC2, and AWS Lambda, with manual approval actions included, let's analyze each option:
Option A: Use AWS CodePipeline with Amazon ECS, Amazon EC2, and Lambda as deploy providers.
- Selected: This is the ideal option because AWS CodePipeline is a fully managed continuous delivery service that integrates well with GitHub (for source control) and supports ECS, EC2, and Lambda as deployment targets. Additionally, CodePipeline supports manual approval actions, which is a key requirement.
- Why selected: It aligns directly with the company's needs to deploy to multiple services (ECS, EC2, Lambda) and includes manual approval in the pipeline, offering full control over the deployment process.
Option B: Use AWS CodePipeline with AWS CodeDeploy as the deploy provider.
- Rejected: AWS CodeDeploy can deploy applications to EC2 instances and Lambda, but it does not have direct support for ECS, which is a critical requirement. While CodeDeploy supports manual approval, it lacks the broad deployment support across ECS, EC2, and Lambda that the company needs.
- Why rejected: This option does not cover ECS deployment, making it incomplete for the company’s needs.
Option C: Use AWS CodePi...
Author: Vikram · Last updated Jul 20, 2026
A company has an application that runs on Amazon EC2 instances that are in an Auto Scaling group. When the application starts up. the application needs to process data from an Amazon S3 bucket before the application can start to serve requests.
The size of the data that is stored in the S3 bucket is growing. When the Auto Scaling group adds new instances, the application now takes several minutes to download and process the data before the application can ser...
To address the issue of long startup times for new EC2 instances in an Auto Scaling group, the goal is to reduce the time it takes for instances to be ready to serve requests. The data processing from the S3 bucket is a bottleneck, so the solution should aim to address this issue while being cost-effective.
Let’s go through the options:
Option A: Configure a warm pool for the Auto Scaling group with warmed EC2 instances in the Stopped state. Configure an `autoscaling:EC2_INSTANCE_LAUNCHING` lifecycle hook on the Auto Scaling group. Modify the application to complete the lifecycle hook when the application is ready to serve requests.
- Rejected: This option uses a warm pool, but the instances are in the "Stopped" state. When an instance is stopped, it must be started before it can be used, and the application still has to process the data from S3 on startup. This does not reduce the time required for data processing and could add additional time when the instance is transitioned from stopped to running.
- Why rejected: The stopped state does not address the S3 data processing delay, and starting instances from stopped will still take time.
Option B: Increase the maximum instance count of the Auto Scaling group. Configure an `autoscaling:EC2_INSTANCE_LAUNCHING` lifecycle hook on the Auto Scaling group. Modify the application to complete the lifecycle hook when the application is ready to serve requests.
- Rejected: Increasing the maximum instance count could help by allowing more instances, but it doesn’t directly address the issue of the application’s startup time for processing data from S3. The lifecycle hook does ensure the application only proceeds once it’s ready, but the data processing from S3 still takes time and does not reduce the startup delay.
- Why rejected: While it may help with scale, it does not tackle the root cause of the delay (data processing).
Option C: Configure a warm pool for the Auto Scaling group with warmed EC2 instances in the Running state. Configure an `autoscaling:EC2_INSTANCE_...
Author: Ahmed · Last updated Jul 20, 2026
A company is using an AWS CodeBuild project to build and package an application. The packages are copied to a shared Amazon S3 bucket before being deployed across multiple AWS accounts.
The buildspec.yml file contains the following:
The DevOps engineer has noticed that a...
To prevent unauthorized users from accessing the artifacts in the shared Amazon S3 bucket, we need to ensure that only the relevant AWS accounts can access the content. Let’s evaluate the options:
Option A: Modify the post_build command to use `--acl public-read` and configure a bucket policy that grants read access to the relevant AWS accounts only.
- Rejected: The `--acl public-read` option makes the objects publicly readable, which defeats the purpose of restricting access. Even if you configure a bucket policy afterward to restrict access to specific accounts, the `--acl public-read` setting has already made the objects publicly accessible to anyone.
- Why rejected: The `--acl public-read` in the post_build command creates a security vulnerability by making the objects publicly accessible.
Option B: Configure a default ACL for the S3 bucket that defines the set of authenticated users as the relevant AWS accounts only and grants read-only access.
- Rejected: While a default ACL could be configured, AWS S3's ACL model is somewhat outdated compared to using IAM policies or bucket policies. Configuring default ACLs based on AWS accounts is not the most scalable or flexible way to manage access control, especially when you want to manage permissions more granularly.
- Why rejected: Default ACLs are less precise and harder to maintain for complex access requirements across multiple accounts.
Option C: Create an S3 bucket policy that grants read access to the relevant AWS accounts and denies read access to the principal ``.
- Selected: This option is the most appropriate. By creating an S3 bucket policy that grants read access to only specific AWS accounts and explicitly denies access to all other u...
Author: FrostFalcon88 · Last updated Jul 20, 2026
A company has developed a serverless web application that is hosted on AWS. The application consists of Amazon S3. Amazon API Gateway, several AWS Lambda functions, and an Amazon RDS for MySQL database. The company is using AWS CodeCommit to store the source code. The source code is a combination of AWS Serverless Application Model (AWS SAM) templates and Python code.
A security audit and penetration test reveal that user names and passwords for authentication to the database a...
Let's evaluate each of the options based on the requirements and key factors like automation, management overhead, and scalability:
Key Requirements:
- Update the Linux AMIs with new patches periodically.
- Install a new version of Chef agents in the golden image.
- Provide the newly generated AMIs to the department's accounts.
- LEAST management overhead.
---
Option A: Write a script to launch an Amazon EC2 instance from the previous golden image, apply the patch updates, install the new version of the Chef agent, generate a new golden image, and modify the AMI permissions to share only the new image with the department's accounts
- Explanation: This solution requires custom scripting and manual processes to manage the updates and AMI sharing. The script will need to handle launching instances, applying patches, updating the Chef agent, and modifying AMI permissions.
- Reason for rejection: While this method is feasible, it is more manual and error-prone. The process of scripting the updates and handling the AMI sharing across accounts would involve ongoing maintenance and higher management overhead. This solution doesn't fully automate the workflow and is less scalable for larger environments.
---
Option B: Use Amazon EC2 Image Builder to create an image pipeline that consists of the base Linux AMI and components to install the Chef agent. Use AWS Resource Access Manager to share EC2 Image Builder images with the department's accounts
- Explanation: Amazon EC2 Image Builder automates the creation of golden images by integrating patching, software installation (like Chef agents), and configuration management in a streamlined pipeline. You can use AWS Resource Access Manager to share the built images with other AWS accounts, simplifying the distribution process.
- Reason for selection: EC2 Image Builder is designed for this exact purpose—automating the process of building, patching, and distributing AMIs. This solution minimizes manual work, allows you to integrate patch management and Chef agent installation, and includes easy sharing across accounts with minimal overhead.
---
Option C: Use an AWS S...
Author: Ravi Patel · Last updated Jul 20, 2026
A company is using Amazon S3 buckets to store important documents. The company discovers that some S3 buckets are not encrypted. Currently, the company's IAM users can create new S3 buckets without encryption. The company is implementing a new requirement that all S3 buckets must be encrypted.
A DevOps engineer must implement a solution to ensure that server-side encryption is enabled on all existing S3 buckets and all new S3 buckets. The encryption must ...
Analysis of Options:
A) Create an AWS Lambda function that is invoked periodically by an Amazon EventBridge scheduled rule. Program the Lambda function to scan all current S3 buckets for encryption status and to set AES-256 as the default encryption for any S3 bucket that does not have an encryption configuration.
- Pros:
- The Lambda function can scan existing S3 buckets periodically to check for encryption and set the default encryption to AES-256 where needed.
- Cons:
- It requires a periodic schedule, which is less efficient compared to a real-time solution.
- You will need to manage the scheduling of this Lambda function and its scalability when scanning large numbers of buckets.
- It does not guarantee that encryption will be set immediately when new buckets are created, which is part of the requirement.
- Use case: This option would work well for periodic checks but doesn't address the requirement for immediate encryption of new buckets and could lead to delays.
B) Set up and activate the s3-bucket-server-side-encryption-enabled AWS Config managed rule. Configure the rule to use the AWS-EnableS3BucketEncryption AWS Systems Manager Automation runbook as the remediation action. Manually run the re-evaluation process to ensure that existing S3 buckets are compliant.
- Pros:
- AWS Config provides real-time monitoring of S3 bucket encryption status.
- It automatically triggers remediation actions when a bucket is found to be non-compliant, and the AWS Systems Manager Automation runbook can apply the necessary encryption settings.
- Cons:
- For existing buckets, this requires manual re-evaluation, which could delay enforcement. Though automatic for new buckets, it lacks instant enforcement for all scenarios.
- The AWS Config rule is limited to monitoring and enforcement of encryption but lacks proactive configuration for all new buckets.
- Use case: Ideal for monitoring and remediation, but the manual process for existing buckets introduces delay, and it's not as proactive as other options.
C) Create an AWS Lambda function that is invoked by an Amazon EventBridge event rule. Define the rule with an event pattern that matches the creation of new S3 buckets. Program the Lambda function to parse the ...
Author: Nathan · Last updated Jul 20, 2026
A DevOps engineer is architecting a continuous development strategy for a company's software as a service (SaaS) web application running on AWS. For application and security reasons, users subscribing to this application are distributed across multiple Application Load Balancers (ALBs), each of which has a dedicated Auto Scaling group and fleet of Amazon EC2 instances. The application does not require a build stage, and when it is committed to AWS CodeCommi...
Analysis of Options:
A) Create a single AWS CodePipeline pipeline that deploys the application in parallel using unique AWS CodeDeploy applications and deployment groups created for each ALB-Auto Scaling group pair.
- Pros:
- Allows for separate deployments for each ALB-Auto Scaling group pair, providing isolation and control for each fleet.
- Deployments are managed in parallel, which fits the requirement to simultaneously deploy to all ALBs and Auto Scaling groups.
- Cons:
- Requires creating unique CodeDeploy applications and deployment groups for each ALB-Auto Scaling pair, which increases configuration complexity.
- While this approach allows for granular control, it involves more setup and management overhead in comparison to using fewer resources.
- Use case: This would be useful if the application had different deployment configurations or needed to be deployed distinctly for each ALB-Auto Scaling pair. However, it is more complex than necessary for the given requirements.
B) Create a single AWS CodePipeline pipeline that deploys the application using a single AWS CodeDeploy application and single deployment group.
- Pros:
- Simple to configure since there is only one CodeDeploy application and deployment group.
- Easy to manage and maintain.
- Cons:
- A single deployment group would target all ALBs and Auto Scaling groups at once, which could result in conflicts or issues with simultaneous deployments across different fleets.
- Does not provide the necessary parallelism or isolation between different ALB-Auto Scaling groups, making this solution less flexible for managing multiple independent fleets.
- Use case: This could be a valid choice for small deployments with a uniform architecture but fails to meet the requirement of handling separate fleets for different ALBs in parallel.
C) Create a single AWS CodePipeline pipeline that deploys the application in parallel using a single AWS CodeDeploy application and unique deployment group for each ALB-Auto Scaling group pair.
- Pros:...
Author: Charlotte · Last updated Jul 20, 2026
A company is hosting a static website from an Amazon S3 bucket. The website is available to customers at example.com. The company uses an Amazon Route 53 weighted routing policy with a TTL of 1 day. The company has decided to replace the existing static website with a dynamic web application. The dynamic web application uses an Application Load Balancer (ALB) in front of a fleet of Amazon EC2 instances.
On the day of production launch to customers, the company creates an additional Route 53 weighted DNS record entry that points to the ALB with a weight of 255 and a TTL...
Analysis of Options:
A) Delete all objects, including previous versions, from the S3 bucket that contains the static website content.
- Pros:
- Removes the static website content from the S3 bucket completely, ensuring that no static content is served from the S3 bucket.
- Cons:
- While this removes the files from S3, it does not address the DNS routing issues caused by the weighted Route 53 records. The DNS record could still be pointing to the S3 bucket, allowing requests to go there and deliver static content.
- Does not help in the situation where DNS propagation and routing are still allowing access to the old content.
- Use case: This might be useful in cases where you want to completely eliminate the static website content, but it doesn't address the DNS or routing configuration issue.
B) Update the weighted DNS record entry that points to the S3 bucket. Apply a weight of 0. Specify the domain reset option to propagate changes immediately.
- Pros:
- Setting the weight of the Route 53 record for the S3 bucket to 0 effectively removes the static website from being a valid endpoint for requests to `example.com`.
- The TTL of 1 hour will ensure that this change propagates quickly, in line with the new routing policy for the dynamic web application.
- Cons:
- The "domain reset" option is not a valid concept in Route 53. Therefore, this option is not applicable.
- Use case: This would normally work, but the "domain reset" option mentioned here is not a correct approach.
C) Configure webpage redirect requests on the S3 bucket with a hostname that redirects to the ALB.
- Pros:
- This would redirect all requests from the old static S3 website to the new dynamic application via the ALB. This ensures that any requests to the old website URL get redirected to the new web application.
- Helps ensure that users are redirected to the correct cont...
Author: Sofia · Last updated Jul 20, 2026
A company is implementing AWS CodePipeline to automate its testing process. The company wants to be notified when the execution state fails and used the following custom event pattern i...
Event Pattern Analysis:
In AWS CodePipeline, EventBridge can be used to capture various pipeline events and trigger notifications based on specific patterns. The custom event pattern mentioned here is intended to match events when the execution state of a pipeline fails. Let's analyze each option and see which type of events it will match:
A) Failed deploy and build actions across all the pipelines
- Pros:
- This option would match events specifically when deploy or build actions fail within the pipelines.
- It is a more specific event pattern focusing on particular actions (deploy and build) that fail in the pipeline.
- Cons:
- This is not as broad as the event pattern might intend. If the failure is in a different type of action (for example, test actions or other steps), this pattern would not capture those.
- This option does not cover the entire pipeline execution state, focusing only on specific action types (deploy and build).
- Use case: This would be used if the company only wants to capture failures related to deployment or build actions but not necessarily the entire pipeline execution state or failures outside these actions.
B) All rejected or failed approval actions across all the pipelines
- Pros:
- This would match events where approval actions fail or are rejected across all pipelines.
- Cons:
- Approval actions are typically part of manual intervention processes and may not reflect the overall pipeline execution state. If other actions fail (build, deploy, etc.), they would not be captured by this pattern.
- This is focused only on approval actions, which may not cover all potential failure states in the pipeline.
- Use case: This would be useful if the company is specifically interested in failures or rejections during manual approval steps, but it would ...
Author: Elizabeth · Last updated Jul 20, 2026
An application running on a set of Amazon EC2 instances in an Auto Scaling group requires a configuration file to operate. The instances are created and maintained with AWS CloudFormation. A DevOps engineer wants the instances to have the latest configuration file when launched, and wants changes to the configuration file to be reflected on all the instances with a minimal delay when the CloudFormation template is updated. ...
Analysis of Options:
A) In the CloudFormation template, add an AWS Config rule. Place the configuration file content in the rules InputParameters property, and set the Scope property to the EC2 Auto Scaling group. Add an AWS Systems Manager Resource Data Sync resource to the template to poll for updates to the configuration.
- Pros:
- AWS Config rules help monitor compliance, but they are not directly intended to handle the real-time deployment or synchronization of configuration files for EC2 instances.
- AWS Systems Manager Resource Data Sync is primarily used for aggregating resource data, which is not directly aligned with the goal of applying a configuration file to instances.
- Cons:
- This solution does not efficiently solve the problem of applying a configuration file to EC2 instances. It focuses more on compliance rather than configuration management or update synchronization.
- The use of AWS Config in this context is not ideal, as it is designed for compliance monitoring, not for distributing configuration files.
- Use case: While this could be used for other purposes, it doesn't address the immediate need to maintain and update configuration files on EC2 instances.
B) In the CloudFormation template, add an EC2 launch template resource. Place the configuration file content in the launch template. Configure the cfn-init script to run when the instance is launched, and configure the cfn-hup script to poll for updates to the configuration.
- Pros:
- EC2 launch templates are an appropriate resource for defining how EC2 instances are launched, and they provide flexibility in configuration.
- cfn-init is a great tool for running initialization tasks when EC2 instances are launched, and cfn-hup can be configured to detect updates to the configuration and apply them without requiring a full instance restart.
- This solution ensures the configuration file is applied to new instances when they are launched and allows for polling of updates to reflect changes.
- Cons:
- The configuration file would need to be included in the launch template, and while `cfn-init` is suitable for initialization tasks, there may be a better solution for managing the configuration file outside the template.
- Use case: This is a good approach for managing configuration files at launch, but it might not scale well if updates to the configuration need to be managed separately from the CloudFormation template.
C) In the CloudFormation template, add an EC2 launch template resource. Place ...
Author: Amira · Last updated Jul 20, 2026
A company manages an application that stores logs in Amazon CloudWatch Logs. The company wants to archive the logs to an Amazon S3 bucket. Logs are rarely accessed after 90 days and must be retained for 10 years.
Whi...
Let’s go through the options and analyze the requirements, reasoning, and how each can be used.
Understanding the Requirements:
1. Logs are rarely accessed after 90 days: This indicates a need for low-cost storage for logs that are infrequently accessed after 90 days.
2. Logs must be retained for 10 years: This indicates a need for long-term retention of logs, so the solution must ensure logs are preserved for 10 years (3650 days).
3. Archival: This typically means transferring logs from an active storage solution (CloudWatch Logs) to Amazon S3 for long-term storage.
---
Option Analysis:
A) Configure a CloudWatch Logs subscription filter to use AWS Glue to transfer all logs to an S3 bucket.
- Explanation: AWS Glue is a managed ETL service that helps in extracting, transforming, and loading data. While it could theoretically help with moving logs to an S3 bucket, it’s not designed specifically for log archival. It involves additional complexity because you would need to configure a proper ETL job, which is overkill for simple log archiving.
- Rejected: AWS Glue is generally used for data transformation and preparation, not ideal for simple log transfer from CloudWatch to S3.
B) Configure a CloudWatch Logs subscription filter to use Amazon Kinesis Data Firehose to stream all logs to an S3 bucket.
- Explanation: Kinesis Data Firehose is a fully managed service for real-time data streaming to various destinations, including S3. This option is valid for streaming logs from CloudWatch Logs to an S3 bucket. It allows for real-time transfer and can handle log data efficiently. However, it’s designed for real-time streaming rather than long-term storage or archival, which could add unnecessary complexity and cost for simply storing logs.
- Rejected: Though viable, it introduces real-time streaming overhead, which is unnecessary for simple archival after 90 days.
C) Configure a CloudWatch...
Author: Amira · Last updated Jul 20, 2026
A company is developing a new application. The application uses AWS Lambda functions for its compute tier. The company must use a canary deployment for any changes to the Lambda functions. Automated rollback must occur if any failures are reported.
The company's DevOps team needs to create the infrastructu...
Let's break down each option, understanding the key requirements, and then select the ones that best meet the needs of the scenario.
Key Requirements:
1. Canary Deployment for Lambda Functions: We need a deployment strategy that gradually shifts traffic to the new version, typically using a canary deployment.
2. Automated Rollback on Failure: If the new version of the function encounters failures, the deployment should automatically rollback.
3. Infrastructure as Code (IaC): This implies using AWS CloudFormation or AWS Serverless Application Model (AWS SAM) to define the infrastructure.
4. CI/CD Pipeline: A pipeline should automate the deployment of the Lambda functions, ensuring the changes are tested and pushed in a controlled way.
---
Option Analysis:
A) Create an AWS CloudFormation template for the application. Define each Lambda function in the template by using the AWS::Lambda::Function resource type. In the template, include a version for the Lambda function by using the AWS::Lambda::Version resource type. Declare the CodeSha256 property. Configure an AWS::Lambda::Alias resource that references the latest version of the Lambda function.
- Explanation: This option involves defining the Lambda functions and their versions within a CloudFormation template. The `AWS::Lambda::Alias` resource is useful for managing different versions of Lambda functions, and it can be used in combination with the `AWS::Lambda::Version` resource. However, this does not directly address the canary deployment or automated rollback. CloudFormation alone can set up the Lambda infrastructure, but additional configuration is required to handle canary deployment and rollback.
- Rejected: This option is useful for defining Lambda functions and versions but does not specifically implement canary deployments or automated rollback.
B) Create an AWS Serverless Application Model (AWS SAM) template for the application. Define each Lambda function in the template by using the AWS::Serverless::Function resource type. For each function, include configurations for the AutoPublishAlias property and the DeploymentPreference property. Configure the deployment configuration type to LambdaCanary10Percent10Minutes.
- Explanation: AWS SAM simplifies deploying serverless applications by offering a higher-level abstraction. The `AutoPublishAlias` and `DeploymentPreference` properties enable canary deployments directly within SAM, which is exactly what the company needs for canary deployment. The `LambdaCanary10Percent10Minutes` setting ensures 10% of the traffic is routed to the new version for 10 minutes before fully deploying it, which also allows for automated rollback if errors occur.
- Selected: This option directly addresses the canary deployment and automated rollback requirements, using SAM to simplify deployment.
C) Create an AWS CodeCommit repository. Create an AWS CodePipeline pipeline. Use the CodeCommit repository in a new source stage that starts the pipeline. Create an AWS CodeBuild project to deploy the AWS Serverless Application Model (AWS SAM) template. Upload the template and source code to the CodeCommit repository. In the CodeCommit repository, create a buildspec.yml file that includes the commands to build and deploy the SAM application.
- Explanation: This option sets up a CI/CD pipeline using AWS CodeCommit, CodePipeline, and CodeBuild. It allows the automatic deployment of the SAM template after ...
Author: Ella · Last updated Jul 20, 2026
A DevOps engineer is deploying a new version of a company's application in an AWS CodeDeploy deployment group associated with its Amazon EC2 instances. After some time, the deployment fails. The engineer realizes that all the events associated with the specific deployment ID are in a Skipped status, and co...
Let's analyze the possible reasons why the CodeDeploy deployment failed, focusing on the key requirements and constraints for successful deployment.
Key Points for Deployment Success:
1. Deployment must reach EC2 instances: The EC2 instances need to be properly registered and configured to communicate with CodeDeploy.
2. Permissions and configuration: The deployment needs appropriate permissions and profiles to interact with the EC2 instances and AWS services.
3. Correct application files: The deployment package should contain necessary files like `appspec.yml` that guide the deployment process.
---
Option Analysis:
A) The networking configuration does not allow the EC2 instances to reach the internet via a NAT gateway or internet gateway, and the CodeDeploy endpoint cannot be reached.
- Explanation: For CodeDeploy to function, the EC2 instances must be able to communicate with the CodeDeploy service. If the networking configuration prevents the EC2 instances from reaching the CodeDeploy endpoint (e.g., due to missing or misconfigured NAT gateway or internet gateway), then the deployment cannot proceed. This would result in events being marked as "Skipped" because the deployment could not be initiated or completed.
- Selected: This is a valid reason because the EC2 instances must be able to reach the CodeDeploy service over the network to perform the deployment.
B) The IAM user who triggered the application deployment does not have permission to interact with the CodeDeploy endpoint.
- Explanation: While the IAM permissions of the user who triggered the deployment are important, this issue would prevent the deployment from being triggered in the first place. If the IAM user did not have the proper permissions to initiate a deployment, it would have failed earlier in the process, not during the execution phase.
- Rejected: This is not the reason for the failure because it would have blocked the deployment initiation rather than causing the "Skipped" status of the deployment.
C) The target EC2 instances were not properly registered with the CodeDeploy endpoint.
- Explanation: If the EC2 instances a...
