Amazon Practice Questions, Discussions & Exam Topics by our Authors
A DevOps engineer is implementing governance controls for a company that requires its infrastructure to be housed within the United States. The engineer must restrict which AWS Regions can be used, and ensure an alert is sent as soon as possible if any activity outside the governance policy takes place. The controls should be auto...
Requirements Breakdown:
1. Restrict AWS Regions to only the United States — This means preventing access to non-US regions.
2. Automatically enable the controls on any new Region — The controls should apply to new regions by default.
3. Send alerts immediately for any non-compliant activity — Alerts should be triggered as soon as any activity occurs in non-US regions.
Option Analysis:
A) Create an AWS Organizations SCP that denies access to all non-global services in non-US Regions. Attach the policy to the root of the organization.
- Pros:
- AWS Organizations Service Control Policies (SCPs) are designed to control permissions for accounts in an organization. This option directly restricts access to non-US Regions by denying services in those regions.
- It ensures that the policy is automatically applied to any new AWS Regions, as the SCP is enforced organization-wide.
- Cons:
- SCPs do not provide alerting functionality, so a separate mechanism for alerting would be required.
- Best Use Case: Ideal for restricting access to specific regions and ensuring that the governance policy is applied organization-wide, including new regions.
B) Configure AWS CloudTrail to send logs to Amazon CloudWatch Logs and enable it for all Regions. Use a CloudWatch Logs metric filter to send an alert on any service activity in non-US Regions.
- Pros:
- AWS CloudTrail logs service activity across all regions, and integrating it with CloudWatch Logs allows for real-time monitoring and alerting.
- The metric filter can be set up to detect activity in non-US regions and trigger alerts immediately when such activity occurs.
- Cons:
- This solution only focuses on detecting and alerting after the fact, but it does not prevent activity in non-US regions (it doesn't directly control which regions can be used).
- Best Use Case: Best suited for monitoring and alerting purposes, making it a good complement to the SCP for enforcement.
C) Use an AWS Lambda function that checks for AWS service activity and deploy it to all Regions. Write an Amazon EventBridge rule that runs the Lambda function every hour, sending an alert if activity is found in a non-US Region.
- Pros:
- AWS Lambda can be used to query for service activity and trigger alerts based on findings.
-...
Author: Ryan · Last updated Jul 20, 2026
A company sells products through an ecommerce web application. The company wants a dashboard that shows a pie chart of product transaction details. The company wants to integrate the dashboard with the company's existing Amazon CloudW...
Requirements:
1. Dashboard Integration: The company wants a pie chart representation of transaction data on its existing CloudWatch dashboards.
2. Operational Efficiency: The solution should be efficient, ideally leveraging existing AWS services for monitoring, logging, and visualization without complex or manual interventions.
Option Analysis:
A) Update the ecommerce application to emit a JSON object to a CloudWatch log group for each processed transaction. Use CloudWatch Logs Insights to query the log group and to visualize the results in a pie chart format. Attach the results to the desired CloudWatch dashboard.
- Pros:
- CloudWatch Logs Insights provides a built-in querying and visualization mechanism for CloudWatch logs.
- You can directly use CloudWatch Logs Insights to query the JSON data emitted by the application and create visualizations such as pie charts.
- Seamless integration with existing CloudWatch dashboards, which is a key requirement.
- Operational efficiency: No need for additional services like Athena or DynamoDB, simplifying the architecture.
- Cons:
- The log data might need to be structured correctly to enable meaningful insights. While CloudWatch Logs Insights is powerful, it may require some setup for efficient querying.
- Best Use Case: When you already have log data in CloudWatch and need to quickly visualize metrics from those logs. It's straightforward and leverages existing infrastructure.
B) Update the ecommerce application to emit a JSON object to an Amazon S3 bucket for each processed transaction. Use Amazon Athena to query the S3 bucket and to visualize the results in a pie chart format. Export the results from Athena. Attach the results to the desired CloudWatch dashboard.
- Pros:
- Athena allows you to query structured data stored in S3 with SQL-like queries, which is powerful for large datasets.
- You can visualize the data externally from Athena, potentially leveraging Amazon QuickSight for advanced dashboards.
- Cons:
- This solution introduces unnecessary complexity, as it involves emitting data to S3, using Athena for queries, and potentially using QuickSight for visualization (though QuickSight is not directly integrated with CloudWatch dashboards).
- Operational inefficiency: More moving parts (S3, Athena, QuickSight) increase maintenance complexity and are more involved than needed for the requirement of integrating with CloudWatch.
- Best Use Case: If you are already using S3 and Athena for other parts of your data pipeline, but it’s overcomplicated for simply visualizing CloudWatch logs.
C) Update the ecommerce application to use A...
Author: Aarav2020 · Last updated Jul 20, 2026
A company is launching an application. The application must use only approved AWS services. The account that runs the application was created less than 1 year ago and is assigned to an AWS Organizations OU.
The company needs to create a new Organizations account structure. The account structure must have an appropriate SCP that supports the use of only services that are currently ac...
The goal is to ensure that the AWS account structure only allows services that are currently active in the AWS account, and the solution should use AWS Identity and Access Management (IAM) Access Analyzer for identifying which services are active. We are also tasked with creating an appropriate Service Control Policy (SCP) and organizing accounts within AWS Organizations. Let’s evaluate each option based on the requirements.
A) Create an SCP that allows the services that IAM Access Analyzer identifies. Create an OU for the account. Move the account into the new OU. Attach the new SCP to the new OU. Detach the default FullAWSAccess SCP from the new OU.
Pros:
- Focused SCP Application: Attaching the new SCP to the Organizational Unit (OU) helps to limit the access to the allowed services in the specific OU, which makes sense when trying to restrict the use of only approved services.
- SCP Customization: The SCP allows only the services identified by IAM Access Analyzer, which is a tailored solution.
- Detaching FullAWSAccess: Detaching the FullAWSAccess SCP ensures that the default unrestricted access is not available, allowing only the specified services.
Cons:
- Potential Risk of Misconfiguration: Moving the account into a new OU and detaching FullAWSAccess could inadvertently lead to misconfigurations, as it requires careful management of SCPs.
- Complexity: It requires understanding of which services IAM Access Analyzer identifies and making sure the new SCP is correctly implemented, which can introduce complexity.
Conclusion: This option is appropriate if the organization wants to implement a restricted access model for specific services while ensuring the new OU is properly controlled.
B) Create an SCP that denies the services that IAM Access Analyzer identifies. Create an OU for the account. Move the account into the new OU. Attach the new SCP to the new OU.
Pros:
- Clear Denial: This approach uses a "deny" SCP, which clearly denies the identified services, ensuring no unauthorized access.
Cons:
- Denying Services: Denying services identified by IAM Access Analyzer is a less flexible approach than the allow-based policy in Option A. While this solution restricts services, it doesn't specifically permit the services that are active in the account, potentially blocking unintended services that the account still requires.
- Negative Impact on Active Services: By denying services, you might inadvertently block active services that the account needs for its current workload or operations, leading to disruptions.
Conclusion: This option could work, but it's not as target...
Author: Akash · Last updated Jul 20, 2026
A company has multiple development teams in different business units that work in a shared single AWS account. All Amazon EC2 resources that are created in the account must include tags that specify who created the resources. The tagging must occur within the first hour of resource creation.
A DevOps engineer needs to add tags to the created resources that include the user ID that created the resource and the cost center ID. The DevOps engineer configures an AWS Lambda function with the cost...
To meet the tagging requirements, we need a solution that automatically tags Amazon EC2 resources with the correct user ID and cost center ID within the first hour of resource creation. Since CloudTrail captures API activities, including EC2 resource creation events, we need to use this information to trigger the tagging action.
Let's break down each option:
A) Create an S3 event notification on the S3 bucket to invoke the Lambda function for `s3:ObjectTagging:Put` events. Enable bucket versioning on the S3 bucket.
Pros:
- S3 Event Notification: S3 event notifications are useful for triggering Lambda functions based on certain events in an S3 bucket.
- Versioning: Enabling versioning ensures that the S3 logs are properly versioned and kept intact.
Cons:
- Irrelevant Event Type: The event type `s3:ObjectTagging:Put` triggers when tags are put on objects in the S3 bucket. However, this has no direct relation to EC2 resource creation events. CloudTrail logs the events related to EC2 resource creation, not S3 object tagging.
- Not Relevant for EC2: This solution focuses on S3 object tagging, but we are interested in triggering actions when EC2 resources are created, which is a completely different use case.
Conclusion: This option is not suitable because the event type and context are not aligned with the EC2 resource creation requirements.
B) Enable server access logging on the S3 bucket. Create an S3 event notification on the S3 bucket for `s3:ObjectTagging:` events.
Pros:
- Server Access Logging: Server access logging helps track access to the S3 bucket, which could be useful for auditing and tracking access patterns.
Cons:
- Irrelevant Event Type: Like option A, this solution focuses on `s3:ObjectTagging:` events, which would track when tags are put on S3 objects. This is not related to EC2 resource creation, which is the primary requirement.
- Not Useful for EC2 Resources: The requirement is to tag EC2 resources, not objects in an S3 bucket. This option doesn’t directly address the tagging of EC2 resources created via CloudTrail.
Conclusion: This is not relevant to the use case because it only handles tagging events for S3 objects.
C) Crea...
Author: Lucas Carter · Last updated Jul 20, 2026
A company runs an application for multiple environments in a single AWS account. An AWS CodePipeline pipeline uses a development Amazon Elastic Container Service (Amazon ECS) cluster to test an image for the application from an Amazon Elastic Container Registry (Amazon ECR) repository. The pipeline promotes the image to a production ECS cluster.
The company needs to move the production cluster into a se...
The company needs to separate the production ECS cluster into a new AWS account while ensuring that the production ECS tasks can download images from an Amazon ECR repository in the main account over a private connection. The goal is to allow secure and efficient image access between accounts while using a private connection (e.g., VPC endpoints).
Let's evaluate each option based on the requirements:
A) Use Amazon ECR VPC endpoints and an Amazon S3 gateway endpoint. In the separate AWS account, create an ECR repository. Set the repository policy to allow the production ECS tasks to pull images from the main AWS account. Configure the production ECS task execution role to have permission to download the image from the ECR repository.
Pros:
- VPC Endpoint for Private Connection: ECR VPC endpoints ensure that the communication between the production ECS tasks and the ECR repository occurs over a private connection.
Cons:
- Extra Complexity with Separate ECR Repository: This option suggests creating a new ECR repository in the separate AWS account. This introduces additional complexity since you would need to manage synchronization between the two repositories and replicate the images between them, which isn’t ideal for maintaining a single source of truth for your images.
- Unnecessary S3 Gateway Endpoint: The mention of an Amazon S3 gateway endpoint here is unnecessary since the focus is on ECR and not S3. This adds confusion and complexity without contributing to the solution.
Conclusion: This option is overcomplicated and introduces additional management overhead, especially with the need to replicate images between separate repositories.
B) Set a repository policy on the production ECR repository in the main AWS account. Configure the repository policy to allow the production ECS tasks in the separate AWS account to pull images from the main account. Configure the production ECS task execution role to have permission to download the image from the ECR repository.
Pros:
- Direct Repository Policy for Cross-Account Access: This solution allows the production ECS tasks in the separate account to directly pull images from the main ECR repository using an appropriate repository policy.
- Simpler Management: This avoids creating a new repository and allows all images to remain in the existing repository in the main AWS account, reducing complexity.
Cons:
- No Mention of Private Connection: This solution doesn't mention using a private connection for image download. While the repository policy allows cross-account access, it doesn't specify whether the connection is private, which might be a requirement in the scenario. This might leave the connection open to the public internet, unless the VPC endpoints are configured separately.
Conclusion: This is a good solution for cross-account image access but needs a...
Author: Ahmed · Last updated Jul 20, 2026
A company needs to ensure that flow logs remain configured for all existing and new VPCs in its AWS account. The company uses an AWS CloudFormation stack to manage its VPCs. The company needs a solution that will ...
To ensure that VPC flow logs are always configured for all existing and new VPCs in an AWS account, the company needs to implement a solution that will apply to both existing VPCs and any new VPCs created by IAM users.
Let's evaluate each option:
A) Add the AWS::EC2::FlowLog resource to the CloudFormation stack that creates the VPCs.
Pros:
- Automated for CloudFormation: Adding an `AWS::EC2::FlowLog` resource in the CloudFormation template ensures that VPC flow logs are enabled for any VPC created through this stack.
Cons:
- Limited Scope: This only works for VPCs created by CloudFormation. It does not apply to VPCs created manually by IAM users or VPCs created via other methods (like the AWS Management Console or the AWS CLI). The solution doesn't address the requirement for "any VPCs that any IAM user creates."
Conclusion: This option is useful if VPCs are exclusively created via CloudFormation. However, it does not work for manually created VPCs by IAM users, which is a requirement in this case.
B) Create an organization in AWS Organizations. Add the company's AWS account to the organization. Create an SCP to prevent users from modifying VPC flow logs.
Pros:
- Enforces Governance at the Organization Level: This solution would be effective in preventing users from modifying VPC flow logs by restricting their actions at the organizational level.
Cons:
- Prevents Changes, Not Enforces Creation: The SCP can prevent users from disabling VPC flow logs, but it does not automatically enable them for new VPCs. It is more of a preventive control to stop users from modifying existing flow logs rather than ensuring that flow logs are configured for every new VPC.
Conclusion: While this solution provides control over modifying flow logs, it does not meet the requirement of ensuring flow logs are enabled on new VPCs.
C) Turn on AWS Config. Create an AWS Config rule to check whether VP...
Author: Kai99 · Last updated Jul 20, 2026
A company's application teams use AWS CodeCommit repositories for their applications. The application teams have repositories in multiple AWS accounts. All accounts are in an organization in AWS Organizations.
Each application team uses AWS IAM Identity Center (AWS Single Sign-On) configured with an external IdP to assume a developer IAM role. The developer role allows the application teams to use Git to work with the code in the repositories.
A security audit reveals that the application teams can modify the main branch in any r...
The goal is to allow application teams to modify the main branch of only the repositories that they manage while ensuring a secure process that limits their access to only the repositories they are responsible for.
Let’s break down the options:
A) Update the SAML assertion to pass the user's team name. Update the IAM role's trust policy to add an access-team session tag that has the team name.
Pros:
- Session Tags: Adding the team name as a session tag through the IAM role’s trust policy ensures that when a developer assumes the role, it’s tied to their specific team.
- Granular Control: Using session tags can help in defining specific permissions based on the team name, which can later be used to control access to repositories.
Cons:
- Complex Setup: This would require updating the IAM role's trust policy and configuring the external IdP to send the correct team name in the SAML assertion. While this is a powerful mechanism for controlling access, it adds complexity to the setup.
Conclusion: This is a good approach as it provides granularity, but it will require careful setup and coordination with the external IdP.
B) Create an approval rule template for each team in the Organizations management account. Associate the template with all the repositories. Add the developer role ARN as an approver.
Pros:
- Approval Process: This solution allows enforcing approval processes for changes to repositories, which adds a layer of control.
Cons:
- Does Not Solve Branch Modification Restriction: The approval rule template will help with controlling changes through an approval workflow but does not specifically limit the ability to modify the main branch. The core issue is controlling who can modify the main branch, and this approach doesn't directly address that.
Conclusion: This option does not address the main concern of restricting access to the main branch for specific teams. It is helpful for approval workflows but doesn’t solve the problem.
C) Create an approval rule template for each account. Associate the template with all repositories. Add the "aws:ResourceTag/access-team": "$ ;{aws:PrincipalTag/access-team}" condition to the approval rule template.
Pros:
- Conditional Access Based on Tags: By adding a condition based on the resource tag, this approach allows for restricting actions on repositories to specific teams, which is exactly the requirement.
- Enforcement: This ensures that only users with the correct team tag can perform actions on the repositories they manage, thus restricting modification of the main branch.
Cons:
- Complex Setup: Requires setting up and associating approval rule templates with each repository and ensuring the correct tags are in place.
Conc...
Author: Aarav2020 · Last updated Jul 20, 2026
A company uses AWS WAF to protect its cloud infrastructure. A DevOps engineer needs to give an operations team the ability to analyze log messages from AWS WAF. The operations team needs to be able to create alarms for specific patterns ...
To meet the requirement of allowing the operations team to analyze log messages from AWS WAF and create alarms for specific patterns in the log output with the least operational overhead, let's analyze each option.
Option A: CloudWatch Logs with Metric Filters
- Steps: Create an Amazon CloudWatch Logs log group, configure AWS WAF to send logs to the group, and instruct the operations team to create CloudWatch metric filters.
- Reasoning: This is a low-overhead solution as CloudWatch Logs natively supports log analysis, pattern matching, and alarm creation using metric filters. CloudWatch metric filters allow the operations team to easily create alarms based on specific log patterns. The operational overhead is minimal because CloudWatch is a fully managed service.
- Pros:
- Fully integrated solution.
- Low operational overhead.
- Easy to use for creating alarms based on log patterns.
- Cons:
- Limited query capabilities compared to other solutions like OpenSearch or Athena.
Option B: OpenSearch Service with Kinesis Data Firehose
- Steps: Create an OpenSearch cluster, configure Kinesis Data Firehose to stream logs, and use OpenSearch Dashboards for analysis.
- Reasoning: While OpenSearch provides powerful search and analysis capabilities, it introduces higher operational overhead due to the need to manage an OpenSearch cluster, configure the Kinesis Firehose delivery stream, and maintain the dashboards. This option is more suited for complex log analysis scenarios where advanced search and visualizations are required.
- Pros:
- Powerful log search and visualization features.
- Scalability for large datasets.
- Cons:
- Higher operational overhead (management of OpenSearch cluster...
Author: Evelyn · Last updated Jul 20, 2026
A software team is using AWS CodePipeline to automate its Java application release pipeline. The pipeline consists of a source stage, then a build stage, and then a deploy stage. Each stage contains a single action that has a runOrder value of 1.
The team wants to integrate unit tests into the existing release pipeli...
To meet the requirement of integrating unit tests into the AWS CodePipeline and deploying only the code changes that pass all unit tests, let's analyze the available options.
Option A: Modify the Build Stage - Add Test Action with AWS CodeDeploy
- Reasoning: AWS CodeDeploy is primarily used for deployment automation. It is not suitable for running unit tests. The option suggests using CodeDeploy to run unit tests, which is a misuse of the service.
- Conclusion: This option is rejected because CodeDeploy is not intended to run unit tests.
Option B: Modify the Build Stage - Add Test Action with AWS CodeBuild
- Reasoning: AWS CodeBuild is the right service for running unit tests in a CI/CD pipeline. It can compile, test, and package the code. By modifying the build stage to add a test action using AWS CodeBuild, you can ensure that the unit tests are executed during the build process. If the unit tests fail, the build will fail, preventing the code from proceeding to the deploy stage. The runOrder value of 2 ensures the test action happens after the initial build action.
- Pros:
- CodeBuild is purpose-built for running tests.
- This solution ensures that only code changes that pass the tests are deployed.
- Cons:
- This solution requires modifying the build stage and adding a test action with the appropriate...
Author: Nathan · Last updated Jul 20, 2026
A company uses an organization in AWS Organizations to manage several AWS accounts that the company's developers use. The company requires all data to be encrypted in transit.
Multiple Amazon S3 buckets that were created in developer accounts allow unencrypted connections. A DevOps engineer must enforce encryption of da...
To meet the requirement of enforcing encryption of data in transit for all existing S3 buckets created in accounts within an AWS Organization, let's evaluate the available options:
Option A: AWS CloudFormation StackSets with AWS Network Firewall for Outbound Requests (Port 80)
- Reasoning: This solution involves using a firewall to block outbound requests on port 80. However, blocking port 80 will prevent all HTTP traffic, not just unencrypted S3 traffic. It doesn't specifically address the requirement to enforce encryption in transit for S3 requests (HTTPS traffic over port 443). Additionally, outbound firewall rules don't directly ensure that S3 buckets require encryption for incoming traffic.
- Conclusion: This option is rejected because it doesn't directly solve the problem of enforcing encryption in transit for S3 buckets.
Option B: AWS CloudFormation StackSets with AWS Network Firewall for Inbound Requests (Port 80)
- Reasoning: This solution involves blocking inbound requests on port 80, effectively preventing unencrypted HTTP traffic to the AWS environment. However, this approach does not address the need to enforce encryption on existing S3 buckets in a manner that fits the use case. Network Firewall rules are more suited for network-level control, not for enforcing S3-specific conditions like SSL encryption.
- Conclusion: This option is rejected because it doesn’t enforce encryption for S3 buckets and instead focuses on network-level access control.
Option C: AWS Config with Conformance Pack (s3-bucket-ssl-requests-only Managed Rule) and Systems Manager Runbook
- Reasoning: This solution uses AWS Config to monitor S3 ...
Author: FlamePhoenix2025 · Last updated Jul 20, 2026
A company is reviewing its IAM policies. One policy written by the DevOps engineer has been flagged as too permissive. The policy is used by an AWS Lambda function that issues a stop command to Amazon EC2 instances tagged with Environment: NonProduction over the weekend. The c...
To achieve the principle of least privilege for the IAM policy, the engineer needs to ensure that the Lambda function only has the minimum permissions necessary to perform its task (i.e., stop EC2 instances tagged with `Environment: NonProduction`). Let’s evaluate the potential changes:
Option A: Add the following conditional expression:
- Reasoning: This option suggests adding a conditional expression, but without the actual expression provided, it's hard to determine its relevance. Conditional expressions are important for limiting actions to specific conditions, but the specific condition is unclear here.
- Conclusion: Rejected—this option needs more details about the condition to evaluate.
Option B: Change "Resource": "" to "Resource": "arn:aws:ec2:::instance/"
- Reasoning: The `"Resource": ""` wildcard grants permissions on all EC2 instances in the account, which is too broad. Changing it to a more specific resource ARN (`"arn:aws:ec2:::instance/"`) narrows it down to EC2 instances, but it still doesn’t address the requirement to limit actions to instances with the `Environment: NonProduction` tag.
- Conclusion: Rejected—this limits the resource to EC2 instances but does not enforce the `Environment: NonProduction` tag condition.
Option C: Add the following conditional expression:
- Reasoning: Similar to Option A, without the actual condition specified, it’s difficult to evaluate. However, a conditional expression could be used to check for the presence of the `Environment: NonProduction` tag.
- Conclusion: Rejected—this option lacks specifics to be actionable.
Option D: Add the following conditional expression:
- Reasoning: As with the previous options A and C, the absence of the ac...
Author: William · Last updated Jul 20, 2026
A company is developing an application that will generate log events. The log events consist of five distinct metrics every one tenth of a second and produce a large amount of data.
The company needs to configure the application to write the logs to Amazon Timestream. The company will configure a daily query agai...
To meet the requirements of writing log events to Amazon Timestream while ensuring the FASTEST query performance, let's evaluate each option:
Option A: Use batch writes to write multiple log events in a single write operation.
- Reasoning: Batch writes allow you to group multiple log events into a single write operation. This reduces the overhead of individual write operations and can help improve performance by reducing the number of API calls. This is particularly helpful for high-volume data, such as the logs that are generated every tenth of a second.
- Conclusion: Selected—Batch writes are efficient for large amounts of data and will speed up the process by reducing write operation overhead.
Option B: Write each log event as a single write operation.
- Reasoning: Writing each log event as a single write operation would create a high number of individual requests to the database, resulting in higher latencies and overhead. This is not optimal for high-frequency log generation where performance is crucial.
- Conclusion: Rejected—This will result in inefficient performance due to too many individual write operations.
Option C: Treat each log as a single-measure record.
- Reasoning: Treating each log as a single-measure record means that each log event will contain one measure (metric). This is not ideal for a scenario where multiple metrics are generated for each log event. It will require storing each metric separately, which could negatively impact query performance and overall efficiency.
- Conclusion: Rejected—Single-measure records would not efficiently handle the structure of the log events, where multiple metrics are involved.
Option D: Treat each log as a multi-measure record.
- Reasoning: A multi-measure record allows you to store multiple metrics within a single record. Since each log event generates five distinct metrics, storing all of them together in a multi-measure record will reduce the num...
Author: Sophia · Last updated Jul 20, 2026
A DevOps engineer has created an AWS CloudFormation template that deploys an application on Amazon EC2 instances. The EC2 instances run Amazon Linux. The application is deployed to the EC2 instances by using shell scripts that contain user data. The EC2 instances have an IAM instance profile that has an IAM role with the AmazonSSMManagedinstanceCore managed policy attached.
The DevOps engineer has modified the user data in the CloudFormation template to install a new version of the application. The engineer has also applied the stack update. However, th...
Analysis of the options:
A) Configure the user data content to use the Multipurpose Internet Mail Extensions (MIME) multipart format. Set the scripts-user parameter to always in the text/cloud-config section.
- Explanation: The MIME multipart format allows the user data to include multiple parts, which can be useful for handling multiple shell scripts or files. Setting the `scripts-user` parameter to "always" ensures that the user data script runs each time the instance is launched or restarted. While this can help with reapplying configurations or installations, it might not address the core issue of applying the application updates dynamically without restarting the instance or redeploying.
- Why Rejected: This method primarily applies to initial instance launches, and it doesn't effectively address updates on already-running EC2 instances or during stack updates.
B) Refactor the user data commands to use the cfn-init helper script. Update the user data to install and configure the cfn-hup and cfn-init helper scripts to monitor and apply the metadata changes.
- Explanation: `cfn-init` is a helper script provided by CloudFormation that ensures the configuration and metadata specified in the CloudFormation stack are applied correctly. `cfn-hup` is a daemon that can detect changes in metadata and apply them to the instance. This would be an effective way to ensure that the application changes are applied when the CloudFormation stack is updated.
- Why Rejected: This is a good option for applying configuration changes on EC2 instances managed by CloudFormation, especially if the update involves changes to instance metadata or configurations. It helps in keeping the system in sync without needing to re-launch the instance.
C) Configure an EC2 launch template for the EC2 instances. Create a new EC2 Auto Scaling group. Associate the Auto Scaling group with the EC2 launch template. Use the AutoScalingScheduledAction update policy for the Auto Scaling group.
- Explanation: This option involves creating an Auto Scaling group and using scheduled actions for scaling purposes. This is more relevant to automatically scaling the environment based on demand, rather than ensuring an update of an existing application. It doesn't provide a direct mechanism for applying updates to already running instances.
- Why Rejected: This option would create ne...
Author: Nia · Last updated Jul 20, 2026
A company is refactoring applications to use AWS. The company identifies an internal web application that needs to make Amazon S3 API calls in a specific AWS account.
The company wants to use its existing identity provider (IdP) auth.company.com for authentication. The IdP supports only OpenID Connect (OIDC). A DevOps enginee...
Analysis of the options:
A) Configure AWS IAM Identity Center (AWS Single Sign-On). Configure an IdP. Upload the IdP metadata from the existing IdP.
- Explanation: AWS IAM Identity Center (SSO) is typically used to manage single sign-on access for users to multiple AWS accounts and applications. This solution is more suited for human users who need to log in and access AWS resources via SSO, rather than for an application making API calls.
- Why Rejected: The web application in this scenario needs to access AWS resources programmatically, so IAM Identity Center and SSO is not the right tool for this use case. Additionally, it's more about user access rather than programmatic access to services like S3.
B) Create an IAM IdP by using the provider URL, audience, and signature from the existing IdP.
- Explanation: This option refers to setting up an IAM Identity Provider (IdP) using the OpenID Connect (OIDC) configuration of the existing IdP (auth.company.com). By establishing the IAM IdP, AWS will trust the authentication provided by the IdP, enabling secure identity federation.
- Why Selected: This is a crucial step because it establishes a trusted relationship between AWS and the external IdP. The IdP URL, audience, and signature help AWS validate incoming OIDC tokens and authenticate the web application's requests.
C) Create an IAM role that has a policy that allows the necessary S3 actions. Configure the role's trust policy to allow the OIDC IP to assume the role if the sts.amazon.com:aud context key is appid_from_idp.
- Explanation: This option refers to setting up an IAM role with a trust policy that allows the external OIDC IdP to assume the role. The trust policy specifies conditions (like `sts.amazon.com:aud`), but it refers to an incorrect audience for the OIDC token.
- Why Rejected: The context key `sts.amazon.com:aud` is incorrect here because the `aud` context key should correspond to the value specified in the IdP, which would likely be a unique identifier for the application (such as `auth.company.com:aud`). Using `sts.amazon.com:aud` would not align with the audience field from the IdP configuration.
D) Create an IAM role that has a policy that allows the necessary S3 actions. Configure the role's trust policy to allow the OIDC IP to assume the role if the auth.company.com:aud context key is appid_from_idp.
- Explanation: ...
Author: Mia · Last updated Jul 20, 2026
A company uses Amazon RDS for all databases in its AWS accounts. The company uses AWS Control Tower to build a landing zone that has an audit and logging account. All databases must be encrypted at rest for compliance reasons. The company's security engineer needs to receive notification about any noncomplia...
Analysis of the options:
A) Use AWS Control Tower to activate the optional detective control (guardrail) to determine whether the RDS storage is encrypted. Create an Amazon Simple Notification Service (Amazon SNS) topic in the company's audit account. Create an Amazon EventBridge rule to filter noncompliant events from the AWS Control Tower control (guardrail) to notify the SNS topic. Subscribe the security engineer's email address to the SNS topic.
- Explanation: AWS Control Tower provides built-in governance features, including guardrails, which help in enforcing security and compliance controls across AWS accounts. Enabling a detective control (guardrail) for RDS encryption at rest can automatically monitor the compliance status and trigger notifications through Amazon EventBridge when a noncompliant database is detected.
- Why Selected: This option uses AWS Control Tower's native capabilities for centralized compliance monitoring and notifications, ensuring a highly automated and operationally efficient solution. It leverages built-in guardrails, reducing the need for custom development or additional resources. The solution also makes use of AWS EventBridge for event filtering and SNS for notifications, making it scalable and reliable.
- Why Rejected: N/A — This is the best solution for operational efficiency.
B) Use AWS CloudFormation StackSets to deploy AWS Lambda functions to every account. Write the Lambda function code to determine whether the RDS storage is encrypted in the account the function is deployed to. Send the findings as an Amazon CloudWatch metric to the management account. Create an Amazon Simple Notification Service (Amazon SNS) topic. Create a CloudWatch alarm that notifies the SNS topic when metric thresholds are met. Subscribe the security engineer's email address to the SNS topic.
- Explanation: This option involves using AWS Lambda functions deployed via CloudFormation StackSets to check the encryption status of RDS storage. Lambda would report findings to CloudWatch as metrics, and CloudWatch alarms would be used to notify the security engineer via SNS.
- Why Rejected: While this is a valid solution, it requires more setup and maintenance, including writing Lambda code, managing CloudWatch metrics, and setting up alarms. This approach introduces additional complexity compared to using AWS Control Tower's built-in capabilities for...
Author: Mia · Last updated Jul 20, 2026
A company is migrating from its on-premises data center to AWS. The company currently uses a custom on-premises Cl/CD pipeline solution to build and package software.
The company wants its software packages and dependent public repositories to be available in AWS CodeArtifact to facilitate the creation of application-specific pipelines.
Which combinat...
Analysis of the options:
A) Update the CI/CD pipeline to create a VM image that contains newly packaged software. Use AWS Import/Export to make the VM image available as an Amazon EC2 AMI. Launch the AMI with an attached IAM instance profile that allows CodeArtifact actions. Use AWS CLI commands to publish the packages to a CodeArtifact repository.
- Explanation: This option involves packaging software, creating a VM image, importing it into AWS, and then using an EC2 instance to push the packages into CodeArtifact. This solution is complex and involves unnecessary steps (e.g., managing AMIs and EC2 instances) when simpler, more efficient methods are available.
- Why Rejected: This adds significant operational overhead and complexity, especially when the company is already using a CI/CD pipeline. The solution would require maintaining AMIs and EC2 instances, which is not the most streamlined approach for updating a CI/CD pipeline.
B) Create an AWS Identity and Access Management Roles Anywhere trust anchor. Create an IAM role that allows CodeArtifact actions and that has a trust relationship on the trust anchor. Update the on-premises CI/CD pipeline to assume the new IAM role and to publish the packages to CodeArtifact.
- Explanation: This solution involves using AWS IAM Roles Anywhere, which allows on-premises servers to securely assume IAM roles for accessing AWS resources. By creating an IAM role with permissions for CodeArtifact actions, the on-premises CI/CD pipeline can publish software packages to CodeArtifact.
- Why Selected: This is a highly effective solution because it leverages AWS IAM for secure access management, allowing the on-premises CI/CD pipeline to directly integrate with CodeArtifact. It minimizes operational overhead by directly tying the pipeline to IAM roles and allowing secure access to AWS services like CodeArtifact.
C) Create a new Amazon S3 bucket. Generate a presigned URL that allows the PutObject request. Update the on-premises CI/CD pipeline to use the presigned URL to publish the packages from the on-premises location to the S3 bucket. Create an AWS Lambda function that runs when packages are created in the bucket through a put command. Configure the Lambda function to publish the packages to CodeArtifact.
- Explanation: This solution involves using an S3 bucket and presigned URLs to upload software packages, followed...
Author: Julian · Last updated Jul 20, 2026
A DevOps team uses AWS CodePipeline, AWS CodeBuild, and AWS CodeDeploy to deploy an application. The application is a REST API that uses AWS Lambda functions and Amazon API Gateway. Recent deployments have introduced errors that have affected many customers.
The DevOps team needs a solution that reverts to the most recent stable version of the application when an ...
Analysis of the options:
A) Set the deployment configuration in CodeDeploy to LambdaAllAtOnce. Configure automatic rollbacks on the deployment group. Create an Amazon CloudWatch alarm that detects HTTP Bad Gateway errors on API Gateway. Configure the deployment group to roll back when the number of alarms meets the alarm threshold.
- Explanation: This option sets the deployment configuration to `LambdaAllAtOnce`, meaning all traffic is routed to the new version immediately, which may introduce errors to all users if a problem occurs. It includes automatic rollback using CloudWatch alarms, but the immediate deployment of all traffic increases the risk of affecting many customers if the deployment is faulty.
- Why Rejected: While automatic rollbacks are beneficial, the deployment configuration (`LambdaAllAtOnce`) is too aggressive and risks affecting all customers immediately. This option doesn’t minimize customer impact and can lead to widespread failures.
B) Set the deployment configuration in CodeDeploy to LambdaCanary10Percent10Minutes. Configure automatic rollbacks on the deployment group. Create an Amazon CloudWatch alarm that detects HTTP Bad Gateway errors on API Gateway. Configure the deployment group to roll back when the number of alarms meets the alarm threshold.
- Explanation: This option uses the `LambdaCanary10Percent10Minutes` deployment configuration, which rolls out the deployment to 10% of the traffic initially and then gradually to the rest. This method reduces the customer impact by allowing only a small portion of traffic to be affected if there are issues with the new version. If errors occur, CloudWatch alarms can trigger an automatic rollback to the last stable version.
- Why Selected: This configuration provides the most operational efficiency because it limits the impact on customers (only 10% of traffic initially) and ensures automatic rollback if errors are detected. This minimizes customer impact and uses the least operational overhead.
C) Set the deployment configuration in CodeDeploy to LambdaAllAtOnce. Configure manual rollbacks on the deployment group. Create an Amazon Simple Notification Service (Amazon SNS) topic to send notifications every time a deployment fails. Configure the SNS topic to invoke a ...
Author: Victoria · Last updated Jul 20, 2026
A company recently deployed its web application on AWS. The company is preparing for a large-scale sales event and must ensure that the web application can scale to meet the demand.
The application's frontend infrastructure includes an Amazon CloudFront distribution that has an Amazon S3 bucket as an origin. The backend infrastructure includes an Amazon API Gateway API, several AWS Lambda functions, and an Amazon Aurora DB cluster.
The company's DevOps engineer conducts a load test and identifies that the Lambda functions can fulfil the peak number of requests. However, the DevOps engineer notices request latency during the initial burst...
In order to provide the application with the required scalability while reducing latency in the Lambda functions, the best approach would be to address both the scaling of the Lambda functions and the latency when establishing database connections. Let's go through each option one by one to evaluate its impact.
A) Configure a higher reserved concurrency for the Lambda functions.
- Why not selected: Reserved concurrency guarantees a specific number of Lambda instances to be available at any given time, but it doesn't address the latency issues caused by database connection initialization. It can improve the Lambda function's scalability in terms of invocation limits, but it doesn't solve the root cause of latency related to database connections.
- When to use: This option is suitable when there is a need to ensure that a minimum number of Lambda executions are always available, especially when a sudden spike in requests is expected. However, this is not sufficient by itself to address the database connection latency problem.
B) Configure a higher provisioned concurrency for the Lambda functions.
- Why not selected: While provisioned concurrency pre-warms a specified number of Lambda instances and can reduce cold start times, it does not directly address the underlying database connection issue. Cold start latency might be improved, but the database connection establishment will still be a bottleneck.
- When to use: This option is useful for improving overall Lambda performance during traffic spikes, but it doesn't target the core problem of database connection overhead.
C) Convert the DB cluster to an Aurora global database. Add additional Aurora Replicas in AWS Regions based on the locations of the company's customers.
- Why not selected: Aurora Global Databases provide low-latency reads across regions, but they don't directly address the latency caused by establishing database connections, especially if the application still needs to connect to a...
Author: Vikram · Last updated Jul 20, 2026
A company runs a web application that extends across multiple Availability Zones. The company uses an Application Load Balancer (ALB) for routing, AWS Fargate for the application, and Amazon Aurora for the application data. The company uses AWS CloudFormation templates to deploy the application. The company stores all Docker images in an Amazon Elastic Container Registry (Amazon ECR) repository in the same AWS account and AWS Region.
A DevOps engineer needs to establish a disaster recovery (DR) process in another Region. The so...
In this scenario, we need to ensure the disaster recovery (DR) process can meet the Recovery Time Objective (RTO) of 2 hours and the Recovery Point Objective (RPO) of 8 hours. Let’s evaluate each option against these requirements.
A) Copy the CloudFormation templates and the Dockerfile to an Amazon S3 bucket in the DR Region. Use AWS Backup to configure automated Aurora cross-Region hourly snapshots. In case of DR, build the most recent Docker image and upload the Docker image to an ECR repository in the DR Region. Use the CloudFormation template that has the most recent Aurora snapshot and the Docker image from the ECR repository to launch a new CloudFormation stack in the DR Region. Update the application DNS records to point to the new ALB.
- Why not selected: While this option addresses Aurora cross-region snapshots and Docker image rebuilding, it doesn’t address the build time for Docker images, which can sometimes take more than 2 hours. Since building the Docker image from scratch can exceed the RTO of 2 hours, this solution doesn't guarantee fast recovery in a disaster scenario.
- When to use: This could be suitable when build time is very predictable and under 2 hours, but that doesn’t fit the problem in this case.
B) Copy the CloudFormation templates to an Amazon S3 bucket in the DR Region. Configure Aurora automated backup Cross-Region Replication. Configure ECR Cross-Region Replication. In case of DR, use the CloudFormation template with the most recent Aurora snapshot and the Docker image from the local ECR repository to launch a new CloudFormation stack in the DR Region. Update the application DNS records to point to the new ALB.
- Why selected: This solution allows Aurora automated backups to be replicated to the DR region, and Docker images are also replicated via ECR Cross-Region Replication. This ensures that the most recent application data and images are available in the DR Region without requiring a long rebuild time for the Docker images. The cross-region replication of both Aurora backups and ECR images ensures that both RPO (8 hours) and RTO (2 hours) can be met because everything will be already available in the DR Region, and it focuses on minimizing downtime.
- When to use: This solution is well-suited for scenarios where fast recovery with minimal manual intervention is required. Cross-Region replication ensures that the da...
Author: Vivaan · Last updated Jul 20, 2026
A company's application runs on Amazon EC2 instances. The application writes to a log file that records the username, date, time, and source IP address of the login. The log is published to a log group in Amazon CloudWatch Logs.
The company is performing a root cause analysis for an event that occurred on the previous da...
Let's evaluate the available options and their ability to provide the required information: the number of logins for a specific user over the past 7 days.
A) Create a CloudWatch Logs metric filter on the log group. Use a filter pattern that matches the username. Publish a CloudWatch metric that sums the number of logins over the past 7 days.
- Why not selected: A metric filter in CloudWatch Logs can be used to count events based on a pattern (such as the username). However, CloudWatch metrics are generally used for continuous monitoring of ongoing events rather than retrospective analysis. This would require the metric filter to be applied beforehand to gather the login data over time, but it will not help with past data (before the metric was created). If you didn't set this up in advance, it won't work for this use case.
- When to use: This approach is best used if you want to track login counts in real-time and have future login counts automatically available.
B) Create a CloudWatch Logs subscription on the log group. Use a filter pattern that matches the username. Publish a CloudWatch metric that sums the number of logins over the past 7 days.
- Why not selected: A CloudWatch Logs subscription is useful for streaming log data to external destinations (e.g., Amazon Kinesis, AWS Lambda). However, this doesn't directly help in analyzing historical data for a specific user over the past 7 days. This would be more relevant for real-time monitoring or processing logs in real-time, not for querying past events.
- When to use: This approach is more suitable when you need to stream and process log data in real-...
Author: Zara1234 · Last updated Jul 20, 2026
A company has an AWS CodeDeploy application. The application has a deployment group that uses a single tag group to identify instances for the deployment of Application. The single tag group configuration identifies instances that have Environment=Production and Name=ApplicationA tags for the deployment of ApplicationA.
The company launches an additional Amazon EC2 instance with Department=Marketing, Environment=Production, and Name=ApplicationB tags. On the next CodeDeploy deployment of Application, the additional ins...
To address the problem where the additional EC2 instance with the `Department=Marketing` tag is incorrectly receiving the ApplicationA deployment, we need to adjust the deployment group’s tag configuration to ensure that only the intended instances with the correct tags are selected for the deployment of ApplicationA.
Let's analyze each option:
A) Change the current single tag group to include only the Environment=Production tag. Add another single tag group that includes only the Name=ApplicationA tag.
- Why not selected: This solution would incorrectly allow instances that have only the `Name=ApplicationA` tag but are not in the `Environment=Production` environment. The lack of the `Environment=Production` tag in the second tag group could lead to unintended instances being included in the deployment group. The goal is to ensure that both the `Environment=Production` and `Name=ApplicationA` tags are enforced together, without having an overlapping deployment with instances that don't need the application.
- When to use: This configuration may be useful when you want to separate logic for specific tags but would not provide the correct exclusion behavior for the additional EC2 instance in the Marketing department.
B) Change the current single tag group to include the Department=Marketing, Environment=Production, and Name=ApplicationA tags.
- Why not selected: This would make the `Department=Marketing` tag a required part of the selection for ApplicationA. However, this is not what we want. The additional EC2 instance, which is tagged with `Department=Marketing`, should not be included in the deployment group for ApplicationA. This solution would inadvertently cause the instance with `Department=Marketing` to be included because of the way the tags are configured, violating the goal.
- When to use: This could be used if you wanted to s...
Author: Max · Last updated Jul 20, 2026
A company is launching an application that stores raw data in an Amazon S3 bucket. Three applications need to access the data to generate reports. The data must be redacted differently for each application be...
Let's evaluate the available options to determine which one meets the requirements of redacting the data differently for each application before the applications can access it:
A) Create an S3 bucket for each application. Configure S3 Same-Region Replication (SRR) from the raw data's S3 bucket to each application's S3 bucket. Configure each application to consume data from its own S3 bucket.
- Why not selected: While this solution uses S3 Same-Region Replication (SRR) to replicate the raw data to different S3 buckets for each application, it doesn't directly address the requirement for redacting the data differently for each application. This approach would require additional manual processes or external tools for redacting data after replication, which adds complexity and makes it harder to maintain. Replication alone doesn't ensure that the data is processed (redacted) as required for each application.
- When to use: This might be suitable for scenarios where the data needs to be replicated to multiple buckets, but the requirement for redaction is more complex than what SRR can handle.
B) Create an Amazon Kinesis data stream. Create an AWS Lambda function that is invoked by object creation events in the raw data's S3 bucket. Program the Lambda function to redact data for each application. Publish the data on the Kinesis data stream. Configure each application to consume data from the Kinesis data stream.
- Why not selected: While Kinesis is a powerful solution for streaming data, it doesn't directly interact with S3 in the same way as S3-specific features. Additionally, the requirement of redacting the data for each application adds complexity, and there might be more straightforward ways to handle redaction. Also, Kinesis would introduce additional operational overhead and complexity compared to other options that directly leverage S3 features.
- When to use: This option would be appropriate if real-time streaming or complex data transformation and processing are required for the data before consumption, but it is more complicated than necessary for this specific use case.
C) For each application, create an S3 access poin...
Author: Manish · Last updated Jul 20, 2026
A company uses AWS Control Tower and AWS CloudFormation to manage its AWS accounts and to create AWS resources. The company requires all Amazon S3 buckets to be encrypted with AWS Key Management Service (AWS KMS) when the...
Let's break down each of the options in relation to the requirement that all S3 buckets must be encrypted with AWS KMS when created in a CloudFormation stack.
A) Use AWS Organizations. Attach an SCP that denies the s3:PutObject permission if the request does not include an x-amz-server-side-encryption header that requests server-side encryption with AWS KMS keys (SSE-KMS).
- Explanation: This option focuses on restricting the permission for object uploads (`s3:PutObject`) if the S3 bucket is not encrypted with KMS. This would work for enforcing encryption on objects after they are uploaded, but it doesn't control encryption at the time of bucket creation (which is the requirement). The solution doesn't directly apply to ensuring that all S3 buckets created in CloudFormation are encrypted with KMS during creation.
- Rejected: This option doesn't address the main concern, which is ensuring encryption for the bucket creation process, not just object uploads.
B) Use AWS Control Tower with a multi-account environment. Configure and enable proactive AWS Control Tower controls on all OUs with CloudFormation hooks.
- Explanation: This option uses proactive AWS Control Tower controls, which can enforce specific guardrails on accounts. By enabling proactive controls and using CloudFormation hooks, you can ensure that any resources created by CloudFormation (including S3 buckets) are validated and can be modified before deployment. This allows for controlling the behavior of resource creation, including setting the S3 bucket encryption using KMS.
- Selected: This approach directly addresses the need to enforce KMS encryption on S3 bucket creation in Cloud...
Author: Lina Zhang · Last updated Jul 20, 2026
A DevOps engineer has developed an AWS Lambda function. The Lambda function starts an AWS CloudFormation drift detection operation on all supported resources for a specific CloudFormation stack. The Lambda function then exits its invocation.
The DevOps engineer has created an Amazon EventBridge scheduled rule that invokes the Lambda function every hour. An Amazon Simple Notification Service (Amazon SNS) topic already exists in the AWS account. The DevOps engineer has subscribed to the SNS t...
Let's evaluate each of the options to determine the most suitable solution for notifying the DevOps engineer when drift is detected in the CloudFormation stack configuration.
A) Configure the existing EventBridge rule to also target the SNS topic. Configure an SNS subscription filter policy to match the CloudFormation stack. Attach the subscription filter policy to the SNS topic.
- Explanation: EventBridge can be configured to trigger an SNS topic, and the subscription filter policy would allow you to filter events based on the CloudFormation stack, which may help narrow down notifications. However, the drift detection process itself is initiated by the Lambda function, which only triggers the drift detection operation; it does not produce an immediate result. This solution does not address how to track the drift detection results or notify the user when drift is actually detected.
- Rejected: While this may trigger notifications when certain events occur, it doesn't provide a solution for tracking the completion of drift detection or when the drift status is detected.
B) Create a second Lambda function to query the CloudFormation API for the drift detection results for the stack. Configure the second Lambda function to publish a message to the SNS topic if drift is detected. Adjust the existing EventBridge rule to also target the second Lambda function.
- Explanation: This solution involves creating a second Lambda function that will periodically query the CloudFormation API to check for drift detection results. If drift is detected, the function will publish a message to the SNS topic. While this can work, it requires additional Lambda function management and querying of the CloudFormation drift detection status, which could introduce some delay between detection and notification.
- Selected: This solution provides a way to detect drift after the detection operation is started and will no...
Author: Aditya · Last updated Jul 20, 2026
A company has deployed a complex container-based workload on AWS. The workload uses Amazon Managed Service for Prometheus for monitoring. The workload runs in an Amazon
Elastic Kubernetes Service (Amazon EKS) cluster in an AWS account.
The company's DevOps team wants to receive workload alerts by using the company's Amazon Simple Notification Service (A...
Let's break down each of the options and assess how they contribute to meeting the requirements of sending workload alerts from Amazon Managed Service for Prometheus (AMP) to an SNS topic for an Amazon Elastic Kubernetes Service (EKS) cluster.
A) Use the Amazon Managed Service for Prometheus remote write URL to send alerts to the SNS topic.
- Explanation: The remote write URL for Amazon Managed Service for Prometheus is used to send metric data to Prometheus-compatible endpoints, but it doesn't directly send alerts to SNS topics. Alerts generated by Prometheus are typically managed and routed through an Alertmanager, not directly through the remote write mechanism.
- Rejected: This option doesn't align with the alerting mechanism; alerts are managed via Alertmanager, not by writing to SNS directly through the remote write URL.
B) Create an alerting rule that checks the availability of each of the workload's containers.
- Explanation: Creating alerting rules based on container availability is a good practice for monitoring workloads. However, this step focuses on the conditions that trigger the alerts, not the mechanism of sending them to SNS. It’s an important step in creating relevant alerts, but it alone doesn’t fulfill the requirement of sending those alerts to SNS.
- Rejected: While useful for defining when alerts should be triggered, this does not address the requirement of sending the alerts to SNS.
C) Create an alert manager configuration for the SNS topic.
- Explanation: Alertmanager in Prometheus is the appropriate tool for handling and routing alerts. By configuring Alertmanager to send notifications to the SNS topic, you ensure that Prometheus alerts can be forwarded to SNS, which is the desired outcome for the DevOps team's requirement.
- Selected: This directly addresses the requirement to route alerts to the SNS topic. Configuring Alertmanager is the correct method for sending alerts to an SNS topic.
D) Modify the access policy of the SNS topic. Grant the aps.amazonaws.com service principal the sns:Publish permission and the sns:GetTopicAttributes permission for the SNS topic.
- Explanation...
Author: SilverBear · Last updated Jul 20, 2026
A company's organization in AWS Organizations has a single OU. The company runs Amazon EC2 instances in the OU accounts. The company needs to limit the use of each EC2 instance's credentials to the specific EC2 instance that the credential is assigned to. A...
To meet the requirement of limiting the use of EC2 instance credentials to the specific EC2 instance that the credentials are assigned to, we need a solution that enforces conditions based on the EC2 instance's network and security context, ensuring that only the instance itself can use its credentials.
A) Create an SCP that specifies the VPC CIDR block. Configure the SCP to check whether the value of the `aws:VpcSourceIp` condition key is in the specified block. In the same SCP check, check whether the values of the `aws:EC2InstanceSourcePrivateIPv4` and `aws:SourceVpc` condition keys are the same. Deny access if either condition is false. Apply the SCP to the OU.
- Analysis: This approach is attempting to enforce network-based conditions on the EC2 instance. However, it combines multiple unrelated condition checks (VPC CIDR block, EC2 instance IP, and VPC source IP), which complicates the enforcement of credentials tied specifically to an EC2 instance. This solution is more suited to controlling network access, not credential binding to specific instances.
- Rejected: This option is not focused on enforcing the EC2 instance's credentials but rather on network-related conditions, making it unsuitable for the task at hand.
B) Create an SCP that checks whether the values of the `aws:EC2InstanceSourceVPC` and `aws:SourceVpc` condition keys are the same. Deny access if the values are not the same. In the same SCP check, check whether the values of the `aws:EC2InstanceSourcePrivateIPv4` and `aws:VpcSourceIp` condition keys are the same. Deny access if the values are not the same. Apply the SCP to the OU.
- Analysis: This option focuses on matching EC2 instance conditions (`aws:EC2InstanceSourcePrivateIPv4`, `aws:EC2InstanceSourceVPC`) with source IP and VPC conditions. While it attempts to ensure the network source matches the instance's private IP, it doesn't fully align with the goal of binding EC2 credentials strictly to the instance. The use of these conditions is still focused on network-based restrictions rather than the identity of the instance itself.
- Rejected: While somewhat relevant, this solution still overcomplicates the conditions and is not entirely focused on limiting credential usage to the specific EC2 instance.
C) Create an SCP that includes a list of acceptable VPC values and checks whether the value of the `aws:SourceVpc` condition key is in the list. In the same SCP check, define a list of acceptable IP address values and check whether the value of...
Author: Kai99 · Last updated Jul 20, 2026
A company has a fleet of Amazon EC2 instances that run Linux in a single AWS account. The company is using an AWS Systems Manager Automation task across the EC2 instances.
During the most recent patch cycle, several EC2 instances went into an error state because of insufficient available disk space. A DevOps engineer needs to ensure that the EC2 instance...
To address the issue of insufficient disk space during patching in the future, we need to take steps that can both monitor and manage disk space proactively. Let's evaluate each option:
A) Ensure that the Amazon CloudWatch agent is installed on all EC2 instances.
- Explanation: The Amazon CloudWatch agent can be used to collect and monitor system-level metrics, such as disk space usage, on EC2 instances. This would provide the necessary visibility into disk space and allow the company to monitor disk usage in real-time. However, the CloudWatch agent alone does not provide any direct corrective actions (e.g., freeing up space during patching), so while monitoring is a necessary component, it doesn't directly address the issue of ensuring sufficient disk space during the patching process.
- Selected: This option is helpful for monitoring, so it is part of the solution to prevent future issues.
B) Create a cron job that is installed on each EC2 instance to periodically delete temporary files.
- Explanation: A cron job to periodically delete temporary files is a good preventive measure to free up disk space regularly. However, this action alone may not be sufficient during the patching process, especially if patching requires a larger amount of space temporarily or if the temporary files are not the cause of the problem. Additionally, it doesn't integrate with Systems Manager Automation or address disk space specifically during patching.
- Rejected: While it may help free up disk space over time, it does not directly address the patching process or ensure sufficient space during patching.
C) Create an Amazon CloudWatch log group for the EC2 instances. Configure a cron job that is installed on each EC2 instance to write the available disk space to a CloudWatch log stream for the relevant EC2 instance.
- Explanation: This option proposes logging disk space to CloudWatch logs, which is useful for historical tracking and analysis. However, while this provides visibility into disk usage, it doesn't provide active monitoring or prevention of disk space issues during patching. CloudWatch logs won't trigger actions based on disk space usage unless coupled with other monitoring tools, such as Cl...
Author: Deepak · Last updated Jul 20, 2026
A DevOps engineer is building an application that uses an AWS Lambda function to query an Amazon Aurora MySQL DB cluster. The Lambda function performs only read queries. Amazon EventBridge events invoke the Lambda function.
As more events invoke the Lambda function each second, the database's latency increases and the database's throughput decreas...
Analysis:
The key challenge here is the increasing latency and decreasing throughput of the Aurora MySQL DB cluster as more events trigger the Lambda function. The solution needs to optimize database connections and throughput.
Option A: Use Amazon RDS Proxy to create a proxy. Connect the proxy to the Aurora cluster reader endpoint. Set a maximum connections percentage on the proxy.
- Reason for selection:
- Amazon RDS Proxy improves the performance by managing and pooling database connections. Lambda functions are short-lived, and establishing a new connection for each invocation can lead to a large overhead. By using RDS Proxy, Lambda can reuse database connections, reducing connection overhead and improving throughput. Connecting to the Aurora cluster reader endpoint helps to offload read queries to read replicas, thus improving overall performance.
- Setting a maximum connection percentage on the proxy ensures that the database is not overwhelmed by too many concurrent connections.
Option B: Implement database connection pooling inside the Lambda code. Set a maximum number of connections on the database connection pool.
- Reason for rejection:
- While connection pooling within Lambda code can help manage database connections, it may not be as effective as using Amazon RDS Proxy. Lambda is stateless, and without external pooling, each invocation of the Lambda function can cause the database to handle new connections, which can still cause latency issues. Implementing pooling in Lambda code can be complex and won't scale as effectively for large volumes of traffic.
Option C: Implement the database connection opening outside the Lambda event handler code.
- Reason for rejection:
- Opening the database connection outside of the event handler could reduce the latency for multiple invocations, but it may introduce issues with connection limits and connection leaks. Lambda is serverless and stateless, and reusing connections outside the event handler can cause...
Author: Vivaan · Last updated Jul 20, 2026
A company has an AWS CloudFormation stack that is deployed in a single AWS account. The company has configured the stack to send event notifications to an Amazon Simple Notification Service (Amazon SNS) topic.
A DevOps engineer must implement an automated solution that applies a tag to the specific CloudFormation stack instance only after a successful stack update occurs. The ...
Analysis:
The goal is to apply a tag to a CloudFormation stack instance only after a successful stack update (i.e., after receiving an `UPDATE_COMPLETE` event). The Lambda function is designed to apply and update the tag for the stack instance.
Option A: Run the AWS-UpdateCloudFormationStack AWS Systems Manager Automation runbook when Systems Manager detects an UPDATE_COMPLETE event for the instance status of the CloudFormation stack. Configure the runbook to invoke the Lambda function.
- Reason for rejection:
- The AWS-UpdateCloudFormationStack runbook is designed to perform CloudFormation stack updates, not to respond to a stack status change. While it could invoke the Lambda function, it is not the most direct or efficient solution for tagging the stack after an update. Using Systems Manager in this case adds unnecessary complexity since it is not specifically designed to handle the event-driven tagging process.
Option B: Create a custom AWS Config rule that produces a compliance change event if the CloudFormation stack has an UPDATE_COMPLETE instance status. Configure AWS Config to directly invoke the Lambda function to automatically remediate the change event.
- Reason for rejection:
- AWS Config rules are generally used for compliance and configuration management. While it is possible to create a custom rule for detecting CloudFormation stack status changes, this would be an over-engineered solution. AWS Config rules typically focus on configuration compliance, not specifically on applying tags after an event. Additionally, AWS Config is more for monitoring and auditing, which is not directly aligned with the event-driven action of tagging a stack after a successful update.
Option C: Create an Amazon EventBridge rule that matches the UPDATE_COMPLETE event ...
Author: Noah Williams · Last updated Jul 20, 2026
A company deploys an application to two AWS Regions. The application creates and stores objects in an Amazon S3 bucket that is in the same Region as the application. Both deployments of the application need to have access to all the objects and their metadata from both Regions. The company has configured two-way replication between the S3 buckets and has enabled S3 Replication metrics on each S3 buc...
Analysis:
The goal is to retry replication when an object fails to replicate between two AWS Regions. The company is using S3 replication and needs an automated solution for handling failed replication events and retrying the replication process.
Option A: Create an Amazon EventBridge rule that listens to S3 event notifications for failed replication events. Create an AWS Lambda function that downloads the failed replication object and then runs a PutObject command for the object to the destination bucket. Configure the EventBridge rule to invoke the Lambda function to handle the object that failed to replicate.
- Reason for selection:
- Amazon EventBridge is well-suited for listening to specific event notifications, such as failed replication events. EventBridge can capture these events and then trigger a Lambda function to handle the retry process. The Lambda function could download the failed object and upload it manually to the destination bucket, effectively retrying the replication.
- This solution directly addresses the problem by automating the retry process without needing to implement complex queues or polling mechanisms.
Option B: Create an Amazon Simple Queue Service (Amazon SQS) queue. Configure S3 event notifications to send failed replication notifications to the SQS queue. Create an AWS Lambda function that downloads the failed replication object and then runs a PutObject command for the object to the destination bucket. Configure the Lambda function to poll the queue for notifications to process.
- Reason for rejection:
- While SQS is a reliable messaging service, it is unnecessary for this scenario. S3 replication failure notifications can be directly captured by EventBridge, which can trigger the Lambda function. Introducing SQS adds an extra layer of complexity, as the Lambda function would need to poll the queue, adding overhead. Even...
Author: Liam · Last updated Jul 20, 2026
A company needs to implement failover for its application. The application includes an Amazon CloudFront distribution and a public Application Load Balancer (ALB) in an AWS Region. The company has configured the ALB as the default origin for the distribution.
After some recent application outages, the company wants a zero-second RTO. The company deploys the application to a secondary Region in a warm standby configuration. A...
Analysis:
The requirement is to implement failover with a zero-second Recovery Time Objective (RTO) for HTTP GET requests. The company has deployed its application in a warm standby configuration in a secondary AWS Region, and the application is accessible via a CloudFront distribution and a public Application Load Balancer (ALB).
We need to automate failover to the secondary Region without delay when an outage occurs. The solution must allow for zero-second RTO and be able to handle failover seamlessly without significant service interruptions.
Option A: Create a second CloudFront distribution that has the secondary ALB as the default origin. Create Amazon Route 53 alias records that have a failover policy and Evaluate Target Health set to Yes for both CloudFront distributions. Update the application to use the new record set.
- Reason for rejection:
- Creating a second CloudFront distribution would involve significant complexity in managing multiple distributions and DNS configurations. CloudFront distributions are not designed to work in tandem with automatic failover by default, and setting up separate distributions could introduce additional points of failure. This option would also require careful management of DNS records, making the failover process slower than necessary and more complicated. This is not the most efficient solution to achieve zero-second RTO.
Option B: Create a new origin on the distribution for the secondary ALB. Create a new origin group. Set the original ALB as the primary origin. Configure the origin group to fail over for HTTP 5xx status codes. Update the default behavior to use the origin group.
- Reason for selection:
- CloudFront origin groups are designed for automatic failover between multiple origins. This solution leverages origin groups to handle automatic failover based on HTTP 5xx status codes, which fits the requirement perfectly. If the primary ALB fails or returns 5xx errors, CloudFront will automatically failover to the secondary ALB in the secondary Region with zero-second RTO.
- This solu...
Author: Maya · Last updated Jul 20, 2026
A cloud team uses AWS Organizations and AWS IAM Identity Center (AWS Single Sign-On) to manage a company's AWS accounts. The company recently established a research team. The research team requires the ability to fully manage the resources in its account. The research team must not be able to create IAM users.
The cloud team creates a Research Administrator permission set in IAM Identity Center for the research team. The permission s...
Analysis:
The requirement is to allow the research team full access to manage resources within their AWS account but prevent them from creating IAM users. Let's break down each option and evaluate how it meets (or doesn't meet) these requirements.
Option A: Create an IAM policy that denies the iam:CreateUser action. Attach the IAM policy to the Research Administrator permission set.
- Reason for selection:
- IAM policy-based control can be used to directly deny the `iam:CreateUser` action while still allowing all other administrative actions. This solution provides fine-grained control over what actions the research team can perform within their AWS account. By denying the creation of IAM users but allowing the rest of the administrative permissions, this solution ensures the research team can manage resources but not create IAM users.
- This is a simple and direct approach to meet the requirement without introducing unnecessary complexity.
Option B: Create an IAM policy that allows all actions except the iam:CreateUser action. Use the IAM policy to set the permissions boundary for the Research Administrator permission set.
- Reason for rejection:
- Permissions boundaries are typically used to define the maximum permissions a role or user can have, regardless of any other policies attached to them. While it is possible to deny certain actions through the permissions boundary, permissions boundaries are not ideal for specific restrictions like preventing IAM user creation because they are designed more for controlling what a user can do in broader terms (like restricting permissions for roles).
- A simpler approach like directly denying the `iam:CreateUser` action in an inline policy (as in Option A) is a better fit. Using boundaries here is unnecessarily complicated.
Option C: Create an SCP that denies the iam:CreateUser action. Attach the SCP to the research team's AWS account.
- Reason for rejection:
- Service Control Policies (SCPs) are a powerful way to control what a...
Author: Andrew · Last updated Jul 20, 2026
A company releases a new application in a new AWS account. The application includes an AWS Lambda function that processes messages from an Amazon Simple Queue Service (Amazon SQS) standard queue. The Lambda function stores the results in an Amazon S3 bucket for further downstream processing. The Lambda function needs to process the messages within a specific period of time after the messages are published. The Lambda function has a batch size of 10 messages and takes a few seconds to process a batch of messages.
As load increases on the application's first day of service, messages in the queue accumulate at a greater rate than the Lambda function can ...
To determine the correct solution, we need to understand the context of the problem:
1. Lambda and SQS Integration: Lambda processes messages from an SQS queue. The Lambda function processes messages in batches of 10, and there's a time sensitivity around how quickly messages need to be processed.
2. Problem: The main challenge is that as the load increases, the Lambda function is unable to keep up with the rate at which messages are added to the SQS queue, which leads to delays in processing, and some messages miss their processing timeline. Additionally, there are issues with invalid data in the queue.
Let's evaluate each option:
---
Option A: Increase the Lambda function's batch size. Change the SQS standard queue to an SQS FIFO queue. Request a Lambda concurrency increase in the AWS Region.
- Increasing batch size: This would allow the Lambda function to process more messages per invocation. However, if the Lambda function can't keep up with the rate of incoming messages in the queue, increasing the batch size may actually exacerbate the problem by increasing the processing time per batch, delaying the processing of subsequent batches.
- Changing to FIFO queue: Switching to a FIFO queue would guarantee that messages are processed in order, but it can decrease throughput (as FIFO queues have throughput limits) and increase latency. FIFO queues are also not ideal for workloads where order isn’t crucial or where the goal is to process as many messages as possible in parallel.
- Requesting a Lambda concurrency increase: This could help scale the Lambda function horizontally, but it only addresses the scaling issue and doesn't address the problem of invalid data or the missed timelines.
This option doesn't fully address the key problem of handling invalid data and timely processing.
---
Option B: Reduce the Lambda function's batch size. Increase the SQS message throughput quota. Request a Lambda concurrency increase in the AWS Region.
- Reducing batch size: This could help by processing fewer messages per invocation, which reduces the time Lambda takes to process each batch, thus allowing the Lambda function to work faster. This helps meet the required processing timelines. However, reducing batch size also means more invocations, which might not scale well if the queue load continues to increase.
- Increasing SQS throughput: This would allow more messages to be sent to the queue, which doesn't directly address the issue of processing messages quickly, but could improve overall message ingestion.
- Requesting...
Author: IceDragon2023 · Last updated Jul 20, 2026
A company has an application that runs on AWS Lambda and sends logs to Amazon CloudWatch Logs. An Amazon Kinesis data stream is subscribed to the log groups in CloudWatch Logs. A single consumer Lambda function processes the logs from the data stream and stores the logs in an Amazon S3 bucket.
The company's DevOps team has ...
To address the high latency issues, we need to focus on improving how quickly the logs are ingested from CloudWatch Logs through Kinesis, and processed by the Lambda function.
Evaluation of the Options:
---
Option A: Create a data stream consumer with enhanced fan-out. Set the Lambda function that processes the logs as the consumer.
- Enhanced fan-out allows multiple consumers to read the data stream in parallel without being throttled. This can drastically reduce the latency in scenarios where there are multiple consumers, or where a single consumer is unable to handle the throughput of data efficiently.
- Why selected: If the single consumer Lambda function is causing delays because it's receiving all the data from the stream in a sequential manner, enhanced fan-out can significantly improve the processing time by allowing parallel consumption.
- Why others might reject: This approach directly addresses the issue of single consumer throttling and delays by enabling better parallelism, making it ideal for reducing latency.
---
Option B: Increase the ParallelizationFactor setting in the Lambda event source mapping.
- ParallelizationFactor controls how many records the Lambda function processes in parallel from each shard of the Kinesis stream. By increasing this factor, more records can be processed simultaneously, reducing latency when the processing rate is slow.
- Why selected: Increasing the parallelization factor helps process more records concurrently, which is key when logs are coming in at a high rate. This can speed up processing and reduce latency.
- Why others might reject: If the Lambda function is already throttling or overwhelmed, increasing parallelization without improving the throughput of the stream could still lead to bottlenecks. But for optimal performance, it works well with other tuning options.
---
Option C: Configure reserved concurrency for the Lambda function that processes the logs.
- Reserved concurrency allows you to allocate a specific number of concurrent executions for your Lambda function. By configuring reserved concurrency, you can guarantee that a set amount of Lambda invocations will always be available, thus avoiding delays caused by AWS Lambda throttling.
- Why selected: If the Lambda function is being throttled due to lack of available concurrency, this step will ensure that the function always has enough capacity to handle incoming events, which can directly reduce latency.
- Why others might reject: Reserved concurrency ensures that the Lambda function isn't throttled, but it doesn’t directly address stream consumption speed. ...
Author: John · Last updated Jul 20, 2026
A company operates sensitive workloads across the AWS accounts that are in the company's organization in AWS Organizations. The company uses an IP address range to delegate IP addresses for Amazon VPC CIDR blocks and all non-cloud hardware.
The company needs a solution that prevents principals that are outside th...
Let's analyze the options based on the requirements: the company wants to prevent AWS principals (users, services, etc.) outside the company’s IP address range from performing AWS actions in the organization's accounts.
Evaluating the Options:
---
Option A: Configure AWS Firewall Manager for the organization. Create an AWS Network Firewall policy that allows only source traffic from the company's IP address range. Set the policy scope to all accounts in the organization.
- AWS Firewall Manager can help manage and enforce security policies, but it is primarily used for managing firewall rules (e.g., AWS Network Firewall) at a network level, not for controlling AWS API actions or permissions. It would be more suitable for controlling inbound and outbound traffic at the network level rather than for limiting API calls from unauthorized IP addresses.
- Why rejected: Firewall Manager and AWS Network Firewall focus on traffic filtering, but they do not directly restrict actions within the AWS API based on source IP. This is not an appropriate solution for controlling AWS actions by IP range.
---
Option B: In Organizations, create an SCP that denies source IP addresses that are outside of the company’s IP address range. Attach the SCP to the organization's root.
- Service Control Policies (SCPs) in AWS Organizations are used to control the maximum available permissions for accounts in an organization. However, SCPs do not natively support filtering or controlling API actions based on source IP address.
- Why rejected: SCPs control permissions for AWS actions based on IAM policies but cannot restrict access by IP address. Thus, this approach cannot directly restrict actions based on the IP address range.
---
Option C: Configure Amazon GuardDuty for the organization. Crea...
Author: CrystalWolfX · Last updated Jul 20, 2026
A company deploys an application in two AWS Regions. The application currently uses an Amazon S3 bucket in the primary Region to store data.
A DevOps engineer needs to ensure that the application is highly available in both Regions. The DevOps engineer has created a new S3 bucket in the secondary Region. All existing and new objects must be in both S3 buckets. The application m...
To ensure that the application is highly available in both AWS Regions and that all existing and new objects are replicated between the S3 buckets in both Regions, we need to configure a solution that ensures both data replication and operational efficiency.
Let's analyze the options step by step:
---
Option A: Create a new IAM role that allows the Amazon S3 and S3 Batch Operations service principals to assume the role that has the necessary permissions for S3 replication.
- Explanation: For Cross-Region Replication (CRR) or S3 Batch Operations to function, appropriate IAM roles need to be configured with the necessary permissions. This option would be useful if an IAM role for replication is required, but it’s not the complete solution on its own. You would need to create the appropriate CRR rule in conjunction with this role.
- Why selected: Creating a proper IAM role for the replication process is a necessary part of the solution, so this step is required.
---
Option B: Create a new IAM role that allows the AWS Batch service principal to assume the role that has the necessary permissions for S3 replication.
- Explanation: AWS Batch is primarily used for running batch computing workloads. However, this is not necessary for data replication in S3 buckets. AWS Batch service principals would not be involved in the replication process.
- Why rejected: AWS Batch is irrelevant in this context, as we are focusing on S3 bucket-to-bucket replication, not batch job management. Therefore, this option does not contribute to the solution.
---
Option C: Create an S3 Cross-Region Replication (CRR) rule on the source S3 bucket. Configure the rule to use the IAM role for Amazon S3 to replicate to the target S3 bucket.
- Explanation: Cross-Region Replication (CRR) is designed specifically to replicate objects across S3 buckets in different Regions. This solution allows you to ensure that new objects are replicated to the secondary Region automatically. CRR is a native S3 feature and is highly operationally efficient.
- Why selected: This is the most efficient solution for replication, as CRR ensures that all objects are replicated from the primary Region to the secondary Region without requiring manual intervention or custom scripts.
---
Option D: Create a two-way replication rule on the source S3 bucket. Configure the rule to use the IAM role for Amazon S3 to replicate to the target S3 bucket.
- ...
Author: Liam · Last updated Jul 20, 2026
A company uses an organization in AWS Organizations to manage multiple AWS accounts. The company needs an automated process across all AWS accounts to isolate any compromised Amazon EC2 instances when the instances rec...
To meet the requirement of automatically isolating any compromised Amazon EC2 instances when they receive a specific tag across all AWS accounts in an organization, the solution must involve automation, cross-account execution, and immediate isolation of the compromised instance based on the tag.
Evaluating the Options:
---
Option A: Use AWS CloudFormation StackSets to deploy the CloudFormation stacks in all AWS accounts.
- Explanation: AWS CloudFormation StackSets allows you to deploy CloudFormation templates to multiple accounts and regions in an AWS Organization. This can automate the process of deploying the required resources (e.g., IAM roles, security groups, Lambda functions) across all accounts in the organization. This fits well for ensuring the solution is applied consistently in all accounts.
- Why selected: This option is ideal for ensuring that the required resources (Lambda function, IAM roles, and security groups) are deployed and automated across multiple AWS accounts. It addresses the need for cross-account automation.
---
Option B: Create an SCP that has a Deny statement for the ec2: action with a condition of "aws:RequestTag/isolation": false.
- Explanation: Service Control Policies (SCPs) allow you to set permission boundaries across AWS accounts in an organization. This option attempts to restrict EC2 actions based on a tag condition. However, the condition "aws:RequestTag/isolation": false would likely block actions for EC2 instances that don’t have the “isolation” tag or have it set incorrectly, but this does not solve the problem of isolating compromised instances. SCPs are more focused on restricting permissions rather than triggering isolation actions based on EC2 tags.
- Why rejected: SCPs are better suited for setting permission boundaries, but they cannot directly isolate or modify EC2 instances based on tags. This option doesn't provide the needed automation for isolating EC2 instances.
---
Option C: Attach the SCP to the root of the organization.
- Explanation: Attaching an SCP to the root of the organization limits the actions that can be performed within the AWS accounts in the organization. However, SCPs by themselves do not provide an automated way to isolate EC2 instances based on tags.
- Why rejected: As discussed in Option B, SCPs alone are not capable of isolating EC2 instances based on a tag. Therefore, this solution alone will not achieve the desired outcome of automatically isolating instances when they receive a specific tag.
---
Option D: Create an AWS CloudFormation template that creates an EC2 instance role that has no IAM polic...
Author: Julian · Last updated Jul 20, 2026
A company manages multiple AWS accounts by using AWS Organizations with OUs for the different business divisions. The company is updating their corporate network to use new IP address ranges. The company has 10 Amazon S3 buckets in different AWS accounts. The S3 buckets store reports for the different divisions. The S3 bucket configurations allow only private corporate network IP addresses to access the S3 buckets.
A DevOps engineer needs to change the range of IP a...
Let's analyze each option in detail.
A) Create a new SCP that has two statements, one that allows access to the new range of IP addresses for all the S3 buckets and one that denies access to the old range of IP addresses for all the S3 buckets. Set a permissions boundary for the OrganizationAccountAccessRole role in the two OUs to deny access to the S3 buckets.
- Pros:
- The Service Control Policy (SCP) can be used to manage permissions across the entire organization or specific OUs.
- The permissions boundary can limit what permissions are granted to the `OrganizationAccountAccessRole` role in the two OUs.
- Cons:
- SCPs are not ideal for managing fine-grained access to specific resources like S3 buckets; they apply at the account or organization level and can't target resources in a precise way.
- Using SCPs to control IP-based access can be challenging, as SCPs do not have the granularity to restrict access to specific IP ranges for S3.
- The permissions boundary may not directly control IP-based access for S3 in the way it is intended.
Rejected due to SCP's inability to manage specific IP address restrictions and lack of fine-grained resource targeting.
B) Create a new SCP that has a statement that allows only the new range of IP addresses to access the S3 buckets. Create another SCP that denies access to the S3 buckets. Attach the second SCP to the two OUs.
- Pros:
- The second SCP to deny access to the S3 buckets in the two OUs is a valid way to revoke access at the OU level.
- Cons:
- Similar to option A, SCPs are not a good fit for managing IP address-based access. While you can define IP conditions in IAM policies, SCPs are more focused on controlling permissions at a higher level (e.g., actions, services) and can't be used to precisely restrict access based on IP.
- Deny permissions via SCP can be restrictive, but again, it doesn’t work as effectively for IP-based controls.
Rejected due to SCP’s limitations with IP-based controls and lack of fine-grained resource-level targeting.
C) On all the S3 buckets, configure resource-based policies that allow only the new range of IP addres...
Author: David · Last updated Jul 20, 2026
A company has started using AWS across several teams. Each team has multiple accounts and unique security profiles. The company manages the accounts in an organization in AWS Organizations. Each account has its own configuration and security controls.
The company's DevOps team wants to use preventive and detective controls to govern all accounts. The DevOps team needs ...
Let's analyze each option to determine which best meets the requirements for using preventive and detective controls in a scalable way as the company creates new accounts.
A) Use Organizations to create OUs that have appropriate SCPs attached for each team. Place team accounts in the appropriate OUs to apply security controls. Create any new team accounts in the appropriate OUs.
- Pros:
- Service Control Policies (SCPs) provide a preventive mechanism by restricting the actions that can be performed in accounts based on their placement in the OUs.
- SCPs are effective for setting organization-wide controls that apply to all accounts under them, making it easier to govern the accounts at a high level.
- Cons:
- SCPs are not sufficient for detective controls; they only control which actions are allowed or denied.
- While SCPs can control what happens within an account, they do not directly govern configurations or compliance (detective controls) across accounts.
- The solution only addresses the security profiles at the account level and may lack integration with compliance checks like AWS Config or AWS Security Hub.
Rejected due to the lack of integrated detective controls, which are necessary to monitor and ensure ongoing compliance.
B) Create an AWS Control Tower landing zone. Configure OUs and appropriate controls in AWS Control Tower for the existing teams. Configure trusted access for AWS Control Tower. Enroll the existing accounts in the appropriate OUs that match the appropriate security policies for each team. Use AWS Control Tower to provision any new accounts.
- Pros:
- AWS Control Tower is a comprehensive solution designed to help manage multiple accounts at scale. It provides both preventive and detective controls via guardrails.
- It can automatically enforce security policies using the guardrails feature, which provides built-in preventive controls and integrates detective controls for monitoring compliance.
- Control Tower automatically provisions new accounts in the correct Organizational Units (OUs) and ensures that they inherit the appropriate guardrails.
- Cons:
- Control Tower is a higher-level service and may not provide as much customization as other more granular solutions like AWS Config or CloudFormation StackSets for specific use cases.
- Depending on the use case, AWS Control Tower might not offer full flexibility for highly custom security profiles.
Selected for its ability to both prevent and detect issues across multiple accounts and its integrated, scalable approach for managing future accounts as they are created.
C) Cr...
Author: Madison · Last updated Jul 20, 2026
A company uses an AWS CodeCommit repository to store its source code and corresponding unit tests. The company has configured an AWS CodePipeline pipeline that includes an AWS CodeBuild project that runs when code is merged to the main branch of the repository.
The company wants the CodeBuild project to run the unit tests. If the unit test...
Let's analyze each option in detail and determine which solution best meets the requirements of running unit tests and tagging the most recent commit after a successful run.
A) Configure the CodeBuild project to use native Git to clone the CodeCommit repository. Configure the project to run the unit tests. Configure the project to use native Git to create a tag and to push the Git tag to the repository if the code passes the unit tests.
- Pros:
- Using native Git to clone the repository directly from CodeCommit is a valid approach to access the source code in the repository.
- After running the unit tests, creating a tag and pushing it using Git commands is a straightforward solution to tagging the commit.
- Cons:
- Pushing changes (such as a new tag) back to the CodeCommit repository requires additional IAM permissions for the CodeBuild service role to push to the repository.
- Using native Git to create and push tags can introduce complexities when dealing with repository state (like ensuring the correct commit is tagged, handling permissions for pushing tags, etc.).
Rejected because pushing tags using native Git requires additional IAM permissions and could introduce complexities in ensuring the correct commit is tagged, which may not be ideal in the context of CodeBuild automation.
B) Configure the CodeBuild project to use native Git to clone the CodeCommit repository. Configure the project to run the unit tests. Configure the project to use AWS CLI commands to create a new repository tag in the repository if the code passes the unit tests.
- Pros:
- AWS CLI commands provide a way to interact with AWS services, including creating repository tags.
- Using AWS CLI to create a repository tag is more consistent with AWS best practices and would allow for finer-grained control and logging through AWS tools.
- This solution avoids the complexity of using native Git to push changes back to the repository.
- Cons:
- While the use of AWS CLI is cleaner for tagging, it requires specific IAM permissions for the CodeBuild project to interact with CodeCommit through AWS CLI commands. These permissions need to...
Author: Sara · Last updated Jul 20, 2026
A DevOps engineer manages a company's Amazon Elastic Container Service (Amazon ECS) cluster. The cluster runs on several Amazon EC2 instances that are in an Auto Scaling group. The DevOps engineer must implement a solution th...
Let's evaluate each of the options in detail to determine which solution best meets the requirement of logging and reviewing all stopped ECS tasks for errors.
A) Create an Amazon EventBridge rule to capture task state changes. Send the event to Amazon CloudWatch Logs. Use CloudWatch Logs Insights to investigate stopped tasks.
- Pros:
- Amazon EventBridge is capable of capturing ECS task state changes, including task stops.
- Sending the events to CloudWatch Logs makes it easy to store and analyze logs centrally.
- CloudWatch Logs Insights provides powerful querying capabilities, enabling detailed investigation of stopped tasks for errors.
- This solution is scalable and directly aligned with the requirement to capture and review stopped ECS tasks.
- Cons:
- None. This solution directly addresses the logging and review requirement with integrated tools for tracking ECS task states.
Selected because it efficiently captures ECS task state changes, sends them to CloudWatch Logs, and provides robust tools for querying and investigating task stops.
B) Configure tasks to write log data in the embedded metric format. Store the logs in Amazon CloudWatch Logs. Monitor the ContainerInstanceCount metric for changes.
- Pros:
- Writing logs in the embedded metric format provides detailed data for monitoring ECS tasks.
- CloudWatch Logs is used for storing the log data.
- Cons:
- This option focuses on metrics, such as `ContainerInstanceCount`, which is more about monitoring the container instance availability rather than the task state changes or errors directly.
- Embedded metrics and monitoring of container instances do not directly capture task state changes like stopping or failures. This makes it less suitable for reviewing stopped tasks for errors.
Rejected because it is more focused on instance metrics and does not provide a way to directly capture and review stopped task events and errors.
C) Configure the EC2 instances to store logs in Amazon CloudWatch Logs. Create a CloudWatch Contributo...
Author: Siddharth · Last updated Jul 20, 2026
A company wants to deploy a workload on several hundred Amazon EC2 instances. The company will provision the EC2 instances in an Auto Scaling group by using a launch template.
The workload will pull files from an Amazon S3 bucket, process the data, and put the results into a different S3 bucket. The EC2 instances must have lea...
Let's evaluate each of the options to identify which two steps will meet the requirement of providing least-privilege temporary credentials for the EC2 instances to pull and process data from S3.
A) Create an IAM role that has the appropriate permissions for S3 buckets. Add the IAM role to an instance profile.
- Pros:
- IAM roles are ideal for granting permissions to EC2 instances.
- Attaching an IAM role to an instance profile ensures that temporary security credentials are automatically available to the EC2 instances.
- The least-privilege principle can be applied by assigning only the necessary S3 permissions (e.g., read from one S3 bucket, write to another).
- Cons:
- None. This is the recommended approach to provide permissions to EC2 instances and ensure they are using temporary credentials via the instance metadata service.
Selected because IAM roles with appropriate S3 permissions provide temporary credentials with the least privilege, making it an effective solution.
B) Update the launch template to include the IAM instance profile.
- Pros:
- Including the IAM instance profile in the launch template ensures that the EC2 instances will assume the IAM role with the least-privilege permissions as they are launched.
- This step is essential to ensure that the EC2 instances will have the correct IAM role attached and receive temporary credentials from the instance metadata service when they are provisioned.
- Cons:
- None. This is a necessary step to enable the EC2 instances to use the IAM role with the appropriate permissions for S3.
Selected because the launch template must include the IAM instance profile to grant the EC2 instances the necessary temporary security credentials at launch.
C) Create an IAM user that has the appropriate permissions for Amazon S3. Generate a secret key and token.
- Pros:
- This would allow the EC2 instances to authenticate to S3 via long-term access keys.
- Cons:
- Using IAM users with long-term credentials (access keys and secret keys) does not adhere to the...
Author: Chloe · Last updated Jul 20, 2026
A company is using AWS CodeDeploy to automate software deployment. The deployment must meet these requirements:
* A number of instances must be available to serve traffic during the deployment. Traffic must be balanced across those instances, and the instances must automatically heal in the event of failure. * A new fleet of instances must be launched for deploying a new revision automatically, with no manual provisioning.
* Traffic must be rerouted to the new environment to half of the new instances at a time. The deployment should succeed if traffic is rerouted to at least half of the instances: otherwise, it should fail.
* Before routing traffic to the ...
To meet the requirements described, let's break down the requirements and how each option addresses them:
Key Requirements:
1. Traffic must be balanced across instances: This can be achieved by using an Application Load Balancer (ALB).
2. Instances should heal automatically in case of failure: This suggests the use of Auto Scaling groups.
3. New fleet of instances must be launched automatically: This implies the use of Auto Scaling groups in combination with AWS CodeDeploy.
4. Traffic rerouted to new instances (half at a time): This requires a specific deployment strategy that allows traffic to be shifted gradually to the new instances.
5. Temporary files must be deleted before routing traffic: This requires a hook in `appspec.yml` to delete files at the right time in the deployment lifecycle.
6. Original instances must be terminated immediately after deployment: The original instances should be terminated to reduce costs.
---
Analyzing the Options:
Option A:
- In-place Deployment: This will update the current fleet of instances instead of launching new ones.
- Traffic Rerouting: Traffic is not shifted gradually in an in-place deployment. Therefore, it doesn't satisfy the requirement of "rerouting traffic to half of the new instances at a time."
- Temporary File Deletion: The use of the `AllowTraffic` hook is appropriate to delete temporary files, but the deployment strategy is not suitable for this case.
- Original Instances: In an in-place deployment, terminating the original instances immediately is not a typical behavior; they would be replaced progressively instead.
Rejected because in-place deployments do not provide a way to reroute traffic gradually or launch a new fleet of instances, which is a key requirement.
Option B:
- Blue/Green Deployment: This option uses a new set of instances (blue environment), meeting the requirement of launching a new fleet automatically.
- Traffic Rerouting: The custom deployment configuration with a 50% healthy host setting ensures that traffic is routed to half of the new instances at a time, meeting the requirement.
- Temporary File Deletion: The `BeforeBlockTraffic` hook is used to delete temporary files before traffic is rerouted to the new fleet, fulfilling that requirement.
- Origina...
Author: Kai · Last updated Jul 20, 2026
A company needs to adopt a multi-account strategy to deploy its applications and the associated CI/CD infrastructure. The company has created an organization in AWS Organizations that has all features enabled. The company has configured AWS Control Tower and has set up a landing zone.
The company needs to use AWS Control Tower controls (guardrails) in all AWS accounts in the organization. The company must create the accounts for ...
To meet the requirements of adopting a multi-account strategy with the least operational overhead while using AWS Control Tower, let’s break down each option.
Key Requirements:
- AWS Control Tower controls (guardrails) should be applied to all AWS accounts in the organization.
- Multi-environment application: You need to provision accounts for multiple environments (e.g., dev, prod) and a CI/CD account.
- Ensure accounts are configured to an initial baseline: Each new account needs to have a specific baseline configuration applied.
---
Analyzing the Options:
Option A:
- AWS Control Tower Account Factory Customization (AFC): The AFC blueprint is used to customize how accounts are created. This is useful for enforcing guardrails and creating the accounts with specific configurations.
- Account Factory: AWS Control Tower’s Account Factory can automatically provision new accounts using the customized blueprint, including the initial baseline configuration and guardrails.
- Operational Overhead: This solution requires minimal manual effort since it uses AWS Control Tower to create the accounts, apply guardrails, and ensure they comply with the baseline configuration.
Selected Option: This is the most straightforward solution because it leverages AWS Control Tower to automate the process of creating accounts and applying the necessary configurations (baseline and guardrails), all with minimal operational overhead.
Option B:
- Account Factory + CloudFormation StackSets: This solution uses AWS Control Tower's Account Factory to provision accounts, and then StackSets is used to apply the baseline configuration.
- Operational Overhead: While AWS CloudFormation StackSets allows you to apply configurations across multiple accounts, it adds an additional layer of complexity since you would need to manage StackSets and ensure proper synchronization of configurations across accounts. This introduces more operational overhead compared to using the Account ...
Author: Chloe · Last updated Jul 20, 2026
A DevOps team has created a Custom Lambda rule in AWS Config. The rule monitors Amazon Elastic Container Repository (Amazon ECR) policy statements for ecr:* actions. When a noncompliant repository is detected, Amazon EventBridge uses Amazon Simple Notification Service (Amazon SNS) to route the notification to a securi...
Let's break down the situation:
Problem Summary:
- The DevOps team has created a custom AWS Config rule using a Lambda function to monitor Amazon Elastic Container Registry (ECR) for noncompliant actions.
- When noncompliance is detected, Amazon EventBridge sends a notification to a security team via SNS.
- However, the Lambda function fails to run when the AWS Config rule is evaluated.
Key Aspects to Consider:
- Lambda and AWS Config Integration: AWS Config needs permission to invoke the Lambda function.
- SNS and EventBridge: EventBridge triggers SNS, which in turn sends the notifications. SNS must have the correct permissions.
- Lambda Execution Role: The Lambda execution role needs appropriate permissions to interact with AWS Config and perform any necessary actions.
- ECR Policies: The Lambda function's behavior shouldn't be directly affected by the repository's individual policies, unless the Lambda is trying to interact with the ECR service itself.
---
Analyzing the Options:
Option A: Modify the Lambda function's resource policy to grant AWS Config permission to invoke the function.
- Reasoning: AWS Config must be able to invoke the Lambda function when a rule is evaluated. If AWS Config lacks the necessary permission to invoke the function, it will fail to execute it. The Lambda function needs to have a proper resource policy that explicitly grants AWS Config permission to invoke it.
Selected Option: This is the correct option because it directly addresses the issue of AWS Config being unable to invoke the Lambda function, which is likely why the function is failing.
Option B: Modify the SNS topic policy to include configuration changes for EventBridge to publish to the SNS topic.
- Reasoning: This option addresses permissions related to EventBridge and SNS. However, the failure occurs when the Lambda function is triggered by AWS Config, not when...
Author: Kai99 · Last updated Jul 20, 2026
A developer is creating a proof of concept for a new software as a service (SaaS) application. The application is in a shared development AWS account that is part of an organization in AWS Organizations.
The developer needs to create service-linked IAM roles for the AWS services that are being considered for the proof of concept. The solu...
Let's break down the problem:
Key Requirements:
- The developer should only be able to create and configure service-linked IAM roles.
- The solution should ensure that the developer has limited permissions for this specific task.
- The solution should not grant the developer broad permissions that might allow them to perform other actions that are not needed for the proof of concept.
---
Analyzing the Options:
Option A:
- IAM user in the management account with a cross-account role in the development account: This option involves creating a cross-account role in the development account and limiting the scope of the role to common services.
- Cross-Account Role: Cross-account roles are typically used for providing access across different AWS accounts, but this is not necessary here since the developer is working in the shared development account. It would add unnecessary complexity for the developer to use cross-account roles.
- Limiting Scope: The scope could be limited, but this adds complexity without directly addressing the issue of limiting permissions for creating service-linked roles in the development account.
Rejection Reason: Cross-account roles add unnecessary complexity and do not directly address the requirement of giving the developer limited permissions within the same account.
Option B:
- IAM group with the PowerUserAccess policy: The PowerUserAccess managed policy grants extensive permissions, including the ability to create roles and manage policies, but it also provides permissions that go beyond creating service-linked IAM roles.
- MFA enforcement: While MFA is a good practice for enhancing security, it does not solve the problem of limiting permissions. The developer would still have access to more actions than necessary.
Rejection Reason: This option grants overly broad permissions (via PowerUserAccess), which violates the requirement to give the developer only the abilit...
Author: ElectricLionX · Last updated Jul 20, 2026
A company uses AWS Organizations to manage its AWS accounts. The company wants its monitoring system to receive an alert when a root user logs in. The company also needs a dashboard to display any log activity that the r...
Let's break down the key requirements and analyze each option:
Key Requirements:
1. Alert when a root user logs in: This involves tracking root user login activity and generating an alert when such an event occurs.
2. Dashboard displaying root user log activity: This requires a way to visualize the log activity generated by the root user in a dashboard.
---
Analyzing the Options:
Option A: Enable AWS Config with a multi-account aggregator. Configure log forwarding to Amazon CloudWatch Logs.
- AWS Config is used for configuration monitoring and compliance tracking, not specifically for tracking root user logins.
- Log forwarding to CloudWatch Logs: While AWS Config can send configuration data to CloudWatch, it does not directly track or generate log entries for user logins, particularly root user logins.
Rejection Reason: AWS Config is not the right service for capturing root user login events, and using it with a multi-account aggregator doesn't directly meet the requirement to track login events.
Option B: Create an Amazon QuickSight dashboard that uses an Amazon CloudWatch Logs query.
- Amazon QuickSight is a business intelligence service that visualizes data, but it doesn't directly process raw log data. It could be used to create a dashboard but requires the log data to be already processed and available in a suitable format.
Rejection Reason: QuickSight is used for data visualization, but it doesn't handle real-time log event processing or alerts. You need a way to process and monitor root user logins before using QuickSight for visualization.
Option C: Create an Amazon CloudWatch Logs metric filter to match root user login events. Configure a CloudWatch alarm and an Amazon Simple Notification Service (Amazon SNS) topic to send alerts to the company's monitoring system.
- CloudWatch Logs metric filter: Metric filters allow you to search and match specific events in CloudWatch Logs, including root user logins, and trigger a metric.
- CloudWatch Alarm: Once the filter matches root login events, you can configure an alarm to notify you.
- SNS for Alerts: SNS sends notifications to your monitoring system when the alarm is triggered.
Selected Option: This option addresses both the alerting and monitoring requirements. It allows you to track root user logins and notify the monitoring system when an event occurs.
Option D: Create an Amazon CloudWatch Logs subscription filter to match root user login events. Configure the filter to forward events to an Amazon Simple Notification Serv...
Author: Lucas · Last updated Jul 20, 2026
A company uses AWS Organizations to manage its AWS accounts. A DevOps engineer must ensure that all users who access the AWS Management Console are authenticated through the company's corporate identity p...
To meet the requirement of ensuring that all users accessing the AWS Management Console are authenticated through the company’s corporate identity provider (IdP), let's examine each option in detail:
A) Use Amazon GuardDuty with a delegated administrator account. Use GuardDuty to enforce denial of IAM user logins.
- Rejected: Amazon GuardDuty is a threat detection service that monitors for malicious activity or unauthorized behavior. It does not provide a mechanism for enforcing specific authentication requirements such as requiring a corporate IdP for authentication. GuardDuty is not designed to enforce login denial or identity provider integration, making it an unsuitable choice.
B) Use AWS IAM Identity Center to configure identity federation with SAML 2.0.
- Selected: AWS IAM Identity Center (formerly AWS Single Sign-On) can be used to configure identity federation with external identity providers using SAML 2.0. This will allow users to authenticate through the company’s corporate IdP, which is exactly the requirement. The IdP can be linked via SAML, ensuring that all authentication happens through the corporate identity system. This is a direct and valid solution for the requirement.
C) Create a permissions boundary in AWS IAM Identity Center to deny password logins for IAM users.
- Rejected: While permissions boundaries in IAM can control what actions an IAM user or role can perform, they cannot directly prevent users from logging in with passwords in the AWS Management Console. Permissions boundaries do not influence authentication mechanism...
Author: Emma Brown · Last updated Jul 20, 2026
A company has deployed a new platform that runs on Amazon Elastic Kubernetes Service (Amazon EKS). The new platform hosts web applications that users frequently update. The application developers build the Docker images for the applications and deploy the Docker images manually to the platform.
The platform usage has increased to more than 500 users every day. Frequent updates, building the updated Docker images for the applications, and deploying the Docker images on the platform manually have all become difficult to manage.
The company needs to receive an Amazon Simple N...
Let's review each option step by step to determine which ones will meet the requirements for automatic Docker image building, scanning, and notification when vulnerabilities are found in the images:
A) Create an AWS CodeCommit repository to store the Dockerfile and Kubernetes deployment files. Create a pipeline in AWS CodePipeline. Use an Amazon S3 event to invoke the pipeline when a newer version of the Dockerfile is committed. Add a step to the pipeline to initiate the AWS CodeBuild project.
- Rejected: This option involves triggering the pipeline with an S3 event, but the requirement is to get notifications based on vulnerability scanning of the Docker images, not just triggering a pipeline. While it automates the build and deployment process, it doesn't address the vulnerability scanning or the SNS notifications based on high or critical findings.
B) Create an AWS CodeCommit repository to store the Dockerfile and Kubernetes deployment files. Create a pipeline in AWS CodePipeline. Use an Amazon EventBridge event to invoke the pipeline when a newer version of the Dockerfile is committed. Add a step to the pipeline to initiate the AWS CodeBuild project.
- Rejected: Similar to Option A, this option automates the process of building and deploying Docker images via CodeCommit and CodePipeline. However, it lacks integration with the Amazon ECR vulnerability scanning feature and SNS notification for high or critical vulnerabilities. Therefore, this option does not fully meet the requirement.
C) Create an AWS CodeBuild project that builds the Docker images and stores the Docker images in an Amazon Elastic Container Registry (Amazon ECR) repository. Turn on basic scanning for the ECR repository. Create an Amazon EventBridge rule that monitors Amazon GuardDuty events. Configure the EventBridge rule to send an event to an SNS topic when the finding-severity-counts parameter is more than 0 at a CRITICAL or HIGH level.
- Rejected: This option turns on basic scanning for images stored in Amazon ECR, but it suggests monitoring Amazon GuardDuty events, which is not ideal fo...
Author: Maya2022 · Last updated Jul 20, 2026
A company groups its AWS accounts in OUs in an organization in AWS Organizations. The company has deployed a set of Amazon API Gateway APIs in one of the Organizations accounts. The APIs are bound to the account's VPC and have no existing authentication mechanism. Only principals in a specific OU can have permissions to invoke the APIs.
The company applies the following policy to the API Gateway interface VPC endpoint:
The company also updates the API Gateway resource policies to deny invocations that do not come through the interface VPC en...
Let's go through each option step by step to determine which ones will address the issue of unauthorized access and help solve the problem described:
A) Enable IAM authentication on all API methods by setting AWS IAM as the authorization method.
- Selected: Enabling IAM authentication ensures that only authenticated AWS IAM principals can invoke the API. This is the simplest way to integrate authentication with AWS services when access is restricted to specific principals in the organization. By enabling IAM authentication, you can configure the API Gateway to accept only signed requests from authorized users, thereby ensuring that only principals from the specific OU are allowed to invoke the API. This directly solves the "anonymous is not authorized" error, as only authorized IAM users will be able to invoke the API.
B) Create a token-based AWS Lambda authorizer that passes the caller's identity in a bearer token.
- Rejected: A token-based Lambda authorizer could work if the system was using token-based authentication (such as OAuth tokens or JWT tokens). However, this is more complex than necessary and would require a different method of handling authentication. The use of IAM authentication (as in Option A) is simpler and more appropriate in this context for validating requests from principals in the organization.
C) Create a request parameter-based AWS Lambda authorizer that passes the caller's identity in a combination of headers, query string parameters, stage variables, and $context variables.
- Rejected: This option involves creating a custom Lambda authorizer that relies on specific request parameters. While Lambda authorizers offer fle...
