Amazon Practice Questions, Discussions & Exam Topics by our Authors
A company uses AWS Organizations to manage a small number of AWS accounts. However, the company plans to add 1,000 more accounts soon. The company allows only a centralized security team to create IAM roles for all AWS accounts and teams. Application teams submit requests for IAM roles to the security team. The security team has a backlog of IAM role requests and cannot review and provision the IAM roles quickly.
The security team must create a process that will allow application...
In this scenario, the key requirements are:
1. Allow application teams to provision their own IAM roles.
2. Limit the scope of IAM roles.
3. Prevent privilege escalation.
4. Ensure minimal operational overhead for the security team.
Now, let's evaluate each option based on these requirements:
Option A: Create an IAM group for each application team. Associate policies with each IAM group. Provision IAM users for each application team member. Add the new IAM users to the appropriate IAM group by using role-based access control (RBAC).
- Analysis:
- This option involves creating IAM users for each team member and associating them with specific IAM groups based on the role they need. While it would allow application teams to manage access, it doesn't specifically address the need for centralized control over the IAM roles and limits on permissions.
- The use of IAM groups and RBAC doesn’t effectively prevent privilege escalation, as users could still be assigned roles with excessive permissions if not properly managed. It also doesn’t directly solve the backlog issue because the security team is still responsible for creating users and managing their permissions.
- Conclusion: Not ideal due to complexity and potential for privilege escalation.
Option B: Delegate application team leads to provision IAM roles for each team. Conduct a quarterly review of the IAM roles the team leads have provisioned. Ensure that the application team leads have the appropriate training to review IAM roles.
- Analysis:
- This approach gives application team leads the responsibility to provision roles, but the security team still has to perform periodic reviews. This adds more operational overhead for the security team, especially with the growing number of accounts.
- Privilege escalation risks remain since team leads may not always apply the least privilege principle and could provision overly permissive roles.
- A quarterly review isn’t proactive enough, and the team leads may not always be well-trained on the best practices for role provisioning.
- Conclusion: This option creates mo...
Author: Lucas · Last updated May 23, 2026
A developer is receiving AccessDenied errors when the developer invokes API calls to AWS services from a workstation. The developer previously configured environment variables and configuration files on the workstation to use multiple roles with other AWS accounts.
A security engineer needs to help the developer configure authentication. The current credentials must be evaluated wi...
In this scenario, the goal is to configure authentication credentials without conflicting with previously configured credentials while maintaining the current credentials.
Let's analyze each option to determine the best approach:
Option A: In the local AWS CLI configuration file
- Analysis:
- The AWS CLI configuration file (`~/.aws/config`) stores configuration settings like default region, output format, and profile information, including credentials.
- You can specify multiple named profiles in this file, which makes it easier to switch between credentials when using different AWS accounts.
- This option is effective because it allows you to explicitly define credentials for a specific profile, thus isolating them from the default profile or any previously configured profiles. It doesn't conflict with other credentials already configured on the workstation.
- Conclusion: This is a valid option because it allows for isolated management of credentials without overriding or conflicting with existing configurations. The profiles are explicitly defined, making it easy to switch between them.
Option B: As environment variables on the local workstation
- Analysis:
- Environment variables (e.g., `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`) are used by the AWS CLI and SDKs to determine which credentials to use for authentication.
- If credentials are set as environment variables, they will take precedence over any credentials configured in configuration files. This can potentially lead to conflicts if other credentials are also set as environment variables.
- In a scenario where the developer is using multiple roles or AWS accounts, setting credentials in environment variables might override existing configurations and cause issues when switching between profiles.
- Conclu...
Author: Nia · Last updated May 23, 2026
A medical company recently completed an acquisition and inherited an existing AWS environment. The company has an upcoming audit and is concerned about the compliance posture of its acquisition.
The company must identify personal health information inside Amazon S3 buckets and must identify S3 buckets that are publicly accessible. The company needs to prepare for the ...
To prepare for the audit and meet the requirements with the least operational overhead, the company needs to focus on identifying personal health information (PHI) inside Amazon S3 buckets and detecting publicly accessible S3 buckets. Here’s a breakdown of the steps:
Option A: Enable Amazon Macie. Run an on-demand sensitive data discovery job that uses the PERSONAL_INFORMATION managed data identifier.
- Analysis:
- Amazon Macie is a fully managed service designed for discovering and classifying sensitive data, such as personally identifiable information (PII) and personal health information (PHI). By enabling Macie and running an on-demand sensitive data discovery job, you can quickly identify any personal health information inside the S3 buckets.
- The PERSONAL_INFORMATION managed data identifier is designed specifically to detect sensitive personal data, which aligns with the company’s goal of identifying PHI.
- This option is ideal for automatically discovering and classifying sensitive data with minimal overhead and is particularly well-suited to the company's need to meet compliance and audit requirements.
- Conclusion: This is a highly suitable choice because it directly addresses the need to identify PHI in the S3 buckets with minimal manual effort.
Option B: Use AWS Glue with the Detect PII transform to identify sensitive data and to mask the sensitive data.
- Analysis:
- AWS Glue is a managed ETL (Extract, Transform, Load) service that is typically used for data processing and transformation, but it’s not designed specifically for identifying sensitive data like PHI in S3 buckets.
- The Detect PII transform is useful for identifying PII in structured data during ETL jobs, but it’s not as effective for unstructured data or identifying sensitive data within S3 buckets directly.
- This approach would require more setup and may not be as efficient for directly scanning S3 buckets for PHI or performing on-demand discovery.
- Conclusion: This option is not ideal as it involves more operational overhead for processing structured data and isn’t optimized for identifying sensitive data directly within S3 buckets.
Option C: Enable AWS Audit Manager. Create an assessment by using a supported framework.
- Analysis:
- AWS Audit Manager helps automate the process of collecting evidence for audits and compliance assessments. While it can help track controls related to compliance, it does not directly scan for sensitive data in S3 buckets or assess S3 bucket accessibility.
- This tool would help document and track compliance but does not directly address the specific need to identify PHI or publicly accessible S3 buckets.
- Conclusion: This opt...
Author: Noah · Last updated May 23, 2026
A company finds that one of its Amazon EC2 instances suddenly has a high CPU usage. The company does not know whether the EC2 instance is compromised or whether the operating system is performing background cleanup.
Which co...
In this scenario, the primary concern is to determine the cause of the high CPU usage on the EC2 instance (whether it's a result of the operating system performing background tasks or an indication of a potential compromise). The security engineer must take steps that provide valuable information and ensure data integrity for further investigation. Here’s an evaluation of each option:
Option A: Disable termination protection for the EC2 instance if termination protection has not been disabled.
- Analysis:
- Termination protection prevents accidental termination of an EC2 instance through the AWS Management Console. However, disabling termination protection right away in response to high CPU usage is premature and unnecessary, as there’s no immediate need to terminate the instance. Termination protection is useful only if you plan to avoid accidental termination, but it does not help with the current issue of diagnosing high CPU usage.
- Conclusion: Not immediately useful for this situation. The focus should be on understanding the cause of the high CPU usage and preserving data integrity first.
Option B: Enable termination protection for the EC2 instance if termination protection has not been enabled.
- Analysis:
- Enabling termination protection helps prevent accidental termination of the instance during investigation, which is important if the instance is critical and you want to ensure it remains running while you gather data for troubleshooting. This provides a safeguard, ensuring that the instance is not unintentionally terminated during the troubleshooting process.
- Conclusion: This is a good first step to protect the instance from accidental termination, which could disrupt the investigation.
Option C: Take snapshots of the Amazon Elastic Block Store (Amazon EBS) data volumes that are attached to the EC2 instance.
- Analysis:
- Taking snapshots of the attached EBS volumes ensures that you have a copy of the current state of the instance’s data, preserving it for further investigation in case the situation worsens (such as data loss or corruption). Snapshots are critical for forensic analysis, as they can be used later to investigate any potential compromise or abnormal behavior without affecting the current running state of the instance.
- Conclusion: This is an essential step in preserving data and ensuring that you have a reliable source of information for later investigation.
Option D: Remove all snapshots of the Amazon Elastic Block Store (Amazon EBS) data volumes that are attached to ...
Author: Ella · Last updated May 23, 2026
A company is implementing a customized notification solution to detect repeated unauthorized authentication attempts to bastion hosts. The company's security engineer needs to implement a solution that will provide notification when 5 failed attempts occur within a 5-minute period. The solution must use native AWS services and mus...
To meet the requirement of notifying the designated system administrator when 5 failed login attempts occur within a 5-minute period on bastion hosts, using AWS native services, let's analyze each option:
Option A: Use the Amazon CloudWatch agent to collect operating system logs. Use Amazon EventBridge to configure an alarm based on a metric filter for failed login attempts. Send an alert to Amazon Simple Notification Service (SNS) when the defined threshold for the alarm is exceeded. Use Amazon EC2 instance tags to determine which SNS topics receive notifications.
- Analysis:
- Amazon CloudWatch agent can collect operating system logs and send them to CloudWatch Logs, from which you can create metric filters.
- EventBridge could be used to set up rules and trigger actions based on events, but the solution doesn’t specify how the logs are evaluated for failed login attempts.
- SNS topics can be used for notifications, and EC2 instance tags can be leveraged to dynamically select the SNS topic, based on the instance’s tags.
- This solution is feasible but requires multiple components: CloudWatch agent, EventBridge, and EC2 tags to target the right administrator. It could work but introduces more complexity.
- Conclusion: While functional, it may add unnecessary complexity with EventBridge when you could achieve the same result with simpler configurations.
Option B: Use AWS Systems Manager Agent to collect operating system logs. Use the Systems Manager Run Command AWS-ConfigureCloudWatch document to configure an Amazon EventBridge event based on a metric filter for failed login attempts. Send an alert to Amazon SNS when the defined threshold for the alarm is exceeded. Use SNS messaging filters to control who receives notifications.
- Analysis:
- AWS Systems Manager Agent (SSM Agent) helps manage EC2 instances, but it’s primarily designed for management tasks like patching or configuration. It’s not the best tool for collecting operating system logs for login attempts.
- SNS messaging filters allow filtering messages to notify specific recipients, but combining SSM Agent for log collection and EventBridge for metrics and alarms could overcomplicate the solution. Systems Manager Run Command is also less suitable here than using CloudWatch directly.
- Conclusion: This option adds unnecessary complexity by using Systems Manager to collect logs and configure alarms. It is not the most e...
Author: Mia · Last updated May 23, 2026
An ecommerce website was down for 1 hour following a DDoS attack. Users were unable to connect to the website during the attack period. The ecommerce company's security team is worried about future potential attacks and wants to prepare for such events. The company needs to mi...
To minimize downtime during a future DDoS attack and prepare the ecommerce website for such events, the following steps are crucial:
Explanation of Options:
A) Enable Amazon GuardDuty to automatically monitor for malicious activity and block unauthorized access.
- Rejected: While GuardDuty is useful for monitoring and detecting malicious activity, it doesn't directly mitigate DDoS attacks. It helps in identifying security threats like unauthorized access, but it doesn’t have direct capabilities to mitigate DDoS traffic. It is more suitable for detecting anomalies in AWS resources but doesn't provide an automatic blocking solution for DDoS events.
B) Subscribe to AWS Shield Advanced and reach out to AWS Support in the event of an attack.
- Selected: AWS Shield Advanced offers DDoS protection and automatic mitigation capabilities. It provides enhanced protection against larger and more sophisticated DDoS attacks. It also includes 24/7 support and provides real-time attack diagnostics, which are critical for minimizing downtime. This step will help ensure that the site is protected during an attack, and in case of a severe attack, the support team can assist in remediation. Shield Advanced is specifically designed to handle DDoS attacks and reduce impact, which is why this is one of the best options.
C) Use VPC Flow Logs to monitor network traffic and an AWS Lambda function to automatically block an attacker's IP using security groups.
- Rejected: VPC Flow Logs can help monitor network traffic and provide visibility into the traffic patterns, but they do not directly block DDoS traffic. Lambda can be set up to respond to specific traffic patterns, but this approach requires significant customization and m...
Author: Lucas · Last updated May 23, 2026
An AWS account includes two S3 buckets: bucket1 and bucket2. The bucket2 does not have a policy defined, but bucket1 has the following bucket policy:
In addition, the same account has an IAM User na...
To determine which S3 buckets the IAM user "alice" can access, we need to analyze both the bucket policy for bucket1 and the IAM policy associated with alice.
Key Factors:
1. Bucket Policy for bucket1:
- Bucket policies are defined for S3 buckets and control access to the objects within them. In this case, bucket1 has a policy that likely grants access to alice, but the exact policy details are missing here.
- However, if the bucket policy allows alice access to bucket1, she will be able to access it.
2. Bucket Policy for bucket2:
- bucket2 does not have any policy defined, which means no explicit permissions are granted to access bucket2. By default, unless there is an explicit permission or an IAM policy allowing access to bucket2, alice will not have access to it.
3. IAM Policy for alice:
- IAM policies define permissions granted to specific IAM users or groups. For alice to access a bucket, her IAM ...
Author: Evelyn · Last updated May 23, 2026
A company has used AWS Lambda functions to build an application on AWS. The company's security engineer implemented Amazon Inspector and activated Lambda standard scanning and Lambda code scanning.
The security engineer reviews the Amazon Inspector console and learns that Amazon Inspector is not scanning some of the Lambda functions. The ...
To investigate why Amazon Inspector is not scanning some Lambda functions and the reason stated is that "the scan eligibility expired," the most relevant factor to investigate is whether the Lambda functions have been invoked recently. Amazon Inspector scans Lambda functions that have been invoked within the past 90 days. If the Lambda functions haven't been invoked in this time frame, their scan eligibility would expire, and Amazon Inspector would not scan them.
Analyzing Each Option:
A) Validate that the AmazonInspector2ServiceRolePolicy AWS managed policy grants permissions to access Lambda.
- Rejected: While it's important for the IAM role used by Amazon Inspector to have the correct permissions, the issue described here is related to the scan eligibility expiration due to lack of recent invocations. The IAM policy would only be relevant if there were issues with permission to scan the Lambda functions, but since the issue is about expired scan eligibility, this is not the cause.
B) Increase the timeout value of the Lambda functions to complete the scans successfully while the code is running.
- Rejected: The timeout value for the Lambda function determines how long the function can run before timing out. This does not affect scan eligibility or the fact that scans are not happening because the Lambda function has not been i...
Author: Kunal · Last updated May 23, 2026
A company is testing incident response procedures for destination containment. The company needs to contain a critical Amazon EC2 instance as quickly as possible while keeping the EC2 instance running. The EC2 instance is the only resource in a public subn...
To immediately contain the EC2 instance while keeping it running, we need a solution that effectively prevents any further traffic to or from the EC2 instance without disrupting its operation.
Let's analyze each option in detail:
A) Create a new security group that has no inbound rules or outbound rules. Attach the new security group to the EC2 instance.
- Analysis: A security group controls traffic at the instance level and allows for immediate changes. Creating a new security group with no inbound or outbound rules and attaching it to the EC2 instance will effectively block any new inbound and outbound traffic to and from the EC2 instance.
- Pros: This action can be performed quickly, and it immediately blocks all traffic without stopping the EC2 instance. It is also non-disruptive to the instance's internal processes.
- Cons: The EC2 instance might still maintain connections to existing resources, but no new connections can be made, and no outbound traffic can occur.
B) Configure the existing security group for the EC2 instance. Remove all existing inbound rules and outbound rules from the security group.
- Analysis: This option modifies the existing security group by removing all inbound and outbound rules, which would have the same effect as option A. The EC2 instance would immediately stop accepting any new inbound connections or making outbound connections.
- Pros: It's effective and fast in blocking all traffic.
- Cons: Since the change is made to the existing security group, it might affect other instances if they are using the same security group.
C) Create a new network ACL that has a single Deny rule for in...
Author: Ava · Last updated May 23, 2026
A company needs to use HTTPS when connecting to its web applications to meet compliance requirements. These web applications run in Amazon VPC on Amazon EC2 instances behind an Application Load Balancer (ALB). A security engineer wants to ensure that the load balancer will only accept connections over port 443, even if the...
In this scenario, the goal is to ensure that the Application Load Balancer (ALB) only accepts connections over port 443 (HTTPS), even if it is mistakenly configured with an HTTP listener (port 80). Let's evaluate each of the options provided:
A) Create a security group with a rule that denies inbound connections from 0.0.0.0/0 on port 80. Attach this security group to the ALB to overwrite more permissive rules from the ALB's default security group.
- Analysis: Security groups in AWS are stateful, meaning that if a rule denies traffic on port 80, it will prevent inbound HTTP connections. However, security groups don't have an explicit deny rule by default, so adding a deny rule for port 80 could conflict with the more permissive rules, potentially causing issues.
- Pros: A security group is applied directly to the ALB and will stop unwanted HTTP traffic.
- Cons: Security groups are stateful, meaning they don't block all types of inbound traffic as strictly as necessary in this case. Instead, they allow traffic unless specifically denied, and applying a deny rule might not be effective in all situations, especially if the default security group is misconfigured. Additionally, this approach might not work if other more permissive security groups are applied elsewhere.
B) Create a network ACL that denies inbound connections from 0.0.0.0/0 on port 80. Associate the network ACL with the VPC's internet gateway.
- Analysis: Network ACLs work at the subnet level and provide a stateless way to allow or deny traffic. Associating a network ACL with the VPC's internet gateway could potentially block traffic at the subnet level. However, this approach would affect all traffic across the subnet, not just the ALB, which could impact other services or resources within the VPC.
- Pros: Network ACLs can enforce network-level restrictions.
- Cons: Sin...
Author: Ava · Last updated May 23, 2026
A consultant agency needs to perform a security audit for a company's production AWS account. Several consultants need access to the account. The consultant agency already has its own AWS account.
The company requires multi-factor authentication (MFA) for all access to its production account. The company also f...
In this scenario, the goal is to provide the consultant agency with access to the company's production AWS account while meeting the following requirements:
1. Multi-factor authentication (MFA): MFA must be enabled for all access to the production account.
2. No long-term credentials: Long-term credentials (e.g., IAM users with static access keys) are forbidden.
Let's analyze each option:
A) Create an IAM group. Create an IAM user for each consultant. Add each user to the group. Turn on MFA for each consultant.
- Analysis: This option involves creating individual IAM users for each consultant, which violates the requirement to avoid long-term credentials. IAM users typically have long-term access keys, which are not permitted by the company.
- Pros: It can meet the MFA requirement if MFA is configured for each user.
- Cons: This approach violates the company's policy against long-term credentials, as IAM users with static access keys would be required.
B) Configure Amazon Cognito on the company’s production account to authenticate against the consultant agency's identity provider (IdP). Add MFA to a Cognito user pool.
- Analysis: Amazon Cognito is primarily used for federating user access, often for web or mobile applications. While Cognito can integrate with an identity provider (IdP) and enforce MFA, this is not the typical approach for giving consultants access to an AWS account. Moreover, it may introduce unnecessary complexity and doesn't align directly with standard AWS access management best practices.
- Pros: MFA can be implemented with Cognito.
- Cons: It is a more complex solution and not a standard approach for granting AWS account access. Additionally, it may not fully integrate with the AWS permissions model.
C) Create an IAM role in the consultant agency’s AWS account. Define a trust policy that requires MFA. In the trust policy, specify the c...
Author: Maya · Last updated May 23, 2026
A company uses AWS Lambda functions to implement application logic. The company uses an organization in AWS Organizations to manage hundreds of AWS accounts.
The company needs to implement a solution to continuously monitor the Lambda functions for vulnerabilities in all accounts. The solution must publish detected issues to a dashboard. Lambda functio...
To continuously monitor Lambda functions for vulnerabilities across multiple AWS accounts and publish detected issues to a dashboard, while ensuring that Lambda functions in testing or development are excluded from the dashboard, we need a combination of security services and filtering options.
Let's analyze each option:
A) Designate a delegated Amazon GuardDuty administrator account in the organization's management account. Use the GuardDuty Summary dashboard to obtain an overview of Lambda functions that have vulnerabilities.
- Analysis: GuardDuty is a security service that detects suspicious activity and potential vulnerabilities in your AWS environment. It provides insights into findings related to Lambda functions, but it does not provide specific vulnerability scanning for Lambda functions, which is not its primary focus. GuardDuty would show security-related findings, but not detailed vulnerabilities in Lambda functions, which makes it unsuitable for this requirement.
- Pros: GuardDuty is useful for security activity monitoring.
- Cons: It does not specifically focus on vulnerabilities in Lambda functions.
B) Designate a delegated Amazon Inspector administrator account in the organization's management account. Use the Amazon Inspector dashboard to obtain an overview of Lambda functions that have vulnerabilities.
- Analysis: Amazon Inspector is designed to assess vulnerabilities in AWS resources, including Lambda functions. By designating an administrator account and using the Amazon Inspector dashboard, you can scan Lambda functions across multiple accounts for vulnerabilities. This meets the requirement of monitoring Lambda functions for vulnerabilities.
- Pros: Amazon Inspector is specifically designed for vulnerability assessment, including Lambda functions. This directly addresses the requirement of continuously monitoring Lambda functions for vulnerabilities.
- Cons: There is no mention of how to exclude Lambda functions in testing or development from appearing on the dashboard.
C) Apply tags of “test” or “development” to all Lambda functions that are in testing or development. Use a suppression filter that suppresses findings that contain these tags.
- Analysis: This option ensures that Lambda functions in testing or development are tagged with specific identifiers (e.g., "test" or "development"). Using a suppression filter based on these tags will ensure that vulnerabilities detected in these Lambda functions do not appear on the dashboard. This so...
Author: Michael · Last updated May 23, 2026
A company has an organization in AWS Organizations that includes dedicated accounts for each of its business units. The company is collecting all AWS CloudTrail logs from the accounts in a single Amazon S3 bucket in the top-level account. The company's IT governance team has access to the top-level account. A security engineer needs to allow each business unit to access its own CloudTrail logs.
The security engineer creates an IAM role in the top-level account for each of the other accounts. For each role, the security engineer creates an IAM p...
The security engineer's goal is to allow IAM users in the business unit accounts to access their respective CloudTrail logs stored in the top-level account's S3 bucket. The security engineer has already created an IAM role in the top-level account for each business unit, with a policy granting read-only permissions to the S3 objects corresponding to each business unit's logs. Now, the next step is to configure the business unit accounts to allow their IAM users to assume the role in the top-level account.
Let's evaluate each option:
A) Attach a policy to the IAM user to allow the user to assume the role that was created in the top-level account. Specify the role's ARN in the policy.
- Analysis: This option is correct. The IAM users in the business unit accounts need permission to assume the role in the top-level account. By attaching a policy to the IAM user in the business unit account that allows the user to assume the role in the top-level account (using the role's ARN), the IAM user can assume the role and access the CloudTrail logs stored in the top-level account's S3 bucket.
- Pros: This is a best practice for cross-account access and is explicitly designed for the scenario described. It adheres to AWS security practices for cross-account roles.
- Cons: No significant cons for this scenario.
B) Create an SCP that grants permissions to the top-level account.
- Analysis: Service Control Policies (SCPs) are used to manage permissions across accounts within AWS Organizations. SCPs control what actions can be performed across the organization or specific accounts, but they do not directly grant permissions for IAM users to assume roles. SCPs are not the correct tool for granting IAM users in the business unit accounts permission to assume roles in the top-level acc...
Author: CrystalWolfX · Last updated May 23, 2026
A company has configured an organization in AWS Organizations for its AWS accounts. AWS CloudTrail is enabled in all AWS Regions.
A security engineer must implement a solution to prev...
To prevent CloudTrail from being disabled, we need a solution that ensures CloudTrail logging cannot be turned off by users or services in the AWS account, even by administrative users. Let's analyze each option in detail:
Option A: Enable CloudTrail log file integrity validation from the organization’s management account.
- Analysis: Enabling log file integrity validation helps ensure the integrity of CloudTrail logs by detecting any tampering, but it does not prevent the ability to disable CloudTrail or stop logging. While it is a good security practice for auditing purposes, it doesn't specifically prevent disabling CloudTrail.
- Rejection Reason: This option doesn't directly prevent CloudTrail from being disabled; it only secures the logs after they've been created.
Option B: Enable server-side encryption with AWS KMS keys (SSE-KMS) for CloudTrail logs. Create a KMS key. Attach a policy to the key to prevent decryption of the logs.
- Analysis: Enabling SSE-KMS encryption ensures that CloudTrail logs are encrypted, but it doesn't prevent CloudTrail from being disabled. The focus here is on securing the logs after they are created, not preventing actions like disabling CloudTrail or stopping logging.
- Rejection Reason: While important for securing logs, it doesn't directly prevent CloudTrail from being disabled or tampered with by users.
Option C: Create an SCP that includes an explicit Deny rule for the StopLogging action and the DeleteTrail action. Attach the SCP to the root OU.
- Analysis: Service Control Policies (SCPs) are part of AWS Organizations and are used to manage permissions across AWS accounts in the organization. By explicitly de...
Author: Maya · Last updated May 23, 2026
A company runs its microservices architecture in Kubernetes containers on AWS by using Amazon Elastic Kubernetes Service (Amazon EKS) and Amazon Aurora The company has an organization in AWS Organizations to manage hundreds of AWS accounts that host different microservices.
The company needs to implement a monitoring solution for logs from all AWS resources across all acc...
To determine the most suitable solution for monitoring logs from all AWS resources across multiple accounts and detecting security-related issues with the least operational effort, let’s analyze each option based on key factors like ease of implementation, operational overhead, automation, and security-focused features.
Option A: Designate an Amazon GuardDuty administrator account in the organization’s management account. Enable GuardDuty for all accounts. Enable EKS Protection and RDS Protection in the GuardDuty administrator account.
- Analysis: Amazon GuardDuty is a managed threat detection service that provides continuous monitoring of AWS accounts for malicious or unauthorized behavior. It works seamlessly with various AWS services like EKS (Elastic Kubernetes Service) and RDS (Relational Database Service). By enabling GuardDuty across all accounts, security-related findings are automatically aggregated in the designated administrator account.
- Selection Reasoning: This option involves the least operational overhead because GuardDuty automatically detects security issues without requiring custom log management, and it integrates natively with AWS services like EKS and RDS. It requires minimal setup once GuardDuty is enabled and provides automatic threat detection across multiple AWS accounts.
- Rejection Reason: This solution doesn't focus on general log collection for all AWS resources, but it is tailored specifically for security-related event detection, which aligns well with the company’s need for automatic detection of security issues.
Option B: Designate a monitoring account. Share Amazon CloudWatch logs from all accounts with the monitoring account. Configure Aurora to publish all logs to CloudWatch. Use Amazon Inspector in the monitoring account to evaluate the CloudWatch logs.
- Analysis: This option involves setting up centralized log collection in CloudWatch and using Amazon Inspector for security evaluations. However, this would require setting up CloudWatch log groups for each service and integrating Aurora with CloudWatch logs, which adds complexity. While Amazon Inspector can help with security assessments, the setup and management effort would be significant.
- Rejection Reason: This option requires more configuration and ongoing management to set up CloudWatch logging across all services and accounts. It also introduces complexity due to the manual log collection and security evaluation processes, making it less efficient compared to other solutions.
Option C: Create a central Amazon S3 bucket in the organizat...
Author: Suresh · Last updated May 23, 2026
A security engineer has been asked to troubleshoot inbound connectivity to a web server. This single web server is not receiving inbound connections from the internet, whereas all other web servers are functioning properly.
The architecture includes network ACLs, security groups, and a virtual security appliance. In addition, the development team has implemented Application Load Balancers (ALBs) to distribute the load across all web servers. It is a requirement that traffic between the web servers and the internet flow through the virtual security appliance.
The security engineer has verified the f...
To troubleshoot why the web server is not receiving inbound connections while others are functioning properly, we need to analyze the networking and routing configuration between the web server, the Application Load Balancer (ALB), and the virtual security appliance. Given the information, we have already ruled out security group, network ACL, and virtual appliance rule set issues.
Let’s go through each option and assess its relevance:
Option A: Verify that the 0.0.0.0/0 route in the route table for the web server subnet points to a NAT gateway.
- Analysis: The web server needs to receive inbound traffic from the internet, and the NAT gateway is typically used for outbound traffic from private subnets to the internet. If the web server is in a private subnet, the NAT gateway might be used for outbound traffic, but it’s not relevant for inbound traffic. The route for inbound traffic should point to the virtual security appliance or ALB, not the NAT gateway.
- Rejection Reason: NAT gateways are used for outbound traffic from private subnets and do not affect inbound traffic. Thus, this is not the root cause of the issue.
Option B: Verify which security group is applied to the particular web server’s elastic network interface (ENI).
- Analysis: Each web server has an ENI, and the correct security group should be applied to it to allow inbound traffic. Even though the security group rule set was verified, it’s possible that a different security group is associated with the ENI of this specific web server, causing connectivity issues.
- Selection Reasoning: This is a valid troubleshooting step. If the incorrect security group is applied to the ENI of the particular web server, it could explain why that specific server is not receiving traffic despite other servers working fine. Verifying this configuration ensures there are no misconfigurations at the ENI level.
Option C: Verify that the 0.0.0.0/0 route in the route table for the web server subnet points to the virtual security appliance.
- Analysis: Since the requirement specifies that traffic between the web servers and the internet must flow through the virtual security appliance, the route table for the web server subnet must direct outbound traffic to the virtual ...
Author: Lucas · Last updated May 23, 2026
A company has a strict policy against using root credentials. The company's security team wants to be alerted as soon as possible when root credentials are used to sign in to th...
The security team needs to be alerted when root credentials are used to sign in to the AWS Management Console. Let’s analyze each option to determine the most effective solution:
Option A: Use AWS Lambda to periodically query AWS CloudTrail for console login events and send alerts using Amazon Simple Notification Service (Amazon SNS).
- Analysis: While AWS Lambda can be used to query CloudTrail logs periodically, this approach introduces complexity because it requires periodic querying, which could be inefficient for real-time alerting. Furthermore, CloudTrail logs are typically delivered with some delay, making this method less immediate. This option is more resource-intensive and would involve custom Lambda functions and scheduled jobs to check for root logins.
- Rejection Reason: This approach introduces unnecessary complexity and might not be as real-time as other solutions. It is not as efficient or simple as directly leveraging AWS services built for event-driven monitoring.
Option B: Use Amazon EventBridge to monitor console logins and direct them to Amazon Simple Notification Service (Amazon SNS).
- Analysis: Amazon EventBridge is a serverless event bus service that can monitor AWS CloudTrail events in near real-time, including sign-ins to the AWS Management Console. EventBridge can be easily configured to trigger alerts when specific events occur, such as the use of root credentials. This method allows the security team to receive instant alerts when root credentials are used to sign in, without the need for complex custom code or periodic queries.
- Selection Reasoning: This is the most efficient and straightforward solution. EventBridge integrates well with CloudTrail and can send immediate alerts based on specific conditions, like root sign-ins, to SNS. It's fully managed and highly scalable, making it the best option...
Author: CrystalWolfX · Last updated May 23, 2026
A security engineer is designing security controls for a fleet of Amazon EC2 instances that run sensitive workloads in a VPC. The security engineer needs to implement a solution to detect and mitigate soft...
To determine which solution will best meet the requirement of detecting and mitigating software vulnerabilities on EC2 instances running sensitive workloads, let’s evaluate each option based on key factors like vulnerability detection, patch management, and automation.
Option A: Scan the EC2 instances by using Amazon Inspector. Apply security patches and updates by using AWS Systems Manager Patch Manager.
- Vulnerability Detection: Amazon Inspector is a security assessment service that helps detect vulnerabilities and exposures in EC2 instances. It can identify vulnerabilities such as missing patches, insecure configurations, and known software flaws.
- Patch Management: AWS Systems Manager Patch Manager automates the process of applying security patches to EC2 instances, ensuring that the instances are up to date with the latest security patches.
- Automation: Both tools offer strong integration with AWS services, making automation and continuous monitoring possible.
- Reason for Selection: This solution directly addresses the need for both vulnerability scanning and patch management. Amazon Inspector and AWS Systems Manager Patch Manager are purpose-built for the task.
Option B: Install host-based firewall and antivirus software on each EC2 instance. Use AWS Systems Manager Run Command to update the firewall and antivirus software.
- Vulnerability Detection: Antivirus and firewall software provide a basic level of defense but are not specifically designed for comprehensive vulnerability detection on EC2 instances. They are more suited to protecting against malware and unauthorized access rather than identifying security vulnerabilities in the software stack.
- Patch Management: While AWS Systems Manager can help automate software updates and patches for the firewall and antivirus, it does not directly address patching the OS or other critical software components.
- Reason for Rejection: This option does not directly address vulnerability scanning at the software level, ma...
Author: Ethan · Last updated May 23, 2026
A company stores sensitive data in AWS Secrets Manager. A security engineer needs to design a solution to generate a notification email when anomalous GetSecretValue API calls occur. The security engineer has configured an Amazon EventBridge rule f...
To determine which solution meets the requirement of generating a notification email when anomalous `GetSecretValue` API calls occur in AWS Secrets Manager, we need to assess the options based on their ability to:
1. Detect anomalous API calls (specifically `GetSecretValue` calls).
2. Trigger notifications based on the detected anomaly.
3. Make use of the EventBridge rule that has already been configured to capture all Secrets Manager events delivered by AWS CloudTrail.
Option A: Configure CloudTrail as the target of the EventBridge rule. Set up an attribute filter on the IncomingBytes attribute and enable anomaly detection. Create an Amazon Simple Notification Service (Amazon SNS) topic. Configure a CloudTrail alarm that uses the SNS topic to send the notification.
- CloudTrail as Target: CloudTrail records API calls for AWS services, but configuring it as the target of an EventBridge rule is not optimal for anomaly detection or notifications. EventBridge rules typically route events to AWS services like Lambda, SNS, or SQS, rather than CloudTrail directly.
- Anomaly Detection: While CloudTrail can log `GetSecretValue` API calls, anomaly detection is typically handled by services like CloudWatch or through EventBridge rules, not directly via CloudTrail alarms.
- Reason for Rejection: This option involves misusing CloudTrail as the target and doesn’t directly address anomaly detection or the correct way to trigger notifications for anomalous API calls.
Option B: Configure CloudTrail as the target of the EventBridge rule. Set up an attribute filter on the IncomingBytes attribute and enable anomaly detection. Create an Amazon Simple Queue Service (Amazon SQS) queue. Configure a CloudTrail alarm that uses the SQS queue to send the notification.
- CloudTrail as Target: Similar to Option A, using CloudTrail as a target of the EventBridge rule isn’t the ideal approach. EventBridge can send events to SQS, SNS, or Lambda, but CloudTrail itself should not be the direct target.
- Anomaly Detection: Anomaly detection is better handled with CloudWatch or other AWS services, not directly through CloudTrail.
- Reason for Rejection: The use of CloudTrail as the target is incorrect, and SQS is not the best fit for handling anomaly-based notifications. SNS is more commonly used for notifications.
...
Author: Emma · Last updated May 23, 2026
A company is using AWS Organizations with the default SCP. The company needs to restrict AWS usage for all AWS accounts that are in a specific OU.
Except for some desired global services, the AWS usage must occur only in the eu-west-1 Region for all accounts in the OU. A security engineer must create ...
To meet the requirement of restricting AWS usage for all accounts in a specific Organizational Unit (OU) to only the `eu-west-1` region, except for some global services, the security engineer needs to design an Service Control Policy (SCP) that applies this restriction. Let's analyze the options based on the following requirements:
Key Requirements:
1. Region Restriction: AWS usage should only be allowed in the `eu-west-1` region for all accounts in the specific OU.
2. Global Services: Some global services (like IAM, AWS SSO, etc.) must remain available across all regions.
3. Applies to Existing and New Accounts: The SCP must apply to both existing and any new accounts in the OU.
Option Analysis:
We need to structure the SCP to:
- Deny access to all regions except `eu-west-1`.
- Allow the usage of global services (those that are not region-specific).
Let's look at the possible structures for this SCP.
SCP Example (General Structure):
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "",
"Resource": "",
"Condition": {
"StringNotEqualsIfExists": {
"aws:RequestedRegion": "eu-west-1"
}
}
},
{
"Effect": "Allow",
"Action": "",
"Resource": "",
"Condition": {
"StringEqualsIfExists": {
"aws:RequestedRegion": "global"
}
}
}
]
}
```
Key Factors:
1. Allow Global Services: The `"S...
Author: Kunal · Last updated May 23, 2026
A company is planning to migrate its applications to AWS in a single AWS Region. The company's applications will use a combination of Amazon EC2 instances, Elastic Load Balancing (ELB) load balancers, and Amazon S3 buckets. The company wants to complete the migration as quickly as possible. All the applications must meet the following requirements:
* Data must be encrypted at rest.
* Data must be encrypted in transit.
* E...
To meet the company's requirements with the least effort, the security engineer needs to ensure that data is encrypted both at rest and in transit, and that endpoints are monitored for anomalous network traffic. Let's break down the options and assess how they contribute to meeting these goals.
Key Requirements:
1. Data Encryption at Rest: This ensures that data stored in services like Amazon EC2 and Amazon S3 is encrypted.
2. Data Encryption in Transit: This ensures that data moving between clients, load balancers, and EC2 instances is encrypted.
3. Endpoint Monitoring for Anomalous Network Traffic: This helps detect any unusual or potentially harmful activity on the endpoints.
Option Analysis:
A) Install the Amazon Inspector agent on EC2 instances by using AWS Systems Manager Automation.
- Data Encryption: This option does not address encryption for data in transit or at rest.
- Anomalous Traffic Monitoring: Amazon Inspector can provide security assessments, but it doesn't directly monitor for anomalous network traffic on EC2 instances.
- Reason for Rejection: While Amazon Inspector is useful for security assessments, this option does not directly address the primary requirements of encryption or monitoring anomalous traffic, and it requires additional configuration and setup for each EC2 instance.
B) Enable Amazon GuardDuty in all AWS accounts.
- Anomalous Traffic Monitoring: GuardDuty is a threat detection service that continuously monitors for anomalous activity, including unusual network traffic patterns and malicious behavior.
- Encryption: GuardDuty does not directly handle encryption but supports monitoring security-related activities (which is useful for endpoint monitoring).
- Reason for Selection: This option is essential for monitoring anomalous network traffic, and it's a relatively easy and effective solution to detect suspicious activity without requiring complex manual setup.
C) Create VPC endpoints for Amazon EC2 and Amazon S3. Update VPC route tables to use only the secure VPC endpoints.
- Data Encryption in Transit: VPC endpoints ensure that traffic between EC2 instances and S3 remains private and encrypted over the AWS network, which is highly secure.
- Encryption at Rest: VPC endpoints do not directly affect encryption at rest for S3 or EC2.
- Reason for Rejection: While VPC endpoints provide secure and encrypted traffic in transit, they do not directly address e...
Author: ShadowWolf101 · Last updated May 23, 2026
A security engineer is working with a development team to design a supply chain application that stores sensitive inventory data in an Amazon S3 bucket. The application will use an AWS Key Management Service (AWS KMS) customer managed key to encrypt the data in Amazon S3.
The inventory data in Amazon S3 will be shared with hundreds of vendors. All vendors will use AWS principals from their own AWS accounts to access the data in Amazon S3. The vendor list might change...
To meet the requirement of securely managing cross-account access for a customer-managed key in AWS KMS and enabling the sharing of sensitive inventory data in Amazon S3, the solution should be both secure and operationally efficient. The application involves multiple vendors with potentially changing access every week, which requires a flexible and scalable access control mechanism.
Let’s evaluate each option in detail:
Option A: Use KMS grants to manage key access. Programmatically create and revoke grants to manage vendor access.
- KMS Grants: KMS grants provide fine-grained access control by granting permissions to specific principals for a limited time or with certain conditions. Grants can be created and revoked programmatically.
- Operational Efficiency: While grants allow fine-grained control over key access, they are less intuitive and harder to manage at scale when dealing with hundreds of vendors. Managing grants programmatically for every vendor change could become cumbersome, especially if the vendor list changes frequently.
- Reason for Rejection: This approach could require significant custom automation for every vendor change, making it less efficient in a scenario where the vendor list changes weekly.
Option B: Use an IAM role to manage key access. Programmatically update the IAM role policies to manage vendor access.
- IAM Roles: IAM roles can be used to grant access to resources across AWS accounts. However, for managing KMS key access specifically, IAM roles would require the role policies to include specific permissions for KMS actions, which would need to be updated programmatically as vendor access changes.
- Operational Efficiency: This solution involves managing IAM policies for every vendor in every account, which could become operationally challenging at scale, especially when there are frequent changes to the vendor list.
- Reason for Rejection: While it’s possible to use IAM roles, it would require manually updating IAM role policies or creating new roles each time vendors change. This adds unnecessary complexity and operational overhead.
Option C: Use KMS key policies to manage key access. Programmatically update the KMS key policies to manage vendor access.
- KMS Key Policies: A KMS key policy de...
Author: Julian · Last updated May 23, 2026
A company runs an application on a fleet of Amazon EC2 instances behind an Application Load Balancer (ALB). A security engineer needs to provide secure access to the application without requiring the use of a VPN. Users should be able to access the application only when they...
To meet the security requirements of providing secure access to the application without requiring a VPN and ensuring that users can access the application only when they meet specific security conditions, including a defined device posture, let's evaluate each option:
Option A: Create an AWS WAF web ACL. Configure a custom response to block traffic that does not align with the defined device posture.
- Analysis: AWS WAF (Web Application Firewall) can block or allow traffic based on a set of conditions, such as IP addresses, geographic locations, HTTP headers, and request body content. However, it is not natively designed to enforce device posture checks. While you can implement some level of security with WAF (e.g., blocking certain traffic types), it does not have built-in support for evaluating specific device posture or enforcing device security checks like device health, installed software, or security settings.
- Reason for Rejection: AWS WAF is not designed to handle detailed device posture evaluation, which is a key requirement in this scenario. It cannot enforce security conditions related to device posture on its own.
Option B: Configure AWS Verified Access. Add the application by creating an endpoint for the ALB.
- Analysis: AWS Verified Access is a service that allows you to control access to your applications based on identity, device posture, and other security conditions. It integrates well with services like Amazon EC2 and ALB and can enforce device posture checks, such as ensuring that users meet specific security conditions like device health, compliance, and security software status. It works seamlessly with ALB to control user access based on these conditions.
- Reason for Selection: AWS Verified Access is specifically designed for scenario...
Author: Ella · Last updated May 23, 2026
A company needs to retain data that is stored in Amazon CloudWatch Logs log groups. The company must retain this data for 90 days. The company must receive notification in AWS Security Hub when log group retention is no...
Option A: Create a Security Hub custom action to assess the log group retention period.
- Analysis: A Security Hub custom action allows users to create custom workflows for security findings, such as marking findings as reviewed or assigning them to a specific user. However, custom actions do not automatically assess compliance or check configurations like log group retention periods. Instead, they are typically triggered manually based on security findings or alerts.
- Reason for Rejection: While Security Hub custom actions are useful for workflow automation based on findings, they do not provide automated monitoring or assessment of CloudWatch Logs retention policies. Therefore, this option is not suitable for continuously monitoring log retention compliance.
Option B: Create a data protection policy in CloudWatch Logs to assess the log group retention period.
- Analysis: CloudWatch Logs data protection policies can be used to monitor log data and ensure compliance with certain security and data protection policies. However, CloudWatch Logs does not directly support a built-in feature for assessing the retention period of log groups through such policies.
- Reason for Rejection: CloudWatch Logs does not have a native "data protection policy" feature to assess the retention period for log groups. This makes it an ineffective solution for the requirement.
Option C: Create a Security Hub automation rule. Configure the automation rule to assess the log group retention period.
- Analysis: Security Hub automation rules can be used to automatically take actions based on security findings, such as triggering workflows or remediati...
Author: Ethan · Last updated May 23, 2026
A company needs to prevent Amazon S3 objects from being shared with IAM identities outside of the company's organization in AWS Organizations. A security engineer is creating and deploying an SCP to accomplish this goal. The company has enabled the S3...
To meet the requirement of preventing Amazon S3 objects from being shared with IAM identities outside of the company's organization in AWS Organizations, the security engineer is creating and deploying a Service Control Policy (SCP). Let's review each option:
Option A: Deny the S3: action with a Condition element that comprises an operator of StringNotEquals, a key of aws:ResourceOrgID, and a value of {aws:PrincipalOrgID}.
- Analysis: The condition `aws:ResourceOrgID` checks the organization ID associated with the resource (in this case, an S3 bucket), and `aws:PrincipalOrgID` checks the organization ID of the IAM principal (the user or role making the request). The condition ensures that the action can only be performed if the resource and the principal belong to the same AWS Organization. This is the correct approach because it directly restricts actions on S3 objects to only IAM identities that belong to the same organization.
- Reason for Selection: This is the most appropriate solution because it ensures that the S3 actions are only allowed when both the IAM principal and the S3 resource belong to the same organization, effectively preventing sharing with external entities.
Option B: Deny the S3:PutAccountPublicAccessBlock action with a Condition element that comprises an operator of StringLike, a key of aws:PrincipalArn, and the values of the external IAM principals.
- Analysis: The action `S3:PutAccountPublicAccessBlock` is used to manage the account-level public access block configuration, but this does not directly address the concern of preventing S3 objects from being shared with external IAM identities. The `aws:PrincipalArn` condition is intended to filter based on the ARN of the IAM principal, but this option is not sufficient to prevent external sharing of S3 objects.
- Reason for Rejection: This option is more related to managing public access settings rather than ensuring that only internal IAM principals can access or share S3 object...
Author: VenomousSerpent42 · Last updated May 23, 2026
A security engineer is implementing authentication for a multi-account environment by using federated access with SAML 2.0. The security engineer has configured AWS IAM Identity Center as an identity provider (IdP). The security engineer also has created IAM roles to grant access to the AWS accounts.
A federated user reports an authentication failure when the u...
To troubleshoot the federated authentication issue in a multi-account environment using SAML 2.0 with AWS IAM Identity Center, let's break down the available options:
Option A: Review the SAML IdP logs to identify errors. Check AWS CloudTrail to verify the API calls that the user made.
- Analysis: Reviewing the SAML IdP logs is critical for identifying potential issues in the SAML assertion or any misconfigurations in the identity provider (IdP). This can help pinpoint if the SAML assertion is correctly formatted and if the correct roles and permissions are included. Checking AWS CloudTrail helps to trace the API calls made by the federated user and can provide insight into what exactly failed during the authentication or authorization process. These steps would give a comprehensive overview of both the IdP and AWS sides of the authentication process.
- Reason for Selection: This approach is operationally efficient because it combines reviewing both IdP logs (for issues with the authentication process) and AWS CloudTrail logs (to verify that the correct roles and permissions are being applied on the AWS side). It directly addresses the need to troubleshoot authentication failures by looking at both the source of the authentication and the subsequent AWS API calls.
Option B: Review the SAML IdP logs to identify errors. Use the IAM policy simulator to validate access to the IAM roles.
- Analysis: Reviewing the SAML IdP logs is essential, but using the IAM policy simulator is less efficient for troubleshooting federated access because the simulator is designed to test permissions for IAM users, not federated users. The simulator does not fully replicate the federated login process and may not catch issues related to the SAML assertion or role mappings that are specific to federated access.
- Reason for Rejection: The IAM policy simulator is not as effective in troubleshooting federated login issues since it does not simulate the full federated authentication and authorization process. It’s ...
Author: ShadowWolf101 · Last updated May 23, 2026
A company stores sensitive data in an Amazon S3 bucket. The company encrypts the data at rest by using server-side encryption with Amazon S3 managed keys (SSE-S3).
A security engineer must prevent any m...
To meet the requirement of preventing any modifications to the data in the Amazon S3 bucket, let's evaluate the available options:
Option A: Configure S3 bucket policies to deny DELETE and PUT object permissions.
- Analysis: Configuring S3 bucket policies to explicitly deny the `DELETE` and `PUT` object actions would prevent users from modifying or deleting objects in the bucket. While this approach will prevent data modifications, it is not foolproof because users with higher-level permissions (e.g., admins) could still modify the policy or bypass this restriction.
- Reason for Rejection: While this approach can work to restrict PUT and DELETE actions, it is not as secure as other solutions that ensure data immutability, such as S3 Object Lock. Bucket policies can be modified by users with the appropriate permissions, making this approach less secure for preventing all modifications.
Option B: Configure S3 Object Lock in compliance mode with S3 bucket versioning enabled.
- Analysis: S3 Object Lock in compliance mode provides immutability for objects in an S3 bucket, meaning that once an object is locked, it cannot be deleted or modified until the retention period expires (if set). When S3 bucket versioning is enabled, previous versions of objects are preserved, ensuring that no modifications can be made to the objects, even by users with administrative permissions. This solution ensures data integrity and prevents any unauthorized changes.
- Reason for Selection: This solution is the most robust for ensuring that the data is protected from modification. S3 Object Lock in compliance mode guarantees that no modifications or deletions can occur, even by administrators, making it the ideal solution to prevent cha...
Author: ElectricLionX · Last updated May 23, 2026
A company is developing a new serverless application that uses AWS Lambda functions. The company uses AWS CloudFormation to deploy the Lambda functions.
The company's developers are trying to debug a Lambda function that is deployed. The developers cannot debug the Lambda function because the Lambda function is not logg...
In this scenario, the goal is to ensure that the Lambda function can log its output to Amazon CloudWatch Logs for debugging. The issue appears to be that the Lambda function is not logging output to CloudWatch Logs. Let's go through each option to determine which ones would help resolve this issue.
A) Check the role that is defined in the CloudFormation template and is passed to the Lambda function. Ensure that the role has a trust policy that allows the sts:AssumeRole action by the service principal lambda.amazonaws.com.
- Explanation: This option is related to the trust policy of the role. It ensures that AWS Lambda can assume the role to execute the function. However, this step focuses more on permissions related to the Lambda function's ability to execute, not directly related to CloudWatch Logs permissions.
- Rejection: The issue described is not related to the Lambda function assuming the role but rather to the function's permissions to log data to CloudWatch. Therefore, this is not the correct solution for logging issues.
B) Check the execution role that is configured in the CloudFormation template for the Lambda function. Ensure that the execution role has the necessary permissions to write to CloudWatch Logs.
- Explanation: This option is the most relevant. Lambda functions need an execution role with the appropriate permissions to interact with other AWS services, including CloudWatch Logs. The execution role must have a policy allowing actions like `logs:CreateLogGroup`, `logs:CreateLogStream`, and `logs:PutLogEvents` in order to write logs to CloudWatch.
- Selected because: This directly addresses the issue of logging by ensuring the Lambda function has the correct permissions to interact with CloudWatch Logs. This is a critical step for debugging Lambda functions.
C) Check the Lambda function configuration in the CloudFormation template. Ensure that the Lambda function has an AWS X-Ray tracing configuration that is set to Active mode or PassThrough mode.
- Explanation: AWS X-Ray is ...
Author: Ming88 · Last updated May 23, 2026
A company uses a collaboration application. A security engineer needs to configure automated alerts from AWS Security Hub in the us-west-2 Region for the application. The security engineer wants to receive an alert in a channel in the application every time Security Hub receives a new finding.
The security engineer creates an AWS Lambda function to convert the message to the format that the application requires. The Lambda function also sends the message to the application's API. The security engineer configures a corresponding Amazon EventBridge rule that specifies the Lambda function as the target.
After the EventBridge rule is implemented, the c...
To solve the problem with the least operational effort, let's analyze each option:
A) Update the Lambda function code to find pattern matches of events from Amazon Inspector and to suppress the findings.
- Explanation: This option suggests modifying the Lambda function itself to filter out Amazon Inspector alerts by matching patterns in the events. While this would work, it requires custom code development and maintenance, which introduces operational overhead. This approach also risks missing updates to Amazon Inspector alerts or additional findings that require suppression logic.
- Rejection: This approach involves additional custom code and requires ongoing maintenance as patterns may change. Therefore, it's not the most efficient solution in terms of operational effort.
B) Create a Security Hub custom action that automatically sends findings from all services except Amazon Inspector to the EventBridge event bus.
- Explanation: Security Hub custom actions allow you to define how findings are processed, but they do not offer an easy way to filter out Amazon Inspector findings specifically from being sent to EventBridge. Custom actions are meant for user-driven tasks and are not the best fit for excluding specific findings automatically from being processed by EventBridge.
- Rejection: This solution is not well-suited for automated filtering at the event level, making it more complex than necessary and requiring additional manual steps for filtering.
C) Modify the value of the ProductArn attribute in the event pattern of the EventBridge rule to `!= arn:aws:securityhub:us-west-2::product/aws/inspector`.
- Explanation: This solution inv...
Author: Emily · Last updated May 23, 2026
A company's security policy requires all Amazon EC2 instances to use the Amazon Time Sync Service. AWS CloudTrail trails are enabled in all of the company's AWS accounts. VPC flow logs are enabled for all VPCs.
A security engineer must identify any EC2 instances that...
To meet the security policy requirements, we need to identify Amazon EC2 instances attempting to use Network Time Protocol (NTP) servers on the internet. Let's break down each option:
A) Monitor CloudTrail logs for API calls to non-standard time servers.
- Explanation: CloudTrail logs capture API calls made within an AWS account, but it does not specifically log NTP-related actions. EC2 instances using NTP servers typically do not generate specific API calls that would be logged by CloudTrail.
- Rejection: CloudTrail will not capture NTP traffic as API calls to non-standard time servers. This option is not suitable because it focuses on API calls, not network traffic.
B) Monitor CloudTrail logs for API calls to the Amazon Time Sync Service.
- Explanation: CloudTrail logs can track API calls to AWS services, including the Amazon Time Sync Service. However, the requirement is to identify EC2 instances using external NTP servers, not AWS-managed time services. EC2 instances using the Amazon Time Sync Service wouldn't violate the security policy.
- Rejection: This option would not help in identifying instances using non-Amazon NTP servers, which is the core issue here.
C) Monitor VPC flow logs for traffic to non-standard time servers.
- Explanation: VPC Flow...
Author: Ella · Last updated May 23, 2026
A company has a multi-account strategy that uses an organization in AWS Organizations with all features enabled. The company has enabled trusted access for AWS Account Management. New accounts are provisioned through AWS Control Tower Account Factory.
The company must ensure that all new accounts in the or...
To determine the best solution with the least development effort, let’s evaluate the provided options based on the requirement of ensuring that all new accounts automatically become AWS Security Hub member accounts.
Option A: Enable Security Hub in the organization’s management account. Create an AWS Step Functions workflow. Create an Amazon EventBridge rule to invoke the workflow when a CreateAccount event occurs.
Analysis:
- This option is highly customizable and offers full control over the process. However, it involves creating a Step Functions workflow, which can add complexity and require more development and maintenance. Additionally, you would need to ensure that the EventBridge rule triggers correctly for the `CreateAccount` event and that the workflow handles enabling Security Hub for each new account.
- Rejected due to high development effort and complexity. It’s over-engineered for this use case.
Option B: Enable Security Hub in the organization’s management account. Wait for all new accounts to complete automatic onboarding.
Analysis:
- Security Hub provides an automatic onboarding process for new accounts when Security Hub is enabled in the organization’s management account. This would require minimal manual intervention and does not require any custom development. As soon as the new accounts are created, they are automatically onboarded into Security Hub.
- Selected as the simplest and least development-intensive solution. It directly satisfies the requirement without extra configuration or development work.
Option C: Enable Security Hub in the organization’s management account. Create an AWS Lambda function to enable Security Hub for new accounts. Invoke the Lambda function by using an AWS Cont...
Author: MoonlitPantherX · Last updated May 23, 2026
A company uses Amazon Elastic Kubernetes Service (Amazon EKS) clusters to run its Kubernetes-based applications. The company uses Amazon GuardDuty to protect the applications.
EKS Protection is enabled in GuardDuty. However, the corresponding GuardDuty feature is not monitorin...
To ensure that GuardDuty is monitoring Kubernetes-based applications running on Amazon Elastic Kubernetes Service (EKS), we need to identify the appropriate solution based on the options provided. Let's evaluate each option:
Option A: Enable VPC flow logs for the VPC that hosts the EKS clusters.
Analysis:
- VPC flow logs capture information about the IP traffic going to and from network interfaces in the VPC. While VPC flow logs can be useful for monitoring network traffic, they do not directly help GuardDuty monitor Kubernetes-based applications themselves.
- Rejected because enabling VPC flow logs alone doesn't specifically integrate with GuardDuty for Kubernetes application monitoring. VPC flow logs are not focused on monitoring application-specific activities.
Option B: Assign the CloudWatchEventsFullAccess AWS managed policy to the EKS clusters.
Analysis:
- The CloudWatchEventsFullAccess policy grants permissions for publishing events to CloudWatch Events, but it does not directly impact GuardDuty’s monitoring capabilities. GuardDuty relies on specific data sources like VPC flow logs, DNS logs, or CloudTrail to detect threats and anomalies.
- Rejected because this policy doesn't align with the need to enable GuardDuty monitoring of Kubernetes-based applications in EKS.
Option C: Ensure that the AmazonGuardDutyFullAccess AWS managed policy is attached to the GuardDuty service role.
Analysis:
- The `AmazonGuardDutyFullAccess` policy is related to managing GuardDuty'...
Author: Elizabeth · Last updated May 23, 2026
A company needs to log object-level activity in its Amazon S3 buckets. The company also needs to validate the integrity of the log file by using a di...
To determine the best solution that satisfies the company's requirements for logging object-level activity in Amazon S3 buckets and validating the integrity of the log files with a digital signature, let’s evaluate each option:
Option A: Create an AWS CloudTrail trail with log file validation enabled. Enable data events. Specify Amazon S3 as the data event type.
Analysis:
- AWS CloudTrail can log object-level activity for S3 buckets by enabling data events for S3. This captures object-level operations like `GetObject`, `PutObject`, and others.
- CloudTrail also supports log file validation, which ensures that the integrity of the log files is maintained by applying a digital signature to the log files.
- Selected because it fully meets the requirements: it logs object-level activity through CloudTrail data events and validates the integrity of the log files via digital signatures.
Option B: Create a new S3 bucket for S3 server access logs. Configure the existing S3 buckets to send their S3 server access logs to the new S3 bucket.
Analysis:
- This solution logs access to objects within S3 but only captures server access logs, not object-level activity such as `PutObject` or `GetObject` events.
- Server access logs are more general and do not include details like object-level operations or the ability to validate the integrity of the log files with a digital signature.
- Rejected because it only logs server access events (like request and response data) but does not meet the requirement for logging object-level activity or validating log integrity.
Option C: Create an ...
Author: Amelia · Last updated May 23, 2026
A company has a new web-based account management system for an online game. Players create a unique username and password to log in to the system.
The company has implemented an AWS WAF web ACL for the system. The web ACL includes the core rule set (CRS) AWS managed rule group on the Application Load Balancer that serves the system.
The company's security team finds that the system was the target of a credential stuffing attack. Credentials that were exposed in other breaches were used to try to log in to the system.
The security team must impleme...
To reduce the chance of a successful credential stuffing attack and minimize the impact on legitimate users, we need to implement solutions that help detect and block malicious login attempts while keeping the user experience for legitimate users intact. Let's evaluate each option to determine which actions will meet these requirements:
Option A: Create an Amazon CloudWatch custom metric to analyze the number of successful login responses from a single IP address.
Analysis:
- This option suggests tracking successful login attempts per IP address using CloudWatch metrics. While this can help identify patterns of potential attacks (e.g., many successful logins from a single IP), it doesn’t proactively mitigate credential stuffing attacks.
- Rejected because it focuses on monitoring rather than actively defending against credential stuffing. While monitoring is important, it's reactive and doesn't directly reduce the likelihood of an attack.
Option B: Add the account takeover prevention (ATP) AWS managed rule group to the web ACL. Configure the rule group to inspect login requests to the system. Block any requests that have the `awswaf:managed:aws:atp:signal:credential_compromised` label.
Analysis:
- The Account Takeover Prevention (ATP) rule group is specifically designed to detect and mitigate credential stuffing attacks. The ATP rule group inspects login attempts and blocks requests that match certain patterns associated with compromised credentials (such as those exposed in past breaches).
- Selected because it directly addresses the problem of credential stuffing by using AWS WAF’s managed rule group for account takeover prevention. It helps block malicious login attempts from users using exposed credentials without impacting legitimate users.
Option C: Configure a default web ACL action that requires all users to solve a CAPTCHA puzzle when they log in.
Analysis:
- While a CAPTCHA can be effective in preventing automated attacks, it could negatively impact the user experience by requiring all users (even legitimate ones) to solve the CAPTCHA each t...
Author: Nia · Last updated May 23, 2026
A company runs workloads on Amazon EC2 instances. The company needs to continually monitor the EC2 instances for software vulnerabilities and must display the findings in AWS Security Hub. The company must...
To meet the company's requirements of continually monitoring EC2 instances for software vulnerabilities and displaying the findings in AWS Security Hub without installing agents on the instances, we need a solution that can scan EC2 instances for vulnerabilities without relying on agent installation. Let's evaluate each option:
Option A: Enable Amazon Inspector. Set the scan mode to hybrid scanning. Enable the integration for Amazon Inspector in Security Hub.
Analysis:
- Amazon Inspector provides vulnerability scanning for EC2 instances and can be integrated with Security Hub to send findings. Hybrid scanning mode allows for both agent-based and agentless scanning, which means it can scan EC2 instances without installing an agent if hybrid scanning is enabled.
- This solution meets the requirement of monitoring EC2 instances for software vulnerabilities without needing agents and integrates the findings into Security Hub.
- Selected because it directly addresses the requirement by using Amazon Inspector's agentless scanning mode and integrates with Security Hub for continuous monitoring.
Option B: Use Security Hub to enable the AWS Foundational Security Best Practices standard. Wait for Security Hub to generate the findings.
Analysis:
- The AWS Foundational Security Best Practices standard in Security Hub provides security checks related to best practices but does not specifically address vulnerability scanning of EC2 instances for software vulnerabilities. It includes checks for configurations, not direct vulnerability assessments.
- Rejected because it doesn’t specifically monitor for software vulnerabilities or provide continuous scanning of EC2 instances.
Option C: Enable Amazon GuardDuty....
Author: Charlotte · Last updated May 23, 2026
A company runs a custom online gaming application. The company uses Amazon Cognito for user authentication and authorization.
A security engineer wants to use AWS to implement fine-grained authorization on resources in the custom application. The security engineer must implement a solution that uses the user attributes that ...
The company needs a solution for implementing fine-grained authorization in its custom application, leveraging the user attributes that exist in Amazon Cognito. Let's evaluate each option based on the requirements:
Option A: Create a set of IAM roles and IAM policies. Configure the Cognito identity pool to assign users to the IAM roles.
Analysis:
- IAM roles and policies are a standard solution for authorization, and Cognito supports assigning users to IAM roles based on their identity. This allows the system to control access to AWS resources based on the user's identity attributes. The roles can have fine-grained access control policies attached to them, and you can use Cognito identity pool attributes to define which roles users are assigned to.
- Selected because this approach leverages Cognito’s identity pool for role-based access control and fine-grained authorization using user attributes. It is the most direct solution for implementing fine-grained authorization in AWS while using Cognito.
Option B: Create a policy store in Amazon Verified Permissions. Configure Cognito as the identity source. Map Cognito access tokens to the Verified Permissions schema.
Analysis:
- Amazon Verified Permissions is a service for managing fine-grained authorization policies in applications. It allows you to create, store, and manage policies, and can be used with external identity providers like Cognito. However, integrating it with Cognito requires configuring a mapping between Cognito’s access tokens and the Verified Permissions schema. While this is a valid solution, it introduces an additional layer of complexity and cost, which might be unnecessary if a simpler solution (like Option A) can meet the requirements.
- Rejected because although it’s a valid approach, it is more complex and involves extra setup, which may not be necessary for the current use case. Option A is simpler and more directly integrated with Cognito.
Option C: Create customer managed permissions by usin...
Author: Arjun · Last updated May 23, 2026
A company wants to automate the creation of a security report. The company has an AWS Lambda function that gathers data from Amazon Inspector findings stored in AWS Security Hub in the us-west-2 Region. The Lambda function then needs to create a daily report by using an Amazon EventBridge schedule.
A security engineer discovers that the Lambda function is failing to create the rep...
To address the issue of the Lambda function failing to create the security report, the Lambda function needs the appropriate permissions to access Amazon Inspector findings stored in AWS Security Hub. The security engineer must implement a solution with least privilege access.
Analysis of Options:
A) Create a resource-based policy that allows Security Hub access to the ARN of the Lambda function.
- Reason for Rejection: This option would allow Security Hub to invoke the Lambda function, but the Lambda function itself needs permissions to access Security Hub and Amazon Inspector. A resource-based policy on Security Hub doesn't solve the problem of allowing the Lambda function to retrieve findings from Security Hub and Amazon Inspector. Thus, this is not the appropriate solution.
B) Attach the AWSSecurityHubReadOnlyAccess AWS managed policy to the Lambda function’s execution role.
- Reason for Rejection: The `AWSSecurityHubReadOnlyAccess` policy grants read-only access to AWS Security Hub, but it may not provide the required permissions for accessing Amazon Inspector findings, such as `inspector:Describe` or `inspector:List`. The solution needs to focus on both Security Hub and Amazon Inspector, ensuring the Lambda function can retrieve and report findings. This policy is too broad because it focuses only on Security Hub and doesn't cover the necessary permissions for Amazon Inspector.
C) Grant the Lambda funct...
Author: IceDragon2023 · Last updated May 23, 2026
A company must retain backup copies of Amazon RDS DB instances and Amazon Elastic Block Store (Amazon EBS) volumes. The company must retain the backup copies in data centers that are several hundred miles a...
To meet the requirement of retaining backup copies of Amazon RDS DB instances and Amazon EBS volumes in data centers several hundred miles apart, the solution must ensure reliable backup management with minimal operational overhead. Let's analyze the options based on this criterion.
Analysis of Options:
A) Configure AWS Backup to create the backups according to the needed schedule. In the backup plan, specify multiple Availability Zones as backup destinations.
- Reason for Rejection: While this option provides backup scheduling using AWS Backup, specifying multiple Availability Zones within the same region doesn't meet the requirement of storing backups in data centers several hundred miles apart. Multiple Availability Zones are still within the same region and do not ensure geographical redundancy across distant locations. Hence, this option doesn't fulfill the geographic separation requirement.
B) Configure Amazon Data Lifecycle Manager to create the backups. Configure the Amazon Data Lifecycle Manager policy to copy the backups to an Amazon S3 bucket. Enable replication on the S3 bucket.
- Reason for Rejection: Amazon Data Lifecycle Manager is specifically for managing Amazon EBS snapshot lifecycles. Although this option handles EBS snapshots well and copying them to S3 with replication across regions is a good strategy for geographic redundancy, it doesn't cover Amazon RDS instances. The solution doesn't address RDS backup retention, which is a critical part of the requirement. Therefore, it’s incomplete for the overall need.
C) Configure AWS Backup to create the backu...
Author: IceDragon2023 · Last updated May 23, 2026
A security engineer has noticed an unusually high amount of traffic coming from a single IP address. This was discovered by analyzing the Application Load Balancer's access logs.
How can the security enginee...
To address the situation of unusually high traffic from a specific IP address without blocking the IP address entirely, we need a solution that can control and rate-limit traffic based on the request rate, without completely denying access. Let’s analyze the options based on these criteria:
Analysis of Options:
A) Add a rule to the Application Load Balancer to route the traffic originating from the IP address in question and show a static webpage.
- Reason for Rejection: Routing traffic to a static webpage does not address the problem of rate limiting the traffic. This method would simply divert traffic from the IP address to a static page but would not reduce the volume of requests. The issue is not with the content served but with the traffic volume itself. Therefore, this option doesn't effectively manage or limit the request rate from the IP.
B) Implement a rate-based rule with AWS WAF.
- Selected Option: AWS WAF (Web Application Firewall) provides the ability to create rate-based rules to limit the number of requests from a particular IP address. By configuring a rate limit (e.g., allowing a specific number of requests per minute), AWS WAF can block excessive requests without completely blocking the IP. It will only trigger the limit if the rate is exceeded, effectively controlling traffic spikes while allowing legitimate traffic to continue. This solution is tailored for the scenario where we want to limit the ...
Author: Ming88 · Last updated May 23, 2026
A company runs workloads that are spread across hundreds of Amazon EC2 instances. During a recent security incident, an EC2 instance was compromised and ran malware code until the company manually terminated the instance.
The company is now using Amazon GuardDuty to detect malware on EC2 instances. A security engineer needs to implement a solution that automates a response when GuardDuty determines that an instance is in...
To automate the response when Amazon GuardDuty detects that an EC2 instance is infected, the solution must efficiently isolate the instance, mitigate the risk, and comply with the AWS Well-Architected Framework's guidance on incident response. Let's examine the options and determine the most effective approach.
Analysis of Options:
A) Configure AWS Systems Manager Run Command to run when a GuardDuty scan determines that an instance is infected. Use Run Command to remove all network adapters from the operating system of the infected instance. Use Run Command to also add a tag of “Infected” to the instance.
- Reason for Rejection: While using AWS Systems Manager Run Command can execute tasks on the EC2 instance, removing network adapters from the operating system could cause operational issues and doesn’t fully isolate the instance from the network. The "Infected" tag can help with identification, but removing network adapters might not be the most effective way to stop malicious activity. This approach could also be difficult to manage and may lead to unforeseen consequences in the instance's behavior.
B) Create an AWS Lambda function that runs when a GuardDuty scan determines that an instance is infected. Program the Lambda function to delete all elastic network interfaces that are associated with the instance. Program the Lambda function to also add a tag of “Infected” to the instance.
- Reason for Rejection: Deleting elastic network interfaces (ENIs) associated with the EC2 instance would effectively disconnect the instance from the network, which can be an effective isolation strategy. However, deleting ENIs could create operational challenges, such as disrupting communication with other services, requiring re-attachment or re-creation of ENIs later. Although tagging the instance as "Infected" is useful for tracking, this approach might not be the most scalable or efficient in all environments, especially for handling large numbers of instances.
C) Create an AWS Lambda function that runs when a GuardDuty scan determines that an instance is infected. Program the Lamb...
Author: Daniel · Last updated May 23, 2026
A public subnet contains two Amazon EC2 instances. The subnet has a custom network ACL. A security engineer is designing a solution to improve the subnet security.
The solution must allow outbound traffic to an internet service that uses TLS through port 443. The solution also...
To improve the security of a subnet with the given requirements, we need to consider how network ACLs work. Network ACLs (Access Control Lists) in AWS are stateless, meaning they need to explicitly allow both inbound and outbound traffic if it's needed. In this case, the goal is to allow outbound traffic for TLS (port 443) and deny inbound traffic for MySQL (port 3306).
Key Requirements:
- Allow outbound traffic on port 443 (for TLS).
- Deny inbound traffic on port 3306 (for MySQL).
Analysis of Options:
A) Use inbound rule 100 to allow traffic on TCP port 443. Use inbound rule 200 to deny traffic on TCP port 3306. Use outbound rule 100 to allow traffic on TCP port 443.
- Reason for Rejection: This option allows traffic on port 443 inbound, which is incorrect since the requirement only specifies allowing outbound traffic to the internet (on port 443). It also denies port 3306 inbound, which is correct, but allowing port 443 inbound is unnecessary and does not meet the specified security requirements. The mistake lies in the inbound rule 100.
B) Use inbound rule 100 to deny traffic on TCP port 3306. Use inbound rule 200 to allow traffic on TCP port range 1024-65535. Use outbound rule 100 to allow traffic on TCP port 443.
- Reason for Rejection: This option denies port 3306 inbound, which is correct. However, the inbound rule 200 allows traffic on a wide port range (1024-65535), which could inadvertently allow unwanted traffic into the subnet. This is a broader rule than necessary and does not meet the requirement of securing the subnet properly. The outbound rule 100 is correct, but th...
Author: MysticJaguar44 · Last updated May 23, 2026
A company hosts its microservices application on Amazon Elastic Kubernetes Service (Amazon EKS). The company has set up continuous deployments to update the application on demand.
A security engineer must implement a solution to provide automatic detection of anomalies in application logs in near real time....
To address the need for automatic detection of anomalies in application logs with real-time notifications to the security team, the solution should efficiently collect and analyze logs, detect anomalies quickly, and trigger alerts in near real-time.
Analysis of Options:
A) Configure Amazon CloudWatch Container Insights to collect and aggregate EKS application logs. Create a CloudWatch alarm to monitor for anomalies. Configure the alarm to launch an AWS Lambda function to alert the security team when anomalies are detected.
- Reason for Rejection: While Amazon CloudWatch Container Insights provides detailed monitoring and logging for EKS workloads, anomaly detection is not a native feature of CloudWatch alarms. CloudWatch alarms are used to track specific metrics or thresholds, but they do not inherently detect anomalies in logs. While using a Lambda function for notification is a valid approach, the anomaly detection capability is lacking, so this option is not ideal.
B) Configure Amazon EKS to send application logs to Amazon CloudWatch. Create a CloudWatch alarm based on a log group metric filter. Specify anomaly detection as the threshold type. Configure the alarm to use Amazon Simple Notification Service (Amazon SNS) to alert the security team.
- Selected Option: This option is the best fit for the scenario:
- CloudWatch Logs can collect application logs from Amazon EKS.
- Metric filters in CloudWatch can be set to detect specific patterns in the logs, such as unusual error rates or specific log entries indicative of an anomaly.
- Anomaly detection within CloudWatch is an advanced feature that allows the service to automatically identify anomalous behavior in the log data.
- When an anomaly is detected, Amazon SNS can trigger alerts to notify the security team, providing near real-time notifications.
- This solution is tightly integrated with CloudWatch and is well-suited for real-time log analysis and anomaly detection with minimal operational overhead.
...
Author: Liam · Last updated May 23, 2026
A company is migrating container workloads from a data center to Amazon Elastic Container Service (Amazon ECS) clusters. The company must implement a solution to detect potential threats in the workloads and to improve ...
When migrating container workloads to Amazon ECS, the company needs a solution that specifically detects potential threats within the workloads and improves the security posture of the container clusters. Let's evaluate each option in terms of meeting these requirements.
Analysis of Options:
A) Configure Amazon Inspector on the VPC that is running the ECS clusters.
- Reason for Rejection: While Amazon Inspector can be used to assess the security of EC2 instances and their configurations, it does not specifically cater to the detection of threats within containers or ECS workloads. It is more geared toward assessing EC2 and other resources. This does not fully address the need for continuous threat detection specifically within ECS clusters and containerized applications. It is useful for vulnerability scanning but does not focus on runtime threat detection in containers.
B) Enable Amazon GuardDuty Runtime Monitoring on the ECS clusters.
- Selected Option: Amazon GuardDuty is a continuous security monitoring service that can detect unusual or potentially unauthorized activity within AWS accounts and workloads. When GuardDuty Runtime Monitoring is enabled for ECS, it actively monitors the runtime behavior of containers, detecting anomalies and threats such as privilege escalation, unauthorized access, or network anomalies within the containerized workloads.
- Why it's selected: GuardDuty Runtime Monitoring is specifically designed for continuous monitoring of container workloads in Amazon ECS. It will directly address the company's need to detect potential threats in container workloads, improving the security postu...
Author: Ming · Last updated May 23, 2026
A security engineer needs to implement a solution to determine whether a company's Amazon EC2 instances are being used to mine cryptocurrency. The solution must provide notifications of cryptocurrency-related activity to an Amaz...
To address the requirement of detecting cryptocurrency-related activity on Amazon EC2 instances and sending notifications, the solution should focus on continuous monitoring, threat detection, and integration with notification services like Amazon SNS.
Analysis of Options:
A) Create AWS Config custom rules by using Guard custom policy. Configure the AWS Config rules to detect when an EC2 instance queries a DNS domain name that is associated with cryptocurrency-related activity. Configure AWS Config to initiate alerts to the SNS topic.
- Reason for Rejection: While AWS Config can track configuration changes and compliance, it is not inherently designed for real-time detection of threats such as cryptocurrency mining activities. It may not effectively monitor network-level activity (such as DNS queries) or runtime behavior in a way that is specific to detecting cryptocurrency mining. Additionally, using AWS Config to trigger alerts for such activities would be complex and may not provide immediate threat detection, making it less suitable for this scenario.
B) Enable Amazon GuardDuty. Create an Amazon EventBridge rule to send alerts to the SNS topic when GuardDuty creates a finding that is associated with cryptocurrency-related activity.
- Selected Option: Amazon GuardDuty is an ideal solution for this scenario:
- GuardDuty is a threat detection service that continuously monitors for malicious or unauthorized activity within an AWS environment, including cryptocurrency mining. GuardDuty has built-in threat intelligence feeds, such as detecting anomalous network behavior, unusual traffic patterns, and activity associated with known cryptocurrency mining domains or IP addresses.
- GuardDuty is specifically designed to detect cryptocurrency mining and other malicious activity on EC2 instances.
- By using EventBridge, you can automatically trigger alerts to an SNS topic whenever GuardDuty creates a finding related to cryptocurrency mining. This provides real-time monitoring and notifications.
- Why it's selected: GuardDuty is designed to ...
Author: Evelyn · Last updated May 23, 2026
A company controls user access by using IAM users and groups in AWS accounts across an organization in AWS Organizations. The company uses an external identity provider (IdP) for workforce single sign-on (SSO).
The company needs to implement a solution to provide a single management portal to access accounts wit...
To provide a single management portal for user access across an organization in AWS, while using an external identity provider (IdP) for single sign-on (SSO), the solution should integrate with both AWS Organizations and an external IdP to manage user access across multiple AWS accounts seamlessly.
Let's evaluate the options:
A) Enable AWS IAM Identity Center. Specify the external IdP as the identity source.
- Selected Option: AWS IAM Identity Center (formerly AWS SSO) is designed for exactly this use case. It allows you to provide SSO across AWS accounts and applications. By specifying the external IdP as the identity source, you can integrate the IdP with IAM Identity Center, which will enable users to log in using their existing credentials. IAM Identity Center provides a single management portal to access all accounts within AWS Organizations, fulfilling both the user access and external IdP federation requirements.
- Why it's selected: This option is specifically designed to handle federated access for users from an external IdP, offering centralized access management across AWS accounts within an AWS Organization.
B) Enable federation with AWS Identity and Access Management (IAM). Specify the external IdP as the identity source.
- Reason for Rejection: While IAM Federation allows users to authenticate via an external IdP, it does not provide a centralized management portal for accessing multiple AWS accounts in AWS Organizations. IAM federation only allows users to access individual AWS resources but does not provide the single management portal to access multiple AWS accounts or support SSO across accounts. Therefore, while this option provides federation, it does ...
Author: RadiantPhoenixX · Last updated May 23, 2026
A company must create annual snapshots of Amazon Elastic Block Store (Amazon EBS) volumes. The company must retain the snapshots for 10 years. The company will use AWS Key Management Service (AWS KMS) to encrypt the EBS volumes and snapshots.
The encryption keys must be rotated automatically every year. Snapshots that were created in previous ye...
To meet the requirement of automatically rotating the encryption keys every year while ensuring that snapshots created in previous years remain readable after key rotation, the company must select the right type of KMS key. Here's a breakdown of the key options and how they align with the requirements:
Key Factors:
1. Automatic Key Rotation: KMS must support automatic rotation of encryption keys.
2. Snapshot Readability After Rotation: The encryption keys used for snapshots created in previous years must remain valid and accessible even after automatic key rotation.
3. Key Management: The company must retain control over the key's lifecycle and handle the key rotation.
Option Breakdown:
A) Asymmetric AWS Managed KMS Keys with Key Material Created by AWS KMS:
- Explanation: Asymmetric keys are typically used for tasks involving encryption and decryption operations that require different keys (public and private keys). AWS managed KMS keys automatically rotate every year, but they are not designed for this kind of use case where the key needs to be rotated yearly for block storage like EBS snapshots.
- Why Rejected: Asymmetric encryption is not necessary for encrypting EBS snapshots because EBS volumes use symmetric encryption. Additionally, asymmetric keys do not directly support reading previously encrypted data with rotated keys in the way symmetric keys do. This would result in challenges for accessing older snapshots.
- Key Rotation: While automatic rotation is supported, asymmetric keys are not intended for the scenario requiring continuous snapshot access.
B) Symmetric Customer Managed KMS Keys with Key Material Created by AWS KMS:
- Explanation: Symmetric keys are appropriate for EBS volume encryption and snapshots. AWS KMS supports automatic key rotation for symmetric customer-managed keys every year, which satisfies the requirement of rotating keys yearly. The company has control over the key's lifecycle, and automatic rotation ensures that newer snapshots are encrypted with the latest key, while older sna...
Author: ThunderBear · Last updated May 23, 2026
A company has hundreds of AWS accounts and uses AWS Organizations. The company plans to create many different IAM roles and policies for its product team, security team, and platform team. Some IAM policies will be shared across teams.
A security engineer needs to implement a solution to logically group together the IAM roles of each...
To solve the problem, we need to group IAM roles logically by team, with the additional requirement that only the platform team can delegate IAM permissions to AWS services.
Key Factors:
1. Logical Grouping of IAM Roles: We need to group IAM roles by team (product, security, platform) in a way that is scalable and manageable.
2. Delegation of IAM Permissions: Only the platform team should be allowed to delegate IAM permissions to AWS services, i.e., only they should have the ability to use `iam:PassRole`.
3. Using AWS Organizations: The solution must work in the context of AWS Organizations and SCPs (Service Control Policies), which apply restrictions across multiple AWS accounts.
Option Breakdown:
A) Set up an IAM path with the IAM roles for each team. Deploy an SCP that denies the iam:PassRole permission to all entities except the IAM path of the platform team.
- Explanation: This option involves using IAM paths to logically group IAM roles by team (e.g., `/platform/`, `/product/`, `/security/`). SCPs are then deployed to restrict the `iam:PassRole` permission to roles under the `platform` path.
- Why Selected: This solution meets the requirement because IAM paths can logically group roles by team, and SCPs can be used to limit `iam:PassRole` to roles that belong to the platform team. This is the most direct approach to restricting the platform team to only delegate IAM permissions while allowing other teams to have necessary permissions.
- Key Rotation and Delegation: The SCP would effectively block other teams from passing roles, ensuring that only the platform team has the `iam:PassRole` permission.
B) Apply different tags for each team to the IAM roles. Deploy an SCP that denies the sts:AssumeRole permission to all entities except the roles of the platform team.
- Explanation: This option uses tags to group IAM roles and restricts `sts:AssumeRole` via an SCP. Th...
Author: William · Last updated May 23, 2026
A company's developers are using AWS Lambda function URLs to invoke functions directly. The company must ensure that developers cannot configure or deploy unauthenticated functions in production accounts. The company wants to meet this requirement by using AWS Organizatio...
Key Factors to Consider:
- Preventing unauthenticated Lambda functions: The goal is to ensure that Lambda function URLs in production are not configured to allow unauthenticated access (i.e., ensuring that only authenticated users or services can invoke them).
- Using AWS Organizations: The solution needs to leverage AWS Organizations to enforce the policy across accounts.
- No additional work for developers: Developers should not need to do additional manual configuration, so the solution should be automated as much as possible.
Option Breakdown:
A) Require the developers to configure all function URLs to support cross-origin resource sharing (CORS) when the functions are called from a different domain.
- Explanation: CORS allows a web application from one domain to request resources from another domain, but this is not directly related to preventing unauthenticated access. It is more about cross-domain access control, not about enforcing authentication for Lambda function URLs.
- Why Rejected: This option does not address the need to block unauthenticated access to Lambda functions in production environments. The issue here is ensuring proper authentication (AWS IAM) for the Lambda function URLs, not controlling CORS behavior.
B) Use an AWS WAF delegated administrator account to view and block unauthenticated access to function URLs in production accounts, based on the OU of accounts that are using the functions.
- Explanation: AWS WAF is a web application firewall that can block traffic based on certain conditions. While it could be used to block unauthenticated traffic, using WAF to restrict unauthenticated access is not the most efficient way to manage authentication requirements at the Lambda function URL level.
- Why Rejected: This approach introduces additional complexity, requiring WAF rules to manage unauthenticated access. The requirement is to use a more direct method to control Lambda function URL configurations and prevent unauthenticated access through AWS Organizations and IAM policies, which...
Author: Liam · Last updated May 23, 2026
A company is implementing new compliance requirements to meet customer needs. According to the new requirements, the company must not use any Amazon RDS DB instances or DB clusters that lack encryption of the underlying storage. The company needs a solution that will generate an email alert when an unencrypted DB instance or DB cluster is created. The solutio...
Key Requirements:
1. Detect Unencrypted DB Instances or Clusters: The solution needs to detect Amazon RDS DB instances or clusters that are created without encryption.
2. Generate Email Alerts: The solution should notify the relevant stakeholders via email when an unencrypted DB instance or DB cluster is created.
3. Terminate Unencrypted Resources: The solution must terminate the unencrypted DB instance or DB cluster immediately after detection.
Option Breakdown:
A) Create an AWS Config managed rule to detect unencrypted RDS storage. Configure an automatic remediation action to publish messages to an Amazon Simple Notification Service (Amazon SNS) topic that includes an AWS Lambda function and an email delivery target as subscribers. Configure the Lambda function to delete the unencrypted resource.
- Explanation: This option uses AWS Config to monitor the compliance of the RDS instances and DB clusters. When a rule detects unencrypted storage, it triggers an automatic remediation action. This action publishes an SNS message, which invokes a Lambda function that deletes the unencrypted resource.
- Why Selected: This is a highly operationally efficient solution because:
- Automated Detection: AWS Config can continuously monitor the configuration of the RDS resources.
- Automatic Remediation: The remediation action automatically deletes the unencrypted DB instance or DB cluster.
- Email Notification: The SNS topic can be configured with an email delivery target to notify relevant stakeholders about the unencrypted resource.
- End-to-End Automation: The whole process is automated without requiring manual intervention, which ensures operational efficiency.
B) Create an AWS Config managed rule to detect unencrypted RDS storage. Configure a manual remediation action to invoke an AWS Lambda function. Configure the Lambda function to publish messages to an Amazon Simple Notification Service (Amazon SNS) topic and to delete the unencrypted resource.
- Explanation: This option also uses AWS Config to detect unencrypted RDS instances and clusters but requires manual remediation. When an unencrypted resource is detected, the remediation action must be triggered manually to invoke the Lambda function.
- Why Rejected: While this approach is similar to Option A, it introduces a manual step in the process, which reduces operational efficiency. The requirement is for an automated solution, and manual remediation introduces unnec...
Author: Aria · Last updated May 23, 2026
A company uses AWS Organizations to manage an organization that consists of three workload OUs. Production, Development, and Testing. The company uses AWS CloudFormation templates to define and deploy workload infrastructure in AWS accounts that are associated with the OUs. Different SCPs are attached to each workload OU.
The company successfully deployed a CloudFormation stack update to workloads in the Development OU and the Testing OU. When the company uses the same CloudFormation template to deplo...
To troubleshoot the issue of insufficient IAM permissions during the CloudFormation stack update, let's break down the reasoning for each option:
A) Review the AWS CloudTrail logs in the account in the Production OU. Search for any failed API calls from CloudFormation during the deployment attempt.
- CloudTrail logs can provide valuable insight into the exact API calls made by CloudFormation, and why they may have failed. In this case, reviewing the CloudTrail logs could show which permissions were lacking when attempting the deployment. This can help identify the specific IAM permission or AWS service issue that caused the failure.
- Why not reject? This step is a logical first step in investigating the specific error, and could provide more detailed information. It helps identify the "why" behind the issue (e.g., a missing permission or misconfigured role). So, this is a useful first step.
B) Remove all the SCPs that are attached to the Production OU. Rerun the CloudFormation stack update to determine if the SCPs were preventing the CloudFormation API calls.
- Removing all the SCPs is a drastic step. While it could allow the CloudFormation API calls to go through, it isn't a targeted or safe approach, especially since the other OUs (Development and Testing) aren't facing the same issue. This could have unintended security consequences, and it's important to narrow down the specific SCP or permission causing the issue.
- Why reject? Removing all SCPs is an excessive action that might violate security best practices and unnecessarily opens up access for all accounts in the Production OU. This is not the most effective or secure troubleshooting step.
C) Confirm that the role used by CloudFormation has sufficient permissions to create,...
