Amazon Practice Questions, Discussions & Exam Topics by our Authors

A company needs to create a centralized solution to analyze log files. The company uses an organization in AWS Organizations to manage its AWS accounts. The solution must aggregate and normalize events from the following sources: * The entire organization in Organizations * All AWS Marketplace of...

To create a centralized solution for analyzing log files from multiple sources (AWS accounts in AWS Organizations, AWS Marketplace offerings, and on-premises systems), we need to focus on an architecture that can aggregate, normalize, and analyze logs efficiently across these diverse sources. The solution must be scalable and flexible to handle different log types and origins. Option A: Configure a centralized Amazon S3 bucket for the logs. Enable VPC Flow Logs, AWS CloudTrail, and Amazon Route 53 logs in all accounts. Configure all accounts to use the centralized S3 bucket. Configure AWS Glue crawlers to parse the log files. Use Amazon Athena to query the log data. - Reason for rejection: While this option allows the aggregation of logs into a centralized S3 bucket, the method for parsing and normalizing the logs using AWS Glue and querying them with Athena is not the most efficient for real-time log analysis, especially for event-based or streaming logs. Additionally, it lacks a robust mechanism to handle logs from AWS Marketplace offerings or on-premises systems, which would require more customized setups for integration. This option also introduces complexity with managing the crawlers and Glue jobs to handle different log formats. Option B: Configure log streams in Amazon CloudWatch Logs for the sources that need monitoring. Create log subscription filters for each log stream. Forward the messages to Amazon OpenSearch Service for analysis. - Reason for rejection: While Amazon CloudWatch Logs and OpenSearch Service can be a good solution for centralized log management and analysis, this option doesn't explicitly address how logs from AWS Marketplace offerings or on-premises systems will be aggregated. It works well for AWS-native logs, but integrating on-premises systems would require additional configuration (e.g., custom log forwarding agents). Furthermore, CloudWatch Logs might not scale well if dealing with very large or diverse log sources beyond the AWS ecosystem. Option C: Set up a delegated Amazon Security Lake administrator account in Organizations. Enable and configure Security Lake for the organization. Add the accounts that need monitoring. Use Amazon Athena to query the log data. - Selected option: This is the best solution because Amazon Security Lak...

Author: Noah Williams · Last updated Jun 27, 2026

A company uses AWS Organizations. The company has more than 100 AWS accounts and will increase the number of accounts. The company also uses an external corporate identity provider (IdP). The company needs to provide users with role-based access to the accounts. ...

To address the company's requirement of providing users with role-based access to a growing number of AWS accounts, while maximizing scalability and operational efficiency, let's evaluate the options: Option A: In each account, create a set of dedicated IAM users. Ensure that all users assume these IAM users through federation with the existing IdP. - Analysis: - Creating IAM users in each account requires extensive manual management and scaling challenges, especially as the number of accounts grows. - Federation via the external corporate identity provider (IdP) would help in centralizing authentication, but each account having its own set of IAM users introduces complexity in user management and increases operational overhead. - Scalability Issue: As the number of accounts increases, the complexity of maintaining IAM users per account and ensuring correct access across accounts becomes increasingly difficult. This does not scale well in a multi-account AWS Organization structure. - Conclusion: This approach is not ideal due to the operational complexity of maintaining IAM users across multiple accounts. Option B: Deploy an IAM role in a central identity account. Allow users to assume the role through federation with the existing IdP. In each account, deploy a set of IAM roles that match the desired access patterns. Include a trust policy that allows access from the central identity account. Edit the permissions policy for the role in each account to match user access requirements. - Analysis: - This approach involves federating users through a central identity account, where users assume roles in individual accounts based on trust policies and permissions. - It offers centralized control over access, which improves scalability compared to IAM users in each account. However, you still need to manage roles in each individual account, which could be challenging as the number of accounts grows. - Operational Overhead: You would need to deploy and maintain roles in each account, along with managing trust policies. This still requires significant effort to scale across 100+ accounts. - Conclusion: While more scalable than Option A, this approach still requires considerable manual management and might not be as efficient as more modern solutions. Option C: Enable AWS IAM Identity Center. Integrate IAM Identity Center with the company's existing IdP. Create permission sets that match the desired access patterns. Assign permissions to match user ...

Author: Kai99 · Last updated Jun 27, 2026

A company has a web-based application that runs behind an Application Load Balancer (ALB). The application is experiencing a credential stuffing attack that is producing many failed login attempts. The attack is coming from many IP addresses. The login attempts are using a user agent string of a known mobile device emulator. A security engineer needs to implement a soluti...

Let's evaluate the possible solutions to mitigate the credential stuffing attack while ensuring legitimate logins are not blocked: Option A: Create an Amazon CloudWatch alarm that reacts to login attempts that contain the specified user agent string. Add an Amazon Simple Notification Service (SNS) topic to the alarm. - Analysis: - CloudWatch alarms can help monitor the application logs and notify when a specific event (like a failed login with a specific user agent) occurs. - However, this option does not actively mitigate the attack. It only notifies security personnel of the issue but doesn't take any real-time action to block or rate-limit the attack. - Limitations: CloudWatch alarms alone don’t provide an immediate solution to stop the attack; they only alert about the situation. - Conclusion: This option does not actively prevent the attack, so it doesn't meet the requirement of mitigating the credential stuffing attack in real-time. Option B: Modify the inbound security group on the ALB to deny traffic from the IP addresses that are involved in the attack. - Analysis: - This approach would involve identifying the attacking IPs and blocking them via the security group on the ALB. - Problem with scalability: Since the attack is coming from many IP addresses, manually blocking each IP would not scale well, especially with credential stuffing attacks where attackers may rotate through many IPs. - False positives: Legitimate users from the same IP ranges might also get blocked, especially if the attacker is using a botnet with distributed IPs, causing disruption for real users. - Conclusion: While this can stop some attacks, it's not scalable or efficient due to the dynamic nature of IP addresses in credential stuffing attacks. Option C: Create an AWS WAF web ACL for the ALB. Create a custom rule that blocks requests that contain the user agent string of the device emulator. - Analysis: - AWS WAF (Web Application Firewall) provides a more ro...

Author: Zain · Last updated Jun 27, 2026

A company is investigating controls to protect sensitive data. The company uses Amazon Simple Notification Service (Amazon SNS) topics to publish messages from application components to custom logging services. The company is concerned that an application component might publish sensitive data that will be accidentall...

Let's evaluate each option in terms of protecting sensitive data from accidental exposure in transaction logs and debug logs while using Amazon SNS topics: Option A: Use Amazon Macie to scan the SNS topics for sensitive data elements in the SNS messages. Create an AWS Lambda function that masks sensitive data inside the messages when Macie records a new finding. - Analysis: - Amazon Macie is a service designed to discover and protect sensitive data, but it focuses on scanning and classifying data in storage (such as S3) and does not directly integrate with SNS for message scanning. - Lambda function: While you could set up a Lambda function to process findings from Macie, this would be reactive, meaning the data would already have been sent and potentially exposed before it could be masked. - Scalability issue: This solution is more about scanning and reacting to data after the fact, rather than proactively preventing sensitive data from being published to SNS topics in the first place. - Conclusion: This option is reactive and doesn't provide an efficient, real-time way to prevent sensitive data from being exposed in SNS messages. Option B: Configure an inbound message data protection policy. In the policy, include the De-identify operation to mask the sensitive data inside the messages. Apply the policy to the SNS topics. - Analysis: - Message data protection policy: This would allow you to configure real-time data masking directly within the SNS service. The De-identify operation can be used to automatically mask sensitive data before it gets published to logs or debug logs. - This option provides a proactive solution to protect sensitive data and is the most suitable for ensuring that no sensitive information is accidentally exposed. - Direct Integration: This policy integrates directly with SNS, making it an ideal solution for this specific use case without relying on additional services like Lambda or Macie. - Conclusion: This is the most appropriate solution for protecting sensitive data in SNS messages, as it ensures data is masked before any potential exposure. Option C: Configure the SNS topics with an AWS Key Management Service (AWS KMS) customer managed key to encrypt the data elements inside the messages. Grant permissions to all message publisher I...

Author: Isabella · Last updated Jun 27, 2026

A company has created a set of AWS Lambda functions to automate incident response steps for incidents that occur on Amazon EC2 instances. The Lambda functions need to collect relevant artifacts, such as instance ID and security group configuration. The Lambda functions must then write a summary to an Amazon S3 bucket. The company runs its workloads in a VPC that uses public subnets and private subnets. The public subnets use an internet gateway to access the internet. The private subnets use a NAT gateway to acces...

Let's evaluate each option to determine which one will meet the requirements for keeping the traffic between the Lambda functions and S3 within the AWS network, without going over the internet. Option A: Deploy the Lambda functions to a private subnet in the VPC. Configure the Lambda functions to access the S3 service through the NAT gateway. - Analysis: - Private Subnet: Deploying the Lambda functions to a private subnet ensures that they do not have direct access to the internet. - NAT Gateway: While the Lambda functions can access S3 through the NAT gateway, this introduces internet-bound traffic because the NAT gateway routes traffic through the internet, which does not meet the requirement to keep traffic within the AWS network. - Problem: The requirement specifies that traffic to S3 should use the AWS network and not the internet, which is violated by using the NAT gateway. - Conclusion: This option does not meet the requirement of keeping traffic within the AWS network because it uses the NAT gateway, which routes traffic over the internet. Option B: Deploy the Lambda functions to a private subnet in the VPC. Create an S3 gateway endpoint to access the S3 service. - Analysis: - Private Subnet: Deploying the Lambda functions in a private subnet ensures they do not have direct access to the internet. - S3 Gateway Endpoint: By creating an S3 gateway endpoint, the Lambda functions can access S3 over the AWS private network instead of routing traffic through the internet. This satisfies the requirement of keeping traffic to S3 within the AWS network. - Solution: The S3 gateway endpoint ensures that the Lambda functions access S3 directly through the AWS network, avoiding the internet entirely. - Conclusion: This is the best option because it keeps all traffic to S3 within the AWS network, as required. Option C: Deploy the S3 bucket and the Lambda functions in the same private subnet. Configure the Lambda functions to use the default endpoint for the S3 service. - Analysis: - Private Subnet: Deploying Lambda functions i...

Author: Kunal · Last updated Jun 27, 2026

A company uses an organization in AWS Organizations to manage its AWS accounts. The company has implemented an SCP in the root account to prevent resources from being shared with external accounts. The company now needs to allow applications in its marketing team's AWS account to share resources with external accounts. The company must continue to prevent all the other accounts in the org...

Let's analyze each option to determine the most suitable solution for the company's requirements: Option A: Create a new SCP in the marketing team's account. Configure the SCP to explicitly allow resource sharing. - Analysis: - SCPs in AWS Organizations apply to AWS accounts within the organization and not at the individual IAM user or role level. - SCPs affect all actions across the entire account, so creating an SCP in just the marketing team's account would not be a solution. SCPs are managed at the organizational unit (OU) or organization level, not per account. - Additionally, if resource sharing is restricted by an SCP at the root level (as mentioned), adding a new SCP in the marketing team's account will not override the restrictions applied at the organization or OU level. - Conclusion: This option is not valid because SCPs are managed at the organizational level, not per individual account. Option B: Edit the existing SCP to add a Condition statement that excludes the marketing team's account. - Analysis: - Condition Statement: SCPs allow you to define conditions that can be used to either allow or deny specific actions. By adding a condition to the existing SCP, you can effectively exclude the marketing team's account from the resource sharing restriction. - This solution allows the marketing team's account to perform actions (such as resource sharing) while still blocking other accounts in the same OU. - Scalability: This solution is scalable because it allows resource sharing for the marketing team specifically, without needing to apply an entirely new SCP to the account. - Conclusion: This is a good option because it modifies the existing SCP with a condition that specifically allows the marketing team to share resources, while still blocking other accounts from doing so. Option C: Edit the existing SCP to include an Allow statement that specifies the marketing team's account. - Analysis: - Adding an explicit Allow...

Author: Rohan · Last updated Jun 27, 2026

A security administrator has enabled AWS Security Hub for all the AWS accounts in an organization in AWS Organizations. The security team wants near-real-time response and remediation for deployed AWS resources that do not meet security standards. All changes must be centrally logged for auditing purposes. The organization has reached the quotas for the number of SCPs attached to an OU and SCP document size. The team wants to avoid making any changes ...

To meet the security team's requirements of near-real-time response and remediation, centrally logging all changes for auditing purposes, and avoiding changes to the existing SCPs, the security administrator needs to focus on maximizing scalability, cost-effectiveness, and avoiding hitting the quota limits of SCPs in AWS Organizations. Let's evaluate each option: Option A: Create an AWS Config custom rule to detect configuration changes to AWS resources. Create an AWS Lambda function to remediate the AWS resources in the delegated administrator AWS account. - Reasoning: AWS Config can help in monitoring changes to AWS resources and evaluate configurations against specific rules. However, creating a custom rule in AWS Config would be helpful only for detecting non-compliant resources. The Lambda function can then remediate the issue in the delegated administrator account. This approach can provide near-real-time remediation of non-compliant resources. - Pros: Centralizes configuration monitoring, provides near-real-time response, and can trigger automatic remediation via Lambda. - Cons: AWS Config custom rules and Lambda for remediation may increase costs depending on usage. However, since it fits the requirement of automation and real-time action without changing SCPs, it’s a good fit. Option B: Use AWS Systems Manager Change Manager to track configuration changes to AWS resources. Create a Systems Manager document to remediate the AWS resources in the delegated administrator AWS account. - Reasoning: AWS Systems Manager Change Manager is designed to manage and track changes to AWS resources. However, it is more suited for managing changes in a controlled, manual manner rather than for automated remediation. - Cons: It is not as automated as other options and is more focused on change management and auditing, not on real-time enforcement of security standards. Additionally, it may add unnecessary complexity for this use case, which focuses on automatic response. Option C: Create a Security Hub custom action to reference in an Amazon EventBridge event rule in the delegated administrator AWS account. - Reasoning: Security Hub custom actions allow you to define custom workflows to take action based on findings in AWS Security Hub. By using an EventBridge rule to trigger this custom action, you can invoke a remediation function or notification. - Pros: This approach integrates Security Hub with EventBridge for streamlined automation. - Cons: Custom actions alone may not address all the needs for automatic remediation and may require extra configuration. It also might not be fully scalable for all AWS accounts if there are too many cu...

Author: Zain · Last updated Jun 27, 2026

A security engineer must Implement monitoring of a company's Amazon Aurora MySQL DB instances. The company wants to receive email notifications when unknown users try to log in to the database endpoin...

To meet the requirements of monitoring login attempts by unknown users on an Amazon Aurora MySQL DB instance and sending email notifications with the least operational overhead, let’s evaluate each of the provided options: Option A: Enable Amazon GuardDuty. Enable the Amazon RDS Protection feature in GuardDuty to detect login attempts by unknown users. Create an Amazon EventBridge rule to filter GuardDuty findings. Send email notifications by using Amazon Simple Notification Service (Amazon SNS). - Reasoning: Amazon GuardDuty is a managed threat detection service that provides an easy-to-use way to detect suspicious activity, including unusual login attempts. By enabling the Amazon RDS Protection feature, GuardDuty can detect and alert for login attempts by unknown users. Using Amazon EventBridge to filter GuardDuty findings and trigger email notifications via SNS provides a fully managed, automated solution. - Pros: This option is fully managed with minimal setup and operational overhead. GuardDuty is scalable and requires no manual monitoring or maintenance. The use of EventBridge and SNS makes notifications highly automated and reliable. - Cons: GuardDuty incurs additional cost, but this cost is relatively low compared to the complexity and overhead of the other options. GuardDuty’s managed nature makes it an ideal fit for security monitoring with minimal operational burden. Option B: Enable the `server_audit_logging` parameter on the Aurora MySQL DB instances. Use AWS Lambda to periodically scan the delivered log files for login attempts by unknown users. Send email notifications by using Amazon Simple Notification Service (Amazon SNS). - Reasoning: Enabling `server_audit_logging` will capture login attempts in the database logs, and Lambda can periodically scan those logs for unknown user attempts. - Cons: While this approach is feasible, it introduces higher operational overhead. Lambda would need to be configured, maintained, and monitored to ensure proper execution. Additionally, periodic scanning of logs adds latency, and depending on log file size, it could be inefficient compared to real-time alerting. This approach would also require handling log management, ensuring Lambda scalability, and troubleshooting any is...

Author: Maya · Last updated Jun 27, 2026

A company runs a global ecommerce website that is hosted on AWS. The company uses Amazon CloudFront to serve content to its user base. The company wants to block inbound traffic from a specific set of countries to comply with rec...

To meet the requirement of blocking inbound traffic from specific countries on the company’s global eCommerce website hosted on AWS, let's analyze each of the options: Option A: Create an AWS WAF web ACL with an IP match condition to deny the countries' IP ranges. Associate the web ACL with the CloudFront distribution. - Reasoning: Using AWS WAF with an IP match condition involves manually configuring the IP ranges for the specific countries you want to block. While AWS WAF provides powerful customizability, the IP ranges for different countries change over time, and manually maintaining these lists can be time-consuming and error-prone. Additionally, using WAF in this manner may incur additional costs due to the need for custom IP matching and more complex configurations. - Cons: This approach can become complex, requiring constant updates to the IP ranges, and may not be the most cost-effective solution compared to other options. The need to manually track and update IP address ranges introduces additional operational overhead. Option B: Create an AWS WAF web ACL with a geo match condition to deny the specific countries. Associate the web ACL with the CloudFront distribution. - Reasoning: AWS WAF supports geo match conditions, which allow you to block or allow traffic based on the geographic location of the request origin. This feature automatically manages the IP ranges associated with specific countries, making it easier to implement and maintain. By using geo match conditions in WAF, the configuration remains simple, and AWS manages the geographic IP ranges for you. - Pros: This is a more automated and cost-effective solution than manually managing IP ranges. The geo match feature is straightforward and does not require frequent updates, as AWS handles the geolocation mapping of IP addresses. - Cons: While this is cost-effective and easy to set up, AWS WAF does have pricing that might be higher than CloudFront’s native geo restriction feature, but it's still quite reasonable and offers greater flexibility for future security ...

Author: Ethan · Last updated Jun 27, 2026

A company deploys its application as a service on an Amazon Elastic Container Service (Amazon ECS) cluster with theAWS Fargate launch type. A security engineer suspects that some incoming requests are malicious. The security engineer needs to inspect the running container by retr...

To meet the requirement of inspecting the running container for log files and memory dump files with the least operational effort, let's evaluate each option: Option A: Migrate the application to an ECS cluster with the Amazon EC2 launch type. Configure the EC2 instances with proper remote access. Log in and inspect the container. - Reasoning: This approach involves moving from AWS Fargate (serverless) to EC2 instances, which would require managing the EC2 infrastructure, configuring remote access, and logging into individual EC2 instances to inspect the containers. - Cons: Migrating to EC2 requires significant operational overhead, as it involves maintaining EC2 instances, managing remote access, and ensuring proper security measures. Additionally, this approach goes against the serverless nature of Fargate and increases complexity, making it a less optimal choice in terms of effort and cost. Option B: Update the application to dump the required data to STDOUT. Use the awslogs log driver to pass the logs to Amazon CloudWatch Logs. Examine the log files in CloudWatch Logs. - Reasoning: The `awslogs` log driver sends container logs to CloudWatch Logs, and dumping required data to STDOUT can be an easy way to gather logs. CloudWatch Logs provides a centralized view for logs. - Cons: This option only covers log data and does not address the memory dump issue. Also, this approach requires modification to the application code to dump data to STDOUT, which could be cumbersome and is not suitable for all use cases, especially for memory dumps or detailed inspection of running containers. Option C: Turn on Amazon CloudWatch Container Insights for the ECS cluster. Send the log data to Amazon CloudWatch Logs by using AWS Distro for OpenTelemetry. Examine the log data in CloudWatch Logs. - Reasoning: CloudWatch Container Insights provides monitoring and diagnostics for containers, giving detailed metrics and logs for ECS tasks. AWS Distro for OpenTelemetry is used for enhanced observability...

Author: Noah · Last updated Jun 27, 2026

A company uses AWS Organizations and has many AWS accounts. The company has a new requirement to use server-side encryption with customer-provided keys (SSE-C) on all new object uploads to Amazon S3 buckets. A security engineer is creating an SCP that includes a Deny effect for t...

To meet the requirement of enforcing server-side encryption with customer-provided keys (SSE-C) on all new object uploads to Amazon S3 buckets via an SCP in AWS Organizations, let's evaluate the options: Key Considerations: - SSE-C is a specific encryption method where the customer provides the encryption key. - The SCP needs to deny the `s3:PutObject` action unless the object upload includes a customer-provided encryption key (SSE-C). - The condition in the SCP will focus on verifying that the correct encryption method (SSE-C) is used when uploading objects to S3. Option Evaluation: Option A: StringEqualsIfExists: s3:x-amz-server-side-encryption: AES256 - Reasoning: This condition checks for the use of server-side encryption with the AES-256 algorithm, but it doesn’t specifically check for SSE-C. AES-256 is the encryption standard for Amazon S3's server-side encryption with Amazon S3 managed keys (SSE-S3), not customer-provided keys (SSE-C). - Cons: This is not applicable to the SSE-C requirement because it’s related to SSE-S3, not SSE-C. Option B: StringEqualsIfExists: s3:x-amz-server-side-encryption-customer-algorithm: AES256 - Reasoning: This condition would check if the `x-amz-server-side-encryption-customer-algorithm` header is present and matches `AES256`. This is closer to the correct condition for SSE-C, as it checks for the presence of a customer-provided encryption key. However, AES256 is typically used in SSE-S3 rather than SSE-C. - Cons: This is still somewhat misleading since it implies a different encryption approach, which might not strictly enforce the SSE-C requirement (where the customer provides the key directly). Option C: StringEqualsIfExists: s3:x-amz-server-side-encryption-customer-key: AND StringEqualsIfExists: s3...

Author: Maya2022 · Last updated Jun 27, 2026

A company wants to deny a specific federated user named Bob access to an Amazon S3 bucket named DOC-EXAMPLE-BUCKET. The company wants to meet this requirement by using a bucket policy. The company also needs to ensure that this bucket policy affects Bob's S3 permissions only. A...

Author: Sam · Last updated Jun 27, 2026

A company runs an online game on AWS. When players sign up for the game, their username and password credentials are stored in an Amazon Aurora database. The number of users has grown to hundreds of thousands of players. The number of requests for password resets and login assistance has become a burden for the company's customer service team. The company needs to implement a solution to give players another way to log in to...

To meet the company's requirements of reducing the burden on the customer service team for password resets and login assistance, and securely protecting each player's credentials, the best solution is Option C: Configure Amazon Cognito user pools to federate access to the game with third-party identity providers (IdPs), such as social IdPs. Migrate the game's authentication mechanism to Cognito. Explanation of selected option: Option C: Amazon Cognito User Pools - Password Management: Amazon Cognito handles password management for users, including secure storage, reset capabilities, and MFA (multi-factor authentication) options, which removes the need for the company to manually handle password resets and login assistance. - Federation: Cognito allows users to authenticate via various third-party identity providers (like Google, Facebook, or other social logins). This gives players the flexibility to log in without requiring a traditional username/password combination. - Scalability and Security: Cognito is designed to scale with a large number of users, making it suitable for handling the hundreds of thousands of players in the game. It provides built-in security features such as encryption, password strength requirements, and advanced authentication protocols. - Ease of Integration: Amazon Cognito can easily integrate with the existing game infrastructure, and it reduces the operational burden by offloading the authentication process to AWS. This can significantly improve the user experience by offering more login options and security. Why other options are rejected: - Option A: Using IAM Access Keys and Secrets - Not Suitable for End Users: IAM is designed for AWS services and applications, not for end users of a game. Creating IAM access keys for players could expose them to risks, such as misuse or accidental exposure, and would not provide the required...

Author: William · Last updated Jun 27, 2026

A company suspects that an attacker has exploited an overly permissive role to export credentials from Amazon EC2 instance metadata. The company uses Amazon GuardDuty and AWS Audit Manager. The company has enabled AWS CloudTrail logging and Amazon CloudWatch logging for all of its AWS accounts. A security engineer must deter...

To determine if the credentials exported from the Amazon EC2 instance metadata were used to access the company’s resources from an external account, the best solution is Option A: Review GuardDuty findings to find InstanceCredentialExfiltration events. Explanation of selected option: Option A: Review GuardDuty findings for InstanceCredentialExfiltration events - GuardDuty’s Detection Capabilities: Amazon GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior. It has built-in capabilities to detect various forms of suspicious behavior, including InstanceCredentialExfiltration. This finding would indicate that credentials were likely exfiltrated from an EC2 instance metadata endpoint, and GuardDuty can further provide insight if those credentials were used externally or in a suspicious context. - Event Type: The InstanceCredentialExfiltration finding specifically detects when an EC2 instance’s credentials are exposed or exported, which directly addresses the suspected attack scenario. - Ease of Use: GuardDuty findings are easy to access and interpret, and they provide immediate insights into suspicious activities that are tied to AWS accounts. Why other options are rejected: - Option B: Review assessment reports in the Audit Manager console for InstanceCredentialExfiltration events - Audit Manager: AWS Audit Manager focuses on auditing and compliance, and it generates reports to help track compliance controls. While it is useful for generating reports related to security and compliance audits, it does not specifically monitor for security threats or detect instances of credential exfiltration in real-time like GuardDuty does. - Not Suitable for Threat Detection: The Audit Manager is not designed for detecting active security incidents or suspicious behavior in real-time, making it less effective for this scenario. - Option C: Review CloudTrail logs for GetSessionTo...

Author: Henry · Last updated Jun 27, 2026

A security engineer needs to run an AWS CloudFormation script. The CloudFormation script builds AWS infrastructure to support a stack that includes web servers and a MySQL database. The stack has been deployed in pre-production environments and is ready for production. The production script must comply with the principle of least privilege. Additi...

The most suitable solution for this scenario is Option A: Use IAM Access Analyzer policy generation to generate a policy that allows the CloudFormation script to run and manage the stack. Attach the policy to a new IAM role. Modify the security engineer's IAM permissions to be able to pass the new role to CloudFormation. Explanation of Selected Option: Option A: - Principle of Least Privilege: IAM Access Analyzer helps generate a policy with the minimal set of permissions required for the CloudFormation stack to function. This ensures that the CloudFormation script has only the permissions necessary to deploy and manage the stack, which aligns with the principle of least privilege. - Separation of Duties: By attaching the policy to a new IAM role, the security engineer’s IAM account does not directly have the permissions to run the CloudFormation script. Instead, the security engineer is granted permission to pass the role to CloudFormation. This establishes clear separation of duties, as the engineer can delegate the action to CloudFormation without having full control over the infrastructure. - Role Passing: The security engineer is granted the ability to pass the new role to CloudFormation, which allows CloudFormation to assume the necessary permissions while ensuring that the security engineer does not have direct administrative access to all resources in the stack. - Security: This solution maintains security best practices, ensuring that the security engineer’s permissions are limited, and CloudFormation can operate within the scope of its defined permissions. Why Other Options Are Rejected: - Option B: - Over-Permissioned Role: Creating an IAM policy that allows `ec2:` and `rds:` permissions would grant overly broad permissions to the new IAM role. This violates the principle of least privilege by allowing access to all EC2 and RDS actions, regardless of the specific needs of the CloudFormation script. - Sepa...

Author: Liam · Last updated Jun 27, 2026

A company that uses AWS Organizations is migrating workloads to AWS. The company's application team determines that the workloads will use Amazon EC2 instances, Amazon S3 buckets, Amazon DynamoDB tables, and Application Load Balancers. For each resource type, the company mandates that deployments must comply with the following requirements: * All EC2 instances must be launched from approved AWS accounts. * All DynamoDB tables must be provisioned with a standardized naming convention. * All infrast...

To meet the company's requirements, the application team needs to ensure compliance with the following: - EC2 Instances Launched from Approved Accounts - DynamoDB Tables with Standardized Naming Conventions - All Infrastructure Deployed via CloudFormation Selected Options: - Option D: Use SCPs to prevent the application AWS account from provisioning specific resources unless conditions for the internal compliance requirements are met. - Option A: Create CloudFormation templates in an administrator AWS account. Share the stack sets with an application AWS account. Restrict the template to be used specifically by the application AWS account. Explanation of Selected Options: Option D: Use SCPs to prevent the application AWS account from provisioning specific resources unless conditions for the internal compliance requirements are met. - Service Control Policies (SCPs) are part of AWS Organizations and are ideal for enforcing organization-wide policies across multiple AWS accounts. - EC2 Instances in Approved Accounts: SCPs can be used to restrict the provisioning of EC2 instances to only those AWS accounts approved by the company, ensuring that only certain accounts can launch EC2 instances. - DynamoDB Tables with Standard Naming: SCPs can be used to enforce policies that prevent the creation of DynamoDB tables unless they follow the standardized naming convention. While SCPs cannot enforce the naming convention directly, they can restrict resource creation or use other mechanisms (like AWS Config or Lambda checks) to ensure compliance with naming conventions. - Enforcing CloudFormation Deployment: SCPs can be used to enforce that resources are only provisioned through CloudFormation by preventing direct API calls to provision resources (e.g., EC2 instances, DynamoDB tables) unless they're managed by CloudFormation. - Why Other Options are Rejected for EC2, DynamoDB, and CloudFormation: - Option A is selected because using SCPs allows for organization-wide control over what resources can be provisioned. - Option C (Permissions Boundaries) would limit the actions of IAM roles and users but would not fully address the organizational-level control for preventing provisioning of specific resources across accounts. - Option E (AWS Config) is a good tool for monitoring compliance post-deployment but does not prevent the initial creation of non-compliant resources, which is the immediate concern. Option A: Create CloudFormation templates in an administrator AWS account. Share the stack sets with an application AWS account. Restric...

Author: Henry · Last updated Jun 27, 2026

A company has a batch-processing system that uses Amazon S3, Amazon EC2, and AWS Key Management Service (AWS KMS). The system uses two AWS accounts: Account A and Account B. Account A hosts an S3 bucket that stores the objects that will be processed. The S3 bucket also stores the results of the processing. All the S3 bucket objects are encrypted by a KMS key that is managed in Account A. Account B hosts a VPC that has a fleet of EC2 instances that access the S3 bucket in Account A by using statements in the bucket policy. The VPC was created with DNS hostnames enabled and DNS resolution enabled. A...

In this scenario, the goal is to ensure that no API calls from the EC2 instances in Account B travel over the internet and to maintain the system's encryption settings. The design involves updating the VPC and endpoint configurations while ensuring seamless access to S3 and KMS resources. Let's evaluate each option: A) In the Account B VPC, create a gateway VPC endpoint for Amazon S3. For the gateway VPC endpoint, create a resource policy that allows the s3:GetObject, s3:ListBucket, s3:PutObject, and s3:PutObjectAcl actions for the S3 bucket. - Reasoning: A gateway VPC endpoint is designed to route traffic from the VPC to Amazon S3 without going over the internet. This option creates a secure and direct route for accessing the S3 bucket. The necessary permissions are granted through the endpoint policy, which allows the EC2 instances to perform actions like `s3:GetObject`, `s3:ListBucket`, and `s3:PutObject` on the S3 bucket. - Selected option: This option is correct because it meets the requirements for routing traffic through private endpoints (i.e., without internet access) and allows the required actions for S3. B) In the Account B VPC, create an interface VPC endpoint for Amazon S3. For the interface VPC endpoint, create a resource policy that allows the s3:GetObject, s3:ListBucket, s3:PutObject, and s3:PutObjectAcl actions for the S3 bucket. - Reasoning: Interface VPC endpoints are generally used for private access to AWS services like AWS API Gateway, AWS Lambda, etc. While this option could technically work, Amazon S3 requires a gateway VPC endpoint for routing traffic from VPCs to S3. Interface endpoints do not provide a native connection for S3. Hence, this option is less appropriate for S3 traffic and should be rejected. C) In the Account B VPC, create an interface VPC endpoint for AWS KMS. For the interface VPC endpoint, create a resource policy that allows the kms:Encrypt, kms:Decrypt, and kms:GenerateDataKey actions for the KMS key. Ensure that private DNS is turned on for the endpoint. - Reasoning: To access AWS KMS from Account B, an interface VPC endpoint is required. AWS KMS provides support for VPC endpoints, and configuring private DNS ensures that the KMS calls use private IP addres...

Author: Ethan · Last updated Jun 27, 2026

A security engineer is designing an IAM policy for a script that will use the AWS CLI. The script currently assumes an IAM role that is attached to three AWS managed IAM policies: AmazonEC2FullAccess, AmazonDynamoDBFullAccess, and AmazonVPCFullAccess. The security engineer needs to construct a least privilege IAM policy that will replace ...

In this scenario, the goal is to design a least privilege IAM policy for a script that currently uses three AWS managed IAM policies: AmazonEC2FullAccess, AmazonDynamoDBFullAccess, and AmazonVPCFullAccess. These policies provide broader access than necessary, and we want to replace them with a policy that grants only the permissions needed for the script to function. Let's evaluate the options and reasoning: Option A) In AWS CloudTrail, create a trail for management events. Run the script with the existing AWS managed IAM policies. Use IAM Access Analyzer to generate a new IAM policy that is based on access activity in the trail. Replace the existing AWS managed IAM policies with the generated IAM policy for the role. - Reasoning: This option proposes creating a CloudTrail trail to capture the access activity and then using IAM Access Analyzer to generate a policy based on this activity. The advantage here is that the policy would be dynamically created based on actual usage, which ensures that the permissions are tailored to the exact needs of the script. This is an operationally efficient solution because IAM Access Analyzer can generate the least privilege policy based on real access activity. - Selected option: This is a highly efficient and effective solution because it directly derives the required permissions from the actual access patterns of the script, ensuring the new policy is accurate and precise. Option B) Remove the existing AWS managed IAM policies from the role. Attach the IAM Access Analyzer Role Policy Generator to the role. Run the script. Return to IAM Access Analyzer and generate a least privilege IAM policy. Attach the new IAM policy to the role. - Reasoning: This option involves removing the existing AWS managed IAM policies before running the script. The Role Policy Generator would be used after running the script to generate the least privilege policy. However, this method introduces unnecessary risk because without the policies in place, the script might fail during the testing phase (especially if the exact permissions are not known beforehand). - Rejected option: It’s less operationally...

Author: Amelia · Last updated Jun 27, 2026

A security engineer is designing a cloud architecture to support an application. The application runs on Amazon EC2 instances and processes sensitive information, including credit card numbers. The application will send the credit card numbers to a component that is running in an isolated environment. The component will encrypt, store, and decrypt the numbers. The component then will issue tokens to replace the numbers in other parts of the application. The component of the application that manages th...

Let's evaluate the provided options based on the requirements for securing sensitive information, particularly credit card numbers, and ensuring that only the tokenization component has access to the sensitive data. Option A) Use EC2 Dedicated Instances for the tokenization component of the application. - Reasoning: EC2 Dedicated Instances run on hardware that is dedicated to a single customer, providing isolation from other tenants. However, while this offers physical isolation, it does not specifically address the need to isolate sensitive data or provide the security controls required for handling and processing credit card numbers. It also does not have native support for isolating or securing sensitive data such as encryption or tokenization. - Rejected option: This option does not directly address the need for isolation in terms of data handling, encryption, and security of sensitive data like credit card numbers. Option B) Place the EC2 instances that manage the tokenization process into a partition placement group. - Reasoning: A partition placement group is used for high availability and fault tolerance across EC2 instances, particularly in distributed systems. It ensures that instances are spread across multiple logical partitions in an underlying hardware infrastructure to prevent failure in the case of hardware failure in one partition. However, it does not inherently provide the level of isolation needed to secure credit card numbers or handle encryption securely. - Rejected option: While useful for fault tolerance and availability, it does not help with securing sensitive information or isolating the tokenization process. Option C) Create a separate VPC to deploy new EC2 instances for the tokenization process. - Reasoning: Deploying the tokenization component in a separate VPC would provide network isolation from other components of the application. This would ensure that only the tok...

Author: Arjun · Last updated Jun 27, 2026

A company has two AWS accounts: Account A and Account B. Account A has an IAM role that IAM users in Account B assume when they need to upload sensitive documents to Amazon S3 buckets in Account A. A new requirement mandates that users can assume the role only if they are authenticated with multi-factor authentication (MFA). A security en...

Let's evaluate each of the options for enforcing multi-factor authentication (MFA) when IAM users from Account B assume the IAM role in Account A. The goal is to ensure that users can only assume the role if they authenticate using MFA, while keeping the solution minimal and secure. Option A) Add an aws:MultiFactorAuthPresent condition to the role's permissions policy. - Reasoning: Permissions policies control the actions a principal (user or role) can perform on resources (e.g., S3). While adding an `aws:MultiFactorAuthPresent` condition in the permissions policy would ensure that MFA is required for actions, it would not effectively enforce MFA for role assumption itself. MFA is typically required when assuming a role, so adding this condition to the permissions policy does not address the core requirement, which is enforcing MFA on the role assumption. - Rejected option: This is not the correct location for enforcing MFA during the role assumption process. Option B) Add an aws:MultiFactorAuthPresent condition to the role's trust policy. - Reasoning: The trust policy defines who can assume the role. By adding an `aws:MultiFactorAuthPresent` condition to the trust policy, the system will require users from Account B to authenticate with MFA before they can assume the role. This directly enforces the MFA requirement on the role assumption process, which is exactly what is needed in this case. - Selected option: This is the most appropriate solution because it directly enforces MFA for assuming the role, which meets the requirement of ensuring that only MFA-authenticated users can perform r...

Author: Madison · Last updated Jun 27, 2026

A company wants to receive automated email notifications when AWS access keys from developer AWS accounts are detected on code repository sites. ...

Let's evaluate each of the options in the context of sending automated email notifications when AWS access keys are detected on code repository sites, with the goal of providing a solution that detects these potentially unauthorized activities. Option A) Create an Amazon EventBridge rule to send Amazon Simple Notification Service (Amazon SNS) email notifications for Amazon GuardDuty UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS findings. - Reasoning: Amazon GuardDuty is a managed threat detection service that can identify suspicious activity, including the exfiltration of AWS credentials outside of AWS (such as when they are leaked on public code repositories). UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration findings are specifically designed to detect when IAM user credentials (including access keys) are exposed in environments outside AWS, such as on GitHub or other code repository sites. By creating an Amazon EventBridge rule that reacts to these findings, and using Amazon SNS to send email notifications, this solution would provide the required automated alerts for when such exposure is detected. - Selected option: This is the most direct and efficient approach because GuardDuty can monitor and identify exactly the type of event needed, and EventBridge with SNS will automate the notification process. Option B) Change the AWS account contact information for the Operations type to a separate email address. Periodically poll this email address for notifications. - Reasoning: This option proposes changing the account contact information to a specific email address, which would presumably receive notifications from AWS regarding account activity. However, this is not a direct mechanism for detecting AWS access keys being exposed on code repository sites. AWS does not automatically send notifications for such events to email addresses based on account settings, and it would not provide the automated monitoring or alerts specifically ...

Author: Victoria · Last updated Jun 27, 2026

A company deployed an Amazon EC2 instance to a VPC on AWS. A recent alert indicates that the EC2 instance is receiving a suspicious number of requests over an open TCP port from an external source. The TCP port remains open for long periods of time. The company's security team needs to stop all activity to this port from the external source to ensu...

To address the requirement of stopping all activity to the open TCP port from an external source while ensuring the application remains available to other users, we need to consider how to prevent incoming malicious traffic to the EC2 instance while allowing legitimate traffic. A) Update the network ACL that is attached to the subnet that is associated with the EC2 instance. Add a Deny statement for the port and the source IP addresses. Explanation: - A Network Access Control List (ACL) operates at the subnet level and can filter traffic based on IP address and port. - By adding a Deny rule for the suspicious external source on the specific TCP port, you can block the malicious traffic while leaving other legitimate traffic unaffected. - Advantages: - Network ACLs apply to all traffic entering or leaving the subnet, including both inbound and outbound traffic. - Since network ACLs are stateless, you can block traffic based on IP addresses and ports at a higher level, ensuring the malicious traffic is blocked. - Reasoning for selection: This approach works because the malicious source is external, and you want to block the specific traffic based on IP and port without affecting legitimate traffic. B) Update the elastic network interface security group that is attached to the EC2 instance to remove the port from the inbound rule list. Explanation: - A security group operates at the EC2 instance level and controls inbound and outbound traffic. - By removing the port from the inbound rule list, you would block all traffic to the instance on that port. - However, the issue is that this solution would also block l...

Author: Amelia · Last updated Jun 27, 2026

A company has secured the AWS account root user for its AWS account by following AWS best practices. The company also has enabled AWS CloudTrail, which is sending its logs to Amazon S3. A security engineer wants to receive notification in near-real time if a user uses the AWS account roo...

To receive near-real-time notifications for AWS root user logins, we need to use solutions that can detect when the root account signs in and trigger an alert quickly. Let's evaluate the options. A) Use AWS Trusted Advisor and its security evaluations for the root account. Configure an Amazon EventBridge event rule that is invoked by the Trusted Advisor API. Configure the rule to target an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe any required endpoints to the SNS topic so that these endpoints can receive notifications. Explanation: - Trusted Advisor provides security evaluations and checks but does not provide specific monitoring for root user logins in near-real-time. - Trusted Advisor does not directly integrate with EventBridge to monitor specific events like successful logins. It is a general tool for evaluating best practices across various AWS resources. - Why rejected: Trusted Advisor is not designed for detecting specific login events and cannot give near-real-time alerts for root account logins. B) Use AWS IAM Access Analyzer. Create an Amazon CloudWatch Logs metric filter to evaluate log entries from Access Analyzer that detect a successful root account login. Create an Amazon CloudWatch alarm that monitors whether a root login has occurred. Configure the CloudWatch alarm to notify an Amazon Simple Notification Service (Amazon SNS) topic when the alarm enters the ALARM state. Subscribe any required endpoints to this SNS topic so that these endpoints can receive notification. Explanation: - IAM Access Analyzer primarily focuses on identifying access to resources, rather than monitoring specific user sign-in activities. It doesn't directly track root user logins. - Using CloudWatch Logs to monitor IAM Access Analyzer logs would not capture the root user login events accurately. - Why rejected: IAM Access Analyzer is not suited for the specific requirement of detecting root user logins, as it focuses on resource access rather than login events. C) Configure AWS CloudTrail to send its logs to Amazon CloudWatch Logs. Configure a metric filter on the CloudWatch Logs log group used by CloudTrail to evaluate log entries for successful root account logins. Create an Amazon CloudWatch alarm that monitors whether a root login has occurred. Configure the CloudWatch alarm to notify an Amazon Simple Notification Service (Amazon SNS) topic when the alarm enters the ALARM state. Subscribe any required endpoints to this SNS topic so that these endpoints can receive notification. Explanation: - AWS CloudTrail logs every API request...

Author: Emma · Last updated Jun 27, 2026

A company has AWS accounts that are in an organization in AWS Organizations. A security engineer needs to set up AWS Security Hub in a dedicated account for security monitoring. The security engineer must ensure that Security Hub automatically manages all existing accounts and all new accounts that are added to the organization. Security Hub also mu...

To meet the requirements with the least operational overhead for setting up AWS Security Hub in a dedicated account, let's evaluate each option based on the need to automatically manage existing and new accounts, and receive findings from all AWS Regions. A) Configure a finding aggregation Region for Security Hub. Link the other Regions to the aggregation Region. Explanation: - Finding aggregation is a feature in Security Hub that allows you to consolidate findings from multiple AWS Regions into a central Region, known as the finding aggregation Region. - By setting up a central aggregation Region, you can ensure that all findings from various Regions are automatically aggregated and accessible in one place, meeting the requirement to receive findings from all AWS Regions. - Why selected: This approach provides an efficient way to aggregate findings across multiple Regions without requiring manual intervention for each Region. It simplifies management by consolidating findings into a central location. B) Create an AWS Lambda function that routes events from other Regions to the dedicated Security Hub account. Create an Amazon EventBridge rule to invoke the Lambda function. Explanation: - This solution involves creating an AWS Lambda function that manually routes events from other Regions to the Security Hub account, which is more complex and requires continuous operational overhead to maintain the Lambda function and EventBridge rule. - Why rejected: This solution requires significant custom development and operational overhead, and it is not as straightforward or scalable as using built-in Security Hub features for aggregation across Regions. C) Turn on the option to automatically enable accounts for Security Hub. Explanation: - Automatic account enabling for Security Hub is a built-in feature that automatically adds all accounts in your AWS Organization to Security Hub, ensuring that both existing and new accounts are automatically enabled fo...

Author: Benjamin · Last updated Jun 27, 2026

A security engineer is implementing a solution to allow users to seamlessly encrypt Amazon S3 objects without having to touch the keys directly. The solution must be highly scalable without requiring continual management. Additionally, the organi...

Let's evaluate each option based on the requirements: - Seamless encryption of Amazon S3 objects: The solution should enable automatic encryption without requiring users to directly manage the keys. - Scalable solution: The solution should scale without requiring continual management or intervention. - Immediate deletion of encryption keys: The solution must allow for the immediate deletion of encryption keys when necessary. A) Use AWS KMS with AWS managed keys and the ScheduleKeyDeletion API with a PendingWindowInDays set to 0 to remove the keys if necessary. Explanation: - AWS Key Management Service (KMS) is a fully managed service that provides encryption at scale and seamlessly integrates with Amazon S3 to automatically encrypt objects. When enabled, S3 can automatically encrypt objects using KMS-managed keys without user intervention. - The ScheduleKeyDeletion API allows you to schedule the deletion of KMS keys. Setting the `PendingWindowInDays` to 0 ensures that the key is immediately scheduled for deletion after the command is issued, allowing for immediate key removal. - Why selected: This solution fits perfectly because it provides the seamless encryption of S3 objects with AWS KMS-managed keys. Additionally, the deletion of keys can be managed with minimal intervention and immediate effect using the `ScheduleKeyDeletion` feature. B) Use KMS with AWS imported key material and then use the DeleteImportedKeyMaterial API to remove the key material if necessary. Explanation: - KMS with imported key material allows you to import and manage your own encryption keys. This gives more control over key management but requires more manual effort in terms of key lifecycle management. - While you can delete the imported key material using the DeleteImportedKeyMaterial API, this method still requires the organization to manage the lifecycle of the key material and potentially higher overhead compared to using AWS-managed keys. - Why rejected: Although it allows for the deletion of key material, this method i...

Author: CrimsonViperX · Last updated Jun 27, 2026

A company needs to implement DNS Security Extensions (DNSSEC) for a specific subdomain. The subdomain is already registered with Amazon Route 53. A security engineer has enabled DNSSEC signing and has created a key-signing key (KSK). When the security engineer tries to test the configuration, t...

To resolve the "broken trust chain" error when testing DNSSEC for a subdomain in Amazon Route 53, the security engineer needs to ensure that the parent zone (which holds the authority over the subdomain) is properly aware of the DNSSEC setup for the subdomain. This is accomplished by linking the child zone (subdomain) to the parent zone using a Delegation Signer (DS) record. Let's evaluate each option: A) Replace the KSK with a zone-signing key (ZSK). Explanation: - The KSK (Key Signing Key) is used to sign the DNSSEC keys (specifically the zone-signing key, ZSK), and it plays a crucial role in DNSSEC by enabling the validation of the ZSK. - The ZSK (Zone Signing Key) is used to sign the DNS records themselves. - Why rejected: The problem described is related to a broken trust chain, which usually points to a misconfiguration in the parent zone. Replacing the KSK with a ZSK will not fix this issue and does not address the requirement to link the subdomain's DNSSEC configuration to the parent zone. B) Deactivate and then activate the KSK. Explanation: - Deactivating and activating the KSK might be useful if the key itself was misconfigured or if there were an issue with key rollover or rotation, but it doesn't directly solve the "broken trust chain" problem. - The error mentioned in the scenario is likely caused by the parent zone not knowing about the KSK, and simply deactivating and activating the KSK won't resolve the issue with the trust chain. - Why rejected: This action doesn't address the key DNSSEC configuration needed be...

Author: Zara1234 · Last updated Jun 27, 2026

A company used AWS Organizations to set up an environment with multiple AWS accounts. The company's organization currently has two AWS accounts, and the company expects to add more than 50 AWS accounts during the next 12 months. The company will require all existing and future AWS accounts to use Amazon GuardDuty. Each existing AWS account has GuardDuty active. The company reviews GuardDuty findings by logging into each AWS account individually. The company wants a centralized view of the Gua...

To meet the company’s requirements for centralized GuardDuty findings across multiple AWS accounts and automatic activation of GuardDuty in all new accounts, let’s analyze each option based on key factors such as automation, scalability, and centralized visibility. Option A: Enable AWS Security Hub in the organization's management account. Configure GuardDuty within the management account to send all GuardDuty findings to Security Hub. - Explanation: This option leverages AWS Security Hub to collect and display findings from GuardDuty. However, Security Hub is not specifically designed for centralized GuardDuty management, and it will not automatically enable GuardDuty in new AWS accounts. Security Hub can aggregate findings, but it does not fulfill the requirement to ensure GuardDuty is automatically turned on in new accounts. - Why rejected: While Security Hub can centralize security findings, it does not solve the problem of automatically enabling GuardDuty for new accounts or centralizing GuardDuty management. This option does not address all the requirements. Option B: Create a new AWS account in the organization. Enable GuardDuty in the new account. Designate the new account as the delegated administrator account for GuardDuty. Configure GuardDuty to add existing accounts as member accounts. Select the option to automatically add new AWS accounts to the organization. - Explanation: This option uses GuardDuty's delegated administrator feature. The newly created account will be designated as the delegated administrator for GuardDuty. It can manage GuardDuty settings across all member accounts, both existing and new. Additionally, the option to automatically add new AWS accounts to the organization ensures that GuardDuty will be automatically enabled for new accounts. - Why selected: This is the best option as it meets all the requirements: centralized GuardDuty management via the delegated administrator, automatic inclusion of new accounts, and existing accounts are added ...

Author: Max · Last updated Jun 27, 2026

A company wants to remove all SSH keys permanently from a specific subset of its Amazon Linux 2 Amazon EC2 instances that are using the same IAM instance profile. However, three individuals who have IAM user accounts will need to access these instances by using an SS...

The company needs to remove SSH keys from its Amazon EC2 instances, but three specific IAM users need SSH access to these instances for critical duties. The solution must enable these users to access the EC2 instances without using SSH keys and without violating security best practices. Let's evaluate each option: Option A: Assign an IAM policy to the instance profile to allow the EC2 instances to be managed by AWS Systems Manager. Provide the IAM user accounts with permission to use Systems Manager. Remove the SSH keys from the EC2 instances. Use Systems Manager Inventory to select the EC2 instance and connect. - Explanation: This option suggests using AWS Systems Manager Inventory, which is typically used for discovering and tracking resources. It does not directly provide a mechanism to establish an SSH session. Systems Manager Inventory doesn’t allow users to connect to EC2 instances for interactive sessions. Instead, it is more for inventory management. - Why rejected: This option does not meet the requirement of providing interactive SSH access to the instances. While it could be used to track instances, it doesn’t facilitate SSH access. Option B: Assign an IAM policy to the IAM user accounts to provide permission to use AWS Systems Manager Run Command. Remove the SSH keys from the EC2 instances. Use Run Command to open an SSH connection to the EC2 instance. - Explanation: AWS Systems Manager Run Command can be used to run commands remotely on EC2 instances. However, it doesn't open an SSH session or provide an interactive shell. While you can use Run Command to execute specific commands remotely, it doesn't provide the necessary SSH access for the IAM users to perform tasks interactively. - Why rejected: This option does not provide interactive access to the EC2 instance, which is a key requirement. It's useful for automation but not for the type of access ...

Author: Elizabeth · Last updated Jun 27, 2026

A company is storing data in Amazon S3 Glacier. A security engineer implemented a new vault lock policy for 10 TB of data and called the initiate-vault-lock operation 12 hours ago. The audit team identified a typo in the policy that is ...

In this scenario, the company needs to correct a typo in a vault lock policy on Amazon S3 Glacier. The vault lock has already been initiated 12 hours ago, and the audit team has identified an issue with unintended access due to the typo. The goal is to correct the policy in the most cost-effective manner. Let's evaluate each option: Option A: Call the abort-vault-lock operation. Update the policy. Call the initiate-vault-lock operation again. - Explanation: Calling `abort-vault-lock` will cancel the existing vault lock and allow changes to the policy. Afterward, the policy can be updated, and the vault lock can be initiated again. The downside of this approach is that aborting the vault lock would potentially incur costs due to the abort process and would reset the state of the vault, which may be inefficient and costly. - Why rejected: Although this method allows you to update the policy, aborting the lock and reinitiating it is unnecessary and could incur additional costs. This is not the most cost-effective solution when compared to other alternatives that do not require aborting the vault lock. Option B: Copy the vault data to a new S3 bucket. Delete the vault. Create a new vault with the data. - Explanation: This option involves copying the entire 10 TB of data to a new location, deleting the existing vault, and creating a new vault with the data. This method is very costly due to the data transfer, storage, and re-setup process. Copying large volumes of data is resource-intensive and incurs significant costs. - Why rejected: This approach is highly inefficient and expensive for c...

Author: MysticJaguar44 · Last updated Jun 27, 2026

A company uses HTTP Live Streaming (HLS) to stream live video content to paying subscribers by using Amazon CloudFront. HLS splits the video content into chunks so that the user can request the right chunk based on different conditions. Because the video events last for several hours, the total video is made up of thousands of chunks. The origin URL is not disclosed, and every user is forced to access the CloudFront URL. The company has a web appl...

In this scenario, the company needs to protect its video content streamed via Amazon CloudFront using HTTP Live Streaming (HLS). The video is split into chunks, and the origin URL is not disclosed. The simplest and most effective way to protect the content and ensure only authorized users (paying subscribers) can access it needs to be considered. Let's evaluate each option: Option A: Develop the application to use the CloudFront key pair to create signed URLs that users will use to access the content. - Explanation: Signed URLs allow you to restrict access to specific CloudFront content by creating URLs that are valid for a limited time. This option is effective for restricting access to the video chunks, as each user would get a URL to access the content, and the URL expires after a defined period. - Why selected: This option is simple and effective because it allows precise control over access to the video content. Each user can receive a unique, time-limited URL that expires after a certain period, ensuring that unauthorized users cannot access the content. It works well in HLS environments, where video is served in multiple chunks, as each chunk can be secured with its own signed URL. Option B: Develop the application to use the CloudFront key pair to set the signed cookies that users will use to access the content. - Explanation: Signed cookies are a method of securing multiple pieces of content from CloudFront by setting cookies on the user’s browser. This is useful when you want to allow access to multiple files under the same domain without requiring a separate signed URL for each one. - Why rejected: While signed cookies are effective for protecting multiple resources (e.g., a complete video playlist or group of files), they are more complex than signed URLs for a use case where each chunk of video content needs to be accessed separately. HLS content typically requires precise access control to individual chunks, which makes signed URLs more appropriate for this scenario. Signed cookies also...

Author: Liam123 · Last updated Jun 27, 2026

A company runs workloads in the us-east-1 Region. The company has never deployed resources to other AWS Regions and does not have any multi-Region resources. The company needs to replicate its workloads and infrastructure to the us-west-1 Region. A security engineer must implement a solution that uses AWS Secrets Manager to store secrets in both Regions. The solution must use AWS Key Management Service (AWS KMS) to encrypt the secrets. The solution must minimize latency and...

To meet the company's requirements, the security engineer must ensure that secrets are replicated from us-east-1 to us-west-1 while using AWS Secrets Manager and AWS Key Management Service (KMS) for encryption. The solution must minimize latency and ensure high availability in the event of a Region failure. Let’s break down each option: Option A: Encrypt the secrets in us-east-1 by using an AWS managed KMS key. Replicate the secrets to us-west-1. Encrypt the secrets in us-west-1 by using a new AWS managed KMS key in us-west-1. - Explanation: AWS managed KMS keys are Region-specific, meaning that a key created in one Region cannot be used to encrypt or decrypt secrets in another Region. In this case, if a new AWS managed KMS key is used in us-west-1, the secrets would not be accessible across Regions since the encryption keys from one Region can't be used in another. - Why rejected: This option would create a scenario where secrets in one Region (us-east-1) cannot be decrypted in another Region (us-west-1), breaking the requirement of cross-Region availability. Each region would need its own encryption key, leading to complications in managing access and replication. Option B: Encrypt the secrets in us-east-1 by using an AWS managed KMS key. Configure resources in us-west-1 to call the Secrets Manager endpoint in us-east-1. - Explanation: This option suggests that resources in us-west-1 would make direct calls to the Secrets Manager endpoint in us-east-1. While this approach may technically work, it does not fully address the need for cross-Region replication and resilience in the event of a Region failure. Relying on a single Region (us-east-1) for all secrets access increases the risk of unavailability if the region becomes inaccessible. - Why rejected: This option introduces a single point of failure and does not provide the desired redundancy or resilience if one Region is unavailable. It also doesn't meet the requirement for replication between the two Regions. Option C: Encrypt the secrets in us-east-1 by using a cu...

Author: Emily · Last updated Jun 27, 2026

A company operates a web application that runs on Amazon EC2 instances. The application listens on port 80 and port 443. The company uses an Application Load Balancer (ALB) with AWS WAF to terminate SSL and to forward traffic to the application instances only on port 80. The ALB is in public subnets that are associated with a network ACL that is named NACL1. The application instances are in dedicated private subnets that are associated with a network ACL that is named NACL2. An Amazon RDS for PostgreSQL DB instance that uses port 5432 is in a dedicated private su...

To ensure the security of the application while maintaining its functionality, let's go through each of the options and explain the reasoning behind selecting the best one. Option A: - Changes to NACL3: - Add a rule allowing inbound traffic on port 5432 from NACL2 (private subnet associated with the application instances). - Add a rule allowing outbound traffic on ports 1024-65536 to NACL2. - Remove the default rules that allow all inbound and outbound traffic. Analysis: - This option allows inbound traffic from NACL2 to port 5432 on the RDS instance, which is the correct direction for the application instances to connect to the RDS database. However, it adds a broad rule allowing outbound traffic from RDS to NACL2 on ports 1024-65536. This is quite permissive and would allow unnecessary wide access. Additionally, removing all default rules could potentially lock down the network too severely without ensuring the correct traffic flows. Issue: The outbound rule for ports 1024-65536 is too broad and insecure. So, this option is not ideal. Option B: - Changes to NACL3: - Add a rule allowing inbound traffic on port 5432 from the CIDR blocks of the application instance subnets. - Add a rule allowing outbound traffic on ports 1024-65536 to the application instance subnets. - Remove the default rules that allow all inbound and outbound traffic. Analysis: - This option correctly allows the RDS instance to receive traffic on port 5432 from the application instance subnets. However, similar to Option A, the outbound rule allowing ports 1024-65536 is too broad and unnecessary. Additionally, removing the default rules might lead to unintended access issues if the new rules are not well-defined. Issue: Again, the broad outbound rule (ports 1024-65536) is too permissive, making this option less secure. Option C: - Changes to NACL2: - Add a rule allowing outbound traffic on port 5432 to the CIDR blocks of the RDS subnets. - Remove the default rules that allow all inbound and outbound traffic. ...

Author: MoonlitPantherX · Last updated Jun 27, 2026

AWS CloudTrail is being used to monitor API calls in an organization. An audit revealed that CloudTrail is failing to deliver events to Amazon S3 as expected. What initial actio...

When CloudTrail is failing to deliver events to Amazon S3, it's essential to verify the configuration and permissions that allow CloudTrail to write to the S3 bucket. Below is a breakdown of each option to determine the best actions. Option A: Verify that the S3 bucket policy allows CloudTrail to write objects. - Analysis: - This is one of the most critical steps. If the S3 bucket policy doesn't grant CloudTrail the necessary permissions (specifically, the `s3:PutObject` permission), CloudTrail will not be able to deliver logs to the S3 bucket. - Ensuring the bucket policy allows CloudTrail to write objects to the bucket is essential for CloudTrail to function correctly. Why selected: This is directly related to the issue and needs to be checked to confirm that CloudTrail has permission to write logs to the S3 bucket. Option B: Verify that the IAM role used by CloudTrail has access to write to Amazon CloudWatch Logs. - Analysis: - This option addresses CloudTrail's ability to send logs to CloudWatch, not to Amazon S3. While CloudWatch integration is important for monitoring, it’s not relevant if the issue specifically concerns CloudTrail delivering logs to S3. The problem at hand is CloudTrail’s ability to write directly to S3, not CloudWatch. Why rejected: This action is unrelated to the direct issue of failing delivery to S3. Option C: Remove any lifecycle policies on the S3 bucket that are archiving objects to S3 Glacier Flexible Retrieval. - Analysis: - This option is about S3 object lifecycle management. If the objects are archived to S3 Glacier Flexible Retrieval, CloudTrail might face issues retrieving them or could fail to write logs if the objects are moved to Glacier before they ...

Author: Amira99 · Last updated Jun 27, 2026

A company has public certificates that are managed by AWS Certificate Manager (ACM). The certificates are either imported certificates or managed certificates from ACM with mixed validation methods. A security engineer needs to design a monitoring solution to provide alerts by email when...

To design a monitoring solution for alerting when a certificate is approaching its expiration date, we need to evaluate the operational efficiency, ease of use, and cost-effectiveness of each option. Option A: Create an AWS Lambda function to list all certificates and describe each certificate using the AWS SDK. Filter on the NotAfter attribute and send an email notification. Use an Amazon EventBridge rate expression to schedule the Lambda function to run daily. - Analysis: - While this option would work, it involves custom coding and the creation of a Lambda function, which increases operational complexity. You would need to write the logic to query the ACM API, parse the expiration dates, and send notifications when certificates are near expiration. - Scheduling the Lambda function with EventBridge adds an additional step, and you would have to handle edge cases like multiple certificates with different expiration dates and errors. Why rejected: This approach is more complex and requires regular maintenance, making it less operationally efficient compared to other built-in solutions from AWS. Option B: Create an Amazon CloudWatch alarm. Add all the certificate ARNs in the AWS/CertificateManager namespace to the DaysToExpiry metric. Configure the alarm to publish a notification to an Amazon Simple Notification Service (Amazon SNS) topic when the value for the DaysToExpiry metric is less than or equal to 31. - Analysis: - CloudWatch does offer a `DaysToExpiry` metric for ACM certificates. However, you would need to manually collect and add all the certificate ARNs to the CloudWatch alarm configuration. This approach is not scalable if you have many certificates, as you would need to continuously manage the ARNs. - While CloudWatch is a powerful service, this requires manual intervention, which is not ideal for operational efficiency, especially when dealing with many certificates. Why rejected: Managing the ARNs manually could be error-prone and difficult to maintain, especially in environments with numerous certificates. Option C: Set up AWS Security Hub. Turn on the AWS ...

Author: Maya2022 · Last updated Jun 27, 2026

A security team is responsible for reviewing AWS API call activity in the cloud environment for security violations. These events must be recorded and retained in a centralized location for both cu...

To meet the requirement of recording and retaining AWS API call activity for security review in a centralized location across both current and future AWS regions, let's analyze each option. Option A: Enable AWS Trusted Advisor security checks in the AWS Console, and report all security incidents for all regions. - Analysis: - AWS Trusted Advisor provides a set of best practice recommendations for security, cost optimization, fault tolerance, performance, and service limits. While Trusted Advisor can highlight some security concerns, it is not focused on recording API calls or providing detailed logs of AWS API call activity. - It doesn't offer a centralized logging solution for AWS API calls. Instead, it focuses more on guidance and alerts, which doesn't meet the requirement of capturing all API activity. Why rejected: Trusted Advisor is not designed for recording and retaining API call logs, and it does not provide detailed or comprehensive security audit logs. Option B: Enable AWS CloudTrail by creating individual trails for each region, and specify a single Amazon S3 bucket to receive log files for later analysis. - Analysis: - While CloudTrail does record API call activity, this option requires you to create individual trails for each region. This introduces additional management overhead as you would need to configure and maintain separate trails for each region, which could become cumbersome as new regions are added. - Moreover, managing individual trails for every region can lead to complexity and inconsistency in monitoring and analysis. Why rejected: This option is less efficient than having a centralized approach across all regions, leading to more management overhead. Option C: Enable AWS CloudTrail by creating a new trail and applying the t...

Author: Manish · Last updated Jun 27, 2026

A company is running an application on Amazon EC2 instances in an Auto Scaling group. The application stores logs locally. A security engineer noticed that logs were lost after a scale-in event. The security engineer needs to recommend a solution to ensure the durability and availability of ...

To address the issue of log data loss after a scale-in event and ensure the durability and availability of logs for at least one year, let’s analyze each option in detail. Option A: Within the Auto Scaling lifecycle, add a hook to create and attach an Amazon Elastic Block Store (Amazon EBS) log volume each time an EC2 instance is created. When the instance is terminated, the EBS volume can be reattached to another instance for log review. - Analysis: - This option involves creating a dedicated EBS volume for each instance in the Auto Scaling group. While this could prevent log loss during instance termination, it introduces complexity. The main issue is that if an instance is terminated, the log data is only retained on the EBS volume. This setup requires manually reattaching EBS volumes, which can be error-prone and doesn’t inherently provide long-term storage or durability. Also, if the instance is terminated without detaching the volume, the logs will be lost. - EBS volumes are not designed to be the most reliable long-term storage for logs in this case. A better approach would involve using services that are designed for log durability and availability. Why rejected: This solution introduces complexity and lacks the long-term durability required for logs, which is best achieved through managed services like CloudWatch or EFS. Option B: Create an Amazon Elastic File System (Amazon EFS) file system and add a command in the user data section of the Auto Scaling launch template to mount the EFS file system during EC2 instance creation. Configure a process on the instance to copy the logs once a day from an instance Amazon Elastic Block Store (Amazon EBS) volume to a directory in the EFS file system. - Analysis: - EFS provides a scalable and persistent file system that can be mounted across multiple EC2 instances. Using EFS ensures that logs are stored in a durable and highly available manner. This setup would prevent log loss during scale-in events and allow easy access to logs from any instance. - However, the added complexity here is the need for a manual process (copying logs daily from EBS to EFS), which might introduce potential failure points and isn’t fully automated. Additionally, while EFS is a reliable option, the extra step of copying logs daily might add overhead and is less efficient than a fully automated logging service. Why rejected: While EFS is a durable option, the added complexity of manually managing log copying could introduce potential points of failure and doesn’t fully address the need for automation and...

Author: Olivia · Last updated Jun 27, 2026

A company uses Amazon EC2 instances to host frontend services behind an Application Load Balancer. Amazon Elastic Block Store (Amazon EBS) volumes are attached to the EC2 instances. The company uses Amazon S3 buckets to store large files for images and music. The company has implemented a security architecture on AWS to prevent, identify, and isolate potential ransomware attacks. The company now wants to further reduce risk. A security engineer must develop a disaste...

In this scenario, the company is seeking a disaster recovery solution that meets a Recovery Point Objective (RPO) of 1 hour. The solution must ensure that if ransomware bypasses preventive and detective controls, the company can restore its operations promptly, potentially mitigating the damage caused by such an attack. Let's break down each option based on the criteria of RPO, automation, and the overall effectiveness for a disaster recovery strategy. A) Use AWS Backup to create backups of the EC2 instances and S3 buckets every hour. Create AWS CloudFormation templates that replicate existing architecture components. Use AWS CodeCommit to store the CloudFormation templates alongside application configuration code. - RPO Consideration: This solution creates hourly backups, which aligns with the 1-hour RPO requirement. - Automation: It automates backup creation, but it doesn't focus on rapid restoration or monitoring for security incidents like ransomware. - Key Features: - AWS Backup is great for creating periodic backups of EC2 instances and S3, but the recovery process (manual or with CloudFormation) could take longer than expected in a disaster scenario, especially for complex infrastructures. - Storing CloudFormation templates in CodeCommit ensures that you can replicate infrastructure, but doesn't guarantee quick recovery of the compromised data itself. - Why rejected: While it provides regular backups, it lacks a more focused and automated recovery mechanism for quick restoration during an attack like ransomware. B) Use AWS Backup to create backups of the EBS volumes and S3 objects every day. Use Amazon Security Lake to create a centralized data lake for AWS CloudTrail logs and VPC flow logs. Use the logs for automated response. - RPO Consideration: The daily backups are a significant gap for this scenario. The required RPO is 1 hour, and daily backups will lead to much higher data loss. - Automation: Using AWS Backup daily with Security Lake for log data analysis is good for monitoring and gathering information, but it does not address the need for quick recovery of data (e.g., from ransomware). - Why rejected: The daily backup schedule doesn't meet the 1-hour RPO. The focus on logs doesn't address the immediate recovery needs for data and infrastructure. C) Use Amazon Security Lake to crea...

Author: Joseph · Last updated Jun 27, 2026

A company has an application that runs on Amazon EC2 instances behind an Application Load Balancer (ALB). The instances are in an Amazon EC2 Auto Scaling group and are attached to Amazon Elastic Block Store (Amazon EBS) volumes. A security engineer needs to preserve all forens...

In this scenario, the goal is to preserve all forensic evidence from an EC2 instance for security or investigative purposes. The steps need to be arranged to ensure that the memory (RAM) and EBS volume data are preserved, and that the instance does not continue to change state after the evidence is collected. Let's evaluate the options one by one: A) Take an EBS volume snapshot of the instance and store the snapshot in an Amazon S3 bucket. Take a memory snapshot of the instance and store the snapshot in an S3 bucket. Detach the instance from the Auto Scaling group. Deregister the instance from the ALB. Stop the instance. - Order Issues: This option starts by taking an EBS snapshot before stopping the instance or detaching it from the Auto Scaling group. The problem is that the instance could continue to change state or receive traffic from the ALB while the snapshots are being taken, potentially altering the evidence. - Memory Snapshot: Memory snapshots need to be taken while the instance is still running, so this option does not preserve the memory state at the optimal time since it takes the EBS snapshot first. - Why rejected: The memory snapshot should be taken before stopping the instance, and stopping the instance too early could lead to losing relevant volatile memory data. B) Take a memory snapshot of the instance and store the snapshot in an Amazon S3 bucket. Stop the instance. Take an EBS volume snapshot of the instance and store the snapshot in an S3 bucket. Detach the instance from the Auto Scaling group. Deregister the instance from the ALB. - Correct Order: This option takes a memory snapshot first, preserving the volatile data before stopping the instance, which is the correct approach. - Post-Stop Actions: Stopping the instance before taking the EBS snapshot could lead to a potential loss of some in-memory data, as stopping the instance may impact how EBS snapshots capture the final state. - Why rejected: While it preserves memory first, the stopping of the instance before the EBS snapshot could lead to inconsistencies in the data, especially in case the EC2 instance writes any final data to disk upon shutdown. C) Detach the instance from the Auto Scaling group....

Author: Andrew · Last updated Jun 27, 2026

An application team wants to use AWS Certificate Manager (ACM) to request public certificates to ensure that data is secured in transit. The domains that are being used are not currently hosted on Amazon Route 53. The application team wants to use an AWS managed distribution and caching solution to optimize requests to its systems and provide better points of presence to customers. The distribution solution will use a primary domain name that is customized. The distribution solution also will use s...

Let's go through each option and reason out why it's selected or rejected, based on the needs of the application team: A) Request a certificate from ACM in the us-west-2 Region. Add the domain names that the certificate will secure. - Rejection Reason: AWS Certificate Manager (ACM) certificates need to be in the correct region for the service they are intended to work with. For CloudFront, the certificate must be issued in the us-east-1 region (N. Virginia) because CloudFront requires certificates from this region to be used globally. - Why rejected: ACM certificates requested in the us-west-2 region would not be compatible with CloudFront, which is required for this caching solution. B) Send an email message to the domain administrators to request validation of the domains for ACM. - Rejection Reason: Email validation is an option for validating ownership of domains when requesting an ACM certificate. However, this method is not the best fit in this scenario because it's typically more manual and requires coordination with the domain administrators. For automation and scalability, DNS validation is generally preferred. - Why rejected: This step is valid, but not as ideal as DNS validation for automating the process and ensuring indefinite renewal without manual intervention. C) Request validation of the domains for ACM through DNS. Insert CNAME records into each domain's DNS zone. - Selection Reason: DNS validation is a better choice in this scenario. Once DNS records are set, the validation process is automatic and can renew indefinitely without requiring manual steps. The application team can configure CNAME records in the DNS zones of their domains (even if not hosted on Route 53), which ensures that the domain ownership is validated efficiently. - Why selected: DNS validation is reliable, automated, and perfect for scenarios where ACM certificates need to renew automatically and without human intervention. D) Create an Application Load Balancer for the caching solution. Select the newly requested certificate from ACM to be used for secure connections. - Rejection Reason: While the Ap...

Author: Nia · Last updated Jun 27, 2026

A company's security engineer wants to receive an email alert whenever Amazon GuardDuty, AWS Identity and Access Management Access Analyzer, or Amazon Macie generate a high-severity security finding. The company uses AWS Control Tower to govern all of its accounts. The company also uses AWS Security Hub wit...

Let's evaluate each of the options based on the requirements of receiving an email alert whenever Amazon GuardDuty, AWS Identity and Access Management (IAM) Access Analyzer, or Amazon Macie generates a high-severity security finding. The goal is to minimize operational overhead while ensuring alerts are triggered for high-severity findings. A) Set up separate AWS Lambda functions for GuardDuty, IAM Access Analyzer, and Macie to call each service's public API to retrieve high-severity findings. Use Amazon Simple Notification Service (Amazon SNS) to send the email alerts. Create an Amazon EventBridge rule to invoke the functions on a schedule. - Rejection Reason: This solution involves creating and managing separate Lambda functions for each service and setting up an EventBridge rule to invoke those functions periodically. This approach would require significant manual configuration, handling multiple Lambda functions, and ongoing maintenance of each function. It would also introduce complexity and higher operational overhead due to managing multiple services and periodic invocations. - Why rejected: While functional, this approach is more complex and would require ongoing management of the Lambda functions and EventBridge rules, leading to unnecessary operational overhead. B) Create an Amazon EventBridge rule with a pattern that matches Security Hub findings events with high severity. Configure the rule to send the findings to a target Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the desired email addresses to the SNS topic. - Selection Reason: This is the most efficient solution with the least operational overhead. Since the company is already using AWS Security Hub with all service integrations enabled, Security Hub aggregates findings from GuardDuty, IAM Access Analyzer, and Macie. EventBridge can be configured to listen for Security Hub findings events (which include high-severity findings) and directly send them to an SNS topic. The email alerts can be sent by subscribing email addresses to the SNS topic. This solution requires minimal configuration and is highly automated. - Why selected: This solution leverages existing AWS Security Hub integrations and EventBridge, which simplifies the process of collecting and alerting on high-severity findings. It minimizes operational overhead because there’s no ...

Author: Leah · Last updated Jun 27, 2026

A company hosts an application on Amazon EC2 instances. The application also uses Amazon S3 and Amazon Simple Queue Service (Amazon SQS). The application is behind an Application Load Balancer (ALB) and scales with AWS Auto Scaling. The company's security policy requires the use of least privilege access, which has been applied to all existing AWS resources. A security enginee...

To meet the company's requirement of least privilege access and private connectivity to AWS services, let's evaluate the steps carefully: A) Use an interface VPC endpoint for Amazon SQS. - Selection Reason: An interface VPC endpoint allows private, secure communication with Amazon SQS without routing traffic over the public internet. This fits well with the need for private connectivity and least privilege access, ensuring that the application can interact with SQS directly within the VPC. - Why selected: Using an interface VPC endpoint ensures that traffic to Amazon SQS does not traverse the public internet, and it provides a secure and private connection. B) Configure a connection to Amazon S3 through AWS Transit Gateway. - Rejection Reason: While AWS Transit Gateway is useful for connecting multiple VPCs and managing inter-VPC traffic, it is not the ideal choice for connecting to Amazon S3 privately. Transit Gateway is generally more appropriate for complex network architectures involving multiple VPCs. For private connectivity to Amazon S3, using a gateway VPC endpoint is more suitable and simpler. - Why rejected: Transit Gateway is not necessary for establishing private connectivity to Amazon S3, and it adds unnecessary complexity. A gateway VPC endpoint is the more straightforward solution for this. C) Use a gateway VPC endpoint for Amazon S3. - Selection Reason: A gateway VPC endpoint is specifically designed for private access to Amazon S3 from resources in a VPC. It enables private connectivity to S3, avoiding the use of the public internet. This is the most efficient and secure way to ensure that the EC2 instances can access S3 without exposing traffic to the public internet. - Why selected: This option directly meets the requirement of private connectivity to Amazon S3, ensuring compliance with the security policy for least privilege access. D) Modify the IAM role applied to the EC2 instances in the Auto Scaling group to allow outbound traffic to the interface endpoints. - Rejection Reason: The IAM role applied to the EC2 instances should not allow broad outbound access to the interface endpoints. IAM policies should be restrictive and grant the least priv...

Author: Ahmed97 · Last updated Jun 27, 2026

A security analyst attempted to troubleshoot the monitoring of suspicious security group changes. The analyst was told that there is an Amazon CloudWatch alarm in place for these AWS CloudTrail log events. The analyst tested the monitoring setup by making a configuration change to the...

To troubleshoot why the analyst didn't receive alerts for security group changes, the primary issue could lie in how the monitoring, alerting, and configuration are set up in CloudWatch. Let's break down the options and assess them: A) Ensure that CloudTrail and S3 bucket access logging is enabled for the analyst's AWS account. - Reasoning: CloudTrail is responsible for capturing events such as security group changes, but enabling CloudTrail alone is not enough to trigger CloudWatch alarms. CloudWatch needs to be configured to monitor specific events in CloudTrail logs, so ensuring CloudTrail is enabled would not directly help with troubleshooting the alarm notification mechanism. - Why rejected: S3 bucket access logging is unrelated to the monitoring of CloudTrail log events. The problem is related to CloudWatch monitoring and alarm configuration, not S3 logging. - Scenario: This step is only necessary if CloudTrail isn't enabled, which doesn't seem to be the case here. B) Verify that a metric filter was created and then mapped to an alarm. Check the alarm notification action. - Reasoning: A metric filter is required in CloudWatch to search through CloudTrail logs for specific events, like security group changes. Once the filter is set up, it must be mapped to a CloudWatch alarm. Additionally, checking the alarm notification ensures that the alarm is set up to send notifications. This option directly addresses the problem, ensuring that the metric filter and alarm are correctly configured. - Why selected: This is the most relevant troubleshooting step. If the metric filter is missing or misconfigured, the CloudWatch alarm would not trigger. Also, verifying the alarm's notification action ensures the alert is set up to notify the analyst. - Scenario: This should be the first step if there's a failure to receive ...

Author: Vivaan · Last updated Jun 27, 2026

An Amazon API Gateway API invokes an AWS Lambda function that needs to interact with a software-as-a-service (SaaS) platform. A unique client token is generated in the SaaS platform to grant access to the Lambda function. A security engineer needs to design a solution to encrypt the access token at...

To determine the most cost-effective solution for securely encrypting and passing the access token to the Lambda function, we need to consider factors such as encryption at rest, ease of retrieval, cost efficiency, and security. Option Analysis: A) Store the client token as a secret in AWS Secrets Manager. Use the AWS SDK to retrieve the secret in the Lambda function. - Reasoning: AWS Secrets Manager is a managed service designed specifically for securely storing secrets like API keys, credentials, and tokens. It offers automatic rotation of secrets and integrates well with AWS Lambda. However, it incurs a higher cost compared to other options like Parameter Store. - Why rejected: While Secrets Manager is highly secure and suitable for managing sensitive data, it is more expensive than alternatives like Parameter Store. If cost-effectiveness is a priority, this option may not be the best choice. B) Configure a token-based Lambda authorizer in API Gateway. - Reasoning: A Lambda authorizer is used for authenticating API requests based on tokens (e.g., JWT). This would help in verifying the client token before allowing access to the Lambda function, but it is not a solution for securely storing or passing the client token to Lambda at runtime. - Why rejected: This option focuses on authorization and API request validation rather than securely storing and retrieving the client token for Lambda to use. It doesn't address the need to store and encrypt the token securely. C) Store the client token as a SecureString parameter in AWS Systems Manager Parameter Store. Use the AWS SDK to retrieve the value of the SecureString parameter in the Lambda function. - Reasoning: AWS Systems ...

Author: Elizabeth · Last updated Jun 27, 2026

A company is using an Amazon CloudFront distribution to deliver content from two origins. One origin is a dynamic application that is hosted on Amazon EC2 instances. The other origin is an Amazon S3 bucket for static assets. A security analysis shows that HTTPS responses from the application do not comply with a security requirement to provide an X-Frame-Options HTTP header to prevent frame-related cross-s...

To meet the security requirement of adding the `X-Frame-Options` HTTP header to the HTTPS responses from the application hosted on Amazon EC2 and delivered through CloudFront, the solution needs to ensure that this header is added in a secure and scalable manner. Let's analyze the options in detail. Option Analysis: A) Create a Lambda@Edge function. Include code to add the X-Frame-Options header to the response. Configure the function to run in response to the CloudFront origin response event. - Reasoning: Lambda@Edge allows you to run functions closer to the users to modify requests and responses as they pass through CloudFront. The origin response event is triggered when CloudFront receives a response from the origin (in this case, the EC2 application or S3 bucket). By using Lambda@Edge at the origin response event, the header can be added after CloudFront receives the response from the origin but before it sends the response back to the client. - Why selected: This solution will effectively add the missing `X-Frame-Options` header to the response for both EC2 and S3 origins, meeting the security requirement. Lambda@Edge functions run with minimal latency and can modify responses from the origin (EC2) or S3, making this a flexible and efficient solution. B) Create a Lambda@Edge function. Include code to add the X-Frame-Options header to the response. Configure the function to run in response to the CloudFront viewer request event. - Reasoning: The viewer request event happens when a request from the client (browser) reaches CloudFront but before it’s forwarded to the origin. Modifying the response headers at this point would not be effective, as the content hasn't been delivered from the origin yet. - Why rejected: This is not the right event for adding headers to a response. The `viewer request` event is too early in the request lifecycle for adding headers to the response, which...

Author: Vikram · Last updated Jun 27, 2026

An application has been built with Amazon EC2 instances that retrieve messages from Amazon SQS. Recently, IAM changes were made and the instances can no longer retrieve messages. What actions shou...

To troubleshoot the issue where EC2 instances can no longer retrieve messages from Amazon SQS due to recent IAM changes, it is essential to identify the root cause while maintaining the principle of least privilege. Let’s break down the options: Option Analysis: A) Configure and assign an MFA device to the role used by the instances. - Reasoning: Enabling Multi-Factor Authentication (MFA) for an IAM role does not directly address permissions issues related to SQS access. MFA is typically used for securing AWS Management Console access or API operations that require additional security layers. It does not help in resolving IAM policy or permissions problems for the EC2 instances retrieving SQS messages. - Why rejected: This step does not provide a relevant solution to the specific problem of retrieving messages from SQS and is unrelated to IAM permission settings in this case. B) Verify that the SQS resource policy does not explicitly deny access to the role used by the instances. - Reasoning: An explicit deny in the SQS resource policy would override any allow permissions in IAM roles. This is a critical step in troubleshooting because if the SQS queue’s resource policy includes an explicit deny for the role used by the EC2 instances, it would block access regardless of IAM permissions. - Why selected: This option helps ensure that the SQS queue policy isn’t causing the issue. If an explicit deny is found in the resource policy, it can directly resolve the issue by removing or modifying that deny. C) Verify that the access key attached to the role used by the instances is active. - Reasoning: While this is a good general troubleshooting step for access-related issues, it is not likely to be the root cause in this scenario. IAM roles used by EC2 instances typically do not rely on access keys directly, as the role itself assumes the necessary permissions au...

Author: Isabella1 · Last updated Jun 27, 2026

A company has an AWS Key Management Service (AWS KMS) customer managed key with imported key material. Company policy requires all encryption keys to be rotated every year. What shoul...

To meet the company policy of rotating encryption keys every year for a customer-managed key in AWS Key Management Service (KMS), let's analyze each option based on the AWS KMS key rotation features and the company's requirements. Option Analysis: A) Enable automatic key rotation annually for the existing customer managed key. - Reasoning: AWS KMS allows automatic key rotation for customer-managed keys (CMKs) that use KMS-generated key material. However, automatic key rotation is not supported for keys with imported key material. When using imported key material, the key material is not generated by AWS, and thus AWS cannot automatically rotate the key. - Why rejected: This option would work if the key material were KMS-generated, but since the company uses imported key material, automatic key rotation is not supported for this type of key. B) Use the AWS CLI to create an AWS Lambda function to rotate the existing customer managed key annually. - Reasoning: While you could theoretically automate key rotation using Lambda functions with AWS CLI commands, this solution is unnecessary and overly complex. AWS KMS does not natively support automatic rotation for imported key material, so creating a Lambda function for key rotation would still require manual intervention to import new key material. This is not a simple or efficient solution, and AWS provides better options for rotating imported key material. - Why rejected: This approach adds unnecessary complexity without leveraging native AWS features for key management. C) Import new key material to the existing customer...

Author: IceDragon2023 · Last updated Jun 27, 2026

A healthcare company has multiple AWS accounts in an organization in AWS Organizations. The company uses Amazon S3 buckets to store sensitive information of patients. The company needs to restrict users from deleting any S3 bu...

To address the need of restricting users from deleting any S3 bucket across multiple AWS accounts in an AWS Organization, the most scalable and effective solution must apply restrictions at the organizational level while being adaptable across multiple accounts. Let's analyze each option: A) Permissions boundaries in AWS Identity and Access Management (IAM) Explanation: Permissions boundaries are a mechanism for limiting the permissions that a user or role can have in IAM. They define the maximum permissions a principal can have, but they cannot enforce specific rules like preventing deletion of S3 buckets in a cross-account setup directly. This option would not be ideal for enforcing a cross-account restriction such as preventing the deletion of S3 buckets in multiple accounts in an organization. Reason for rejection: Permissions boundaries are limited to controlling what permissions a principal (user or role) can be granted, but they cannot globally prevent actions (like S3 bucket deletion) across all accounts in an organization. Suitable Scenario: Permissions boundaries could be used in specific scenarios where an IAM principal's permissions need to be restricted for particular actions within one account, but not for organization-wide actions. --- B) S3 bucket policies Explanation: S3 bucket policies can be applied to individual buckets to control access. You could create a policy that denies the `s3:DeleteBucket` action. However, this would need to be configured for each S3 bucket, and would not automatically apply to new buckets or across all accounts unless managed carefully. Reason for rejection: S3 bucket policies only affect the specific bucket where the policy is applied. They do not provide a scalable solution for enforcing restrictions across all buckets or accounts, especially in an organization with multiple AWS accounts. Suitable Scenario: S3 bucket policies are useful for controlling access to specific buckets and ensuring compliance on a per-bucket basis, but are not scalable across an entire organization with many ...

Author: Ravi Patel · Last updated Jun 27, 2026

A company needs to detect unauthenticated access to its Amazon Elastic Kubernetes Service (Amazon EKS) clusters. The company needs a solution that requires no additional configuration of the existing EKS dep...

To detect unauthenticated access to Amazon Elastic Kubernetes Service (EKS) clusters with the least operational effort, the solution needs to be scalable, minimize the need for additional configuration, and integrate with existing AWS services without requiring custom setup for the EKS deployment. Let’s evaluate each option in terms of meeting these criteria: A) Install an Amazon EKS add-on from a security vendor Explanation: Installing an EKS add-on from a third-party security vendor could provide additional security features and monitoring, such as detecting unauthenticated access. However, this typically requires additional configuration and management of the add-on, which adds operational complexity. Furthermore, you would need to ensure the add-on integrates well with your current EKS deployment. Reason for rejection: While this solution could provide specific security benefits, it involves external dependencies and requires additional configuration and ongoing management, which contradicts the need for minimal operational effort. Suitable Scenario: This option is best when you need specific security features that aren’t natively available in AWS, and you are comfortable with the added configuration and operational effort. --- B) Enable AWS Security Hub. Monitor the Kubernetes findings Explanation: AWS Security Hub provides centralized security monitoring, but it primarily focuses on gathering and analyzing findings from other AWS services, such as Amazon GuardDuty, Amazon Inspector, and more. While it offers security visibility across AWS accounts and regions, it doesn't directly detect unauthenticated access to EKS clusters. Reason for rejection: Although AWS Security Hub is valuable for overall security posture monitoring, it doesn't directly address the need for detecting unauthenticated access to EKS clusters without additional configuration, such as enabling GuardDuty or other services for more specific monitoring. Suitable Scenario: Security Hub is effective for organizations that want a central place to view security findings, but it is not a targeted solution for detecting unauthenticated access in EKS without additional configuration. --- C) Monitor Amazon CloudWatch Container Insights metrics for Amazon EKS Explanation: CloudWatch C...

Author: Benjamin · Last updated Jun 27, 2026

A security engineer is investigating a malware infection that has spread across a set of Amazon EC2 instances. A key indicator of the compromise is outbound traffic on TCP port 2905 to a set of command and control hosts on the internet. The security engineer creates a network ACL rule that denies the identified outbound traffic. The security engineer applies the network ACL rule to the subnet of the EC2 instances. The securi...

To identify which EC2 instances are attempting to communicate on TCP port 2905 with the least operational effort, we need to focus on minimizing configuration complexity and operational overhead while effectively detecting the malicious traffic. Let's evaluate each option: A) Create a Network Access Scope in Amazon VPC Network Access Analyzer. Use the Network Access Scope to identify EC2 instances that try to send traffic to TCP port 2905. Explanation: Amazon VPC Network Access Analyzer is a tool for evaluating network access to resources in a VPC, helping to identify traffic flows between resources. However, it is primarily used for evaluating network paths and identifying misconfigurations in access, such as overly permissive security groups or network ACLs. It is not designed for identifying specific traffic patterns or for directly detecting traffic on specific ports like 2905. Reason for rejection: While Network Access Analyzer is useful for auditing VPC access configurations, it does not directly track or identify outbound traffic on specific ports such as TCP port 2905, which is needed in this case. Suitable Scenario: This would be useful for investigating VPC access issues or security group misconfigurations, but not for identifying malicious traffic targeting specific ports. --- B) Enable VPC flow logs for the VPC where the affected EC2 instances are located. Configure the flow logs to capture rejected traffic. In the flow logs, search for REJECT records that have a destination TCP port of 2905. Explanation: VPC Flow Logs can capture detailed information about the traffic flowing to and from network interfaces in a VPC, including the source and destination IP, port, and the action (ACCEPT/REJECT). By enabling VPC flow logs and configuring them to capture rejected traffic, you can specifically track denied traffic on TCP port 2905, which directly helps identify the EC2 instances attempting to communicate with the command and control servers. Reason for selection: VPC Flow Logs is a native AWS service that requires minimal additional configuration and operational effort. By filtering rejected traffic based on the destination port, you can quickly identify the EC2 instances involved in the suspicious communication. This solution efficiently meets the requirement with little additional effort. Suitable Scenario: VPC Flow Logs are ideal when you want to analyze network traffic for security incidents with minimal setup. It is especially useful in identifying blocked or denied traffic, making it perfect for this use case. --- C) Enable Amazon GuardDuty. Create a custom GuardDuty IP list to create a finding when an EC2 instance tries to communicate with one of the command and control hosts. Use Amazon Detective to identify the EC2 instances that initiate the communication. Explanation: Amazon GuardDuty is a threat detection service that monitors AWS accounts for malicious activity. You ca...

Author: SolarFalcon11 · Last updated Jun 27, 2026

A security engineer uses Amazon Macie to scan a company's Amazon S3 buckets for sensitive data. The company has many S3 buckets and many objects stored in the S3 buckets. The security engineer must identify S3 buckets that contain sensitive data and must perform additional...

The goal is to identify S3 buckets containing sensitive data and perform additional scanning on those buckets with the least administrative overhead. Let’s evaluate each option and determine the most efficient and manageable solution: A) Configure S3 Cross-Region Replication (CRR) on the S3 buckets to replicate the objects to a second AWS Region. Configure Macie in the second Region to scan the replicated objects daily. Explanation: This option would involve setting up S3 Cross-Region Replication (CRR) to replicate the objects to another AWS Region. Then, Macie would scan the replicated data in the second region. This solution introduces unnecessary complexity by creating cross-region replication and managing the replicated data, which can increase both administrative overhead and cost. The sensitivity of the data could also create challenges regarding data residency and compliance requirements. Reason for rejection: This option is not optimal because of the added complexity of managing replication across regions, unnecessary duplication of data, and the overhead of managing multiple AWS Regions. There is no need for replication to scan the data with Macie. Suitable Scenario: This could be used in scenarios where data needs to be replicated for disaster recovery or compliance, but it adds unnecessary steps in the context of just scanning S3 buckets for sensitive data. --- B) Create an AWS Lambda function as an S3 event destination for the S3 buckets. Configure the Lambda function to start a Macie scan of an object when the object is uploaded to an S3 bucket. Explanation: This option involves setting up an AWS Lambda function to trigger a Macie scan each time a new object is uploaded to an S3 bucket. While this could work, it introduces the overhead of creating and managing Lambda functions, which might not be necessary for the use case of scanning all objects in a bucket. Additionally, Lambda could only initiate scans when new objects are added, potentially missing scans for existing objects and requiring a manual process to handle the entire bucket's contents. Reason for rejection: While this solution could trigger scanning of new objects, it does not cover existing data and introduces more complexity through Lambda functions. It also requires continual management of Lambda and event triggers. Suitable Scenario: This approach might be effective if you want to monitor real-time data uploads, but it is not ideal for scanning existing data across many S3 buckets. --- C) Configure Macie automated discovery to continuously sample data from the S3 buc...

Author: Max · Last updated Jun 27, 2026