Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company uses AWS Organizations to manage its AWS accounts. The organization root has an OU that is named Environments. The Environments OU has two child OUs that are named Development and Production, respectively.
The Environments OU and the child OUs have the default FullAWSAccess policy in place. A DevOps engineer plans to remove the FullAWSAccess policy from t...
Let’s carefully analyze the scenario and the available options:
Scenario Breakdown:
- The company uses AWS Organizations with a root OU called Environments, containing two child OUs: Development and Production.
- The FullAWSAccess policy is applied to both the Environments OU and its child OUs by default.
- The DevOps engineer plans to replace the FullAWSAccess policy for the Development OU with a new policy that allows all actions on Amazon EC2 resources.
Key Considerations:
- The FullAWSAccess policy gives unrestricted access to all AWS resources, allowing all actions on all resources across the AWS account.
- When the new policy replaces FullAWSAccess, the policy will limit the permissions to only Amazon EC2 actions and will deny all other actions, as the new policy only permits EC2 actions.
Option Evaluation:
A) All users in the Development OU will be allowed all API actions on all resources.
- This option is incorrect because the new policy specifically grants access to Amazon EC2 resources only, not all resources. Therefore, it will not provide full access to all API actions across all resources.
B) All ...
Author: FrozenWolf2022 · Last updated May 17, 2026
A company is examining its disaster recovery capability and wants the ability to switch over its daily operations to a secondary AWS Region. The company uses AWS CodeCommit as a source control tool in the primary Region.
A DevOps engineer must provide the capability for the company to develop code in the secondary Region. If the company needs to ...
To meet the requirements of disaster recovery and enabling the ability to switch operations to a secondary AWS Region, we need a solution that allows code to be developed and committed in the secondary Region while mirroring or syncing the primary Region’s CodeCommit repository.
Option Evaluation:
A) Create a CodeCommit repository in the secondary Region. Create an AWS CodeBuild project to perform a Git mirror operation of the primary Region's CodeCommit repository to the secondary Region's CodeCommit repository. Create an AWS Lambda function that invokes the CodeBuild project. Create an Amazon EventBridge rule that reacts to merge events in the primary Region's CodeCommit repository. Configure the EventBridge rule to invoke the Lambda function.
Explanation:
- This option is valid. By creating a CodeCommit repository in the secondary Region and setting up a Git mirror operation using CodeBuild, it ensures that the repository is copied over. The Lambda function and EventBridge rule ensure that any changes or merges in the primary Region's CodeCommit repository trigger the synchronization process to the secondary Region’s repository.
- This allows the ability to switch operations to the secondary Region by using the mirrored repository, with minimal impact to the developers. They can add the secondary Region's repository as an additional remote URL in their Git configuration, as required.
B) Create an Amazon S3 bucket in the secondary Region. Create an AWS Fargate task to perform a Git mirror operation of the primary Region's CodeCommit repository and copy the result to the S3 bucket. Create an AWS Lambda function that initiates the Fargate task. Create an Amazon EventBridge rule that reacts to merge events in the CodeCommit repository. Configure the EventBridge rule to invoke the Lambda function.
Explanation:
- This option introduces unnecessary complexity by using an S3 bucket as an intermediary and requires the use of Fargate tasks, which is not an ideal solution ...
Author: CrimsonViperX · Last updated May 17, 2026
A DevOps team is merging code revisions for an application that uses an Amazon RDS Multi-AZ DB cluster for its production database. The DevOps team uses continuous integration to periodically verify that the application works. The DevOps team needs to test the ch...
In this scenario, the goal is to test changes to the application without directly impacting the production database, and ensure that proper testing is done before deployment to production. Let’s analyze each option in detail:
A) Use a buildspec file in AWS CodeBuild to restore the DB cluster from a snapshot of the production database, run integration tests, and drop the restored database after verification.
- Explanation: This option involves creating a separate instance of the production database by restoring it from a snapshot. It allows the DevOps team to run integration tests on a real-world version of the database. After the tests, the restored database is discarded.
- Pros: It isolates the testing environment from the production system, ensuring that no changes are made to the live database. It provides a realistic testing environment.
- Cons: The process could be time-consuming due to the snapshot restore and the need to tear down the environment afterward. Costs could also increase due to the need for additional resources for this temporary database.
- Conclusion: This option ensures safety and isolation of the production environment, which is critical for testing changes before deployment.
B) Deploy the application to production. Configure an audit log of data control language (DCL) operations to capture database activities to perform if verification fails.
- Explanation: This option suggests deploying the application directly to production and using an audit log to capture database operations in case of verification failure.
- Pros: This option does not involve extra infrastructure and focuses on monitoring and logging.
- Cons: It directly deploys to the production environment, which is risky because any issues in the deployment could affect the live system. This does not meet the requirement of testing changes before deployment.
- Conclusion: This option is rejected because deploying directly to production is not a safe practice, especially when changes are not fully tested.
C) Create a snapshot of the DB cluster before deploying the application. Use the Update requires:Replacement property on the DB instance in AWS CloudFormation ...
Author: Vivaan · Last updated May 17, 2026
A company manages a multi-tenant environment in its VPC and has configured Amazon GuardDuty for the corresponding AWS account. The company sends all GuardDuty findings to AWS Security Hub.
Traffic from suspicious sources is generating a large number of findings. A DevOps engineer needs to implement a solution to automat...
To meet the requirements of automatically denying traffic when GuardDuty discovers a new suspicious source, the solution must trigger an action that immediately blocks traffic at the network level across the entire VPC. Let’s evaluate the options:
A) Create a GuardDuty threat list. Configure GuardDuty to reference the list. Create an AWS Lambda function that will update the threat list. Configure the Lambda function to run in response to new Security Hub findings that come from GuardDuty.
- Explanation: GuardDuty threat lists are a way to manually manage suspicious IP addresses or domain names, but updating the threat list with a Lambda function in response to findings is not designed to actively block traffic. GuardDuty uses these lists to identify threats, but they don’t directly trigger traffic denial actions in the VPC.
- Pros: Allows customization of threat identification.
- Cons: This option doesn't provide a direct mechanism to block traffic at the VPC level. It focuses on identification rather than prevention.
- Conclusion: This option doesn’t meet the requirement of blocking traffic automatically across the entire VPC.
B) Configure an AWS WAF web ACL that includes a custom rule group. Create an AWS Lambda function that will create a block rule in the custom rule group. Configure the Lambda function to run in response to new Security Hub findings that come from GuardDuty.
- Explanation: AWS WAF is primarily used to protect web applications by filtering HTTP/HTTPS traffic. While this solution can block suspicious web traffic, it doesn’t extend to all traffic within the VPC, especially non-web traffic. This makes it less suitable for the requirement of blocking all traffic from suspicious sources across the entire VPC.
- Pros: AWS WAF is good for blocking malicious HTTP/HTTPS traffic.
- Cons: This solution only targets web traffic and doesn't apply to other types of traffic within the VPC (such as database or internal communication).
- Conclusion: This option is rejected because it doesn’t provide comprehensive protection for all traffic within the VPC, just HTTP/HTTPS traffic.
C) Configure a firewall in AWS Netwo...
Author: ShadowWolf101 · Last updated May 17, 2026
A company uses AWS Secrets Manager to store a set of sensitive API keys that an AWS Lambda function uses. When the Lambda function is invoked the Lambda function retrieves the API keys and makes an API call to an external service. The Secrets Manager secret is encrypted with the default AWS Key Management Service (AWS KMS) key.
A DevOps engineer needs to update the infrastructure to ensure that only the Lambda function's exe...
The key goal is to ensure that only the Lambda function’s execution role has access to decrypt the secrets stored in AWS Secrets Manager. This involves applying the principle of least privilege by restricting access to the secret and the associated KMS key. Let’s evaluate the options:
A) Update the default KMS key for Secrets Manager to allow only the Lambda functions execution role to decrypt.
- Explanation: The default AWS KMS key used for Secrets Manager is managed by AWS, and it might allow broader access to principals within the account. However, we can modify the permissions on this default KMS key to allow decryption only by the Lambda function's execution role.
- Pros: This option is a straightforward way to enforce access control at the KMS key level. It ensures that only the Lambda function has access to decrypt the secret.
- Cons: While effective, modifying the default key may not be as flexible as using a custom KMS key, and it may involve changing the permissions of an existing shared key, which could have unintended effects.
- Conclusion: This option is valid and can meet the requirement of ensuring only the Lambda function can access the secret.
B) Create a KMS customer managed key that trusts Secrets Manager and allows the Lambda function's execution role to decrypt. Update Secrets Manager to use the new customer managed key.
- Explanation: A customer-managed KMS key provides more control over access policies and can be scoped to only allow the Lambda function’s execution role to decrypt the secret. You can configure this KMS key to allow the Lambda function to use the key to decrypt the secret and update Secrets Manager to use this key instead of the default key.
- Pros: This approach gives full control over access and is the most flexible solution. It allows the KMS key to be used only by the Lambda function’s execution role while adhering to the principle of least privilege.
- Cons: Requires creating and managing an additional KMS key, which introduces slight operational overhead.
- Conclusion: This option is ideal for meeting the requirement, as it allows fine-grained access control.
C) Create a KMS customer managed key that trusts Secrets Manager and allows the account's root principal to decrypt. Update Secrets Manager to use the new customer managed key.
- Explanation: The root principal (account owner) has broad access acr...
Author: Sophia · Last updated May 17, 2026
A company's DevOps engineer is creating an AWS Lambda function to process notifications from an Amazon Simple Notification Service (Amazon SNS) topic. The Lambda function will process the notification messages and will write the contents of the notification messages to an Amazon RDS Multi-AZ DB instance.
During testing, a database administrator accidentally shut down the DB instance. While the database was down the company lost several of the SNS notificati...
The key requirement here is to ensure that the company does not lose SNS notification messages while the database is down. The solution must provide a way to temporarily store the messages until the Lambda function can successfully process them when the database is available again. Let’s evaluate the options:
A) Replace the RDS Multi-AZ DB instance with an Amazon DynamoDB table.
- Explanation: Replacing RDS with DynamoDB would change the nature of the database, but it does not directly address the issue of lost SNS messages during Lambda processing. DynamoDB is a NoSQL database that can handle high throughput, but the key problem here is the need to ensure that SNS messages are not lost during processing when the database is unavailable.
- Pros: DynamoDB can be more resilient for certain use cases, but it does not address message loss.
- Cons: This option doesn’t solve the immediate problem of lost SNS messages, and replacing the RDS instance with DynamoDB may involve significant changes in the application logic.
- Conclusion: This option is rejected because it doesn’t specifically address the message loss issue during Lambda processing.
B) Configure an Amazon Simple Queue Service (Amazon SQS) queue as a destination of the Lambda function.
- Explanation: This solution would allow the Lambda function to consume messages from an SQS queue, but simply configuring an SQS queue as the destination of the Lambda function does not help with the scenario of message retention during downtime. SQS is typically used to queue messages for processing, but this option alone would not help in case the Lambda function fails or the DB is down.
- Pros: SQS is reliable for queuing and retrying messages, but it’s not fully addressing message loss on the SNS side.
- Cons: It doesn't prevent the message loss from SNS to Lambda itself, as the SNS topic would still directly push messages without a retry mechanism for failures.
- Conclusion: This option is rejected because it doesn’t address message retention and potential loss when the Lambda function itself is unable to process the message due to a failure.
C) Configure an Amazon Simple Queue Service (Amazon SQS) dead-letter queue for the SNS topic.
- Explanation: A dead-letter queue (DLQ) is used to capture messages that could not be processed successfully. In the case of SNS, if the message cannot be delivered to its endpoint (e.g., the Lambda function fails or the database is down), it can be sent to an SQS DLQ.
- Pros: Using a DLQ ensures that messages are not lost, even if they cannot be processed immediately. The DLQ allows for later inspection and reprocessing of messages that f...
Author: Deepak · Last updated May 17, 2026
A company has an application that runs on Amazon EC2 instances. The company uses an AWS CodePipeline pipeline to deploy the application into multiple AWS Regions. The pipeline is configured with a stage for each Region. Each stage contains an AWS CloudFormation action for each Region.
When the pipeline deploys the application to a Region, the company wants to confirm that the application is in a healthy state before the pipeline moves on to the next Region. Amazon Route 53 record sets are configured for the application i...
To meet the requirement of confirming that the application is in a healthy state before proceeding to the next Region, we need to ensure that the health check (via CloudWatch alarm based on Route 53 health checks) can block or halt the pipeline if the application is unhealthy in any Region.
Let’s evaluate each option:
A) Create an AWS Step Functions workflow to check the state of the CloudWatch alarm. Configure the Step Functions workflow to exit with an error if the alarm is in the ALARM state. Create a new stage in the pipeline between each Region deployment stage. In each new stage, include an action to invoke the Step Functions workflow.
- Explanation: This solution involves using AWS Step Functions to manage the health check logic. It checks the state of the CloudWatch alarm, and if the alarm is triggered (in the ALARM state), it can stop the pipeline by exiting with an error. Creating an additional pipeline stage for each Region makes it possible to pause the pipeline and evaluate the application’s health before proceeding.
- Pros: This solution provides a robust workflow for checking the health of the application, and it can pause the pipeline to check for the application’s health before continuing with the deployment to the next Region.
- Cons: This requires additional complexity, as Step Functions would need to be configured and integrated into the pipeline, creating more steps in the process.
- Conclusion: This solution is suitable for managing health checks with flexibility but introduces additional complexity. It ensures that the pipeline only proceeds if the health check is passed.
B) Configure an AWS CodeDeploy application to deploy a CloudFormation template with automatic rollback. Configure the CloudWatch alarm as the instance health check for the CodeDeploy application. Remove the CloudFormation actions from the pipeline. Create a CodeDeploy action in the pipeline stage for each Region.
- Explanation: This solution replaces CloudFormation actions with CodeDeploy. CodeDeploy can automatically handle application deployments and rollbacks based on health checks (like the CloudWatch alarm). However, this approach changes the deployment strategy from using CloudFormation to CodeDeploy and introduces complexity in the pipeline.
- Pros: CodeDeploy has built-in support for automatic rollbacks on health check failures, which simplifies the process.
- Cons: This solution requires a change in the deployment strategy, which may not align with the existing CloudFormation-based deployment model. It also removes the flexibility that CloudFormation provides in managing resources.
- Conclusion: While CodeDeploy is a good option for managing health checks and rollbacks, it introduces significant changes to the pipeline and may not be required if the company p...
Author: David · Last updated May 17, 2026
A company plans to use Amazon CloudWatch to monitor its Amazon EC2 instances. The company needs to stop EC2 instances when the average of the NetworkPacketsIn metric is less than 5 for at least 3 hours in a 12-hour time window. The company must evaluate the metric every hour. The EC2 instances must continue to run if there is missing data for the NetworkPacketsIn metric during the evaluation period.
A DevOps engineer creates a CloudWatch alarm for the NetworkP...
Let's break down the requirements and evaluate each option:
Requirements Recap:
1. NetworkPacketsIn metric average should be less than 5 for at least 3 hours in a 12-hour window.
2. The metric should be evaluated every hour.
3. The EC2 instance should continue to run if there is missing data.
4. The EC2 instance should stop when the alarm triggers (for 3 hours of low traffic).
Key factors to consider:
- The Datapoints to Alarm value defines the number of periods the metric should breach the threshold to trigger the alarm. This needs to align with the requirement of "at least 3 hours" of low NetworkPacketsIn in a 12-hour period.
- Treating missing data is crucial. The company specified that missing data should not trigger the alarm (i.e., instances should continue running even if data is missing for a period).
Option-by-option breakdown:
A) Configure the Datapoints to Alarm value to be 3 out of 12. Configure the alarm to treat missing data as breaching the threshold. Add an AWS Systems Manager action to stop the instance when the alarm enters the ALARM state.
- Datapoints to Alarm value (3 out of 12): This means the alarm triggers if 3 evaluation periods out of 12 hours breach the threshold.
- Treat missing data as breaching the threshold: This is not ideal because the requirement explicitly says that missing data should not trigger the alarm. This would cause false positives when data is missing, and the instance would stop even if the network traffic is fine but data is unavailable for some periods.
- AWS Systems Manager action: This is an incorrect action because the goal is to stop the instance directly using an EC2 action, not Systems Manager.
B) Configure the Datapoints to Alarm value to be 3 out of 12. Configure the alarm to treat missing data as not breaching the threshold. Add an EC2 action to stop the instance when the alarm enters the ALARM state.
- Datapoints to Alarm value (3 out of 12): This meets the requirement of evaluating over a 12-ho...
Author: Leah Davis · Last updated May 17, 2026
A company manages 500 AWS accounts that are in an organization in AWS Organizations. The company discovers many unattached Amazon Elastic Block Store (Amazon EBS) volumes in all the accounts. The company wants to automatically tag the unattached EBS volumes for investigation.
A DevOps engineer needs to deploy an AWS Lambda function to all the AWS accounts. The Lambda function must run every 30 minutes ...
Let's break down the options based on the requirements and key factors such as operational efficiency, security, and scalability:
Requirements Recap:
1. Lambda function to run every 30 minutes in all AWS accounts.
2. Tag unattached EBS volumes that have been unattached for at least 7 days.
3. Operational efficiency: The solution should minimize manual intervention, be scalable, and integrate well with AWS Organizations.
Key factors:
- AWS Organizations: Since the company manages multiple AWS accounts, a solution that leverages AWS Organizations is preferred for central management and scalability.
- Lambda Deployment: The Lambda function needs to be deployed in all 500 accounts, so a solution that allows bulk deployment across accounts is necessary.
- Event Scheduling: A mechanism must be in place to invoke the Lambda function every 30 minutes in each account.
- Security and Permissions: The least privilege principle should be followed, ensuring only the necessary permissions are granted to the Lambda function and resources.
Option-by-option analysis:
A) Configure a delegated administrator account for the organization. Create an AWS CloudFormation template that contains the Lambda function. Use CloudFormation StackSets to deploy the CloudFormation template from the delegated administrator account to all the member accounts in the organization. Create an Amazon EventBridge event bus in the delegated administrator account to invoke the Lambda function in each member account every 30 minutes.
- Delegated administrator account: This option utilizes AWS Organizations effectively by configuring a delegated administrator account for central management.
- CloudFormation StackSets: This is a great approach for deploying resources to multiple accounts. It ensures that the Lambda function is deployed consistently across all accounts.
- EventBridge event bus in the delegated administrator account: EventBridge can be used to trigger the Lambda function, but it needs to invoke the function in all member accounts. This setup is feasible but could introduce complexity because EventBridge typically targets resources in a specific account, and cross-account invocations might require additional configuration for permissions.
B) Create a cross-account IAM role in the organization's member accounts. Attach the AWSLambda_FullAccess policy and the AWSCloudFormationFullAccess policy to the role. Create an AWS CloudFormation template that contains the Lambda function and an Amazon EventBridge scheduled rule to invoke the Lambda function every 30 minutes. Create a custom script in the organizations management account that assumes the role and deploys the CloudFormation template to the member accounts.
- Cross-account IAM role: This requires manual role creation in each member account, which adds overhead, especially across 500 acco...
Author: CrimsonViperX · Last updated May 17, 2026
A company's production environment uses an AWS CodeDeploy blue/green deployment to deploy an application. The deployment incudes Amazon EC2 Auto Scaling groups that launch instances that run Amazon Linux 2.
A working appspec.yml file exists in the code repository and contains the following text:
A DevOps engineer needs to ensure that a script downloads and installs a license file onto the instances before the replacement instances start to ha...
Let's analyze the requirements and each option:
Requirements Recap:
1. Script execution: A script must be run to download and install a license file on the instances.
2. Timing: The script should run before the replacement instances handle request traffic, which means it should occur before the new instances are made live and start serving traffic.
Key Factors:
- In a blue/green deployment, traffic is shifted from the old instances (blue) to the new instances (green) once they are ready. This means we need to run the script before the new instances are fully functional and begin serving traffic.
- AppSpec hooks are used to run scripts at specific stages of the deployment process.
Option-by-option breakdown:
A) AfterBlockTraffic
- AfterBlockTraffic is used after the old instances (blue) have been blocked from receiving traffic but before the new instances (green) begin handling traffic.
- While this hook happens after blocking traffic to the old instances, it is too late for our scenario, as we need to install the license before the new instances start handling requests.
- Not suitable because it runs after traffic is blocked, which is later than required.
B) BeforeBlockTraffic
- BeforeBlockTraffic happens before the old instances stop receiving traffic. This is still not ideal because it runs before the new instances are...
Author: Ethan · Last updated May 17, 2026
A company has an application that includes AWS Lambda functions. The Lambda functions run Python code that is stored in an AWS CodeCommit repository. The company has recently experienced failures in the production environment because of an error in the Python code. An engineer has written unit tests for the Lambda functions to help avoid releasing any future defects into the production environment.
The company's DevOps team needs to implement a solution ...
Let's break down the options and identify the most appropriate solution:
Requirements Recap:
1. The company needs to integrate unit tests into an existing AWS CodePipeline pipeline.
2. The solution must produce test reports that the company can view.
3. The unit tests are already written and stored in Python code in the AWS CodeCommit repository.
4. The reports must be generated and integrated into the pipeline for visibility.
Key Factors:
- Unit test execution: The unit tests need to be executed as part of the build process in CodePipeline.
- Test reports: These should be generated and displayed for the team to view, typically in formats like JUnit XML, HTML, or other recognized formats.
- Integration into CodePipeline: The solution should work seamlessly with CodePipeline, integrating into an existing pipeline.
Option-by-option analysis:
A) Associate the CodeCommit repository with Amazon CodeGuru Reviewer. Create a new AWS CodeBuild project. In the CodePipeline pipeline, configure a test stage that uses the new CodeBuild project. Create a buildspec.yml file in the CodeCommit repository. In the buildspec.yml file, define the actions to run a CodeGuru review.
- CodeGuru Reviewer: CodeGuru is primarily used for code reviews, static analysis, and identifying code quality issues. It is not directly used for running unit tests.
- Unit testing: This option does not focus on running unit tests and generating test reports, which is the primary requirement. It is more geared toward reviewing code quality.
- Not suitable: This option does not meet the core requirement of integrating unit tests and generating test reports.
B) Create a new AWS CodeBuild project. In the CodePipeline pipeline, configure a test stage that uses the new CodeBuild project. Create a CodeBuild report group. Create a buildspec.yml file in the CodeCommit repository. In the buildspec.yml file, define the actions to run the unit tests with an output of JUNITXML in the build phase section. Configure the test reports to be uploaded to the new CodeBuild report group.
- CodeBuild project: This is a good choice because CodeBuild can run the unit tests and generate reports. It fits perfectly into the existing CodePipeline setup.
- JUnit XML output: The output of JUnit XML format is a widely accepted format for test reports and is easily viewable in many CI/CD tools, including CodePipeline.
- Test reports: The test reports will be generated and st...
Author: Nia · Last updated May 17, 2026
A company manages multiple AWS accounts in AWS Organizations. The company's security policy states that AWS account root user credentials for member accounts must not be used. The company monitors access to the root user credentials.
A recent alert shows that the root user in a member account launched an Amazon EC2 instance. A DevOps engineer must create an SCP at th...
Requirement Recap:
- Root user restriction: The company’s security policy explicitly requires that root user credentials must not be used, and access to the root user must be prevented.
- Prevention of EC2 API calls: The root user in member accounts should not be able to make any API calls, including launching EC2 instances.
- SCP (Service Control Policy): The DevOps engineer must create an SCP at the organization's root level to enforce this restriction.
Key Factors:
- SCP scope: An SCP applies to all accounts within the organization (or organizational unit), and it specifies which actions are allowed or denied. It’s important to use a policy that targets the root user specifically without affecting other necessary permissions for other users or roles.
- Root user restrictions: The root user has the highest level of access in an account, and there are specific SCPs that can be used to block root user access to services or resources.
Option-by-option analysis:
A) "Effect": "Deny", "Action": "sts:AssumeRole", "Principal": { "AWS": "arn:aws:iam::account-id:root" }
- This option denies the root user from assuming any IAM roles, but it doesn’t prevent the root user from performing other actions like launching EC2 instances.
- Not sufficient: While it restricts some root user activities (like assuming roles), it doesn’t comprehensively prevent root users from making all API calls, including launching EC2 instances.
B) "Effect": "Deny", "Action": "", "Principal": { "AWS": "arn:aws:iam::account-id:root" }
- This SCP denies all actions (`"Action": ""`) for the root user by targeting their IAM principal (`"arn:aws:iam::account-id:root"`).
- Correct choice: This effec...
Author: Ryan · Last updated May 17, 2026
A company uses AWS and has a VPC that contains critical compute infrastructure with predictable traffic patterns. The company has configured VPC flow logs that are published to a log group in Amazon CloudWatch Logs.
The company's DevOps team needs to configure a monitoring solution for the VPC flow logs to identify anomalies in network traffic to the VPC over time. If the monitoring solution detect...
In this scenario, the DevOps team is looking to set up a solution that can identify anomalies in VPC flow logs and initiate a response upon detection. Let's evaluate the options based on the requirements of anomaly detection and response initiation:
Option A:
- Process: Use Amazon Kinesis Data Streams to ingest the VPC flow logs. Then, configure Amazon Kinesis Data Analytics to detect anomalies in the data stream. If an anomaly is found, the Kinesis Data Analytics output triggers an AWS Lambda function that sends an event to Amazon EventBridge.
- Pros:
- Kinesis Data Analytics is well-suited for real-time analytics, which can detect patterns or anomalies in the data stream.
- EventBridge allows seamless integration with AWS services for triggering automated responses.
- Cons:
- This approach introduces additional complexity with Kinesis Data Analytics, which might be overkill for a simpler anomaly detection use case. It requires setting up a data stream and analytics job, which adds overhead.
- Kinesis Data Analytics can have higher costs, especially for continuous monitoring of flow logs.
Option B:
- Process: Use Kinesis Data Firehose to stream VPC logs to an Amazon S3 bucket. Then, Amazon Lookout for Metrics is used to detect anomalies in the S3 data. Upon detecting an anomaly, an AWS Lambda function is triggered to respond.
- Pros:
- Lookout for Metrics is a managed service specifically designed to detect anomalies in time-series data, and it can scale efficiently.
- Using S3 as an intermediate storage layer provides durability and allows historical analysis of logs.
- Cons:
- This solution involves an extra step of writing the data to S3, which adds complexity and potentially delays anomaly detection because it requires batch processing rather than real-time analysis.
- Lookout for Metrics is better suited for monitoring data stored over time, but in this case, there may be a better fit for real-time anomaly detection.
Option C:
- Process: Create a custom AWS Lambda function to directly process the VPC flow logs and detect anomalies. If an anomaly is detected, the function publishes an event to EventBridge.
- Pros:
- A Lambda function is easy ...
Author: Isabella · Last updated May 17, 2026
AnyCompany is using AWS Organizations to create and manage multiple AWS accounts. AnyCompany recently acquired a smaller company, Example Corp. During the acquisition process, Example Corp's single AWS account joined AnyCompany's management account through an Organizations invitation. AnyCompany moved the new member account under an OU that is dedicated to Example Corp.
AnyCompany's DevOps engineer has an IAM user that assumes a role that is named OrganizationAccountAccessRole to access member accounts. This role is configured with a full access policy. When the DevOps engineer tries to use the AWS Management Console to assume the role...
In this scenario, the DevOps engineer is trying to assume the OrganizationAccountAccessRole role in the new member account, but encounters an error message. The core issue is likely related to either permissions or trust policies in AWS Organizations and IAM roles.
Let's break down the options:
Option A:
- Process: Grant the DevOps engineer's IAM user permission to assume the OrganizationAccountAccessRole role in the new member account from the management account.
- Explanation: The DevOps engineer must have permission to assume roles in other accounts within AWS Organizations. In this case, the engineer’s IAM user in the management account needs explicit permission to assume the OrganizationAccountAccessRole role in the new member account.
- Why it works: This option ensures that the DevOps engineer’s IAM user has the required permission to assume the role in the member account. This is crucial because IAM roles that are assumable by users must have the proper permissions granted to them.
- Why other options are less relevant: This option directly solves the permission issue, whereas other options don’t address the DevOps engineer’s IAM permissions in the management account.
Option B:
- Process: Create a Service Control Policy (SCP) in the management account and apply it to the Organizational Unit (OU) containing the new member account to allow full access.
- Explanation: SCPs control permissions at the AWS Organizations level, but they do not grant specific permissions to IAM users or roles. SCPs are meant for restricting or allowing access at a high level across multiple accounts.
- Why it’s not ideal: SCPs are not used for managing specific IAM role assumptions by users. SCPs affect permissions on a broader level and would not directly address the role assumption issue in this case. It would not resolve the DevOps engineer's need to assume the role itself.
Option C:
- Process: I...
Author: Benjamin · Last updated May 17, 2026
A DevOps engineer is designing an application that integrates with a legacy REST API. The application has an AWS Lambda function that reads records from an Amazon Kinesis data stream. The Lambda function sends the records to the legacy REST API.
Approximately 10% of the records that the Lambda function sends from the Kinesis data stream have data errors and must be processed manually. The Lambda function event source configuration has an Amazon Simple Queue Service (Amazon SQS) dead-letter queue as an on-failure destination. The DevOps engineer has configured the Lambda function to process records in batches and has implemented retries in case of failure.
During testing, the DevOps engineer notices that the dead-letter queue c...
In this scenario, the DevOps engineer is trying to reduce the number of errorless records that are sent to the dead-letter queue (DLQ) when the Lambda function processes records from a Kinesis data stream. The current issue is that records that have no errors but are being processed successfully by the legacy REST API are still getting sent to the DLQ. This suggests that the Lambda function is marking them as failed, even though they were processed correctly.
Let's evaluate each option to determine the best solution:
Option A: Increase the retry attempts
- Explanation: Increasing the number of retry attempts allows Lambda to retry failed records multiple times before sending them to the DLQ. However, this option may not solve the issue of errorless records being sent to the DLQ. The retry attempts will only matter when an actual failure happens, but in this case, the issue is that records that have been successfully processed are still being treated as failures.
- Why it’s not ideal: This doesn't address the core problem, which is the incorrect classification of successful records as failures.
Option B: Configure the setting to split the batch when an error occurs
- Explanation: This option allows the Lambda function to split the records in a batch when an error occurs, processing them separately. This means that if a single record fails, it won’t affect the rest of the records in the batch. The idea is that failing records would be isolated from successfully processed ones, reducing the chance of errorless records being sent to the DLQ.
- Why it works: This option is effective because it enables t...
Author: William · Last updated May 17, 2026
A company has microservices running in AWS Lambda that read data from Amazon DynamoDB. The Lambda code is manually deployed by developers after successful testing. The company now needs the tests and deployments be automated and run in the cloud. Additionally, traffic to the new versions of each microservice should...
To meet the requirements, we need an automated solution that ensures continuous integration and continuous deployment (CI/CD), automated testing, and controlled traffic shifts for new Lambda versions. Additionally, we want to prioritize developer velocity, meaning the solution should simplify the process and minimize manual intervention.
Let's evaluate each option:
Option A:
- Process: Use AWS CodePipeline for CI/CD, trigger the pipeline after tests have passed via a post-commit hook, and deploy new Lambda versions using AWS CodeDeploy with a Canary deployment configuration that controls the percentage of traffic and the interval.
- Pros:
- AWS CodePipeline provides an integrated solution for automating the entire CI/CD process.
- AWS CodeDeploy with a Canary deployment configuration ensures controlled traffic shifting with a specific percentage and interval.
- This solution provides a streamlined approach, integrating testing, deployment, and traffic management.
- Cons:
- The "post-commit hook" is a good way to trigger the pipeline but may require more setup compared to automatic triggers based on version control push events.
Option B:
- Process: Use AWS CodeBuild to trigger on test code pushes. Use AWS CloudFormation to trigger a CodePipeline configuration for deployment and traffic shifting.
- Pros:
- AWS CodeBuild can trigger based on code pushes, allowing for automation of tests.
- AWS CloudFormation can handle infrastructure management and the pipeline.
- Cons:
- AWS CloudFormation adds complexity. It's more suited to managing infrastructure as code and might overcomplicate a simple deployment pipeline for Lambda.
- More complex setup and maintenance than necessary for a Lambda microservices architecture.
Option C:...
Author: FrostFalcon88 · Last updated May 17, 2026
A company is building a web and mobile application that uses a serverless architecture powered by AWS Lambda and Amazon API Gateway. The company wants to fully automate the backend Lambda deployment based on code that is pushed to the appropriate environment branch in an AWS CodeCommit repository.
The deployment must have the following:
* Separate environment ...
To fully automate the deployment of backend Lambda functions for both test and production environments, with separate pipelines and automatic deployment only for test environments, the best approach would involve using AWS CodePipeline for continuous integration and deployment (CI/CD), along with AWS CodeCommit for source control.
Let's evaluate each option based on the requirements:
Option A:
- Process: Create a new AWS CodePipeline service and a CodeCommit repository for each environment. Set up CodePipeline to retrieve source code from the appropriate repository and deploy Lambda functions using AWS CloudFormation.
- Pros:
- This option separates the environments by using different repositories, ensuring clear isolation between test and production.
- CloudFormation can automate the Lambda function deployments.
- Cons:
- This approach introduces unnecessary complexity by creating separate repositories for test and production. While repositories are usually for organizing code, using different repositories for environments isn't ideal in most cases. CodeCommit branches within the same repository would be a better approach.
- This method does not directly address the automatic deployment to the test environment only, as the pipelines would need to be manually controlled for each environment.
Option B:
- Process: Create two AWS CodePipeline configurations for test and production environments. Configure the production pipeline to have a manual approval step. Create separate CodeCommit repositories for each environment, and set up the deployment step to deploy Lambda functions using AWS CloudFormation.
- Pros:
- This approach allows clear separation of test and production environments.
- The manual approval step for production ensures that deployments to production are controlled and deliberate.
- Cons:
- Again, creating separate CodeCommit repositories is unnecessarily complex. It would be easier and more efficient to use one repository with separate branches for different environments.
- The production pipeline is configured with manual approval, but the test pipeline is not fully automated for deployment, which may not align with the need for fully automated deployment to test environments.
Option C:
- Process: Create two AWS CodePipeline configurations for test and production environments. C...
Author: Oscar · Last updated May 17, 2026
A DevOps engineer wants to find a solution to migrate an application from on premises to AWS. The application is running on Linux and needs to run on specific versions of Apache Tomcat, HAProxy, and Varnish Cache to function properly. The application's operating system-level parameters require tuning. The solution must include a way to automate the deployment of new ap...
Let's evaluate each of the given options in detail, based on the requirements and the factors:
Key Requirements:
1. Application is running on Linux and requires specific versions of Apache Tomcat, HAProxy, and Varnish Cache.
2. The operating system parameters need tuning.
3. Automated deployment of new application versions.
4. The solution must be scalable.
5. Faulty servers should be replaced automatically.
---
A) Upload the application as a Docker image that contains all the necessary software to Amazon ECR. Create an Amazon ECS cluster using an AWS Fargate launch type and an Auto Scaling group. Create an AWS CodePipeline pipeline that uses Amazon ECR as a source and Amazon ECS as a deployment provider.
- Why it might work:
- Dockerizing the application ensures that the exact versions of software (Tomcat, HAProxy, Varnish Cache) and system-level configurations are bundled within the container, which fits the requirement of maintaining consistency across environments.
- AWS Fargate allows for a fully managed container deployment solution with automatic scaling.
- Amazon ECS combined with an Auto Scaling group ensures automatic scaling, and faulty servers can be replaced as part of this scalable infrastructure.
- CodePipeline allows for continuous integration and deployment automation.
- Why it might not work:
- While Fargate provides a serverless approach, certain use cases (like requiring OS-level tuning and specific software versions) might require more control over the underlying infrastructure, which containers may abstract away.
- ECS/Fargate could be overkill if full control of the underlying infrastructure is needed (e.g., when fine-tuning OS parameters), as Fargate abstracts away server management.
---
B) Upload the application code to an AWS CodeCommit repository with a saved configuration file to configure and install the software. Create an AWS Elastic Beanstalk web server tier and a load balanced-type environment that uses the Tomcat solution stack. Create an AWS CodePipeline pipeline that uses CodeCommit as a source and Elastic Beanstalk as a deployment provider.
- Why it might work:
- Elastic Beanstalk simplifies deployment and management by automatically handling the scaling and load balancing.
- CodePipeline ensures automated deployment.
- The Tomcat solution stack fits the requirement for running Apache Tomcat.
- Why it might not work:
- Elastic Beanstalk’s solution stack might not allow for the customization needed for HAProxy and Varnish Cache, as it is tailored primarily for Tomcat.
- OS-level tuning might be challenging in Elastic Beanstalk as it abstracts much of the system management and is more suited for conventional web applications without requiring deep OS-level tuning.
- Elastic Beanstalk might not provide enough flexibility for fin...
Author: Henry · Last updated May 17, 2026
A DevOps engineer is using AWS CodeDeploy across a fleet of Amazon EC2 instances in an EC2 Auto Scaling group. The associated CodeDeploy deployment group, which is integrated with EC2 Auto Scaling, is configured to perform in-place deployments with CodeDeployDefault.OneAtATime. During an ongoing new deployment, the engineer discovers that, although the overall deployment finished successfully, two ...
Let's analyze each of the options in light of the scenario where a new deployment was performed successfully, but two out of five instances ended up with the previous application revision instead of the latest one.
Key Points:
- The deployment is in-place, meaning that the application revision on the instances should be updated without replacing the instances themselves.
- The deployment group uses CodeDeployDefault.OneAtATime, which means instances are updated one at a time during the deployment process.
- EC2 Auto Scaling is integrated with CodeDeploy, which means that EC2 instances can be added or removed based on the scaling policies.
---
A) The two affected instances failed to fetch the new deployment.
- Why it might be correct:
- If these two instances failed to fetch the new revision due to network issues or misconfigurations, the deployment process could have skipped those instances while successfully updating the others.
- Why it might not be correct:
- If the fetching of the deployment had failed, this would likely result in the deployment failing completely on those instances. However, if the deployment was successful on the other three instances, it's unlikely that fetching the new revision was the issue.
- Conclusion: This is a possible cause, but it's less likely given that the deployment was successful on other instances.
---
B) A failed AfterInstall lifecycle event hook caused the CodeDeploy agent to roll back to the previous version on the affected instances.
- Why it might be correct:
- AfterInstall lifecycle hooks are used to run post-installation tasks. If there is an error in the AfterInstall phase, CodeDeploy would roll back to the previous version. The fact that the affected instances ended up with the previous application revision could be a direct result of a failure in this phase.
- Rollbacks typically occur when there is a failure during the deployment, and if the lifecycle hook fails, the CodeDeploy agent will revert to the previous version.
- Why it might not be correct:
- If the issue was during AfterInstall, then there would likely be logs or error messages indicating this problem. Without evidence of a lifecycle hook failure, it's hard to confirm this as the root cause.
- Conclusion: This is a strong possibility, especially if there were failures during the AfterInstall phase, which would explain the rollback on the affected instances.
---
C) The CodeDeploy agent was no...
Author: Elijah · Last updated May 17, 2026
A security team is concerned that a developer can unintentionally attach an Elastic IP address to an Amazon EC2 instance in production. No developer should be allowed to attach an Elastic IP address to an instance. The security team must be no...
Let's evaluate each option to find the most suitable solution to prevent developers from unintentionally attaching an Elastic IP address (EIP) to a production instance and ensure that the security team is notified if this occurs.
Key Requirements:
- No developer should be allowed to attach an Elastic IP to an instance.
- The security team must be notified if any production server has an Elastic IP attached.
- We need an automated solution that manages both preventing and notifying.
---
A) Use Amazon Athena to query AWS CloudTrail logs to check for any associate-address attempts. Create an AWS Lambda function to disassociate the Elastic IP address from the instance, and alert the security team.
- Why it might work:
- CloudTrail records actions taken on AWS resources, so querying CloudTrail logs via Athena can identify when an `AssociateAddress` API call is made (i.e., when an Elastic IP is associated with an instance).
- An AWS Lambda function could automatically disassociate the EIP and send an alert.
- Why it might not work:
- While this approach allows for detection and response, it's reactive, meaning the EIP would already be attached before the Lambda function runs. This could be problematic, especially if an EIP was unintentionally associated with a critical production instance.
- Athena querying could introduce delays in detecting these changes, making the solution less proactive.
- Conclusion: This option is not ideal because it focuses on detecting and fixing the issue after it happens, rather than preventing it in the first place.
---
B) Attach an IAM policy to the developers' IAM group to deny associate-address permissions. Create a custom AWS Config rule to check whether an Elastic IP address is associated with any instance tagged as production, and alert the security team.
- Why it might work:
- IAM policies can explicitly deny the `associate-address` permission, effectively preventing developers from attaching Elastic IPs to instances.
- An AWS Config rule can be created to monitor instances tagged as production and check if they have an Elastic IP attached. The security team would be notified via an alert if any production instance violates this rule.
- Why it might not work:
- While this approach blocks developers from attaching an EIP, it still relies on an AWS Config rule to monitor and alert if a violation occurs. This means there's a lag between when the violation happens (if someone else attaches the EIP) and when the alert is sent. It also requires extra configuration work for the rule.
- Conclusion: This is a solid option because it prevents developers from attaching an EIP, but it might miss a proactive way to prevent all possible attachment attempts, including by other users, and it requires configuration monitoring.
---
C) Ensure that all IAM groups associated with developers do not have associate-address permissions. Cre...
Author: FrostFalcon88 · Last updated May 17, 2026
A company is using AWS Organizations to create separate AWS accounts for each of its departments. The company needs to automate the following tasks:
* Update the Linux AMIs with new patches periodically and generate a golden image
* Install a new version of Chef agents in the golden image, if available
* Prov...
Let's evaluate each option to determine the best solution that meets the company's requirements with the least management overhead.
Key Requirements:
- Update the Linux AMIs with new patches periodically and generate a golden image.
- Install a new version of Chef agents in the golden image if available.
- Provide the newly generated AMIs to the department's accounts.
The goal is to minimize management overhead while automating the process efficiently.
---
A) Write a script to launch an Amazon EC2 instance from the previous golden image. Apply the patch updates. Install the new version of the Chef agent, generate a new golden image, and then modify the AMI permissions to share only the new image with the department's accounts.
- Why it might work:
- This approach involves a manual scripting process that can be automated by using EC2 instances, patching, installing the Chef agent, and generating a new AMI.
- Afterward, AMI permissions can be adjusted to share the new image with the department accounts.
- Why it might not work:
- While this solution is functional, it requires manual scripting and management overhead. You'll need to handle patching, Chef agent installation, AMI creation, and permissions management manually, which can be cumbersome and error-prone.
- The process might also involve managing scripts and scheduling tasks for periodic updates, increasing complexity.
- Conclusion: This option requires a lot of manual setup and monitoring, making it more labor-intensive than other automated solutions.
---
B) Use Amazon EC2 Image Builder to create an image pipeline that consists of the base Linux AMI and components to install the Chef agent. Use AWS Resource Access Manager to share EC2 Image Builder images with the department's accounts.
- Why it might work:
- Amazon EC2 Image Builder is a fully managed service that automates the creation of golden images, including the application of patches and the installation of software components like the Chef agent.
- AWS Resource Access Manager (RAM) allows the newly created AMI to be shared across accounts in the organization, making it easy to provide the new AMI to the department's accounts automatically.
- Why it might not work:
- This option is very streamlined and automated. However, it relies on using AWS Resource Access Manager for sharing, which might require additional setup if the departments are in separate AWS accounts or regions, though this is manageable.
- Conclusion: This solution is highly automated and uses managed AWS services for creating, patching, and distributing AMIs. It minimizes manual intervention and is ideal for organizations using multiple accounts.
---
C) Use an AWS Systems Manager Automation runbook to update the Li...
Author: Aarav · Last updated May 17, 2026
A company has a mission-critical application on AWS that uses automatic scaling. The company wants the deployment lifecycle to meet the following parameters:
* The application must be deployed one instance at a time to ensure the remaining fleet continues to serve traffic.
* The application is CPU intensive and must be closely monitored.
* The...
Let's evaluate each option based on the key requirements:
Key Requirements:
- One instance at a time deployment to ensure the remaining fleet continues to serve traffic.
- The application is CPU-intensive, so it must be closely monitored during deployment.
- The deployment must automatically roll back if the CPU utilization exceeds 85%.
---
A) Use AWS CloudFormation to create an AWS Step Functions state machine and Auto Scaling lifecycle hooks to move one instance at a time into a wait state. Use AWS Systems Manager automation to deploy the update to each instance and move it back into the Auto Scaling group using the heartbeat timeout.
- Why it might work:
- AWS Step Functions could orchestrate the deployment process, and lifecycle hooks can pause the instances while the deployment happens.
- AWS Systems Manager automation allows you to deploy updates to each instance and monitor the deployment.
- Why it might not work:
- This solution involves complex orchestration with CloudFormation, Step Functions, and lifecycle hooks, which might lead to high management overhead and complexity.
- It requires you to manually handle rollback conditions based on CPU usage, which makes it more error-prone and not as automated as other solutions.
- Conclusion: While functional, this option introduces unnecessary complexity compared to the other solutions that directly support the required features. It's less efficient than other choices.
---
B) Use AWS CodeDeploy with Amazon EC2 Auto Scaling. Configure an alarm tied to the CPU utilization metric. Use the CodeDeployDefault OneAtATime configuration as a deployment strategy. Configure automatic rollbacks within the deployment group to roll back the deployment if the alarm thresholds are breached.
- Why it might work:
- AWS CodeDeploy supports the OneAtATime deployment strategy, which ensures only one instance is updated at a time.
- Automatic rollback can be configured if the CPU utilization exceeds 85%, making it suitable for your CPU-intensive application.
- The integration with EC2 Auto Scaling ensures that the remaining fleet continues to serve traffic during deployment.
- Why it might not work:
- This solution is straightforward and directly fits the requirements, making it unlikely to fail. There is no significant downside.
- Conclusion: This option is the most appropriate as it directly addresses all the requirements with minimal complexity. CodeDeploy offers native support for the OneAtATime deployment strategy and automatic rollbacks based on alarms.
---
C) Use AWS Elastic Beanstalk for load balancing and AWS Auto Scaling. Configure an alarm tied to the CPU utilization metric. Configure rolling deploy...
Author: Ethan Smith · Last updated May 17, 2026
A company has a single developer writing code for an automated deployment pipeline. The developer is storing source code in an Amazon S3 bucket for each project. The company wants to add more developers to the team but is concerned about code conflicts and lost work. The company also wants to build a test environment to deploy newer versions of code for testing and all...
Let's evaluate each option based on the requirements:
Option A: AWS CodeCommit Repository with Branches and Pull Requests
- Advantages:
- Version Control: AWS CodeCommit is a version-controlled repository, which helps manage code changes and track them efficiently, reducing the risk of code conflicts or lost work.
- Branching and Pull Requests: Developers can work on feature branches, and pull requests can be used to merge code into the main and testing branches. This provides a controlled and collaborative environment for code deployment.
- Test and Production Environment Separation: The use of separate branches (main for production, testing for test code) makes it easy to manage deployment to different environments (production and testing).
- Automatic Deployments: Integration with AWS services allows automatic deployment pipelines when code is committed or merged, which aligns with the company's goal to deploy code automatically when changes occur.
- Disadvantages:
- Learning Curve: For new developers, learning Git-based workflows may have a slight learning curve, but it is a best practice in software development.
- When to use: This is the most efficient and scalable option for managing version control, collaboration, and automatic deployment pipelines.
Option B: S3 Buckets with Lambda Promotion
- Advantages:
- Versioning: Enabling versioning on S3 buckets can protect against accidental deletions and code conflicts.
- Lambda Promotion: Lambda functions can help automate the movement of code between environments (testing and production).
- Disadvantages:
- No Version Control: S3 does not offer traditional source control features like branches or pull requests. This means developers might face difficulties collaborating on code without worrying about overwriting each other's changes.
- Manual Merging: S3 lacks the necessary features to handle merging changes in the same file or resolving conflicts.
- Inefficiency: Lambda promotion between S3 buckets is an indirect solution, adding complexity to the deployment pipeline without providing real version control.
- When to use: This approach can be used for simpler scenarios where version control isn't a major concern, but for a growing development team, this would not scale well.
Option C: AWS CodeCommit Repository with Separate Deployment Pipelines
- Advantages:
- Version Contro...
Author: Rahul · Last updated May 17, 2026
A DevOps engineer notices that all Amazon EC2 instances running behind an Application Load Balancer in an Auto Scaling group are failing to respond to user requests. The EC2 instances are also failing target group HTTP health checks.
Upon inspection, the engineer notices the application process was not running in any EC2 instances. There are a significant number of out of memory messages in the system logs. The engineer needs to improve the resilience of the application ...
Let's evaluate the different actions and their relevance to addressing the issue of application memory leaks and improving the resilience of the application.
Option A: Change the Auto Scaling Configuration to Replace the Instances When They Fail the Load Balancer's Health Checks
- Advantages:
- This action can help to quickly remove and replace instances that are unhealthy (i.e., due to memory leaks or other issues) by using the Auto Scaling group’s health checks, improving the availability and reliability of the application.
- If the application crashes or goes out of memory, this will automatically trigger a replacement of the EC2 instance, reducing downtime.
- Disadvantages:
- While this can help resolve the issue temporarily by replacing the instances, it doesn't address the root cause of the application memory leak. The problem can keep recurring if the application doesn't resolve the memory leak.
- When to use: This option is useful to ensure the application remains available even when instances experience issues, but it does not solve the underlying problem of memory leaks. Still, it contributes to resilience and availability in the short term.
Option B: Change the Target Group Health Check HealthCheckIntervalSeconds Parameter to Reduce the Interval Between Health Checks
- Advantages:
- This will make the health checks more frequent, meaning the system can detect failures faster and trigger instance replacement more promptly.
- Disadvantages:
- While this may make the system more responsive to health check failures, it doesn’t address the underlying issue of memory consumption or application crashes. Frequent health checks can lead to unnecessary checks, adding more load on the system, and it may not provide a permanent solution to memory issues.
- When to use: This action is not very effective in the context of dealing with an application memory leak. It focuses more on detection speed than on fixing the problem itself.
Option C: Change the Target Group Health Checks from HTTP to TCP to Check if the Port Where the Application is Listening is Reachable
- Advantages:
- TCP health checks can ensure the application is reachable on the specific port, regardless of the application’s ability to handle HTTP requests. This could be useful if the application is stuck but still reachable at the network level.
- Disadvantages:
- TCP checks do not verify that the application is functioning correctly (i.e., whether the application is running and responsive). While this might temporarily make the system seem healthy (if the port is open), it won't necessarily alert the system to issues like memory leaks or application crashes. HTTP health checks are more application-specific and should remain the preferred choice for checking application health.
- When to use: This option could be useful if the system is fa...
Author: Rahul · Last updated May 17, 2026
An ecommerce company uses a large number of Amazon Elastic Block Store (Amazon EBS) backed Amazon EC2 instances. To decrease manual work across all the instances, a DevOps engineer is tasked with automating restart...
Let's evaluate the different options based on the requirements: automating restart actions for EC2 instances when scheduled retirement events are triggered.
Option A: Create a Scheduled Amazon EventBridge Rule to Run an AWS Systems Manager Automation Runbook That Checks if Any EC2 Instances Are Scheduled for Retirement Once a Week. If the Instance Is Scheduled for Retirement, the Runbook Will Hibernate the Instance.
- Advantages:
- EventBridge allows for automation based on specific events, which could include EC2 instance retirement.
- Running a Systems Manager Automation runbook offers flexibility in defining actions, such as hibernating the instance, which could be useful for preserving the state of the instance during a restart.
- Disadvantages:
- This solution does not directly address the need for automatic restarts when the EC2 instances are scheduled for retirement. It focuses on a weekly check and uses the hibernation option, which might not be the most suitable or efficient method.
- It doesn’t provide real-time responses to EC2 retirement events, instead requiring a scheduled check, which may not act quickly enough when the event occurs.
- When to use: This approach is not ideal for automating actions in response to EC2 retirement events, as it involves scheduled checks rather than real-time automation based on the retirement event itself.
Option B: Enable EC2 Auto Recovery on All of the Instances. Create an AWS Config Rule to Limit the Recovery to Occur During a Maintenance Window Only.
- Advantages:
- EC2 Auto Recovery automatically recovers instances when they become impaired (due to underlying hardware failure, for example). This can keep the instances running without manual intervention.
- Disadvantages:
- EC2 Auto Recovery is designed for hardware failures and not specifically for EC2 instance retirement events. Instance retirement is different from failure or impairment, and auto recovery may not address the need for restarting instances due to scheduled retirement events.
- The setup of AWS Config rules might not be directly relevant to ensuring an action on EC2 instance retirement events.
- When to use: This approach is useful for hardware failures or impairment but not for the specific case of automating actions on EC2 retirement events.
Option C: Reboot All EC2 Instances During an Approved Maintenance Window That Is Outside of Standard Business Hours. Set Up Amazon CloudWatch Ala...
Author: Zara · Last updated May 17, 2026
A company manages AWS accounts for application teams in AWS Control Tower. Individual application teams are responsible for securing their respective AWS accounts.
A DevOps engineer needs to enable Amazon GuardDuty for all AWS accounts in which the application teams have not already enabled GuardDuty. The DevOps engineer is using AWS CloudFormation StackSets from the ...
Let's evaluate the different options based on the requirement to enable Amazon GuardDuty for all AWS accounts in which the application teams have not already enabled GuardDuty, while ensuring that the CloudFormation StackSets deployment does not fail.
Option A: Create a CloudFormation Custom Resource That Invokes an AWS Lambda Function. Configure the Lambda Function to Conditionally Enable GuardDuty if GuardDuty Is Not Already Enabled in the Accounts.
- Advantages:
- Conditional Execution: Using a Lambda function as a custom resource allows for dynamic checks to determine whether GuardDuty is enabled in each account and only enable it if needed.
- Flexibility: This method offers high flexibility and control, allowing the Lambda function to perform custom logic for each account before enabling GuardDuty.
- Disadvantages:
- Complexity: Setting up a Lambda function as a custom resource adds complexity to the solution, as you would need to manage Lambda execution roles, permissions, and handling the state of GuardDuty in each account.
- Potential Failure: If the Lambda function fails or encounters issues, it could cause CloudFormation stack deployment to fail.
- When to use: This option is suitable if custom checks and complex logic are needed for each account. However, it might be more complex than necessary for this specific use case.
Option B: Use the Conditions Section of the CloudFormation Template to Enable GuardDuty in Accounts Where GuardDuty Is Not Already Enabled.
- Advantages:
- Built-in CloudFormation Feature: The Conditions section in CloudFormation provides an easy, declarative way to conditionally create resources.
- Simplicity: This approach avoids the need for custom resources or Lambda functions, making it simpler to implement.
- Disadvantages:
- Limited Scope: The Conditions section in CloudFormation only controls the creation of resources based on static conditions but doesn’t allow querying the actual state of GuardDuty in the account. It cannot check whether GuardDuty is already enabled in the account, which is a key requirement.
- Potential Failure: Since CloudFormation can’t dynamically check the state of GuardDuty, this approach would likely fail in cases where GuardDuty is already enabled in some accounts, as CloudFormation won’t be able to skip already enabled accounts.
- When to use: This option is not appropriate because CloudFormation Conditions are static and cannot dynamically check the state of resources like GuardDuty in the target accounts.
Option C: Use the C...
Author: Daniel · Last updated May 17, 2026
A company has an AWS Control Tower landing zone. The company's DevOps team creates a workload OU. A development OU and a production OU are nested under the workload OU. The company grants users full access to the company's AWS accounts to deploy applications.
The DevOps team needs to allow only a specific management IAM role to manage ...
Let's evaluate the steps needed to meet the requirement, which is to allow only a specific management IAM role to manage IAM roles and policies of accounts within the production OU while restricting this for other OUs (development and workload OUs).
Option A: Create an SCP that Denies Full Access with a Condition to Exclude the Management IAM Role for the Organization Root.
- Advantages:
- This option could work to restrict access to IAM-related actions for all users, while allowing the specified management IAM role to perform necessary actions.
- Using the organization root as the scope could restrict full IAM access globally across accounts.
- Disadvantages:
- The SCP would be too broad if applied to the organization root. While it might help in denying access, it could impact other roles and permissions at the root level, which might not be what is desired in this case. It might prevent other necessary actions in accounts that aren't in the production OU.
- When to use: This option would be useful if the aim was to completely restrict IAM permissions across all accounts. However, the requirement specifies restricting management to IAM roles and policies in the production OU, so this approach is not ideal because it applies restrictions across the organization.
Option B: Ensure That the FullAWSAccess SCP Is Applied at the Organization Root.
- Advantages:
- FullAWSAccess is a predefined SCP that grants broad permissions. Applying this at the organization root can give full access to IAM users in all accounts, which is not restrictive.
- Disadvantages:
- While this grants full access across accounts, it doesn't fulfill the requirement to restrict IAM role and policy management to a specific management IAM role in the production OU. This would be too permissive and would not help in managing the IAM roles within just the production OU.
- When to use: This is not ideal because it doesn't address the requirement to restrict IAM permissions within the production OU. Instead, it grants unrestricted access.
Option C: Create an SCP that Allows IAM Related Actions. Attach the SCP to the Development OU.
- Advantages:
- This option would provide explicit permissions to manage IAM roles within the development OU if that's a goal.
- Disadvantages:
- However, this does not specifically address the requirement for controlling access to IAM roles in the ...
Author: Aarav2020 · Last updated May 17, 2026
A company hired a penetration tester to simulate an internal security breach. The tester performed port scans on the company's Amazon EC2 instances. The company's security measures did not detect the port scans.
The company needs a solution that automatically provides notification when port scans are performed on EC2 instances. The comp...
To meet the company's requirement of being automatically notified when port scans are performed on EC2 instances, let's evaluate each option:
A) Ensure that Amazon GuardDuty is enabled. Create an Amazon CloudWatch alarm for detected EC2 and port scan findings. Connect the alarm to the SNS topic.
- Why selected: Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity, including port scans and other suspicious network activity. GuardDuty can identify port scanning attempts and other security threats. By setting up a CloudWatch alarm for GuardDuty findings, the company can automate notifications to an SNS topic when a port scan is detected. This approach is both specific and efficient for detecting security threats such as port scans.
- Key factors: GuardDuty is purpose-built for detecting threats like port scans, and integrating it with CloudWatch and SNS ensures automatic alerts in response to specific findings.
B) Ensure that Amazon Inspector is enabled. Create an Amazon EventBridge event for detected network reachability findings that indicate port scans. Connect the event to the SNS topic.
- Why rejected: Amazon Inspector is focused on assessing security vulnerabilities, such as open ports or insecure configurations on EC2 instances. While it provides valuable insights into network reachability, it is not optimized for real-time detection of active port scans, which are better handled by Amazon GuardDuty. EventBridge integration could work, but the solution is not as suitable as GuardDuty for detecting live port scanning activity.
- Key factors: Amazon Inspector is not designed for live monitoring of attacks, but rather for vulnerability scanning and assessment.
C) Ensure that Am...
Author: Zara1234 · Last updated May 17, 2026
A company runs applications in an Amazon Elastic Kubernetes Service (Amazon EKS) cluster. The EKS cluster uses an Application Load Balancer to route traffic to the applications that run in the cluster.
A new application that was migrated to the EKS cluster is performing poorly. All the other applications in the EKS cluster maintain appropriate operation. The new application scales out horizontally to the preconfigured maximum numbe...
Let's evaluate each of the options to resolve the scaling behavior issue of the new web application in the Amazon EKS cluster:
A) Implement the Horizontal Pod Autoscaler in the EKS cluster.
- Why selected: The Horizontal Pod Autoscaler (HPA) is designed to automatically scale the number of pods in a deployment based on observed CPU utilization or custom metrics (such as memory or request latency). In this case, the new web application scales out to the maximum number of pods immediately upon deployment, but this may not be necessary if it's not receiving any traffic yet. The HPA will help adjust the number of pods dynamically based on the actual demand and traffic, rather than scaling based on preconfigured maximum values.
- Key factors: The issue here is that the application scales out too quickly to the maximum number of pods without considering actual traffic load. The HPA will allow the application to scale in a way that matches traffic levels, thus improving the resource utilization and performance of the application.
B) Implement the Vertical Pod Autoscaler in the EKS cluster.
- Why rejected: The Vertical Pod Autoscaler (VPA) automatically adjusts the CPU and memory resource requests and limits for pods. However, in this case, the issue isn't with resource allocation per pod, but rather with the number of pods that are deployed in the first place. Scaling vertically (adjusting CPU and memory per pod) will not resolve the issue of the application scaling out too quickly to the maximum number of pods before any traffic is even routed to it.
- Key factors: The problem is with scaling the number of pods, not the resource allocation per pod. VPA is not suitable for controlling the number of pods in response to actual demand.
C) Implement the Cluster Autoscaler....
Author: Ishaan · Last updated May 17, 2026
A company has an AWS Control Tower landing zone that manages its organization in AWS Organizations. The company created an OU structure that is based on the company's requirements. The company's DevOps team has established the core accounts for the solution and an account for all centralized AWS CloudFormation and AWS Service Catalog solutions.
The company wants to of...
To meet the requirement of offering a series of customizations that an account can request through AWS Control Tower, let’s evaluate each option.
A) Enable trusted access for CloudFormation with Organizations by using service-managed permissions.
- Why selected: This step is essential because AWS Control Tower uses AWS CloudFormation StackSets to deploy resources across accounts in an AWS Organization. Enabling trusted access allows AWS CloudFormation to manage resources in the accounts governed by AWS Organizations. This ensures that CloudFormation can deploy templates across accounts, aligning with Control Tower’s central management capabilities.
- Key factors: Trusted access is necessary for coordination between AWS CloudFormation and AWS Organizations for managing resources across multiple accounts.
B) Create an IAM role that is named AWSControlTowerBlueprintAccess. Configure the role with a trust policy that allows the AWSControlTowerAdmin role in the management account to assume the role. Attach the AWSServiceCatalogAdminFullAccess IAM policy to the AWSControlTowerBlueprintAccess role.
- Why rejected: This option focuses on creating a specific IAM role for control over AWS Service Catalog, but it is not required for enabling the customizations themselves in AWS Control Tower. While Service Catalog is a useful service for creating and managing standardized resources, Control Tower provides a more integrated method for customizing landing zones with the Customizations for AWS Control Tower (CfCT) CloudFormation stack. This step is useful for deeper customization but not a core requirement for offering the requested customizations through AWS Control Tower.
- Key factors: This role setup is not necessary for providing the customizations through AWS Control Tower directly.
C) Create a Service Catalog product for each CloudFormation template.
- Why selected: Creating Service Catalog products for each CloudFormation template is a key part of enabling users to request and deploy customizations in AWS Control Tower. AWS Service Catalog allows you to define a catalog of approved resources that can be deployed to AWS accounts. By setting up a Service Catalog, you enable the request and deployment of these customizations in a controlled manner.
- Key factors: Service Catalog products provide the mechanism by which end-users (e.g., account owners) can req...
Author: Noah · Last updated May 17, 2026
A company runs a workload on Amazon EC2 instances. The company needs a control that requires the use of Instance Metadata Service Version 2 (IMDSv2) on all EC2 instances in the AWS account. If an EC2 instance does not prevent the use of Instance Metadata S...
To meet the requirement of ensuring that EC2 instances use Instance Metadata Service Version 2 (IMDSv2) and terminating any EC2 instance that does not enforce IMDSv2, let’s evaluate each of the options:
A) Set up AWS Config in the account. Use a managed rule to check EC2 instances. Configure the rule to remediate the findings by using AWS Systems Manager Automation to terminate the instance.
- Why selected: AWS Config offers a managed rule for checking whether EC2 instances use IMDSv2 (the `ec2-instance-metadata-service-required` rule). This rule can evaluate the configuration of EC2 instances to ensure they are compliant with the IMDSv2 requirement. If an instance is found to be non-compliant (i.e., still using IMDSv1), the rule can trigger an AWS Systems Manager Automation runbook to automatically remediate the issue by terminating the non-compliant instance.
- Key factors: This solution provides a simple, automated way to check and enforce the use of IMDSv2 on EC2 instances. It ensures compliance by terminating non-compliant instances, meeting the company's security requirement.
B) Create a permissions boundary that prevents the ec2:RunInstance action if the ec2:MetadataHttpTokens condition key is not set to a value of required. Attach the permissions boundary to the IAM role that was used to launch the instance.
- Why rejected: While a permissions boundary could restrict the creation of EC2 instances with improper metadata configurations, this would prevent the instances from being launched in the first place, rather than addressing the scenario where an instance is already running. This does not meet the requirement of detecting and terminating instances that are already running with IMDSv1 enabled.
- Key factors: Permissions boundaries are effective for controlling permissions at launch time, but they don't address the ongoing enforcement of IMDSv2 for ...
Author: Julian · Last updated May 17, 2026
A company builds an application that uses an Application Load Balancer in front of Amazon EC2 instances that are in an Auto Scaling group. The application is stateless. The Auto Scaling group uses a custom AMI that is fully prebuilt. The EC2 instances do not have a custom bootstrapping process.
The AMI that the Auto Scaling group uses was recently deleted. The Auto Scaling group's sca...
To resolve the issue where the AMI that the Auto Scaling group uses has been deleted, the DevOps engineer needs to update the Auto Scaling group to use a valid AMI so that it can properly scale and launch new EC2 instances. Let’s evaluate each of the options:
A) Create a new launch template that uses the new AMI.
- Why selected: A launch template specifies the configuration for the EC2 instances that are launched by the Auto Scaling group, including the AMI. By creating a new launch template with a valid AMI, the DevOps engineer ensures that the Auto Scaling group can launch new instances. This step is crucial because the Auto Scaling group uses the launch template for instance configuration.
- Key factors: The AMI used in the launch template must be valid for scaling activities to proceed. This step ensures that the Auto Scaling group will use a new, valid AMI for instance creation.
B) Update the Auto Scaling group to use the new launch template.
- Why selected: After creating a new launch template with the new AMI, it is necessary to update the Auto Scaling group to use this new launch template. This ensures that future instances launched by the Auto Scaling group will use the correct AMI and configuration.
- Key factors: This step directly addresses the issue by ensuring that the Auto Scaling group is using the updated launch template with the correct AMI.
C) Reduce the Auto Scaling group's desired capacity to 0.
- Why rejected: Reducing the desired capacity to 0 would stop all instances in the Auto Scaling group, which is not required to resolve the issue of the deleted AMI. The desired capacity can be adjusted later if necessary, but reducing it to 0 will not solve the issue of invalid AMI reference and would cause the application to stop functioning.
- Key factors: This step is unnecessary and will disrupt the application, which is stateless and needs to maintain instances in the Auto Scaling group for continued operation.
D) Increase the Auto Scaling grou...
Author: Lucas · Last updated May 17, 2026
A company deploys a web application on Amazon EC2 instances that are behind an Application Load Balancer (ALB). The company stores the application code in an AWS CodeCommit repository. When code is merged to the main branch, an AWS Lambda function invokes an AWS CodeBuild project. The CodeBuild project packages the code, stores the packaged code in AWS CodeArtifact, and invokes AWS Systems Manager Run Command to deploy the packaged code to the EC2 instances.
Previous deployments have resulted in defects, EC2 instances ...
To implement a more reliable deployment solution, a DevOps engineer should focus on automation, consistency, and minimizing manual intervention, which will help resolve the issues of defects, instances not running the latest version of code, and inconsistencies. Here's an analysis of the options:
A) Create a pipeline in AWS CodePipeline that uses the CodeCommit repository as a source provider. Configure pipeline stages that run the CodeBuild project in parallel to build and test the application. In the pipeline, pass the CodeBuild project output artifact to an AWS CodeDeploy action.
- Why selected: This option automates the entire deployment process, including code retrieval, build, test, and deployment. Using CodePipeline ensures that each deployment is consistent and monitored, reducing the likelihood of defects. The integration with CodeDeploy provides a reliable and repeatable deployment strategy, ensuring all EC2 instances are updated with the same version of the code.
- Why rejected: This option isn't rejected but is part of the correct solution because it supports continuous integration and deployment and solves the main issues, such as consistency and reliability.
B) Create a pipeline in AWS CodePipeline that uses the CodeCommit repository as a source provider. Create separate pipeline stages that run a CodeBuild project to build and then test the application. In the pipeline, pass the CodeBuild project output artifact to an AWS CodeDeploy action.
- Why rejected: This option is almost identical to option A, but it specifically separates the build and test stages. While this separation could make it easier to pinpoint issues, it does not add significant value over option A and doesn’t solve the core problem more effectively. The key value of CodePipeline is in automating all stages, and separating build and test is not critical unless the tests are complex, which isn't mentioned in the problem.
C) Create an AWS CodeDeploy application and a deployment group to deploy the packaged code to the E...
Author: Zain · Last updated May 17, 2026
A company uses an organization in AWS Organizations to manage its AWS accounts. The company's automation account contains a CI/CD pipeline that creates and configures new AWS accounts.
The company has a group of internal service teams that provide services to accounts in the organization. The service teams operate out of a set of services accounts. The service teams want to receive an AWS CloudT...
To share CloudTrail events of the `CreateAccount` API call from the automation account to the service accounts, the company must ensure that the service accounts can receive the event and that permissions are properly configured. Here’s an analysis of the options:
A) Create an Amazon EventBridge rule in the automation account to send account creation events to the default event bus in the services accounts. Update the default event bus in the services accounts to allow events from the automation account.
- Why selected: This option simplifies the setup by using the default event bus in the services accounts, which is already configured to accept events. By creating an EventBridge rule in the automation account to send events to the services accounts' default event bus and configuring permissions to allow events from the automation account, the service accounts will receive the events efficiently. This approach ensures a straightforward, cross-account event sharing mechanism.
- Why rejected: This is the most direct and efficient solution. There’s no need to manage additional custom event buses, and using the default event bus in the service accounts minimizes complexity.
B) Create a custom Amazon EventBridge event bus in the services accounts. Update the custom event bus to allow events from the automation account. Create an EventBridge rule in the services account that directly listens to CloudTrail events from the automation account.
- Why rejected: While this option could work, creating a custom event bus in the service accounts adds unnecessary complexity. Using the default event bus...
Author: Elizabeth · Last updated May 17, 2026
A DevOps engineer is building a solution that uses Amazon Simple Queue Service (Amazon SQS) standard queues. The solution also includes an AWS Lambda function and an Amazon DynamoDB table. The Lambda function pulls content from an SQS queue event source and writes the content to the DynamoDB table.
The solution must maximize the scalability...
To meet the requirements of maximizing the scalability of AWS Lambda while preventing successfully processed SQS messages from being processed multiple times, we need to ensure that messages are processed efficiently and that the SQS message is not reprocessed after successful handling.
Key considerations for each option:
A) Decrease the batch window to 1 second when configuring the Lambda function's event source mapping.
- Why rejected: The batch window controls how long Lambda will wait for additional messages before invoking the function. Setting this to a very short duration like 1 second would limit how long Lambda waits to process a batch, potentially reducing efficiency when there are spikes in traffic. This wouldn't prevent message reprocessing or enhance scalability significantly. Moreover, setting a short batch window could lead to unnecessary function invocations, which is counterproductive for scalability.
B) Decrease the batch size to 1 when configuring the Lambda function's event source mapping.
- Why rejected: Decreasing the batch size to 1 means that Lambda will process only one SQS message at a time. While this approach may prevent multiple messages from being processed simultaneously, it will reduce scalability since Lambda can no longer process multiple messages in parallel, thus affecting throughput. This would not be an efficient solution, especially for high-throughput use cases.
C) Include the ReportBatchItemFailures value in the FunctionRespons...
Author: Joseph · Last updated May 17, 2026
A company has a new AWS account that teams will use to deploy various applications. The teams will create many Amazon S3 buckets for application-specific purposes and to store AWS CloudTrail logs. The company has enabled Amazon Macie for the account.
A DevOps engineer needs to optimize the Macie cos...
To optimize Amazon Macie costs while ensuring that the account's functionality remains intact, it is essential to minimize unnecessary scanning and focus on relevant data. Let’s review each option in detail:
A) Exclude S3 buckets that contain CloudTrail logs from automated discovery.
- Why selected: CloudTrail logs are typically structured and may not require the same level of sensitive data discovery that other buckets might. By excluding CloudTrail log buckets from Macie’s automated discovery, unnecessary scanning of these logs can be avoided, reducing the overall Macie cost while maintaining effective security and compliance for other data.
- Why rejected: This option should be selected because it directly reduces scanning costs associated with buckets that are unlikely to contain sensitive data.
B) Exclude S3 buckets that have public read access from automated discovery.
- Why rejected: While excluding public buckets from discovery could reduce some costs, it does not address the need to optimize Macie’s performance specifically. Public access to buckets does not necessarily mean they should be excluded from automated discovery, as these buckets could still contain sensitive data that requires discovery. Moreover, this exclusion may miss important security threats in publicly accessible buckets.
C) Configure scheduled daily discovery jobs for all S3 buckets in the account.
- Why rejected: Running daily discovery jobs for all S3 buckets increases the frequency of scanning, which could lead to unnecessary costs. Not all buckets may require daily scanning, especia...
Author: Krishna · Last updated May 17, 2026
A company uses an organization in AWS Organizations to manage its AWS accounts. The company recently acquired another company that has standalone AWS accounts. The acquiring company's DevOps team needs to consolidate the administration of the AWS accounts for both companies and retain full administrative control of the accounts. The DevOps team also needs to collect and group findings a...
The company’s DevOps team needs to consolidate AWS accounts, retain full administrative control, and collect and group findings to maintain security posture across both the acquiring and acquired companies. Let's analyze each option:
A) Invite the acquired company's AWS accounts to join the organization. Create an SCP that has full administrative privileges. Attach the SCP to the management account.
- Why rejected: While inviting the acquired accounts into the organization and creating an SCP is part of the process, creating an SCP with full administrative privileges is not a good practice. Service Control Policies (SCPs) are used to set permission guardrails, and applying one with full administrative privileges would override the benefits of using SCPs (i.e., they are supposed to restrict actions, not allow everything). The primary purpose of SCPs is to restrict permissions, not provide them, and full administrative privileges are best handled through IAM roles and policies, not SCPs.
B) Invite the acquired company's AWS accounts to join the organization. Create the OrganizationAccountAccessRole IAM role in the invited accounts. Grant permission to the management account to assume the role.
- Why selected: This solution consolidates administration effectively by enabling the management account to assume the OrganizationAccountAccessRole in the acquired accounts. This provides administrative control without requiring individual IAM roles in each account. The DevOps team can maintain full administrative access through this process. Additionally, by inviting the accounts into the organization, central management becomes easier.
- Why rejected: This is actually the most appropriate and secure way to consolidate management control because it leverages the built-in OrganizationAccountAccessRole to access accounts in the organization securely.
C) Use AWS Security Hub to collect and group findings across all accounts. Use Security Hub to automatically detect new accounts as the accounts are added to the organization.
- Why selected: AWS Security Hub is designed to aggregate and centralize security findings from multiple accounts, which helps to implement and maintain a security posture across accounts. As new accounts are added to th...
Author: Henry · Last updated May 17, 2026
A company has an application and a CI/CD pipeline. The CI/CD pipeline consists of an AWS CodePipeline pipeline and an AWS CodeBuild project. The CodeBuild project runs tests against the application as part of the build process and outputs a test r...
Let's go over each option to analyze which one would meet the requirements, and explain the reasoning behind the rejection of others:
Option A:
Add a new stage in the CodePipeline pipeline after the stage that contains the CodeBuild project. Create an Amazon S3 bucket to store the reports. Configure an S3 deploy action type in the new CodePipeline stage with the appropriate path and format for the reports.
- Pros: This option introduces a new CodePipeline stage to store test reports directly into an S3 bucket, which is appropriate for storing reports persistently.
- Cons: There is no direct reference to handling the expiration of these reports after 90 days. You would need to configure the expiration manually on the S3 bucket or add a separate lifecycle rule later.
- Reason for Rejection: While it can store reports, the option does not address the automatic expiration of the reports after 90 days. This could add unnecessary complexity as you would need to manually configure lifecycle rules in S3.
Option B:
Add a report group in the CodeBuild project buildspec file with the appropriate path and format for the reports. Create an Amazon S3 bucket to store the reports. Configure an Amazon EventBridge rule that invokes an AWS Lambda function to copy the reports to the S3 bucket when a build is completed. Create an S3 Lifecycle rule to expire the objects after 90 days.
- Pros: This option uses EventBridge to trigger a Lambda function to copy reports, and also utilizes an S3 lifecycle rule for report expiration after 90 days, which satisfies the retention requirement.
- Cons: The complexity of adding a Lambda function and configuring EventBridge introduces unnecessary overhead for what should be a relatively simple operation.
- Reason for Rejection: While it meets the functional requirement, it introduces extra complexity by involving EventBridge and Lambda. This could lead to additional maintenance overhead and potential points of failure in the pipeline.
Option C:
Add a new stage in the CodePipeline pipel...
Author: Emma · Last updated May 17, 2026
A company uses an Amazon API Gateway regional REST API to host its application API. The REST API has a custom domain. The REST API's default endpoint is deactivated.
The company's internal teams consume the API. The company wants to use mutual TLS between the API and the internal...
To meet the requirements for mutual TLS (mTLS) between Amazon API Gateway and the internal teams, we need to ensure that the API Gateway can authenticate both the server and the client (internal teams) using certificates. Mutual TLS involves both the server and client presenting certificates to each other to authenticate the connection. The company wants to add this as an additional layer of authentication for the API hosted via a custom domain.
Let's break down the options:
Option A:
Use AWS Certificate Manager (ACM) to create a private certificate authority (CA). Provision a client certificate that is signed by the private CA.
- Pros: This option is a valid approach for setting up mutual TLS in a controlled environment. The private CA will issue the client certificates that can be used by the internal teams. These client certificates can then be validated by API Gateway to ensure that only valid clients can access the API.
- Cons: None. This approach uses AWS Certificate Manager (ACM) to generate and manage a private CA, which is a scalable and secure method to provision client certificates.
- Reason for Selection: This directly meets the need for mutual TLS as it enables the creation of client certificates with a private CA.
Option B:
Provision a client certificate that is signed by a public certificate authority (CA). Import the certificate into AWS Certificate Manager (ACM).
- Pros: This approach would work in scenarios where you want to use public CAs for authentication.
- Cons: While valid client certificates could be provisioned by a public CA, it’s less secure and manageable compared to using a private CA. The use of public CAs often leads to higher costs and potential trust issues since you would have to rely on a third-party CA for internal use cases.
- Reason for Rejection: Since the company is likely managing internal teams and prefers control over certificates, using a private CA (Option A) is a more appropriate solution than using public CAs.
Option C:
Upload the provisioned client certificate to an Amazon S3 bucket. Configure the API Gateway mutual TLS to use the client certificate that is stored in the S3 bucket as the trust store.
- Pros: Storing the client certificate in an S3 bucket is possible, but...
- ...
Author: Noah · Last updated May 17, 2026
A company uses AWS Directory Service for Microsoft Active Directory as its identity provider (IdP). The company requires all infrastructure to be defined and deployed by AWS CloudFormation.
A DevOps engineer needs to create a fleet of Windows-based Amazon EC2 instances to host an application. The DevOps engineer has created a CloudFormation template that contains an EC2 launch template, IAM role, EC2 security group, and EC2 Auto Scaling group. The DevOps engi...
Let's analyze each option in detail, focusing on operational efficiency, scalability, and alignment with the given requirements:
Option A:
Create an AWS::SSM::Document resource in CloudFormation to join the EC2 instance to the AWS Managed Microsoft AD domain. Update the launch template to include the SSMAssociation property to use the new SSM document. Attach the AmazonSSMManagedInstanceCore and AmazonSSMDirectoryServiceAccess AWS managed policies to the IAM role that the EC2 instances use.
- Pros: This solution leverages AWS Systems Manager (SSM) to automate the domain joining process, which is a widely used practice for operational efficiency. The use of the SSMAssociation property in the launch template ensures that the domain join action occurs automatically during instance startup. The SSM document can be customized to use the existing directory.
- Cons: The SSM document needs to be manually defined, and while this option is highly efficient, it requires the creation and maintenance of the SSM document. For environments with large-scale or complex domain join requirements, managing custom SSM documents could become an extra overhead.
- Reason for Selection: This option is highly operationally efficient because it leverages AWS managed services to handle the domain join, which minimizes manual intervention. It integrates well with CloudFormation and allows for automation of the process during instance provisioning.
Option B:
Update the launch template to include specific tags that propagate on launch. Create an AWS::SSM::Association resource to associate the AWS-JoinDirectoryServiceDomain Automation runbook with the EC2 instances that have the specified tags. Attach the AmazonSSMManagedInstanceCore and AmazonSSMDirectoryServiceAccess AWS managed policies to the IAM role that the EC2 instances use.
- Pros: This solution uses a predefined Automation runbook (AWS-JoinDirectoryServiceDomain), which is a convenient and efficient way to join instances to an AD domain. Tagging EC2 instances can be useful for selectively applying this runbook.
- Cons: The reliance on tags for association introduces an additional layer of complexity, as the tagging process would need to be accurate to ensure that the correct instances are tagged and associated with the runbook. In large environments, managing tags for automated workflows could lead to human error or inconsistency.
- Reason for Rejection: While the AWS-JoinDirectoryServiceDomain runbook is an excellent tool, the reliance on tags can introduce unnecessary complexity and overhead in managing and tracking instance tags. This is less efficient compared to directly specifying the domain join process.
Option C:
Store the AWS Managed Microsoft AD domain connection details in AWS Secrets Manager. Create an AWS::SSM::Association resource to associat...
Author: Ava · Last updated May 17, 2026
A company uses AWS Organizations to manage its AWS accounts. The company has a root OU that has a child OU. The root OU has an SCP that allows all actions on all resources. The child OU has an SCP that allows all actions for Amazon DynamoDB and AWS Lambda, and denies all other actions.
The company has an AWS account that is named vendor-data in the child OU. A DevOps engineer has an IAM user that is attached to the Administrator Access IAM policy in the vendor-data account. The DevOps eng...
Let's break down the situation and evaluate each option to determine which change will resolve the issue of the access denied error when the DevOps engineer attempts to launch an EC2 instance:
Current Scenario:
- The company uses AWS Organizations with a root OU and a child OU.
- The root OU has an SCP that allows all actions on all resources.
- The child OU has an SCP that allows all actions for Amazon DynamoDB and AWS Lambda, but denies all other actions, including EC2.
- The vendor-data account is in the child OU.
- The DevOps engineer has an IAM user with the AdministratorAccess IAM policy attached, but is still denied access to launch an EC2 instance due to the restrictive SCP on the child OU.
Key Insights:
- SCPs (Service Control Policies) are applied at the organization level and limit the maximum permissions available to accounts in an OU.
- Even though the IAM user has full administrative privileges via the AdministratorAccess policy, the SCP applied to the child OU overrides this and denies all actions for services that are not explicitly allowed, such as EC2.
Option A: Attach the AmazonEC2FullAccess IAM policy to the IAM user.
- Pros: Attaching this IAM policy would give the user the necessary permissions to manage EC2 instances.
- Cons: IAM policies are effective only within the permissions allowed by the SCP. Since the SCP in the child OU denies all actions on EC2, the IAM policy cannot take effect because the SCP is blocking EC2 actions at the account level.
- Reason for Rejection: Attaching the AmazonEC2FullAccess IAM policy would not resolve the issue because the restrictive SCP in the child OU still prevents EC2 actions, regardless of the IAM user's permissions.
Option B: Create a new SCP that allows all actions for Amazon EC2. Attach the SCP to the vendor-data account.
- Pros: This option seems like a reasonable approach since it allows the vendor-data account to have p...
Author: ElectricLionX · Last updated May 17, 2026
A company's security policies require the use of security hardened AMIs in production environments. A DevOps engineer has used EC2 Image Builder to create a pipeline that builds the AMIs on a recurring schedule.
The DevOps engineer needs to update the launch templates of the company's Auto Scaling groups. The Auto Scaling groups must u...
Let's analyze the options based on the requirement to ensure that Auto Scaling groups always use the latest AMIs created by EC2 Image Builder with the most operational efficiency.
Key Considerations:
- Security Hardening: The company requires security-hardened AMIs, which are created using EC2 Image Builder.
- Recurring Schedule: EC2 Image Builder pipeline runs on a recurring schedule to build new AMIs.
- Operational Efficiency: The solution should ensure that the Auto Scaling groups automatically use the latest AMI version without manual intervention.
Option A:
Configure an Amazon EventBridge rule to receive new AMI events from Image Builder. Target an AWS Systems Manager Run Command document that updates the launch templates of the Auto Scaling groups with the newest AMI ID.
- Pros: Using EventBridge to trigger updates based on new AMI creation is an automated approach. Systems Manager Run Command can be used to automate tasks like updating launch templates.
- Cons: Using Systems Manager Run Command adds complexity as it requires additional configurations and steps (e.g., managing runbooks, permissions). This might introduce more operational overhead and requires more manual management than necessary.
- Reason for Rejection: Although effective, this solution is more complex compared to others, and it's not as streamlined as directly using AWS Lambda or other native AWS integrations.
Option B:
Configure an Amazon EventBridge rule to receive new AMI events from Image Builder. Target an AWS Lambda function that updates the launch templates of the Auto Scaling groups with the newest AMI ID.
- Pros: Using AWS Lambda in conjunction with EventBridge is highly automated and flexible. Lambda functions can be customized to update the Auto Scaling group launch templates with the latest AMI ID in an efficient, serverless manner.
- Cons: While this is a great solution for automation, Lambda functions do require some setup (e.g., permissions, IAM roles). However, this approach is highly scalable and avoids the need for additional management tools.
- Reason for Selection: This solution is clean, automated, and directly responds to the AMI creation events. It ensures that the Auto Scaling groups always use the latest AMI, with minimal operational overhead. Lambda offers flexibility, scalability, and is a highly operationally efficient choice.
Option C:
Configure the launch templa...
Author: Rohan · Last updated May 17, 2026
A company has configured an Amazon S3 event source on an AWS Lambda function. The company needs the Lambda function to run when a new object is created or an existing object is modified in a particular S3 bucket. The Lambda function will use the S3 bucket name and the S3 object key of the incoming event to read the contents of the created or modified S3 object. The Lambda function will parse the contents and save the parsed contents to an Amazon DynamoDB table.
The Lambda function's execution role has permissions to read from the S3 bucket and ...
Let's evaluate the options one by one based on the scenario:
A) Increase the memory of the Lambda function to give the function the ability to process large files from the S3 bucket.
- Explanation: Increasing memory in the Lambda function is important for handling large files, but this is not directly related to the trigger not firing when new objects are created or modified in the S3 bucket. The issue described is that the Lambda function is not being invoked at all, not that it cannot process large files.
- Reason for rejection: This solution does not address the root cause of the Lambda trigger not being invoked by S3 events.
- Use case: This would be applicable if the issue were about processing large files but not relevant to the Lambda invocation issue.
B) Create a resource policy on the Lambda function to grant Amazon S3 the permission to invoke the Lambda function for the S3 bucket.
- Explanation: When you configure an S3 bucket to invoke a Lambda function, you need to ensure that the Lambda function has the necessary permissions to be invoked by S3. This is done through a resource policy that grants S3 the permission to invoke the Lambda function. Without this permission, S3 events cannot trigger the Lambda function.
- Reason for selection: This is the most likely solution to the problem, as it directly addresses the issue of the Lambda function not being invoked by S3 events.
- Use case: This solution is neede...
Author: MoonlitPantherX · Last updated May 17, 2026
A company has deployed a critical application in two AWS Regions. The application uses an Application Load Balancer (ALB) in both Regions. The company has Amazon Route 53 alias DNS records for both ALBs.
The company uses Amazon Route 53 Application Recovery Controller to ensure that the application can fail over between the two Regions. The Route 53 ARC configuration includes a routing control for both Regions. The company uses Route 53 ARC to perform quarterly disaster recovery (DR) tests.
During the m...
Let's evaluate the options step by step:
A) In Route 53 ARC, create a new assertion safety rule. Apply the assertion safety rule to the two routing controls. Configure the rule with the ATLEAST type with a threshold of 1.
- Explanation: The assertion safety rule with the ATLEAST type and a threshold of 1 ensures that at least one of the two routing controls must be turned on. This is exactly what is needed to ensure that at least one routing control is active at all times.
- Reason for selection: This is the most direct solution to the problem. It will enforce the requirement that at least one routing control is active, which prevents both from being accidentally turned off.
- Use case: This option is ideal when you need to ensure that a minimum number of routing controls (in this case, 1) is always active.
B) In Route 53 ARC, create a new gating safety rule. Apply the assertion safety rule to the two routing controls. Configure the rule with the OR type with a threshold of 1.
- Explanation: The OR type in a gating safety rule ensures that if one of the routing controls is turned on, the system will consider it as "satisfied," but it doesn't necessarily prevent both from being turned off. This rule is used to allow flexibility, but it won't guarantee that at least one routing control is always on, which is the core requirement here.
- Reason for rejection: The OR type doesn't fully meet the requirement of ensuring that at least one routing control is always on. It allows either one of them to be turned off, so it doesn't strictly prevent the problem the company encountered.
- Use case: This would be useful if you want more flexibility in routing control configurations but doesn't fit the need to guarantee at least one routing control is active....
Author: Maya · Last updated May 17, 2026
A healthcare services company is concerned about the growing costs of software licensing for an application for monitoring patient wellness. The company wants to create an audit process to ensure that the application is running exclusively on Amazon EC2 Dedicated Hosts. A DevOps engineer must create a workflow to audit th...
Let's evaluate each option in the context of meeting the requirement with the least administrative overhead:
A) Use AWS Systems Manager Configuration Compliance. Use calls to the `put-compliance-items` API action to scan and build a database of noncompliant EC2 instances based on their host placement configuration. Use an Amazon DynamoDB table to store these instance IDs for fast access. Generate a report through Systems Manager by calling the `list-compliance-summaries` API action.
- Explanation: This option involves creating custom API calls to monitor and store noncompliant EC2 instances based on host placement. It requires manual setup to call the `put-compliance-items` API, store data in DynamoDB, and generate reports.
- Reason for rejection: While this is a valid solution, it introduces manual overhead in the form of custom API calls and data management. AWS Systems Manager Configuration Compliance can do the job but without native support for the exact EC2 Dedicated Host compliance check. It would require significant custom development and maintenance, leading to higher administrative overhead.
- Use case: This could be used if a custom, specific solution is required, but it involves significant complexity.
B) Use custom Java code running on an EC2 instance. Set up EC2 Auto Scaling for the instance depending on the number of instances to be checked. Send the list of noncompliant EC2 instance IDs to an Amazon SQS queue. Set up another worker instance to process instance IDs from the SQS queue and write them to Amazon DynamoDB. Use an AWS Lambda function to terminate noncompliant instance IDs obtained from the queue, and send them to an Amazon SNS email topic for distribution.
- Explanation: This approach uses EC2 Auto Scaling, SQS, Lambda, and custom Java code. It involves multiple components and would require manual monitoring and maintenance of EC2 instances, Lambda functions, SQS queues, DynamoDB, and SNS.
- Reason for rejection: While it could work, this solution introduces considerable complexity. It requires managing EC2 instances, scaling, Lambda functions, and other components, which increases administrative overhead significantly.
- Use case: This option might be useful in highly customized workflows but involves too much overhead for the given requirement.
C) Use AWS Config. Identify all EC2 instances to be audited by enabling Config Recording on all Amazon EC2 resources for the region. Create a custom A...
Author: Kai · Last updated May 17, 2026
A DevOps engineer is planning to deploy a Ruby-based application to production. The application needs to interact with an Amazon RDS for MySQL database and should have automatic scaling and high availability. The stored data in the database is critical and should persist regardless of the state of the application stack.
The DevOps engineer needs to set up an automated deployment strategy for the application...
Let's evaluate the options one by one to determine the most effective combination to meet the requirements for automatic scaling, high availability, automated deployment, and alerting for deployment failures.
A) Deploy the application on AWS Elastic Beanstalk. Deploy an Amazon RDS for MySQL DB instance as part of the Elastic Beanstalk configuration.
- Explanation: This option involves deploying the application on AWS Elastic Beanstalk and creating the RDS for MySQL instance as part of the Elastic Beanstalk configuration. While Elastic Beanstalk does provide automatic scaling and a managed environment for your application, embedding RDS in this configuration could complicate database management, particularly for high availability, as Elastic Beanstalk typically does not manage the database's availability and persistence effectively compared to managing the RDS instance separately.
- Reason for rejection: Although it can work, deploying RDS as part of Elastic Beanstalk may not provide the level of high availability and persistence needed for critical data, and Elastic Beanstalk is better suited for handling the application layer while keeping RDS separate for better control.
B) Deploy the application on AWS Elastic Beanstalk. Deploy a separate Amazon RDS for MySQL DB instance outside of Elastic Beanstalk.
- Explanation: This option involves deploying the application on Elastic Beanstalk and deploying an RDS for MySQL database instance separately. This is a more effective approach because it separates the application layer from the database layer, ensuring better control over the database's high availability, persistence, and backup options.
- Reason for selection: Deploying RDS separately allows for better management of the database’s availability (such as enabling Multi-AZ for RDS), and it aligns with the best practices of separating application and database layers. Elastic Beanstalk provides automatic scaling for the application, while the RDS database can be configured independently for high availability and persistence.
- Use case: This is the ideal solution as it separates application deployment (Elastic Beanstalk) and database management (RDS), ensuring better scalability, high availability, and persistence.
C) Configure a notification email address that alerts the application team in the AWS Elastic Beanstalk configuration.
- Explanation: This option enables setting up notifications for deployment failures or status changes via email alerts. Elastic Beanstalk has built-in notification functionality for deployment health, making it easy to alert the application team if something goes wrong.
- Reason for selection: This option directly supports the requirement to alert the application team when a deployment fails, making it a necessary part of the solution to ensure visibility and automatic communication.
- Use c...
Author: Ravi Patel · Last updated May 17, 2026
A company is using AWS CodePipeline to deploy an application. According to a new guideline, a member of the company's security team must sign off on any application changes before the changes are deployed into production. The approval mus...
Let's evaluate the options one by one to determine the most effective solution to meet the requirements of having the security team sign off on application changes and retaining the approval record.
A) Configure CodePipeline to write actions to Amazon CloudWatch Logs.
- Explanation: Writing actions to Amazon CloudWatch Logs will help in tracking the actions and events happening during the pipeline execution. However, this alone does not specifically address the requirement for a security team member to approve the changes before deployment.
- Reason for rejection: While CloudWatch Logs can provide useful information about pipeline events, it does not facilitate the manual approval process by the security team, nor does it inherently support approval recording and retention.
- Use case: CloudWatch Logs can be useful for monitoring, but it doesn't meet the specific requirement for the security team approval and retention.
B) Configure CodePipeline to write actions to an Amazon S3 bucket at the end of each pipeline stage.
- Explanation: Storing actions in an Amazon S3 bucket could capture the pipeline's progress and actions. However, it does not provide a structured approval process nor does it ensure that a security team member signs off on the changes.
- Reason for rejection: While this approach might store useful data about pipeline execution, it doesn't fulfill the specific requirement of having a security team member approve the changes, nor does it automate the process of recording and retaining the approval.
- Use case: This could be used for general logging or backup purposes but doesn't address the approval process needed by the security team.
C) Create an AWS CloudTrail trail to deliver logs to Amazon S3.
- Explanation: CloudTrail records AWS API calls, and while it can track the changes made to CodePipeline, it does not specifically handle the manual approval step by the security team. CloudTrail logs can help in auditing the actions taken but don't directly support approval workflows.
- Reason for rejection: CloudTrail logs are good for auditing and tracking API calls, but they do not mee...
Author: ThunderBear · Last updated May 17, 2026
A company requires its internal business teams to launch resources through pre-approved AWS CloudFormation templates only. The security team requires automated monitoring when resources drift fro...
To determine the best strategy, let's review the options based on the company's requirements:
Requirements:
1. Only pre-approved CloudFormation templates should be used for launching resources.
2. Automated monitoring when resources drift from their expected state is required.
Option Analysis:
A) Allow users to deploy CloudFormation stacks using a CloudFormation service role only. Use CloudFormation drift detection to detect when resources have drifted from their expected state.
- Pros:
- Drift detection is specifically designed to identify changes from the original template's state.
- Provides an automated way to detect drifts within CloudFormation-managed resources.
- Cons:
- The drift detection mechanism in CloudFormation requires manual invocation or periodic checks, and it is not an automatic trigger for monitoring. While it can detect drift, it doesn't provide continuous automated monitoring out-of-the-box.
- Best Use Case: When CloudFormation drift detection is desired in smaller-scale environments where the team is okay with periodic checks instead of continuous monitoring.
B) Allow users to deploy CloudFormation stacks using a CloudFormation service role only. Use AWS Config rules to detect when resources have drifted from their expected state.
- Pros:
- AWS Config can continuously monitor resources for drift and can provide detailed compliance reports.
- More granular and continuous monitoring is supported by AWS Config, which can alert the security team when drift occurs.
- Cons:
- It doesn't strictly enforce the use of pre-approved templates (although CloudFormation service roles can manage this aspect to some degree).
- Best Use Case: For environments that require continuous, automated drift monitoring with a security-focused solution.
C) Allow users to deploy CloudFormation stacks using AWS Service Catalog only. Enforce the use of a launch constraint. Use AWS Config ...
Author: Ahmed97 · Last updated May 17, 2026
A company has multiple development groups working in a single shared AWS account. The senior manager of the groups wants to be alerted via a third-party API call when the creation of resources approaches the service limits for...
Analysis of Options:
A) Create an Amazon EventBridge rule that runs periodically and targets an AWS Lambda function. Within the Lambda function, evaluate the current state of the AWS environment and compare deployed resource values to resource limits on the account. Notify the senior manager if the account is approaching a service limit.
- Pros:
- This approach directly targets the service limit issue by evaluating the current environment and resource usage.
- It provides flexibility, as you can compare the deployed resources with the actual service limits.
- Cons:
- Requires custom logic in the Lambda function to retrieve resource usage and compare it with service limits, which involves a bit of development effort.
- It doesn’t have built-in service limit monitoring, so the development effort may be higher than other solutions.
- Best Use Case: If you want full control over how the service limits are monitored and customized. However, it requires more development effort compared to other solutions.
B) Deploy an AWS Lambda function that refreshes AWS Trusted Advisor checks, and configure an Amazon EventBridge rule to run the Lambda function periodically. Create another EventBridge rule with an event pattern matching Trusted Advisor events and a target Lambda function. In the target Lambda function, notify the senior manager.
- Pros:
- Trusted Advisor provides insights into AWS account usage and potential risks, including service limits.
- This solution uses built-in AWS services (Trusted Advisor, EventBridge) with relatively low development effort.
- Cons:
- Trusted Advisor checks might not provide complete and real-time service limit data. It might not cover every specific limit that the company is concerned about.
- While it provides useful information, it might not be tailored to every service's limits and could require some customization for a comprehensive solution.
- Best Use Case: When using AWS Trusted Advisor to track various AWS limits and get broad, high-level insights into account health.
C) Deploy an AWS Lambda function that refreshes AWS Health Dashboard checks, and configure an Amazon EventBridge rule to run the Lambda function periodically. Create another EventBridge rule with an event pattern matching Health Dashboard events and a target ...
Author: Ethan Smith · Last updated May 17, 2026
A DevOps engineer is setting up a container-based architecture. The engineer has decided to use AWS CloudFormation to automatically provision an Amazon ECS cluster and an Amazon EC2 Auto Scaling group to launch the EC2 container instances. After successfully creating the CloudFormation stack, the engineer noticed that, even though the ECS cluster and the EC2 instances were created successfully and the stack...
Problem Analysis:
The issue is that the EC2 instances are associating with the wrong ECS cluster. This happens because the ECS container instances must be registered with the correct ECS cluster via their user data configuration.
Option Analysis:
A) Reference the EC2 instances in the AWS::ECS::Cluster resource and reference the ECS cluster in the AWS::ECS::Service resource.
- Pros:
- The ECS cluster is used for managing services and tasks, but this option doesn’t directly address the need for EC2 instances to register with the ECS cluster. The `AWS::ECS::Cluster` resource typically defines the ECS cluster itself, and the `AWS::ECS::Service` resource is used for managing services, not directly for instance registration.
- Cons:
- This option doesn’t solve the core problem of associating the EC2 instances with the ECS cluster.
- Best Use Case: When you need to define ECS services but not for registering EC2 instances with the ECS cluster.
B) Reference the ECS cluster in the AWS::AutoScaling::LaunchConfiguration resource of the UserData property.
- Pros:
- This option allows for passing configuration into the EC2 instances' user data, which is crucial for registering the EC2 instances with the correct ECS cluster.
- The EC2 instances need to be configured with the ECS cluster during initialization, which is typically done via user data.
- Cons:
- This approach involves configuring the user data of the EC2 instances, but it might not be the most direct and efficient way of ensuring proper ECS cluster registration.
- Best Use Case: If the ECS cluster needs to be passed to EC2 instances during initialization, this is a valid approach but could require manual setup in the launch configuration.
C) Reference the ECS cluster in ...
