Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company has a guideline that every Amazon EC2 instance must be launched from an AMI that the company's security team produces. Every month, the security team sends an email message with the latest approved AMIs to all the development teams.
The development teams use AWS CloudFormation to deploy their applications. When developers launch a new service, they have to search their email for the latest AMIs that the security department sent. A...
Let’s break down the options to determine which is the most scalable and automated solution for ensuring development teams can always access the latest approved AMI IDs, without having to manually search emails.
Key Requirements:
1. Automation: The process must be automated so that developers don’t have to manually search emails or other sources for the latest AMI IDs.
2. Scalability: The solution should scale as the number of instances or developers increases.
3. Security: The AMI information should be stored in a secure and accessible way.
4. Integration with CloudFormation: Since the development teams use CloudFormation, the solution should allow the AMI IDs to be easily integrated into their CloudFormation templates.
---
Option Analysis:
A) Direct the security team to use CloudFormation to create new versions of the AMIs and to list the AMI ARNs in an encrypted Amazon S3 object as part of the stack's Outputs section. Instruct the developers to use a cross-stack reference to load the encrypted S3 object and obtain the most recent AMI ARNs.
- Explanation: CloudFormation could be used to store and output AMI ARNs in S3. Developers could reference the S3 object using cross-stack references. However, this method introduces complexity as it requires manual updates and sharing of CloudFormation stacks. Additionally, using S3 as the storage medium could lead to issues with encryption management, permissions, and retrieval complexity.
- Rejected: While CloudFormation can output values to S3, the extra management of encrypted S3 objects and cross-stack references makes this less automated and scalable than other solutions.
B) Direct the security team to use a CloudFormation stack to create an AWS CodePipeline pipeline that builds new AMIs and places the latest AMI ARNs in an encrypted Amazon S3 object as part of the pipeline output. Instruct the developers to use a cross-stack reference within their own CloudFormation template to obtain the S3 object location and the most recent AMI ARNs.
- Explanation: This option uses CodePipeline, which is designed for automating CI/CD pipelines, to build new AMIs. It stores the AMI ARNs in S3 as an output. However, this still involves the complexity of managing S3 objects, cross-stack references, and encryption, along with the need to set up a pipeline for AMI creation.
- Rejected: While automating AMI creation through CodePipeline is beneficial, the reliance on S3 and cross-stack references makes this solution less direct and scalable than alternatives, especially in term...
Author: William · Last updated May 17, 2026
An application runs on Amazon EC2 instances behind an Application Load Balancer (ALB). A DevOps engineer is using AWS CodeDeploy to release a new version. The deployment fails during the AllowTraffic lifecycle event, ...
Let's analyze each of the options to determine what could cause the failure during the AllowTraffic lifecycle event of a deployment using AWS CodeDeploy.
Key Points:
- AllowTraffic is the lifecycle event where CodeDeploy attempts to route traffic to the updated EC2 instances behind the ALB.
- The failure during this step usually means that CodeDeploy is unable to send traffic to the newly deployed EC2 instances, often due to issues with the health checks, permissions, or configuration of the instances and ALB.
---
Option Analysis:
A) The appspec.yml file contains an invalid script that runs in the AllowTraffic lifecycle hook.
- Explanation: The `appspec.yml` file defines the lifecycle hooks for the deployment process, but AllowTraffic is typically not associated with running custom scripts. Instead, this event mainly involves making the newly updated instances accept traffic (via the ALB). If there was an invalid script in a different lifecycle event (like `BeforeAllowTraffic`), it could cause issues, but it’s unlikely to be the direct cause of failure during AllowTraffic itself.
- Rejected: Invalid scripts in `appspec.yml` would affect earlier lifecycle events (e.g., `BeforeInstall`), not the AllowTraffic event itself.
B) The user who initiated the deployment does not have the necessary permissions to interact with the ALB.
- Explanation: CodeDeploy needs the proper permissions to update the ALB and direct traffic to the EC2 instances. If the IAM user or role initiating the deployment does not have sufficient permissions to interact with the ALB, it could lead to failures when trying to shift traffic to the newly updated instances during the AllowTraffic lifecycle event. However, this issue would typically show up in the logs with permission-related error messages, and this question specifies that no cause was indicated.
- Rejected: While lacking permissions could cause issue...
Author: Kai · Last updated May 17, 2026
A company has 20 service teams. Each service team is responsible for its own microservice. Each service team uses a separate AWS account for its microservice and a VPC with the 192.168.0.0/22 CIDR block. The company manages the AWS accounts with AWS Organizations.
Each service team hosts its microservice on multiple Amazon EC2 instances behind an Application Load Balancer. The microservices communicate with each other across the public internet. The company's security team has issued a new guideline that all communication between microservices must use HTTPS over priva...
The company wants to implement secure communication between microservices over private network connections, with HTTPS as the communication protocol, while minimizing the number of changes for each service team. Let's evaluate each of the proposed solutions:
Option A: Create a new AWS account in AWS Organizations. Create a VPC in this account, and use AWS Resource Access Manager to share the private subnets of this VPC with the organization. Instruct the service teams to launch a new Network Load Balancer (NLB) and EC2 instances that use the shared private subnets. Use the NLB DNS names for communication between microservices.
- This solution would require a complete redesign of the infrastructure since each service team would need to launch new EC2 instances and NLBs in a new shared VPC. This would involve a significant amount of changes for each service team, which contradicts the goal of minimizing changes.
- Moreover, this solution requires using AWS Resource Access Manager and managing a new centralized VPC, which adds more complexity and operational overhead.
- Rejected due to the large scope of changes and additional overhead for service teams.
Option B: Create a Network Load Balancer (NLB) in each of the microservice VPCs. Use AWS PrivateLink to create VPC endpoints in each AWS account for the NLBs. Create subscriptions to each VPC endpoint in each of the other AWS accounts. Use the VPC endpoint DNS names for communication between microservices.
- AWS PrivateLink is a suitable solution for secure, private communication between VPCs. It allows communication over private network connections without exposing services to the public internet. Each service team can continue using their own VPC and NLB.
- Creating VPC endpoints for each NLB and using PrivateLink ensures that the communication is private, secure, and over HTTPS as required.
- The service teams do not need to make major changes to their existing infrastructure beyond configuring PrivateLink, which keeps the impact minimal.
- Selected due to its simplicity, minimal changes, and effective use of PrivateLink to meet the security and communication r...
Author: Lucas · Last updated May 17, 2026
An Amazon EC2 instance is running in a VPC and needs to download an object from a restricted Amazon S3 bucket. When the DevOps engineer tries to download the object, an AccessDenied e...
When an EC2 instance attempts to download an object from a restricted Amazon S3 bucket and encounters an "AccessDenied" error, there are a few potential causes to consider. Let's evaluate the provided options:
Option A: The S3 bucket default encryption is enabled.
- Explanation: S3 bucket default encryption ensures that all objects stored in the bucket are automatically encrypted, but this should not directly result in an "AccessDenied" error unless there are additional access control issues (e.g., IAM permissions that do not allow decrypting the objects).
- Rejection: Default encryption alone does not prevent access; it only requires encryption for new objects. If the EC2 instance has the necessary permissions, it can still access the encrypted objects by using the appropriate permissions to decrypt them. Thus, this is not a valid cause of the AccessDenied error.
Option B: There is an error in the S3 bucket policy.
- Explanation: S3 bucket policies control access to objects based on various conditions, such as IAM roles, source IP addresses, and other criteria. If the bucket policy does not grant the appropriate permissions to the EC2 instance (or the IAM role associated with it), an "AccessDenied" error will occur when attempting to access the object.
- Selection Reasoning: This is a common cause for the AccessDenied error. If the bucket policy explicitly denies access, or if the permissions granted are insufficient, the EC2 instance will be unable to access the object.
- Valid Scenario: A misconfigured bucket policy can prevent access to the S3 object, especially if there are restrictions on IAM roles or other criteria.
Option C: The object has been moved to S3 Glacier.
- Explanation: If the object has been moved to S3 Glacier (an archival storage class), it is still stored in the S3 bucket but requires a restoration process before it can be accessed.
- Rejection: While it's true that accessing objects in S3 Glacier requires restoration, an "Acce...
Author: Sara · Last updated May 17, 2026
A company wants to use a grid system for a proprietary enterprise in-memory data store on top of AWS. This system can run in multiple server nodes in any Linux-based distribution. The system must be able to reconfigure the entire cluster every time a node is added or removed. When adding or removing nodes, an /etc/cluster/nodes.config file must be updated, listing the IP addresses of the curr...
To meet the requirements of dynamically managing a cluster where the `/etc/cluster/nodes.config` file is updated each time a node is added or removed, the solution must ensure that the file always reflects the current nodes in the cluster without manual intervention. Let's evaluate the provided options:
Option A: Use AWS OpsWorks Stacks to layer the server nodes of that cluster. Create a Chef recipe that populates the content of the /etc/cluster/nodes.config file and restarts the service by using the current members of the layer. Assign that recipe to the Configure lifecycle event.
- Explanation: AWS OpsWorks Stacks is a configuration management service that integrates with Chef (or Puppet) to automate the deployment of infrastructure. In this case, a Chef recipe could be used to dynamically populate the `/etc/cluster/nodes.config` file based on the current set of nodes in the layer. After updating the file, the recipe could restart the service.
- Selection Reasoning: This approach aligns well with the requirements. Using OpsWorks, you can automate the configuration and reconfiguration of the nodes in the cluster, and the Chef recipe will manage the configuration file and restart services dynamically. It integrates well with the DevOps workflow and ensures that the configuration is updated on node changes.
- Valid Scenario: This solution is great when using a configuration management tool like Chef to automate infrastructure management and reconfiguration tasks.
Option B: Put the file nodes.config in version control. Create an AWS CodeDeploy deployment configuration and deployment group based on an Amazon EC2 tag value for the cluster nodes. When adding a new node to the cluster, update the file with all tagged instances, and make a commit in version control. Deploy the new file and restart the services.
- Explanation: Version control (e.g., Git) can be used to maintain the `/etc/cluster/nodes.config` file, and AWS CodeDeploy can help deploy changes to EC2 instances based on tags. However, this requires manual updates to the file whenever a new node is added, including committing the changes to version control and triggering a deployment.
- Rejection: This approach involves more manual steps, especially when managing multiple nodes. It doesn't provide automation for dynamically updating the file each time a node is added or removed. This is less efficient than other options since it requires ongoing human intervention to manage commits and deployments.
Option C: Create an Amazon S3 bu...
Author: Evelyn · Last updated May 17, 2026
A DevOps engineer is working on a data archival project that requires the migration of on-premises data to an Amazon S3 bucket. The DevOps engineer develops a script that incrementally archives on-premises data that is older than 1 month to Amazon S3. Data that is transferred to Amazon S3 is deleted from the on-premises location. The script uses the S3 PutObject operation.
During a code review, the DevOps engineer notices that the script does not verify whether the data was successfully copied to Amazon S3. The DevOps engineer must update the scr...
The requirement is to ensure that the data is correctly transferred to Amazon S3 and verified using MD5 checksums before deleting the data from the on-premises location. Let's evaluate the provided options:
Option A: Check the returned response for the VersionId. Compare the returned VersionId against the MD5 checksum.
- Explanation: The VersionId is a unique identifier for the version of an object in S3, but it is not related to MD5 checksums or data integrity. The VersionId does not provide any information about the checksum of the object itself.
- Rejection: This option is not valid because comparing the VersionId to the MD5 checksum will not help in verifying data integrity.
Option B: Include the MD5 checksum within the Content-MD5 parameter. Check the operation calls return status to find out if an error was returned.
- Explanation: The Content-MD5 parameter is a way to ensure data integrity when uploading an object to S3. The MD5 checksum of the data is provided in the Content-MD5 header, and S3 will compute its own MD5 checksum upon receiving the data. If the two checksums do not match, S3 will return an error.
- Selection Reasoning: This is the correct approach because using the Content-MD5 parameter ensures that S3 verifies the integrity of the data. If the checksum doesn't match, the upload will fail, and the DevOps engineer can handle the error and ensure that the data is not deleted from the on-premises location until the transfer is successful.
- Valid Scenario: This solution is specifically designed to ensure data integrity during transmission, making it ideal for the use case described.
Option C: Include the checksum digest within the tagging parameter as a URL query parameter.
- Explanation: The tagging parameter is used to attach metadata tags to an S3 object. While tags can be useful for organizing and identifying objects, they are not designed for checksum validation or data integrity purposes. Including a checksum in the tagging parameter does not help in verifying the data during transfer.
- Rejection: This approach is not relevant to verifying data integrity during the upload. Tags are not used to...
Author: Kunal · Last updated May 17, 2026
A company deploys updates to its Amazon API Gateway API several times a week by using an AWS CodePipeline pipeline. As part of the update process, the company exports the JavaScript SDK for the API from the API Gateway console and uploads the SDK to an Amazon S3 bucket.
The company has configured an Amazon CloudFront distribution that uses the S3 bucket as an origin. Web clients then download the SDK by using the CloudFront distr...
The goal here is to automate the process of making the updated JavaScript SDK available after each new API deployment. The solution should ensure that the SDK is automatically uploaded to the S3 bucket and that the CloudFront cache is invalidated for the updated SDK, without manual intervention.
Let's evaluate the provided options:
Option A: Create a CodePipeline action immediately after the deployment stage of the API. Configure the action to invoke an AWS Lambda function. Configure the Lambda function to download the SDK from API Gateway, upload the SDK to the S3 bucket, and create a CloudFront invalidation for the SDK path.
- Explanation: This option proposes using AWS Lambda in the CodePipeline to automate the download of the SDK from API Gateway, uploading it to the S3 bucket, and invalidating the CloudFront cache. This ensures that every time the API is updated, the SDK is automatically updated and the CloudFront cache is invalidated.
- Selection Reasoning: This is a good approach because it tightly integrates with CodePipeline, allowing it to trigger the Lambda function right after the deployment stage of the API. The Lambda function can handle the necessary steps (downloading the SDK, uploading it to S3, and invalidating the CloudFront cache) all in one seamless process.
- Valid Scenario: This approach is perfect when using CodePipeline for automated deployment and when needing to integrate post-deployment tasks like SDK updates and cache invalidation.
Option B: Create a CodePipeline action immediately after the deployment stage of the API. Configure the action to use the CodePipeline integration with API Gateway to export the SDK to Amazon S3. Create another action that uses the CodePipeline integration with Amazon S3 to invalidate the cache for the SDK path.
- Explanation: This option suggests using native CodePipeline integrations to export the SDK directly to S3 and then invalidate the CloudFront cache via a subsequent S3 action. However, as of now, there is no native CodePipeline action to export the SDK from API Gateway directly. While you can use CodePipeline to interact with S3, there is no direct integration between API Gateway and CodePipeline for exporting the SDK.
- Rejection: This approach is not valid because there is no out-of-the-box CodePipeline integration with API Gateway for exporting the SDK. It would require custom scripting or Lambda functions, making this solution less streamlined than Option A.
Option C: Create an A...
Author: StarryEagle42 · Last updated May 17, 2026
A company has developed an AWS Lambda function that handles orders received through an API. The company is using AWS CodeDeploy to deploy the Lambda function as the final stage of a CI/CD pipeline.
A DevOps engineer has noticed there are intermittent failures of the ordering API for a few seconds after deployment. After some investigation, the DevOps engineer believ...
To address the intermittent failures of the ordering API due to database changes not fully propagating before the Lambda function is invoked, the DevOps engineer needs to ensure that any changes to the database are fully propagated before the Lambda function is allowed to handle requests.
Option Analysis:
- A) Add a BeforeAllowTraffic hook to the AppSpec file that tests and waits for any necessary database changes before traffic can flow to the new version of the Lambda function.
- Explanation: The `BeforeAllowTraffic` hook is ideal for situations where you want to ensure that dependencies (like database changes) are fully settled before the new Lambda function begins processing requests. This hook is called before any traffic is routed to the new version of the Lambda function, allowing it to wait until the necessary database changes have propagated.
- Why chosen? This option ensures that database changes are fully propagated before the Lambda function starts processing requests, thereby avoiding failures that occur when the Lambda function is invoked before the database is ready.
- B) Add an AfterAllowTraffic hook to the AppSpec file that forces traffic to wait for any pending database changes before allowing the new version of the Lambda function to respond.
- Explanation: The `AfterAllowTraffic` hook runs after traffic is already routed to the new version of the Lambda function. This would not address the issue of ensuring the database is fully updated before the Lambda function starts processing requests. Instead, it could lead to delays in response times or failures if the database changes are still not complete.
- Why rejected? This hook doesn’t ensure the database is ready before traffic starts flowing to the Lambda function. The problem occurs because the Lambda function may process requests before the database is ready, which this option doesn't prevent.
- C) Add a BeforeInstall hook to the AppSpec file that tests and waits for any necessary database ...
Author: Sofia · Last updated May 17, 2026
A company uses a single AWS account to test applications on Amazon EC2 instances. The company has turned on AWS Config in the AWS account and has activated the restricted-ssh AWS Config managed rule.
The company needs an automated monitoring solution that will provide a customized notification in real time if any security group in the account is not compliant with the restricted-ssh rule. The customized notification must contain the name and ID of the noncompliant security group.
A DevOps...
To meet the company's requirements for an automated solution that provides customized notifications when a security group is noncompliant with the restricted-ssh rule, we need a way to match the noncompliant evaluation results from AWS Config and send a real-time, customized notification to the appropriate personnel via an SNS topic.
Option Analysis:
- A) Create an Amazon EventBridge rule that matches an AWS Config evaluation result of NON_COMPLIANT for the restricted-ssh rule. Configure an input transformer for the EventBridge rule. Configure the EventBridge rule to publish a notification to the SNS topic.
- Explanation: This option is highly suitable because it allows EventBridge to match the specific NON_COMPLIANT evaluation result for the restricted-ssh rule, and the use of an input transformer enables customization of the notification. The notification can include specific details like the name and ID of the noncompliant security group. EventBridge will then publish the notification to the SNS topic. This meets all the requirements for real-time notification and customization.
- Why selected? It directly fulfills the requirements by allowing fine-grained control over the noncompliance results, the ability to format the notification as needed, and the capability to send the notification to the SNS topic for further alerting.
- B) Configure AWS Config to send all evaluation results for the restricted-ssh rule to the SNS topic. Configure a filter policy on the SNS topic to send only notifications that contain the text of NON_COMPLIANT in the notification to subscribers.
- Explanation: While this option does send evaluation results to an SNS topic, it relies on the filter policy at the SNS level to handle noncompliance notifications. However, this approach lacks the level of customization needed, such as adding the name and ID of the noncompliant security group. This solution is more passive and relies on post-processing in the SNS filter, which could be less flexible and potentially not provide the specific details in the notification.
- Why rejected? It does not offer the level of customization for the notification that is required, such as including specific details like the security group's...
Author: William · Last updated May 17, 2026
A company requires an RPO of 2 hours and an RTO of 10 minutes for its data and application at all times. An application uses a MySQL database and Amazon EC2 web servers. The development team needs a strategy for failover and disaster...
To meet the company's requirements for an RPO of 2 hours and an RTO of 10 minutes, the DevOps team needs a disaster recovery strategy that ensures fast failover and minimal data loss. The solution must address both database failover and application failover, with quick recovery times and minimal disruption to the users.
Option Analysis:
- A) Create an Amazon Aurora cluster in one Availability Zone across multiple Regions as the data store. Use Aurora’s automatic recovery capabilities in the event of a disaster.
- Explanation: While Amazon Aurora offers automatic recovery features and can work across multiple Availability Zones (AZs) in a single Region, this option does not provide cross-Region disaster recovery. A single Availability Zone across multiple Regions is a limited design, and it does not provide failover capability to another Region in the event of a disaster. This fails to meet the requirement of high availability and disaster recovery across regions.
- Why rejected? This option doesn't align with the need for cross-Region failover, which is critical for meeting the RTO and RPO.
- B) Create an Amazon Aurora global database in two Regions as the data store. In the event of a failure, promote the secondary Region as the primary for the application.
- Explanation: Amazon Aurora Global Databases are specifically designed for cross-Region disaster recovery. This setup provides near-instantaneous failover capabilities with minimal data loss (RPO of seconds to minutes), which satisfies the company's RPO of 2 hours and RTO of 10 minutes. The ability to promote a secondary Region to primary ensures quick recovery times and geographic redundancy.
- Why selected? This option provides the necessary cross-Region high availability and rapid failover, fulfilling both the RTO and RPO requirements.
- C) Create an Amazon Aurora multi-master cluster across multiple Regions as the data store. Use a Network Load Balancer to balance the database traffic in different Regions.
- Explanation: While Aurora multi-master clusters can offer high availability and write scalability across multiple Regions, they are a more complex and potentially costly solution. A Network Load Balancer (NLB) to balance database traffic across Regions is also not ideal, as NLB is typically used for network traffic and not for database failover. Aurora Global Databases are a more purpose-built and ef...
Author: MoonlitPantherX · Last updated May 17, 2026
A business has an application that consists of five independent AWS Lambda functions.
The DevOps engineer has built a CI/CD pipeline using AWS CodePipeline and AWS CodeBuild that builds, tests, packages, and deploys each Lambda function in sequence. The pipeline uses an Amazon EventBridge rule to ensure the pipeline starts as quickly as possible after a change is made to the application source code.
After working with the p...
The goal here is to reduce the overall time taken by the CI/CD pipeline, which currently sequentially builds, tests, packages, and deploys each Lambda function. To speed up the pipeline, the best approach is to implement parallel execution where possible, instead of running the Lambda functions in sequence.
Option Analysis:
- A) Modify the CodeBuild projects within the pipeline to use a compute type with more available network throughput.
- Explanation: Increasing the network throughput of the compute type may improve certain aspects of performance, especially if the Lambda functions interact with external resources that require high network bandwidth. However, this primarily affects the performance of a single build task, and doesn't address the pipeline's core issue, which is the sequential nature of the tasks. The real problem lies in how the Lambda functions are being deployed, not just the network throughput.
- Why rejected? While this might help with specific performance issues, it won't significantly improve the overall pipeline speed if tasks are still executed sequentially.
- B) Create a custom CodeBuild execution environment that includes a symmetric multiprocessing configuration to run the builds in parallel.
- Explanation: Using a custom execution environment with symmetric multiprocessing could theoretically improve performance, but it would require significant custom setup and might not have a big impact on the pipeline's overall speed. It also wouldn't directly address the core issue of running multiple Lambda function builds sequentially. Additionally, custom environments would add complexity and maintenance overhead.
- Why rejected? The complexity introduced by setting up a custom execution environment outweighs the potential benefits in improving pipeline speed. The core need is to run...
Author: Stella · Last updated May 17, 2026
A company uses AWS CloudFormation stacks to deploy updates to its application. The stacks consist of different resources. The resources include AWS Auto Scaling groups, Amazon EC2 instances, Application Load Balancers (ALBs), and other resources that are necessary to launch and maintain independent stacks. Changes to application resources outside of CloudFormation stack updates are not allowed.
The company recently attempted to update the application stack by using the AWS CLI. The stack failed to update and produced the following error message: 'ERROR: both the deploy...
When a CloudFormation stack is in the `UPDATE_ROLLBACK_FAILED` status, it typically means that an error occurred during the update process, and CloudFormation attempted to roll back to the previous state but was unable to complete the rollback. This can happen due to issues with specific resources that could not be updated or deleted as part of the rollback process. The error message in this case indicates that the `AutoScalingGroup` resource is the one causing the failure.
Option Analysis:
- A) Update the subnet mappings that are configured for the ALBs. Run the aws cloudformation update-stack-set AWS CLI command.
- Explanation: The error message indicates an issue with the `AutoScalingGroup`, not the ALB subnet mappings. Changing subnet mappings of ALBs likely won't address the issue related to the failed update of the Auto Scaling Group. Also, the `update-stack-set` command is typically used for updating CloudFormation stack sets, not for resolving rollback issues.
- Why rejected? This option does not address the root cause of the issue, which is related to the `AutoScalingGroup` and rollback failure.
- B) Update the IAM role by providing the necessary permissions to update the stack. Run the aws cloudformation continue-update-rollback AWS CLI command.
- Explanation: The `continue-update-rollback` command is specifically designed to continue a rollback process that has failed. This is a suitable option if the rollback failed due to an error in resource management or permissions. In this case, if the rollback failure was caused by permissions or other resource dependencies that weren't correctly updated, continuing the rollback could resolve the issue. Updating IAM roles could be useful if permission-related problems are identified, but this approach addresses the process of continuing the rollback rather than manually resolving the Auto Scaling Group issue.
- Why selected? This command will continue th...
Author: Lucas Carter · Last updated May 17, 2026
A company is deploying a new application that uses Amazon EC2 instances. The company needs a solution to query application logs and AWS account...
Let's analyze each option to determine the best solution:
A) Use the Amazon CloudWatch agent to send logs from the EC2 instances to Amazon CloudWatch Logs. Configure AWS CloudTrail to deliver the API logs to Amazon S3. Use CloudWatch to query both sets of logs.
- Pros:
- Using CloudWatch Logs for application logs from EC2 instances is straightforward and integrates with CloudWatch seamlessly.
- CloudTrail logs can be delivered to Amazon S3, but CloudWatch does not natively query S3 data.
- CloudWatch is primarily used for monitoring and logs, but querying logs from S3 through CloudWatch itself is not native.
- Cons:
- CloudWatch cannot directly query logs stored in S3. You would need another service to query the S3 logs, such as Athena, which is missing here.
B) Use the Amazon CloudWatch agent to send logs from the EC2 instances to Amazon CloudWatch Logs. Configure AWS CloudTrail to deliver the API logs to CloudWatch Logs. Use CloudWatch Logs Insights to query both sets of logs.
- Pros:
- CloudWatch Logs Insights is a powerful tool for querying and analyzing logs within CloudWatch Logs.
- This solution ensures all logs (application and API activity) are within CloudWatch, and Logs Insights provides an easy way to query and correlate them.
- Cons:
- CloudTrail logs cannot be directly delivered to CloudWatch Logs unless configured properly to do so. This may require setting up CloudTrail to log to CloudWatch, which is an additional configuration step but is fully supported.
- Best fit: This is an efficient and consolidated solution, leveraging CloudWatch for all logging and querying.
C) Use the Amazon CloudWatch...
Author: Maya · Last updated May 17, 2026
A company wants to ensure that their EC2 instances are secure. They want to be notified if any new vulnerabilities are discovered on their instances, and they also want an audit trail of all ...
Let's evaluate each option based on the requirements: detecting vulnerabilities on EC2 instances and having an audit trail of login activities.
A) Use AWS Systems Manager to detect vulnerabilities on the EC2 instances. Install the Amazon Kinesis Agent to capture system logs and deliver them to Amazon S3.
- Pros:
- AWS Systems Manager can detect vulnerabilities on EC2 instances via the Patch Manager and other tools in the Systems Manager suite.
- Kinesis is used for streaming data, but it is not directly focused on managing system logs or login activity.
- Cons:
- Kinesis is not the most suitable service for capturing system logs and login activities, and storing logs in S3 without querying tools (such as Athena) would add unnecessary complexity.
- This option does not provide a clear solution for auditing login activities.
B) Use AWS Systems Manager to detect vulnerabilities on the EC2 instances. Install the Systems Manager Agent to capture system logs and view login activity in the CloudTrail console.
- Pros:
- AWS Systems Manager can indeed detect vulnerabilities through Patch Manager, AWS Inspector, and other capabilities.
- The Systems Manager Agent (SSM Agent) can capture system logs, and AWS CloudTrail can be used to log and audit all API activity, including login activities (via AWS Systems Manager Session Manager or EC2 login).
- Cons:
- This solution requires some configuration steps to integrate the Systems Manager Agent with CloudTrail for full login activity tracking, but it is very well suited for the need to monitor security and login activities.
- Best fit: This option addresses both the vulnerability detection and the audit trail of login activities, making it a solid solution.
C) Configure Amazon CloudWatch to detect vulnerabilities on the EC2 instances. Install the AWS Config daemon to capture system logs and view them in the AWS Config console.
- Pros:
- AWS Config provides configuration t...
Author: Ahmed · Last updated May 17, 2026
A company is running an application on Amazon EC2 instances in an Auto Scaling group. Recently, an issue occurred that prevented EC2 instances from launching successfully, and it took several hours for the support team to discover the issue. The support team wants t...
Let's evaluate each option based on the requirement: notifying the support team via email when an EC2 instance fails to launch successfully.
A) Add a health check to the Auto Scaling group to invoke an AWS Lambda function whenever an instance status is impaired.
- Pros:
- Health checks can trigger alerts if an instance is unhealthy, but they typically monitor the instance status after it has launched and is part of the Auto Scaling group.
- Cons:
- This option won't specifically help in the case of a failed EC2 instance launch. Health checks are for monitoring the health of running instances, not for detecting launch failures. Therefore, it does not meet the requirement of notifying the team when an instance fails to start.
- Best fit: This could be useful for ongoing instance health but not for initial launch failures.
B) Configure the Auto Scaling group to send a notification to an Amazon SNS topic whenever a failed instance launch occurs.
- Pros:
- Auto Scaling groups have built-in support for sending notifications on scaling events, including failed instance launches.
- You can configure notifications directly within the Auto Scaling group to send alerts to an Amazon SNS topic.
- This would notify the support team in real time whenever an instance fails to launch, which is the exact requirement.
- Cons:
- No significant cons—this option aligns directly with the goal of notifying the support team for launch failures.
- Best fit: This is the ideal solution because it directly addresses the requirement of notifying the team when an EC2 instance fails to launch.
C) Create an Amazon CloudWatch alarm that invokes an AWS Lambda function when a failed AttachInstances ...
Author: Rohan · Last updated May 17, 2026
A company is using AWS Organizations to centrally manage its AWS accounts. The company has turned on AWS Config in each member account by using AWS CloudFormation StackSets. The company has configured trusted access in Organizations for AWS Config and has configured a member account as a delegated administrator account for AWS Config.
A DevOps engineer needs to implement a new security policy. The policy must require all current and future AWS member accounts to use a common baseline of AWS Config rules that contain remediation actions that are manage...
Let's break down the requirements and evaluate each solution:
Requirements:
1. Common baseline of AWS Config rules and remediation actions should be used across all current and future AWS member accounts.
2. Remediation actions should be managed centrally, likely in the management account.
3. Non-administrator users should not be able to modify the baseline.
4. The common baseline must be deployed automatically to all member accounts using a central management account.
Evaluating the options:
A) Create a CloudFormation template that contains the AWS Config rules and remediation actions. Deploy the template from the Organizations management account by using CloudFormation StackSets.
- Pros:
- CloudFormation StackSets allow you to deploy a template across multiple accounts and regions, which meets the requirement to deploy AWS Config rules consistently across all member accounts.
- However, CloudFormation itself doesn’t directly manage AWS Config rules or remediation actions. You would need to ensure the template manages these resources correctly, which could be complex.
- Cons:
- CloudFormation is a bit less specialized for managing AWS Config rules and remediation actions compared to AWS Config conformance packs, which are specifically designed for this purpose. This means that while it could technically work, it’s not the most efficient or straightforward approach for managing AWS Config rules and remediation actions.
- Best fit: While functional, this option is not ideal because AWS Config conformance packs are specifically designed for the use case of managing and deploying AWS Config rules with remediation actions.
B) Create an AWS Config conformance pack that contains the AWS Config rules and remediation actions. Deploy the pack from the Organizations management account by using CloudFormation StackSets.
- Pros:
- AWS Config conformance packs are designed specifically to bundle AWS Config rules and remediation actions, which aligns perfectly with the goal of applying a common baseline of rules across accounts.
- You can deploy conformance packs across accounts using CloudFormation StackSets, which is a robust way to manage deployments centrally and consistently across all accounts.
- The management of remediation actions and rules in AWS Config conformance packs ensures that the baseline remains intact, and non-administrator users cannot modify the baseline as it’s centrally managed.
- Cons:...
Author: Aria · Last updated May 17, 2026
A DevOps engineer manages a large commercial website that runs on Amazon EC2. The website uses Amazon Kinesis Data Streams to collect and process web logs. The DevOps engineer manages the Kinesis consumer application, which also runs on Amazon EC2.
Sudden increases of data cause the Kinesis consumer application to fall behind, and the Kinesis data streams drop records before the records ca...
To address the issue of Kinesis data streams dropping records due to the consumer application falling behind, we need to select a solution that ensures that records are processed reliably and with minimal operational overhead. Let's evaluate each option carefully:
A) Modify the Kinesis consumer application to store the logs durably in Amazon S3. Use Amazon EMR to process the data directly on Amazon S3 to derive customer insights. Store the results in Amazon S3.
- Analysis: This solution involves adding significant complexity by modifying the consumer application to store data in S3 and then processing the logs with Amazon EMR. This approach introduces more components (S3, EMR) that require management and is more operationally intensive, which makes it less optimal for handling Kinesis data streams with minimal operational overhead.
- Rejected: This option is complex and adds extra layers of infrastructure (EMR and S3) that are not necessary to simply handle stream processing more efficiently.
B) Horizontally scale the Kinesis consumer application by adding more EC2 instances based on the Amazon CloudWatch GetRecords.IteratorAgeMilliseconds metric. Increase the retention period of the Kinesis data streams.
- Analysis: Horizontally scaling the consumer application (by adding more EC2 instances) could help process more records in parallel. Monitoring the `IteratorAgeMilliseconds` metric allows dynamic scaling based on lag. Increasing the retention period can give the application more time to process records before they are dropped. While this solution improves throughput, it still requires managing EC2 instances and scaling them manually or via automation, leading to increased operational overhead.
- Rejected: While this is a valid approach, it involves more management of EC2 instances, scaling, and monitoring, which adds operational complexity compared to other solutions.
C) Convert the Kinesis consum...
Author: Victoria · Last updated May 17, 2026
A company recently created a new AWS Control Tower landing zone in a new organization in AWS Organizations. The landing zone must be able to demonstrate compliance with the Center for Internet Security (CIS) Benchmarks for AWS Foundations.
The company's security team wants to use AWS Security Hub to view compliance across all accounts. Only the security team can be allowed to view aggregated Security Hub findings. In addition, specific users must be able to view findings from their own ...
Analysis of Options:
Let's break down each option based on the requirements, security principles, and automation needs.
A) Turn on trusted access for Security Hub in the organization's management account. Create a new security account by using AWS Control Tower. Configure the new security account as the delegated administrator account for Security Hub. In the new security account, provide Security Hub with the CIS Benchmarks for AWS Foundations standards.
- Explanation: Enabling trusted access for Security Hub allows centralized management of findings. Setting up a delegated administrator account using AWS Control Tower provides a centralized management layer for Security Hub findings. Configuring the CIS Benchmarks ensures compliance.
- Why this is correct: By creating a dedicated security account and making it a delegated administrator for Security Hub, only the security team will be able to access aggregated findings.
- Scenario where this is useful: This is ideal in environments where there is a need to separate administrative control over security findings from the general AWS Organization accounts, maintaining security and compliance.
B) Turn on trusted access for Security Hub in the organization's management account. From the management account, provide Security Hub with the CIS Benchmarks for AWS Foundations standards.
- Explanation: This approach would involve managing Security Hub directly from the organization's management account.
- Why this is not correct: This doesn’t leverage the use of a separate security account for the security team, which is crucial for limiting access to aggregated findings. Additionally, all users in the management account would have access to the findings unless further restrictions are set, which is contrary to the requirement of allowing only the security team to view aggregated findings.
C) Create an AWS IAM Identity Center (AWS Single Sign-On) permission set that includes the required permissions. Use the CreateAccountAssignment API operation to associate the security team users with the permission set and with the delegated security account.
- Explanation: This would ensure that only users in the security team can access Security Hub findings in the security account.
- Why this is correct: By using AWS IAM Identity Center (formerly AWS Single Sign-On) with permission sets, you can precisely control access to Security Hub in the security account for authorized users (the security team).
- Scenario where this is useful: This is useful for ensuring the proper management of user access and enforcing role-based access control with...
Author: Jack · Last updated May 17, 2026
A company runs applications in AWS accounts that are in an organization in AWS Organizations. The applications use Amazon EC2 instances and Amazon S3.
The company wants to detect potentially compromised EC2 instances, suspicious network activity, and unusual API activity in its existing AWS accounts and in any AWS accounts that the company creates in the future. When the company detects one of these events, the company wants to use an existing Amazon Simple Notificati...
Analysis of Options:
Let's break down each option based on the requirements and AWS best practices.
A) In the organization's management account, configure an AWS account as the Amazon GuardDuty administrator account. In the GuardDuty administrator account, add the company’s existing AWS accounts to GuardDuty as members. In the GuardDuty administrator account, create an Amazon EventBridge rule with an event pattern to match GuardDuty events and to forward matching events to the SNS topic.
- Explanation: This solution configures Amazon GuardDuty as a threat detection service to monitor EC2 instances, S3 activity, and network traffic. The events are forwarded to an SNS topic via an EventBridge rule, ensuring that notifications are sent to the operational support team.
- Why this is correct: GuardDuty is well-suited for detecting potentially compromised EC2 instances, suspicious network activity, and unusual API activity. By setting it up as a master account with member accounts, you can automatically monitor all existing and future AWS accounts. Using EventBridge to forward GuardDuty events to an SNS topic fits well with AWS best practices.
- Scenario where this is useful: This is the most appropriate solution as it directly leverages GuardDuty for threat detection and integrates it with EventBridge for automated notifications, which meets the company’s requirements for detecting and notifying suspicious activities across all accounts.
B) In the organization's management account, configure Amazon GuardDuty to add newly created AWS accounts by invitation and to send invitations to the existing AWS accounts. Create an AWS CloudFormation stack set that accepts the GuardDuty invitation and creates an Amazon EventBridge rule. Configure the rule with an event pattern to match GuardDuty events and to forward matching events to the SNS topic. Configure the CloudFormation stack set to deploy into all AWS accounts in the organization.
- Explanation: This solution involves GuardDuty with CloudFormation to automate the invitation and account setup. The CloudFormation stack sets are used to propagate configurations across the organization, including the EventBridge rule for forwarding events to SNS.
- Why this is not correct: This solution introduces unnecessary complexity with CloudFormation stack sets. While GuardDuty and EventBridge are appropriate for the task, using CloudFormation to configure GuardDuty invitations and event forwarding is more complicated than needed. AWS best practices prefer simpler and more direct configurations where possible.
- Scenario where this is useful: This approach may be useful in environments that require extensive automation via CloudFormation, but it is unnecessarily complex for the given task.
C) In the organization's management accou...
Author: Amelia · Last updated May 17, 2026
A company's DevOps engineer is working in a multi-account environment. The company uses AWS Transit Gateway to route all outbound traffic through a network operations account. In the network operations account, all account traffic passes through a firewall appliance for inspection before the traffic goes to an internet gateway.
The firewall appliance sends logs to Amazon CloudWatch Logs and includes event severities...
Analysis of Options:
Let’s evaluate each option to determine the best solution for triggering alerts based on CRITICAL events from the firewall logs.
A) Create an Amazon CloudWatch Synthetics canary to monitor the firewall state. If the firewall reaches a CRITICAL state or logs a CRITICAL event, use a CloudWatch alarm to publish a notification to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the security team's email address to the topic.
- Explanation: CloudWatch Synthetics allows you to monitor the health of endpoints, but it is typically used for synthetic transactions, such as checking if a website or an API endpoint is available and responding. While it could theoretically monitor the firewall, it is not ideal for directly monitoring log data or event severities in CloudWatch Logs.
- Why this is not correct: The CloudWatch Synthetics canary is more suited for synthetic monitoring of HTTP/S endpoints, not for monitoring specific log events from the firewall. This is an overcomplicated solution for the problem of monitoring log event severity (CRITICAL).
- Scenario where this is useful: If the task was to monitor a specific endpoint or service, this could be applicable, but it's not the right fit for log-based event severity monitoring.
B) Create an Amazon CloudWatch metric filter by using a search for CRITICAL events. Publish a custom metric for the finding. Use a CloudWatch alarm based on the custom metric to publish a notification to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the security team's email address to the topic.
- Explanation: CloudWatch Logs metric filters allow you to create custom metrics based on specific log patterns. By creating a filter that searches for CRITICAL event severity in the firewall logs, you can publish a custom metric and set a CloudWatch alarm on that metric. When a CRITICAL event occurs, the alarm will trigger, sending a notification to the SNS topic.
- Why this is correct: This solution is ideal because it leverages CloudWatch Logs and metric filters to detect CRITICAL events from the firewall logs directly, and it uses a CloudWatch alarm to trigger notifications. It provides a simple and effective way to alert the security team based on the CRITICAL severity level of events.
- Scenario where this is useful: This is the best solution for monitoring log data and sending notifications based on event severity, as it uses AWS-native tools (CloudWatch Logs and SNS) efficiently.
...
Author: Ava · Last updated May 17, 2026
A company is divided into teams. Each team has an AWS account, and all the accounts are in an organization in AWS Organizations. Each team must retain full administrative rights to its AWS account. Each team also must be allowed to access only AWS services that the company approves for use. AWS services must ga...
Analysis of Options:
Let's evaluate each option to determine the best solution for restricting access to only approved AWS services while retaining full administrative rights for each team's AWS account.
A) Use AWS CloudFormation StackSets to provision IAM policies in each account to deny access to restricted AWS services. In each account, configure AWS Config rules that ensure that the policies are attached to IAM principals in the account.
- Explanation: AWS CloudFormation StackSets would deploy policies across all accounts to deny access to specific services. AWS Config can be used to enforce the configuration and ensure policies are attached correctly.
- Why this is not ideal: While this solution ensures that IAM policies are deployed and enforced, it's a more manual and less centralized approach compared to the other options. Config rules are also typically used for compliance checks rather than continuous enforcement of service restrictions.
- Scenario where this is useful: This approach could work in scenarios where you need to customize policy enforcement or when using CloudFormation for infrastructure automation. However, it introduces more complexity than needed.
B) Use AWS Control Tower to provision the accounts into OUs within the organization. Configure AWS Control Tower to enable AWS IAM Identity Center (AWS Single Sign-On). Configure IAM Identity Center to provide administrative access. Include deny policies on user roles for restricted AWS services.
- Explanation: AWS Control Tower helps manage governance across accounts and enables centralized access control through IAM Identity Center (formerly AWS SSO). IAM Identity Center can manage permissions and grant administrative access. Deny policies can be applied to restrict access to non-approved services.
- Why this is correct: AWS Control Tower simplifies multi-account management and governance, especially with service restrictions, through IAM Identity Center. The solution integrates easily into the AWS Organizations structure, providing centralized administration and service restrictions based on user roles.
- Scenario where this is useful: This is useful in environments where organizations want to enforce centralized access control and compliance policies across multiple teams and accounts while maintaining user-specific access management.
C) Place all the accounts under a new top-level OU within the organization. Create an SCP that ...
Author: Sofia · Last updated May 17, 2026
A DevOps engineer used an AWS CloudFormation custom resource to set up AD Connector. The AWS Lambda function ran and created AD Connector, but CloudFormation is not transitioning from CREATE_IN_PROGRE...
Analysis of Options:
The issue is that AWS CloudFormation has not transitioned from `CREATE_IN_PROGRESS` to `CREATE_COMPLETE` after running the Lambda function for the custom resource to create AD Connector. CloudFormation relies on the Lambda function to signal when the operation is complete.
Let’s evaluate each option:
A) Ensure the Lambda function code has exited successfully.
- Explanation: The Lambda function must finish its execution for CloudFormation to move the status to `CREATE_COMPLETE`. However, if the Lambda function finishes without reporting success or failure, CloudFormation won't be able to proceed with the stack creation.
- Why this is not correct: While ensuring that the Lambda function exits successfully is important, this action alone doesn't guarantee that CloudFormation will transition to `CREATE_COMPLETE`. The Lambda function needs to explicitly report the completion status back to CloudFormation via a pre-signed URL.
- Scenario where this is useful: This is generally a good practice to ensure the Lambda finishes correctly, but in this case, CloudFormation requires explicit signaling (via the pre-signed URL) to transition the status.
B) Ensure the Lambda function code returns a response to the pre-signed URL.
- Explanation: For CloudFormation to transition from `CREATE_IN_PROGRESS` to `CREATE_COMPLETE`, the Lambda function must return a response to the pre-signed URL that CloudFormation provides. This response should indicate whether the operation was successful or if there was an error. Without this response, CloudFormation will remain in `CREATE_IN_PROGRESS`.
- Why this is correct: This is the key action required. CloudFormation uses the pre-signed URL to track the status of the operation. The Lambda function must call this URL and provide an appropriate response (success or failure) for the stack operation to be marked as complete.
- Scenario where this is useful: This is the correct solution because CloudFormation depends on the Lambda function responding to the pre-signed URL to complete the stack creation process.
C) Ensure the Lambda functio...
Author: NebulaEagle11 · Last updated May 17, 2026
A company uses AWS CodeCommit for source code control. Developers apply their changes to various feature branches and create pull requests to move those changes to the main branch when the changes are ready for production.
The developers should not be able to push changes directly to the main branch. The company applied the AWSCodeCommitPowerUser managed policy to the developers' IAM role, and now these developers can push c...
The company wants to restrict developers from pushing changes directly to the main branch, while still allowing them to work with feature branches and create pull requests. The current configuration of the AWSCodeCommitPowerUser managed policy gives the developers too broad of permissions, including the ability to push changes directly to the main branch.
Let’s evaluate the options one by one:
Option A: Create an additional policy to include a Deny rule for the GitPush and PutFile actions. Include a restriction for the specific repositories in the policy statement with a condition that references the main branch.
- This option allows you to restrict the ability to push changes to the main branch by explicitly denying the `GitPush` and `PutFile` actions, but only for the main branch of specific repositories. This approach ensures that developers cannot push directly to the main branch while still being able to make changes in other branches.
- Reasoning: Deny rules are evaluated with higher priority than Allow rules, so the Deny for pushing changes to the main branch will take precedence. The condition referencing the main branch ensures that the restriction applies specifically to the main branch without affecting other branches.
- Best fit: This is the ideal option to meet the company’s requirement.
Option B: Remove the IAM policy, and add an AWSCodeCommitReadOnly managed policy. Add an Allow rule for the GitPush and PutFile actions for the specific repositories in the policy statement with a condition that references the main branch.
- The AWSCodeCommitReadOnly managed policy grants only read access, which does not align with the goal of allowing developers to work on feature branches and make changes to them. By removing the existing permissions entirely, you are limiting the developers' ability to work with repositories. Adding an Allow rule for the main branch would allow them to push changes directly to the main branch, which is precisely what the company wants to avoid.
- ...
Author: Amira · Last updated May 17, 2026
A company manages a web application that runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The EC2 instances run in an Auto Scaling group across multiple Availability Zones. The application uses an Amazon RDS for MySQL DB instance to store the data. The company has configured Amazon Route 53 with an alias record that points to the ALB.
A new company guideline requires a geographically isol...
To meet the company’s disaster recovery (DR) requirements of an RTO (Recovery Time Objective) of 4 hours and an RPO (Recovery Point Objective) of 15 minutes, the solution must:
1. Ensure that the application and database are replicated and can fail over to a DR site with minimal changes to the existing architecture.
2. Ensure minimal downtime (RTO) and data loss (RPO).
3. Leverage the current infrastructure, with the least changes to the application stack.
Let’s evaluate each option:
Option A: Launch a replica environment of everything except Amazon RDS in a different Availability Zone. Create an RDS read replica in the new Availability Zone, and configure the new stack to point to the local RDS DB instance. Add the new stack to the Route 53 record set by using a health check to configure a failover routing policy.
- Reasoning: This option uses an Availability Zone (AZ) within the same region. While the RDS read replica can be in a different AZ, it does not fulfill the requirement of a geographically isolated DR site. It is not an effective DR solution because a disaster affecting an entire region (including AZs) would impact the solution, meaning the RTO could be violated.
- Rejected because: It does not provide a geographically isolated DR solution and may not fully meet the RTO requirement if the entire region is impacted.
Option B: Launch a replica environment of everything except Amazon RDS in a different AWS Region. Create an RDS read replica in the new Region, and configure the new stack to point to the local RDS DB instance. Add the new stack to the Route 53 record set by using a latency routing policy.
- Reasoning: This option uses a geographically isolated DR site in a different AWS Region, which meets the requirement for isolation. The RDS read replica in the new Region would allow the application to continue with minimal downtime in the event of a failure. The latency routing policy helps ensure that traffic is routed to the healthiest region. However, the option does not have a defined failover mechanism like promoting the read replica in the event of an outage, so it would require manual intervention in case of a ...
Author: Amira · Last updated May 17, 2026
A large enterprise is deploying a web application on AWS. The application runs on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Auto Scaling group across multiple Availability Zones. The application stores data in an Amazon RDS for Oracle DB instance and Amazon DynamoDB. There are separate envir...
To determine the most secure and flexible way to obtain password credentials during deployment, let's evaluate each option carefully based on security, flexibility, and the best practices for managing sensitive information in AWS.
Option A: Retrieve an access key from an AWS Systems Manager SecureString parameter to access AWS services. Retrieve the database credentials from a Systems Manager SecureString parameter.
- Reasoning: While using AWS Systems Manager (SSM) SecureString parameters for sensitive data such as database credentials is secure, retrieving the access key from a Systems Manager parameter is not a recommended practice. Access keys should be securely managed and provided through IAM roles, not manually retrieved from a parameter. Using access keys in this way can increase the risk of mismanagement and accidental exposure.
- Rejected because: Storing access keys in SSM parameters instead of using IAM roles is less secure and violates best practices for managing AWS credentials.
Option B: Launch the EC2 instances with an EC2 IAM role to access AWS services. Retrieve the database credentials from AWS Secrets Manager.
- Reasoning: This option provides the most secure and flexible solution:
- EC2 IAM role: Assigning an IAM role to EC2 instances is the best practice for securely granting permissions to access AWS services, including Secrets Manager.
- AWS Secrets Manager: Secrets Manager is specifically designed to store and manage sensitive credentials like database passwords. It integrates well with other AWS services and can automatically rotate credentials to improve security. This is the recommended approach for handling database credentials in a secure and scalable manner.
- This approach ensures that sensitive information such as database passwords is never hard-coded or stored insecurely.
- Selected because: It follows AWS security best practices by using IAM roles for service access and Secrets Manager for managi...
Author: Ethan Smith · Last updated May 17, 2026
The security team depends on AWS CloudTrail to detect sensitive security issues in the company's AWS account. The DevOps engineer needs a solution to auto-remediate CloudTrail being turned off in an AWS account...
To ensure the least downtime for CloudTrail log deliveries and automatically remediate the situation if CloudTrail is turned off, we need to evaluate the options based on their efficiency, speed, and ability to minimize downtime while maintaining security.
Option A: Create an Amazon EventBridge rule for the CloudTrail StopLogging event. Create an AWS Lambda function that uses the AWS SDK to call StartLogging on the ARN of the resource in which StopLogging was called. Add the Lambda function ARN as a target to the EventBridge rule.
- Reasoning: This solution is the most efficient because:
- EventBridge rule: It reacts immediately to the specific StopLogging event, meaning the function is triggered as soon as CloudTrail is stopped.
- Lambda function: It uses the AWS SDK to automatically start logging, minimizing downtime.
- The solution provides an event-driven response, so remediation happens automatically and promptly without requiring periodic checks.
- Best fit: This solution ensures near-zero downtime, and it's based on detecting the issue as it happens, which is highly efficient and quick.
Option B: Deploy the AWS-managed CloudTrail-enabled AWS Config rule, set with a periodic interval of 1 hour. Create an Amazon EventBridge rule for AWS Config rules compliance change. Create an AWS Lambda function that uses the AWS SDK to call StartLogging on the ARN of the resource in which StopLogging was called. Add the Lambda function ARN as a target to the EventBridge rule.
- Reasoning: This solution involves AWS Config, which can check compliance and track CloudTrail status. However:
- The 1-hour interval between AWS Config evaluations introduces a significant delay. The CloudTrail log might remain turned off for up to an hour before the system detects and remediates the issue.
- While it offers remediation, the lag in detection and response could result in a longer downtime for CloudTrail, violating the goal of minimizing downtime.
- Rejected because: The periodic check with a 1-hour interval leads to unacceptable downtime for CloudTrail.
Opti...
Author: Sara · Last updated May 17, 2026
A company uses AWS CodeArtifact to centrally store Python packages. The CodeArtifact repository is configured with the following repository policy:
A development team is building a new project in an account that is in an organization in AWS Organizations. The development team wants to use a Python library that has already been stored in the CodeArtifact repository in the organization. The development team uses AWS CodePipeline and AWS CodeBuild to build the new application. The CodeBuild job that the development team uses to build the application is configured to run in a VPC. Because of compliance requirements, the VPC has no internet connectivity.
The development team cre...
To resolve the issue where the development team cannot download the Python library from the CodeArtifact repository while building the application in a VPC with no internet connectivity, we need to address both the VPC configuration and permissions issues.
Let’s evaluate each option:
Option A: Create an Amazon S3 gateway endpoint. Update the route tables for the subnets that are running the CodeBuild job.
- Reasoning: CodeArtifact relies on Amazon S3 to store and retrieve packages, and an S3 gateway endpoint would be required to access S3 resources from within the VPC without internet access.
- However, CodeArtifact is not directly dependent on S3 gateway endpoints for VPC access. The issue is related to CodeArtifact endpoints, not S3 endpoints.
- Therefore, creating an S3 gateway endpoint is not a necessary step to resolve the issue of accessing CodeArtifact.
- Rejected because: The solution is not specific to CodeArtifact access; it would not address the core problem of CodeArtifact access within the VPC.
Option B: Update the repository policy's Principal statement to include the ARN of the role that the CodeBuild project uses.
- Reasoning: The CodeBuild service role needs permission to access the CodeArtifact repository. This can be done by updating the repository policy to explicitly grant access to the service role's ARN.
- The repository policy must specifically allow the CodeBuild role to interact with CodeArtifact, ensuring that permissions are in place for the job to download the Python package.
- Selected because: This step ensures the CodeBuild project has the required permissions to access the repository, which is a likely cause of the failure to retrieve the package.
Option C: Share the CodeArtifact repository with the organization by using AWS Resource Access Manager (AWS RAM).
- Reasoning: While AWS RAM can be used to share resources across accounts, this is typically used for cross-account sharing of resources (e.g., VPCs, subnets). CodeArtifact repositories...
Author: RadiantPhoenixX · Last updated May 17, 2026
A company uses a series of individual Amazon CloudFormation templates to deploy its multi-Region applications. These templates must be deployed in a specific order. The company is making more changes to the templates than previously expected and wants to deploy new templates more efficiently. Additionally, ...
To determine the best solution, let's break down each option in relation to the company's needs for efficient template deployment and notification of changes.
A) Create an AWS Lambda function to deploy the CloudFormation templates in the required order. Use stack policies to alert the data engineering team.
- Pros: Lambda could automate the deployment of CloudFormation templates in the required order. Stack policies could notify the data engineering team if any issues arise during stack updates.
- Cons: Writing and maintaining a custom Lambda function to manage the deployment order introduces complexity. It also doesn't naturally scale or manage templates across regions. Stack policies focus on stack-level changes but may not offer the granularity needed to track all template changes or updates.
- Rejected because: The manual intervention required for creating and managing the Lambda function adds overhead, and it doesn't scale well across multiple regions.
B) Host the CloudFormation templates in Amazon S3. Use Amazon S3 events to directly trigger CloudFormation updates and Amazon SNS notifications.
- Pros: Storing templates in Amazon S3 allows easy management, and Amazon S3 events can trigger CloudFormation updates. SNS notifications could notify the data engineering team about template changes.
- Cons: While S3 events are convenient for triggering CloudFormation stack updates, this setup does not ensure the correct order of deployments or handle multi-region complexities. Additionally, it doesn't inherently address the need for change management and notification granularity in a more structured way.
- Rejected because: This approach lacks the required order of deplo...
Author: Kai · Last updated May 17, 2026
A DevOps engineer has implemented a CI/CD pipeline to deploy an AWS CloudFormation template that provisions a web application. The web application consists of an Application Load Balancer (ALB), a target group, a launch template that uses an Amazon Linux 2 AMI, an Auto Scaling group of Amazon EC2 instances, a security group, and an Amazon RDS for MySQL database. The launch template includes user data that specifies a script to install and start the application.
The initial deployment of the application was successful. The DevOps engineer made changes to update the version of the application with the user data. The CI/CD pipeline has deployed a new version of the template. However, the health checks on the ALB are now failing. The health checks have marked all targets as unhealthy.
During investigation, the DevOps engineer notices that the CloudFormation stack has a st...
To ensure that the CloudFormation deployment will fail if the user data fails to successfully execute and the Apache web server does not start correctly, the best option should allow CloudFormation to detect and react to issues during instance setup or user data execution. Let's analyze each option in detail:
A) Use the cfn-signal helper script to signal success or failure to CloudFormation. Use the WaitOnResourceSignals update policy within the CloudFormation template. Set an appropriate timeout for the update policy.
- Pros: This approach allows the EC2 instances to send success or failure signals back to CloudFormation using the `cfn-signal` helper script in the user data script. By using the `WaitOnResourceSignals` update policy in the CloudFormation template, CloudFormation will wait for a signal indicating whether the user data script ran successfully before proceeding with stack creation or updates. This ensures that if the user data fails (e.g., Apache doesn't start), CloudFormation can roll back the deployment.
- Cons: It requires modifying the user data to include the signal, and if the signal is not sent (because of a failure), CloudFormation will correctly mark the deployment as failed, which could trigger a rollback.
- Best fit for the scenario: This is the most suitable solution because it directly addresses the issue of detecting user data script failures and ensures that CloudFormation won't proceed without confirmation of successful execution.
B) Create an Amazon CloudWatch alarm for the UnhealthyHostCount metric. Include an appropriate alarm threshold for the target group. Create an Amazon Simple Notification Service (Amazon SNS) topic as the target to signal success or failure to CloudFormation.
- Pros: This setup can notify the DevOps engineer if the ALB targets become unhealthy, and CloudWatch alarms can help detect if the web application is not functioning as expected.
- Cons: This option does not directly affect the CloudFormation stack status. CloudWatch alarms and SNS notifications won’t impact CloudFormation itself; they only alert on unhealthy instances. CloudFormation would not automatically fail the deployment based on this metric, so it doesn’t provide the same level of direct control.
- Rejected because: While useful for monitoring, it doesn't directly control or fail the CloudFormation dep...
Author: Noah · Last updated May 17, 2026
A company has a data ingestion application that runs across multiple AWS accounts. The accounts are in an organization in AWS Organizations. The company needs to monitor the application and consolidate access to the application. Currently, the company is running the application on Amazon EC2 instances from several Auto Scaling groups. The EC2 instances have no access to the internet because the data is sensitive. Engineers have deployed the necessary VPC endpoints. The EC2 instances run a custom AMI that is built specifically for the application.
To maintain and troubleshoot the application, system...
Let's analyze each solution based on the requirements:
Requirements:
1. Centralized and automated logins to EC2 instances.
2. Security team must be notified of any login activity.
3. No internet access for EC2 instances, but VPC endpoints are in place.
4. Access must be controlled and automated centrally.
A) Create an Amazon EventBridge rule to send notifications to the security team whenever a user logs in to an EC2 instance. Use EC2 Instance Connect to log in to the instances. Deploy Auto Scaling groups by using AWS CloudFormation. Use the cfn-init helper script to deploy appropriate VPC routes for external access. Rebuild the custom AMI so that the custom AMI includes AWS Systems Manager Agent.
- Pros:
- EventBridge can be used to send notifications to the security team.
- EC2 Instance Connect can enable access to the EC2 instances, which supports SSH-based login.
- Custom AMI can include Systems Manager Agent for centralized management.
- Cons:
- EC2 Instance Connect does not work well without internet access, as it requires internet connectivity for SSH-based access.
- Using EC2 Instance Connect and adding routes for external access contradicts the requirement of no internet access for the instances, even with VPC endpoints.
- The solution is overly complex due to the need for rebuilding the AMI and routing adjustments.
- Rejected because: EC2 Instance Connect does not align well with the restriction of no internet access for the EC2 instances. It also introduces complexity.
B) Deploy a NAT gateway and a bastion host that has internet access. Create a security group that allows incoming traffic on all the EC2 instances from the bastion host. Install AWS Systems Manager Agent on all the EC2 instances. Use Auto Scaling group lifecycle hooks for monitoring and auditing access. Use Systems Manager Session Manager to log in to the instances. Send logs to a log group in Amazon CloudWatch Logs. Export data to Amazon S3 for auditing. Send notifications to the security team by using S3 event notifications.
- Pros:
- The NAT gateway and bastion host provide access to the EC2 instances.
- Systems Manager Agent and Session Manager can provide a way to log in securely without requiring internet access.
- CloudWatch Logs can be used for auditing session activity.
- Security team notifications can be sent via S3 event notifications.
- Cons:
- The bastion host and NAT gateway violate the requirement of no internet access for the EC2 instances.
- The architecture is more complex than needed since we already have AWS Systems Manager as a viable alternative to direct SSH access.
- The need for external access (via NAT and bastion) conflicts with the security requirement.
- Rejected because: The solution requires internet access through a NAT gateway and bastion host, which violates the no-internet requirement.
C) Use EC2 Image Builder to rebuild the custom AMI. Include the most rece...
Author: FrozenWolf2022 · Last updated May 17, 2026
A company uses Amazon S3 to store proprietary information. The development team creates buckets for new projects on a daily basis. The security team wants to ensure that all existing and future buckets have encryption, logging, and versioning enabled. Additionally, no buck...
To meet the security team's requirements for ensuring all existing and future Amazon S3 buckets are properly configured with encryption, logging, versioning, and no public access, let's review each option and its relevance:
A) Enable AWS CloudTrail and configure automatic remediation using AWS Lambda.
- Pros:
- AWS CloudTrail can help monitor and log access to AWS resources, including S3 buckets.
- AWS Lambda can be used for custom remediation actions when security issues are detected.
- Cons:
- While CloudTrail logs API activities, it does not directly enforce the required bucket configurations. CloudTrail is better suited for monitoring and auditing, not for enforcement of bucket settings like encryption, versioning, and access controls.
- Using Lambda for remediation would require complex custom logic to continuously check and enforce configurations on all buckets, which introduces significant overhead and complexity.
- Rejected because: While useful for monitoring, CloudTrail and Lambda require more manual effort to enforce compliance and are not the most efficient tool for this particular use case.
B) Enable AWS Config rules and configure automatic remediation using AWS Systems Manager documents.
- Pros:
- AWS Config is designed to track resource configurations and ensure they are compliant with security standards. It allows you to define compliance rules for S3 buckets and other AWS resources.
- AWS Config can continuously monitor the state of your S3 buckets and ensure they meet the security team's requirements (encryption, logging, versioning, and no public access).
- AWS Config remediation can automatically trigger AWS Systems Manager Automation runbooks to fix non-compliant resources.
- Best fit for the scenario: AWS Config is the ideal tool for continuously monitoring and enforcing resource configurations. It provides specific rules for S3 buckets and can automatically remediate non-compliant buckets (e.g., enabling versioning, encryption, logging, and blocking public access). This meets the security team's requirements efficiently and is built to handle this exact use case.
- Selected option: This is the most direct and efficie...
Author: Elizabeth · Last updated May 17, 2026
A DevOps engineer is researching the least expensive way to implement an image batch processing cluster on AWS. The application cannot run in Docker containers and must run on Amazon EC2. The batch job stores checkpoint data on an NFS volume and can tolerate interruptions. Config...
Let's evaluate each option based on the key factors:
Key Factors:
1. Cost-Effectiveness: The solution needs to minimize cost while meeting the application's requirements.
2. Tolerates Interruptions: The batch job can handle interruptions, so utilizing Spot Instances is an optimal option.
3. NFS Volume for Checkpoint Data: The batch job needs to store checkpoint data on an NFS volume, which can be efficiently provided by Amazon EFS.
4. Time to Configure EC2 Instances: The EC2 instances take 30 minutes to configure manually, so automation of the configuration is preferred.
5. Temporary Nature of EC2 Instances: The batch job uses EC2 instances temporarily, so using Spot Instances (which are cheaper than On-Demand instances) is a suitable option.
A) Use Amazon EFS for checkpoint data. To complete the job, use an EC2 Auto Scaling group and an On-Demand pricing model to provision EC2 instances temporarily.
- Pros:
- Amazon EFS can provide a scalable and shared file system for storing checkpoint data.
- EC2 Auto Scaling can ensure the right number of EC2 instances are running for the batch job.
- Cons:
- On-Demand instances are significantly more expensive than Spot instances. Since the application can tolerate interruptions, Spot Instances would be a more cost-effective solution for a temporary workload.
- This solution does not take advantage of the lower-cost Spot Instances, which is crucial for minimizing costs.
- Rejected because: The On-Demand pricing model does not align with the requirement for a cost-effective solution when Spot Instances are available and appropriate for the job.
B) Use GlusterFS on EC2 instances for checkpoint data. To run the batch job, configure EC2 instances manually. When the job completes, shut down the instances manually.
- Pros:
- GlusterFS can provide a distributed file system across EC2 instances.
- Cons:
- Manual configuration of EC2 instances is inefficient and introduces potential for errors.
- Shutting down instances manually adds complexity and management overhead.
- GlusterFS may require more management compared to Amazon EFS, which is a managed service.
- The manual process also increases operational overhead and could result in unnecessary downtime during setup.
- Rejected because: The manual configuration and management of instances make this approach cumbersome. Additionally, GlusterFS is not as easily scalable or mana...
Author: IceDragon2023 · Last updated May 17, 2026
A company recently migrated its legacy application from on-premises to AWS. The application is hosted on Amazon EC2 instances behind an Application Load Balancer, which is behind Amazon API Gateway. The company wants to ensure users experience minimal disruptions during any deployment of a new version of the application. The company also wants to...
Let's evaluate each option based on the requirements of minimal disruption during deployments and the ability to quickly roll back changes.
Option A: Canary Release with API Gateway
- How it works: You deploy the new version of the application in a separate environment and configure API Gateway to use a canary release. In this setup, a small subset of traffic is routed to the new environment while the rest of the traffic continues to use the old version.
- Benefits: This option allows testing the new version with a small group of users, minimizing risk. If issues arise, traffic can be rerouted back to the original environment without disruption. It also provides an easy way to roll back if needed.
- Challenges: The main challenge is setting up and managing multiple environments. However, it still requires minimal changes to the existing application.
- When to use: Best when the application can be split into independent environments and you need gradual testing with a small group of users before full deployment.
Option B: Update DNS Alias Records
- How it works: The new version of the application is deployed in a parallel environment, and DNS alias records are updated to point to the new environment.
- Benefits: This is a straightforward approach, as updating DNS is simple.
- Challenges: DNS changes can take time to propagate (depending on TTL settings), leading to potential issues where users may still be directed to the old environment during the DNS propagation delay. It also doesn't allow for easy rollbacks or gradual traffic shifting.
- When to use: This method can be used for simple applications where the user base can handle DNS changes and there's no need for gradual deployment or rollback capabilities.
Option C: Canary Release with Target Groups and API Gateway
- How it works: A new version of the application is deployed in a separate target group behind the Application Load Balancer (ALB), and ...
Author: Noah · Last updated May 17, 2026
A company is storing 100 GB of log data in .csv format in an Amazon S3 bucket. SQL developers want to query this data and generate graphs to visualize it. The SQL developers also need an efficient, automated way to store metadata from the .csv file....
Let's evaluate each option based on the requirements: SQL developers querying CSV data and automated storage of metadata, with the goal of minimal effort.
Option A: Filter the data through AWS X-Ray
- How it works: AWS X-Ray is designed for tracing and debugging applications, particularly for performance and operational insights in distributed applications.
- Rejection: AWS X-Ray is not meant for querying or visualizing data stored in an S3 bucket. It is more relevant to monitoring and debugging application performance. This does not meet the requirements of querying and visualizing CSV data.
Option B: Filter the data through Amazon QuickSight
- How it works: Amazon QuickSight is a business intelligence (BI) tool used to create visualizations, reports, and dashboards. It can connect directly to S3, allowing users to generate graphs and visualize data stored in CSV files.
- Benefits: QuickSight can directly query data stored in S3, enabling the developers to visualize the data easily without needing to move it elsewhere. This is a good choice for visualization.
- Rejection: While QuickSight is excellent for visualizations, it does not provide querying capabilities with SQL. It would be good for the graphing portion but not ideal for SQL querying.
Option C: Query the data with Amazon Athena
- How it works: Amazon Athena is a serverless interactive query service that allows SQL queries to be run directly on data stored in S3. It uses standard SQL to query CSV files and integrates seamlessly with S3.
- Benefits: Athena is well-suited for querying large CSV files stored in S3 using SQL. It is fully managed and serverless, so it doesn't require provisioning or managing infrastructure. Athena also integrates with the AWS Glue Data Catalog, which is useful for managing metadata.
- Rejection: This option fits perfectly with the requirement for SQL querying but doesn't provide a direct solution for visualization.
Option D: Query the data with Amazon Redshift
- How it works: Amazon Redshift is a full...
Author: RadiantJaguar56 · Last updated May 17, 2026
A company deploys its corporate infrastructure on AWS across multiple AWS Regions and Availability Zones. The infrastructure is deployed on Amazon EC2 instances and connects with AWS IoT Greengrass devices. The company deploys additional resources on on-premises servers that are located in the corporate headquarters.
The company wants to reduce the overhead involved in maintaining and updating its resources. The company's DevOps team plans to use AWS Systems Manager to implement automated management and application of patches. The DevOps team confirms that Systems Manager is available in the Regions that the resources are deployed in. Systems ...
Let's evaluate each option based on the company's needs for automated patch and configuration management for EC2 instances, IoT devices, and on-premises servers using AWS Systems Manager.
Option A: Apply tags to all the EC2 instances, AWS IoT Greengrass devices, and on-premises servers. Use Systems Manager Session Manager to push patches to all the tagged devices.
- How it works: This option suggests using tags to group the resources and then using Session Manager to push patches.
- Rejection: Session Manager is primarily used for remote administration of instances, not for patching or configuration management. Systems Manager Patch Manager or Run Command is a better fit for automating patching tasks.
- When to use: This option is useful for administrative tasks but not suitable for patch management.
Option B: Use Systems Manager Run Command to schedule patching for the EC2 instances, AWS IoT Greengrass devices, and on-premises servers.
- How it works: Run Command allows you to execute commands on managed instances. It can be scheduled to apply patches.
- Rejection: While Run Command can be used to apply patches, it is not specifically designed for automated patch management like Patch Manager. Run Command provides more granular control but doesn't offer the out-of-the-box patching functionality or compliance tracking provided by Patch Manager.
- When to use: Run Command can be useful for custom patching scripts or when more control over commands is needed, but Patch Manager is a more efficient and automated solution.
Option C: Use Systems Manager Patch Manager to schedule patching for the EC2 instances, AWS IoT Greengrass devices, and on-premises servers as a Systems Manager maintenance window task.
- How it works: Patch Manager is specifically designed for automated patch management. It allows you to define patch baselines, schedules, and maintenance windows for EC2 instances and on-premises servers. You can automate patching across multiple environments.
- Benefits: This is the ideal solution for automated patching. Patch Manager supports scheduling, maintenance windows, and compliance tracking. It also integrates with Run Command for additional automation.
- Rejection: This is a strong solution and should be used over Run Command for automated patching. It directly addresses the need for patching across AWS and on-premises resources.
Option D: Configure Amazon EventBridge to monitor Systems Manager Patch Manager for updates to patch baselines. Associate Systems Manager Run Command with the event to initiate a patch action for all EC2 instances, AWS IoT Greengrass devices, and on-premises servers.
- How it works: This option i...
Author: Lucas · Last updated May 17, 2026
A company is testing a web application that runs on Amazon EC2 instances behind an Application Load Balancer. The instances run in an Auto Scaling group across multiple Availability Zones. The company uses a blue/green deployment process with immutable instances when deploying new software.
During testing, users are being automatically logged out of the application at random times. Testers also report that, when a new version of the application is deployed, all users are logged...
To ensure users remain logged in across scaling events and application deployments, we need to address session management in a way that maintains session continuity, even when EC2 instances are replaced, scaled, or upgraded. Let's evaluate each option.
Option A: Enable smart sessions on the load balancer and modify the application to check for an existing session.
- How it works: This option refers to "sticky sessions" (also known as session affinity) where the Application Load Balancer (ALB) directs requests from the same user to the same instance. This ensures session continuity as long as the session persists on the same EC2 instance.
- Rejection: Sticky sessions are not ideal in this scenario because if an EC2 instance is replaced or terminated (as in immutable deployments), the user would be logged out since their session is tied to a specific instance. While sticky sessions help in some use cases, they don't work well in blue/green deployments where instances are replaced frequently, leading to user logout.
Option B: Enable session sharing on the load balancer and modify the application to read from the session store.
- How it works: This option seems to refer to sharing session data across instances through a centralized session store. It suggests that the load balancer would use a session store to ensure that session data is accessible regardless of which instance serves the request.
- Rejection: The load balancer doesn't directly manage session sharing. While this concept sounds good in theory, it would require significant application changes to handle session storage and sharing externally, adding complexity. Additionally, load balancers do not manage session state directly but rely on backend storage for that.
Option C: Store user session information in an Amazon S3 bucket and modify the application to read session information from the bucket.
- How it works: Storing session data in Amazon S3 would allow persistent storage ...
Author: ElectricLionX · Last updated May 17, 2026
A DevOps engineer needs to configure a blue/green deployment for an existing three-tier application. The application runs on Amazon EC2 instances and uses an Amazon RDS database. The EC2 instances run behind an Application Load Balancer (ALB) and are in an Auto Scaling group.
The DevOps engineer has created a launch template and an Auto Scaling group for the blue environment. The DevOps engineer also has created a launch template and an Auto Scaling group for the green environment. Each Auto Scaling group deploys to a matching blue or green target group. The target group also specifies which software, blue or green, gets loaded on the EC2 instances. The ALB can be configured to send traffic to the blue environment's target group or the green environment...
To meet the requirements for a blue/green deployment, where traffic should be moved all at once from the blue environment to the green environment, we need to consider a strategy that ensures smooth traffic transition and minimal disruption to the application.
Option A: Start a rolling restart of the Auto Scaling group for the green environment to deploy the new software on the green environment’s EC2 instances. When the rolling restart is complete, use an AWS CLI command to update the ALB to send traffic to the green environment’s target group.
- How it works: This option suggests first deploying the new software on the green environment by performing a rolling restart of the EC2 instances in the green environment. After the new software is deployed, the traffic is switched to the green target group in the ALB.
- Rejection: The blue/green deployment model requires traffic to be switched to the green environment all at once after the green environment is fully ready. A rolling restart might create a gap in traffic handling or lead to traffic being directed to partially updated EC2 instances. It doesn't align well with the requirement for moving traffic all at once.
Option B: Use an AWS CLI command to update the ALB to send traffic to the green environment’s target group. Then start a rolling restart of the Auto Scaling group for the green environment to deploy the new software on the green environment’s EC2 instances.
- How it works: In this option, the ALB is updated to send traffic to the green environment before the new software is deployed on the green EC2 instances. Once traffic is moved, the green environment's EC2 instances are updated with a rolling restart.
- Rejection: Moving traffic to the green environment before the new software is fully deployed on the EC2 instances in the green environment can result in an inconsistent application state. The green environment should be fully ready (with the new software deployed) before traffic is switched.
Option C: Update the launch template to deploy the green environment’s software on the blue environment’s EC2 instances. Keep ...
Author: Ravi Patel · Last updated May 17, 2026
A company is building a new pipeline by using AWS CodePipeline and AWS CodeBuild in a build account. The pipeline consists of two stages. The first stage is a CodeBuild job to build and package an AWS Lambda function. The second stage consists of deployment actions that operate on two different AWS accounts: a development environment account and a production environment account. The deployment stages use the AWS CloudFormation action that CodePipeline invokes to deploy the infrastructure that the Lambda function requires.
A DevOps engineer creates the CodePipeline pipeline and configures the pipeline to encrypt build artifacts by using the AWS Key Management Serv...
To resolve the access denied error that occurs during the CloudFormation deployment actions in this scenario, the DevOps engineer needs to address the permissions related to the encrypted artifacts stored in S3 and the actions performed by CodePipeline and CloudFormation across different AWS accounts. Let's break down the options and reasoning for selecting the right ones:
Option A: Create an S3 bucket in each AWS account for the artifacts. Allow the pipeline to write to the S3 buckets. Create a CodePipeline S3 action to copy the artifacts to the S3 bucket in each AWS account. Update the CloudFormation actions to reference the artifacts S3 bucket in the production account.
- Analysis: This option introduces unnecessary complexity by requiring the creation of separate S3 buckets for each environment and manually copying artifacts between accounts. It doesn't address the underlying issue of permissions related to the encrypted artifacts directly.
- Conclusion: This option is not ideal since it adds complexity and doesn't directly address the problem with KMS encryption or IAM role permissions.
Option B: Create a customer-managed KMS key. Configure the KMS key policy to allow the IAM roles used by the CloudFormation action to perform decrypt operations. Modify the pipeline to use the customer-managed KMS key to encrypt artifacts.
- Analysis: This option involves creating a customer-managed KMS key and setting up the key policy to allow the CloudFormation action IAM roles to decrypt the artifacts. While this solution might address encryption/decryption permissions, it does not necessarily address cross-account permissions between CodePipeline and CloudFormation or the need for artifact access from the S3 bucket. Additionally, modifying the pipeline to use the customer-managed KMS key adds overhead.
- Conclusion: This option is somewhat viable but adds unnecessary complexity and is not the most streamlined solution.
Option C: Create an AWS-managed KMS key. Configure the KMS key policy to allow the development account and the production account to perform decrypt operations. Modify the pipeline to use the KMS key to encrypt artifacts.
- Analysis: AWS-managed keys (like `aws/s3`) are automatically available and intended for use with services like S3. Modifying the KMS key policy to allow cross-account decryption permissions can help address the permissions issue when the pipeline moves artifacts between accounts. This solution is much simpler and use...
Author: Ahmed97 · Last updated May 17, 2026
A company is using an organization in AWS Organizations to manage multiple AWS accounts. The company's development team wants to use AWS Lambda functions to meet resiliency requirements and is rewriting all applications to work with Lambda functions that are deployed in a VPC. The development team is using Amazon Elastic File System (Amazon EFS) as shared storage in Account A in the organization.
The company wants to continue to use Amazon EFS with Lambda. Company policy requires all serverless projects to be deployed in Account B.
A DevOps engine...
To meet the company's requirements and ensure that the Lambda functions in Account B can access Amazon EFS data in Account A, the DevOps engineer must address the following considerations:
Option A: Update the EFS file system policy to provide Account B with access to mount and write to the EFS file system in Account A.
- Analysis: EFS access is controlled through resource-based policies that define which accounts, VPCs, or IAM roles can access the file system. Since Account B must access the EFS file system in Account A, updating the EFS file system policy to grant Account B the necessary permissions is essential.
- Conclusion: This is the correct action to allow Account B's Lambda functions to access the EFS file system in Account A. The file system policy needs to be updated to allow mounting and reading/writing to the file system.
Option B: Create SCPs to set permission guardrails with fine-grained control for Amazon EFS.
- Analysis: Service Control Policies (SCPs) are used in AWS Organizations to define guardrails for what actions can be performed across accounts. While SCPs can restrict or grant permissions at a high level, they are not the appropriate tool for granting EFS-specific access, which is managed through resource-based policies, not SCPs.
- Conclusion: SCPs are not needed for this specific use case because EFS access control is managed at the resource level (via the file system policy), not through organization-wide guardrails.
Option C: Create a new EFS file system in Account B. Use AWS Database Migration Service (AWS DMS) to keep data from Account A and Account B synchronized.
- Analysis: While this option would technically create a way to sync data between accounts, it introduces unnecessary complexity. The goal is to allow Lambda functions in Account B to access data in Account A directly via the existing EFS access point, not to create a separate EFS file system or use DMS.
- Conclusion: This option is overly complicated and unnecessary, as the problem can be solved by correctly configuring access between the accounts rather than migrating or synchronizing data.
Option D: Update the Lambda execution roles with permission to access the VPC and the EFS file system.
- Analysis: Lambda functions running in a VPC must have the correct IA...
Author: FrozenWolf2022 · Last updated May 17, 2026
A media company has several thousand Amazon EC2 instances in an AWS account. The company is using Slack and a shared email inbox for team communications and important updates. A DevOps engineer needs to send all AWS-scheduled EC2 maintenance notifications to the Slack channel and the ...
To meet the requirements of sending AWS-scheduled EC2 maintenance notifications, including the instance's Name and Owner tags, to a Slack channel and a shared email inbox, let's evaluate each solution option:
Option A: Integrate AWS Trusted Advisor with AWS Config. Configure a custom AWS Config rule to invoke an AWS Lambda function to publish notifications to an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe a Slack channel endpoint and the shared inbox to the topic.
- Analysis: AWS Trusted Advisor does not directly manage EC2 maintenance notifications, and AWS Config rules are typically used for compliance and configuration monitoring. Using AWS Config with Trusted Advisor for EC2 maintenance notifications is not an ideal solution, as it is not specifically designed to handle AWS Health or EC2 events.
- Conclusion: This option is not suitable because Trusted Advisor and AWS Config are not intended for handling EC2 maintenance notifications.
Option B: Use Amazon EventBridge to monitor for AWS Health events. Configure the maintenance events to target an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe an AWS Lambda function to the SNS topic to send notifications to the Slack channel and the shared inbox.
- Analysis: Amazon EventBridge can monitor AWS Health events, which include EC2 maintenance notifications. By configuring EventBridge to capture these events and forwarding them to an SNS topic, you can then use a Lambda function to forward notifications to the Slack channel and the shared inbox. This method can be customized to include the EC2 instance's Name and Owner tags by using the EC2 metadata or AWS API calls from within the Lambda function.
- Conclusion: This is the best solution because it directly integrates with AWS Health, handles EC2 maintenance notifications, and allows customization (e.g., adding tags) through Lambda.
Option C: Create an AWS Lambda function that sends EC2 maintenance notifications ...
Author: Stella · Last updated May 17, 2026
An AWS CodePipeline pipeline has implemented a code release process. The pipeline is integrated with AWS CodeDeploy to deploy versions of an application to multiple Amazon EC2 instances for each CodePipeline stage.
During a recent deployment, the pipeline failed due to a CodeDeploy issue. The DevOps team wants to improve monitoring and not...
To improve monitoring and notifications during the deployment process in AWS CodePipeline and CodeDeploy, the DevOps engineer needs to implement a solution that provides real-time notifications when deployment issues occur. The solution should focus on the integration of monitoring services, event-driven notifications, and automated responses.
Option A: Implement Amazon CloudWatch Logs for CodePipeline and CodeDeploy, create an AWS Config rule to evaluate code deployment issues, and create an Amazon Simple Notification Service (Amazon SNS) topic to notify stakeholders of deployment issues.
- Analysis: While CloudWatch Logs can capture logs from both CodePipeline and CodeDeploy, AWS Config is primarily designed for configuration compliance and monitoring, not for real-time event tracking or notification of deployment issues. AWS Config rules would not be the best fit for monitoring real-time CodeDeploy failures, as they are intended for assessing configuration drift and compliance.
- Conclusion: AWS Config is not appropriate for this real-time monitoring and notification use case.
Option B: Implement Amazon EventBridge for CodePipeline and CodeDeploy, create an AWS Lambda function to evaluate code deployment issues, and create an Amazon Simple Notification Service (Amazon SNS) topic to notify stakeholders of deployment issues.
- Analysis: Amazon EventBridge is well-suited for monitoring events in AWS services like CodePipeline and CodeDeploy. EventBridge allows you to capture real-time events such as failed deployments. By triggering a Lambda function from EventBridge, you can easily process these events and send notifications to an SNS topic. This solution is highly scalable, event-driven, and can be customized to fit specific requirements, such as notifying stakeholders when deployment issues are detected.
- Conclusion: This is the best option, as it uses EventBridge to monitor real-time deployment events and SN...
Author: Grace · Last updated May 17, 2026
A global company manages multiple AWS accounts by using AWS Control Tower. The company hosts internal applications and public applications.
Each application team in the company has its own AWS account for application hosting. The accounts are consolidated in an organization in AWS Organizations. One of the AWS Control Tower member accounts serves as a centralized DevOps account with CI/CD pipelines that application teams use to deploy applications to their respective target AWS accounts. An IAM role for deployment exists in the centralized DevOps account.
An application team is attempting to deploy its application to an Amazon Elastic Kubernetes Service (Amazon EKS) cluster in an application AWS account. An IAM role for deployment exists in the application AWS account...
The error occurs when the deployment process in the centralized DevOps account tries to access the Amazon EKS cluster in the application AWS account. This is likely due to missing permissions and/or improper cross-account role assumption. The solution must address the cross-account access issues between the centralized DevOps account, the application account, and the EKS cluster.
Option A: Configure the application account's deployment IAM role to have a trust relationship with the centralized DevOps account. Configure the trust relationship to allow the `sts:AssumeRole` action. Configure the application account's deployment IAM role to have the required access to the EKS cluster. Configure the EKS cluster `aws-auth` ConfigMap to map the role to the appropriate system permissions.
- Analysis: This option correctly addresses the need to establish a trust relationship between the application account's deployment IAM role and the centralized DevOps account. Allowing the `sts:AssumeRole` action in the trust policy enables the DevOps account to assume the deployment role in the application account. Additionally, granting the necessary permissions to the EKS cluster and configuring the `aws-auth` ConfigMap ensures the role is mapped with the necessary EKS permissions.
- Conclusion: This option is the most suitable as it covers the necessary cross-account trust and EKS access configuration.
Option B: Configure the centralized DevOps account's deployment IAM role to have a trust relationship with the application account. Configure the trust relationship to allow the `sts:AssumeRole` action. Configure the centralized DevOps account's deployment IAM role to allow the required access to CodeBuild.
- Analysis: While this option is focused on allowing the DevOps role to assume a role in the application account, the issue is specifically related to accessing the EKS cluster, not CodeBuild. The error occurs during the deployment to EKS, so addressing the access permissions to EKS is more relevant than ensuring CodeBuild permissions.
- Conclusion: This option is not ideal because it focuses on CodeBuild access and doesn't address the permissions needed to conn...
Author: Deepak · Last updated May 17, 2026
A highly regulated company has a policy that DevOps engineers should not log in to their Amazon EC2 instances except in emergencies. If a DevOps engineer does log in, the security team must be notifie...
To meet the requirements of notifying the security team within 15 minutes of a DevOps engineer logging into an EC2 instance, we need to consider solutions that allow for:
1. Monitoring EC2 instance login activity.
2. Real-time notification of login events within the 15-minute window.
Let’s go through the options:
Option A: Install the Amazon Inspector agent on each EC2 instance. Subscribe to Amazon EventBridge notifications. Invoke an AWS Lambda function to check if a message is about user logins. If it is, send a notification to the security team using Amazon SNS.
- Analysis: Amazon Inspector is designed for security assessments, not for monitoring user logins. Although it could be part of a broader security posture, it is not typically used for monitoring login activity specifically. EventBridge could be used to detect events, but using Amazon Inspector for logins is not ideal for the specific requirement of detecting login events.
- Why Rejected: It involves using Amazon Inspector, which doesn't specifically target login activity.
Option B: Install the Amazon CloudWatch agent on each EC2 instance. Configure the agent to push all logs to Amazon CloudWatch Logs and set up a CloudWatch metric filter that searches for user logins. If a login is found, send a notification to the security team using Amazon SNS.
- Analysis: CloudWatch is highly suitable for monitoring and capturing logs. The CloudWatch agent can push logs to CloudWatch Logs, and metric filters can be created to search for login events. This approach can be effective for real-time notifications.
- Why Rejected: While this is a good option, the key challenge is ensuring that all relevant login data is captured in the logs, especially if it’s not part of the default logs. Also, CloudWatch Logs might not capture logins as promptly as other more specialized solutions like C...
Author: Emma · Last updated May 17, 2026
A company updated the AWS CloudFormation template for a critical business application. The stack update process failed due to an error in the updated template, and AWS CloudFormation automatically began the stack rollback process. Later, a DevOps engineer discovered that the application was still unavailable and that the stack was in the UPDATE_ROLLB...
When a stack update fails and AWS CloudFormation enters the UPDATE_ROLLBACK_FAILED state, the rollback process cannot complete due to errors in the template, resource inconsistencies, or other issues. The DevOps engineer must resolve the issue and guide the rollback to completion.
Option A: Attach the AWSCloudFormationFullAccess IAM policy to the AWS CloudFormation role.
- Analysis: Attaching the AWSCloudFormationFullAccess IAM policy could grant necessary permissions, but it is unlikely to directly resolve the issue related to the stack being in the UPDATE_ROLLBACK_FAILED state. The problem is typically related to resource mismatches or template issues, not a permissions issue.
- Conclusion: While permissions are important, this action is unlikely to solve the root issue directly and does not address the failed rollback or the resources that need to be corrected.
Option B: Automatically recover the stack resources by using AWS CloudFormation drift detection.
- Analysis: AWS CloudFormation drift detection can help identify resources that have drifted from the desired state defined in the stack. However, drift detection does not automatically fix the rollback failure or resolve the issues that caused the stack update to fail. It’s useful for understanding which resources have changed outside of CloudFormation's management, but it does not recover the stack from the UPDATE_ROLLBACK_FAILED state.
- Conclusion: This option is not effective for recovering a stack from the UPDATE_ROLLBACK_FAILED state and does not resolve the rollback failure directly.
Option C: Issue a ContinueUpdateRollback command from the AWS CloudFormation console or the AWS CLI.
- Analysis: The ContinueUpdateRollback command is the most direct method to resume and complete the rollback process after a failure. ...
Author: Emily · Last updated May 17, 2026
A development team manually builds an artifact locally and then places it in an Amazon S3 bucket. The application has a local cache that must be cleared when a deployment occurs. The team runs a command to do this, downloads the artifact from Amazon S3, and unzips the artifact to complete the deployment.
A DevOps team wants to migrate to a CI/CD process and build in checks to stop and roll back t...
The goal is to transition from a manual process to a CI/CD pipeline that automates building, deploying, and monitoring the application, while ensuring that failure points can be tracked and rollback mechanisms are in place. Let's evaluate each option based on these requirements.
Option A: Allow developers to check the code into a code repository. Using Amazon EventBridge, on every pull into the main branch, invoke an AWS Lambda function to build the artifact and store it in Amazon S3.
- Analysis: This approach automates the build process using a code repository (e.g., GitHub, CodeCommit). When changes are pushed to the main branch, EventBridge can trigger a Lambda function to build the artifact and store it in S3. However, EventBridge is not ideal for this scenario because it doesn't provide built-in rollback or tracking of deployment progression. Lambda can handle building but doesn't handle deployment or managing the application lifecycle (such as clearing caches).
- Conclusion: While this could work for building the artifact, it lacks the integration needed for deployment, rollback, and monitoring, so it is not the best fit for this requirement.
Option B: Create a custom script to clear the cache. Specify the script in the BeforeInstall lifecycle hook in the AppSpec file.
- Analysis: This is a good approach to handle the cache clearing before the deployment begins, as AWS CodeDeploy allows you to specify hooks in the AppSpec file. The BeforeInstall hook can be used to clear the cache to ensure that the application starts with a clean slate after the deployment. However, this does not address the CI/CD pipeline or tracking of the deployment's progress.
- Conclusion: This is a helpful step but lacks the full CI/CD integration and the ability to track the deployment status, so it's useful for cache clearing but not enough for full automation.
Option C: Create user data for each Amazon EC2 instance that contains the clear cache script. Once deployed, test the application. If it is not successful, deploy it again.
- Analysis: User data scripts can be used to run the cache clearing on EC2 instances, but this would only run when the instances are launched or rebooted. It doesn't provide proper deployment tracking, failure handling, or rollback mechanisms. Additionally, simply redeploying on failure without tracking the issue or using a more structured deployment service like CodeDeploy can lead to instability.
- Conclusion: This approach could help with clearing caches, but it doesn’t provide the necessary CI/CD process or tracking mechanisms, and it risks re-deploying wit...
Author: Kai · Last updated May 17, 2026
A DevOps engineer is working on a project that is hosted on Amazon Linux and has failed a security review. The DevOps manager has been asked to review the company buildspec.yaml file for an AWS CodeBuild project and provide recommendations. The buildspec.yaml file is config...
In reviewing the buildspec.yaml file for an AWS CodeBuild project, there are several important security best practices to consider. Let's evaluate the given options based on AWS security recommendations.
Option A: Add a post-build command to remove the temporary files from the container before termination to ensure they cannot be seen by other CodeBuild users.
- Analysis: AWS CodeBuild runs each build in a Docker container, and temporary files can sometimes be left behind when the build is complete. These files might contain sensitive data, which could be accessible to other builds or users in some scenarios if not properly cleaned up. Adding a post-build command to delete any temporary files ensures that sensitive data is not left in the build environment.
- Conclusion: This is a good security practice to ensure that no sensitive data remains accessible after the build completes. This action ensures that the container is cleaned up properly, which is vital in multi-user environments.
Option B: Update the CodeBuild project role with the necessary permissions and then remove the AWS credentials from the environment variable.
- Analysis: AWS credentials should never be hardcoded into environment variables or source code, as this exposes sensitive data. Instead, AWS Identity and Access Management (IAM) roles should be used to grant the necessary permissions for accessing AWS resources. CodeBuild should rely on IAM roles for permissions rather than storing credentials in environment variables, which is more secure and follows AWS security best practices.
- Conclusion: This is a critical recommendation because storing AWS credentials in environment variables can lead to accidental exposure of sensitive data. Using IAM roles is the proper way to handle permissions securely.
Option C: Store the DB_PASSWORD as a SecureString value in AWS Systems Manager Parameter Store and then remove the DB_PASSWORD from the environment variables.
- Analysis: Sensitive information like database passwords should be stored securely. AWS Systems Manager Parameter Store provides the option to store parameters securely as SecureString, which encrypts the values at rest. Storing sensitive data in environment variables is not recommended because these values can be easily retrieved. Moving the DB_PASSWORD to Parameter Store enhances security.
- Conclusion: This is a good security practice, as it ensures the password is securely stored and managed, reducing the risk of accide...
Author: Henry · Last updated May 17, 2026
A company has a legacy application. A DevOps engineer needs to automate the process of building the deployable artifact for the legacy application. The solution must store the deployable artifact in an existing Amazon S3 bucket for future deploym...
Analysis of Options
Option A: Create a custom Docker image that contains all the dependencies for the legacy application. Store the custom Docker image in a new Amazon Elastic Container Registry (Amazon ECR) repository. Configure a new AWS CodeBuild project to use the custom Docker image to build the deployable artifact and to save the artifact to the S3 bucket.
- Reasoning: Using AWS CodeBuild in this option leverages a fully managed service for building the deployable artifact. By using a custom Docker image that contains all the dependencies, the environment is predictable and consistent across builds. AWS CodeBuild can easily output the artifact to Amazon S3 for storage. CodeBuild is a serverless service, meaning it is scalable, cost-efficient, and eliminates the need for managing servers or instances.
- Advantages: This is highly operationally efficient because it abstracts infrastructure management, scales automatically, and integrates directly with other AWS services like S3 for artifact storage.
- Conclusion: This is the most efficient and modern approach to automating the build process for the legacy application.
Option B: Launch a new Amazon EC2 instance. Install all the dependencies for the legacy application on the EC2 instance. Use the EC2 instance to build the deployable artifact and to save the artifact to the S3 bucket.
- Reasoning: This solution involves manually provisioning an EC2 instance, installing dependencies, and then managing the build and artifact storage process. This approach requires more management overhead for infrastructure (like scaling, patching, and instance management) compared to serverless solutions like CodeBuild.
- Disadvantages: While EC2 gives full control, it introduces significant operational overhead in terms of provisioning, maintaining, and ensuring that the build environment is correct and up-to-date.
- Conclusion: This option is not the most efficient because it involves more manual management and less automation, which increases operational overhead.
Option C: Create a custom EC2 Image Builder image. Install all the dependencies for the legacy application on the image. Launch a new Amazon EC2 instance from the ...
Author: Layla · Last updated May 17, 2026
A company builds a container image in an AWS CodeBuild project by running Docker commands. After the container image is built, the CodeBuild project uploads the container image to an Amazon S3 bucket. The CodeBuild project has an IAM service role that has permissions to access the S3 bucket.
A DevOps engineer needs to replace the S3 bucket with an Amazon Elastic Container Registry (Amazon ECR) repository to store the container images. The DevOps engineer creates an ECR private image repository in the same AWS Region of the CodeBuild project. The DevOps engineer adjusts the IAM service role with the permissions that are necessary to work with the new ECR repository. The DevOps engineer also places new repos...
To resolve the issue where the AWS CodeBuild project fails to access the Amazon Elastic Container Registry (ECR) repository, let’s evaluate each option:
Option A:
Update the buildspec.yml file to log in to the ECR repository by using the `aws ecr get-login-password` AWS CLI command to obtain an authentication token. Update the `docker login` command to use the authentication token to access the ECR repository.
Explanation:
The AWS CLI command `aws ecr get-login-password` is used to retrieve an authentication token for logging into ECR, which is required before performing any Docker operations like pushing or pulling images. By updating the buildspec.yml file to include this authentication process, CodeBuild will be able to log in and authenticate with the ECR repository, allowing the push command to succeed.
Why other options are rejected:
- Option B is rejected because using an environment variable of type `SECRETS_MANAGER` to store the IAM role ARN is unnecessary and doesn’t...
Author: Harper · Last updated May 17, 2026
A company manually provisions IAM access for its employees. The company wants to replace the manual process with an automated process. The company has an existing Active Directory system configured with an external SAML 2.0 identity provider (IdP).
The company wants employees to use their existing corporate credentials to access AWS. The groups from the existing Active Directory system must be available for permission management in AWS Identity and Access Management (IAM)...
To meet the requirements of automating IAM access for employees with existing Active Directory (AD) credentials and managing permissions through AWS IAM Identity Center (AWS SSO), let’s evaluate the options:
Option A:
Configure an external IdP as an identity source. Configure automatic provisioning of users and groups by using the SCIM protocol.
Explanation:
- SCIM (System for Cross-domain Identity Management) is a protocol designed for automating the exchange of identity data between identity providers (IdPs) and service providers. While SCIM is useful for provisioning and managing users and groups across multiple platforms, it requires support for SCIM from both the IdP and the service provider (in this case, AWS IAM Identity Center).
- However, SCIM typically applies to IdPs that support it and is often used with cloud-native identity providers rather than a traditional Active Directory system.
Why other options are rejected:
- Option B is rejected because AWS Directory Service is not typically used in a scenario where the company already has an existing exte...
Author: Noah · Last updated May 17, 2026
A company is using AWS to run digital workloads. Each application team in the company has its own AWS account for application hosting. The accounts are consolidated in an organization in AWS Organizations.
The company wants to enforce security standards across the entire organization. To avoid noncompliance because of security misconfiguration, the company has enforced the use of AWS CloudFormation. A production support team can modify resources in the production environment by using the AWS Management Console to troubleshoot and resolve application-related issues.
A DevOps engineer must implement a solution to identify in near real time any AWS service misconfiguration that results in n...
To meet the company's requirements for enforcing security standards, identifying noncompliant resources, and automating remediation in near real-time with centralized tracking, let’s evaluate each solution option:
Option A:
Use CloudFormation drift detection to identify noncompliant resources. Use drift detection events from CloudFormation to invoke an AWS Lambda function for remediation. Configure the Lambda function to publish logs to an Amazon CloudWatch Logs log group. Configure an Amazon CloudWatch dashboard to use the log group for tracking.
Explanation:
- CloudFormation Drift Detection identifies any discrepancies between the actual configuration of resources and the configuration defined in the CloudFormation template.
- AWS Lambda can be invoked for remediation when drift is detected, and logs can be sent to CloudWatch for tracking and monitoring.
- CloudWatch Dashboard can be used to create a centralized dashboard to monitor drift events in near real-time.
- This solution is highly integrated with CloudFormation and focuses on drift detection, which is ideal for tracking and resolving noncompliant resources based on infrastructure-as-code configurations.
Why other options are rejected:
- Option B is reject...
