Amazon Practice Questions, Discussions & Exam Topics by our Authors

A company has a new partnership with a vendor. The vendor will process data from the company's customers. The company will upload data files as objects into an Amazon S3 bucket. The vendor will download the objects to perform data processing. The objects will contain sensitive data. A security engineer must implemen...

To meet the requirement of preventing sensitive data objects from residing in the Amazon S3 bucket for longer than 72 hours, the solution needs to ensure that the objects are automatically removed after the specified time period. Let's evaluate each option: A) Use Amazon Macie to scan the S3 bucket for sensitive data every 72 hours. Configure Macie to delete the objects that contain sensitive data when they are discovered. - Explanation: Amazon Macie is a data security and privacy service that helps identify and protect sensitive data in AWS. However, Macie primarily focuses on discovering and classifying sensitive data, not on automating the deletion of objects based on their age. While Macie can help identify sensitive data, it doesn't automatically manage object expiration based on their age or enforce a retention policy like this. - Reasoning: This option is not suitable for this scenario because Macie’s purpose is not to delete objects based on their age. It’s designed for data discovery and classification, not lifecycle management. B) Configure an S3 Lifecycle rule on the S3 bucket to expire objects that have been in the S3 bucket for 72 hours. - Explanation: Amazon S3 Lifecycle policies allow automatic management of objects in a bucket based on age, transition, or expiration. You can create a lifecycle rule to automatically delete objects that have been in the S3 bucket for more than 72 hours. This is a built-in feature of S3 and is designed for exactly this type of use case. - Reasoning: This solution directly meets the requirement. S3 Lifecycle rules are ideal for expiring objects after a specified time period, ensuring that sensitive data does not remain in the bucket longer than required. - Use Case: This is the most efficient and cost-effective solution for managing object expiration in S3. C) Create an Amazon EventBridge sch...

Author: Zara · Last updated Aug 14, 2026

A company accidentally deleted the private key for an Amazon Elastic Block Store (Amazon EBS)-backed Amazon EC2 instance. A security engineer needs to regain access to the ins...

To regain access to an Amazon EC2 instance that is EBS-backed and has lost its private key, we need to perform actions that allow the security engineer to access the instance's file system and modify its configurations (such as updating the `authorized_keys` file with a new public key). Here's the analysis of each option: Option A: Stop the instance. Detach the root volume. Generate a new key pair. - Explanation: This option involves stopping the instance, detaching the root volume, generating a new key pair, and likely using the new key to access the instance. - Rejected Reason: Detaching the root volume would require you to use another instance to modify the authorized keys file, and generating a new key pair alone does not provide a clear method to regain access to the EC2 instance. The new key would not automatically work unless the `authorized_keys` file is updated. It leaves out necessary steps for modifying the instance's file system. Option B: Keep the instance running. Detach the root volume. Generate a new key pair. - Explanation: Keeping the instance running while detaching the root volume is risky, as it may cause the instance to become inaccessible without the root volume. Moreover, like Option A, generating a new key pair alone doesn't solve the problem unless the instance's `authorized_keys` file is updated with a new public key. - Rejected Reason: Detaching the root volume while the instance is running will likely lead to a problem where the instance can no longer boot, as the root volume is essential for running the instance. This step can break the instance, and generating a new key pair does not resolve the access issue directly. Option C: When the volume is detached from the original instance, attach the volume to another instance as a data volume. Modify the authorized_keys file with a new public key. Move the volume back to the original instance. Start the instance. - Explanation: This option allows you to detach the root volume from the original instance and attach it to another EC2 instance as a data volume. You can then modify the `authorized_keys` f...

Author: Matthew · Last updated Aug 14, 2026

A company purchased a subscription to a third-party cloud security scanning solution that integrates with AWS Security Hub. A security engineer needs to implement a solution that will remediate the findings from ...

To automatically remediate findings from a third-party cloud security scanning solution integrated with AWS Security Hub, we need to use an automation approach that reacts to findings in Security Hub and performs actions to resolve them. Here's a breakdown of each option: Option A: Set up an Amazon EventBridge rule that reacts to new Security Hub findings. Configure an AWS Lambda function as the target for the rule to remediate the findings. - Explanation: This approach involves setting up an Amazon EventBridge rule to listen for Security Hub findings, and then using AWS Lambda to automatically remediate the findings. - Selected Reason: This option is a valid solution because Amazon EventBridge allows you to react to specific findings in Security Hub, and AWS Lambda can be used to perform the remediation actions (e.g., patching, stopping malicious activities, changing configurations). EventBridge provides fine-grained control over event handling, making it an excellent choice for automated remediation. Option B: Set up a custom action in Security Hub. Configure the custom action to call AWS Systems Manager Automation runbooks to remediate the findings. - Explanation: This option sets up a custom action in Security Hub that can trigger AWS Systems Manager Automation runbooks, which are predefined workflows to automate operational tasks. - Rejected Reason: While this option can trigger automated actions, the custom action approach requires manual intervention to activate the action. It is not fully automated, as you must initiate the custom action manually from within Secur...

Author: FlamePhoenix2025 · Last updated Aug 14, 2026

An application is running on an Amazon EC2 instance that has an IAM role attached. The IAM role provides access to an AWS Key Management Service (AWS KMS) customer managed key and an Amazon S3 bucket. The key is used to access 2 TB of sensitive data that is stored in the S3 bucket. A security engineer discovers a potential vulnerability on the EC2 instance that could result in the compromise of the sensitive data. Due to other crit...

The goal is to prevent the sensitive data from being exposed on the EC2 instance due to a potential vulnerability while maintaining operational continuity for other critical tasks. We need to act quickly to ensure the security of the data without shutting down the instance. Option A: Download the data from the existing S3 bucket to a new EC2 instance. Then delete the data from the S3 bucket. Re-encrypt the data with a client-based key. Upload the data to a new S3 bucket. - Explanation: This option involves manually moving the data and re-encrypting it with a new client-based key. - Rejected Reason: While effective, this is not the fastest option. It involves multiple steps: downloading data, re-encrypting, and uploading to a new bucket. Given the 2 TB of sensitive data, this could take a significant amount of time and is not a rapid response to the immediate security concern. Option B: Block access to the public range of S3 endpoint IP addresses by using a host-based firewall. Ensure that internet-bound traffic from the affected EC2 instance is routed through the host-based firewall. - Explanation: This option involves using a firewall to block outbound traffic from the EC2 instance, which would prevent access to the S3 bucket. - Rejected Reason: This is not an optimal solution. It only addresses one aspect (public access), and it doesn't directly impact the security of the sensitive data stored in the S3 bucket or address the potential vulnerability on the EC2 instance itself. It does not prevent the EC2 instance from accessing the sensitive data if the attacker exploits the vulnerability. Option C: Revoke the IAM role's active sessi...

Author: Deepak · Last updated Aug 14, 2026

A company is building an application on AWS that will store sensitive information. The company has a support team with access to the IT infrastructure, including databases. The company's security engineer must introduce measures to protect the sensitive data against any data breach whi...

The goal is to protect sensitive information in a way that minimizes management overhead while ensuring the security of the credentials through regular rotation. The options vary in terms of encryption methods, credential management, and the use of services such as AWS RDS, EC2, Secrets Manager, and Systems Manager. Let's break down the options: Option A: Enable Amazon RDS encryption to encrypt the database and snapshots. Enable Amazon Elastic Block Store (Amazon EBS) encryption on Amazon EC2 instances. Include the database credential in the EC2 user data field. Use an AWS Lambda function to rotate database credentials. Set up TLS for the connection to the database. - Explanation: This option includes enabling RDS encryption, EBS encryption, and TLS. However, it suggests storing the database credential in the EC2 user data field, which is insecure and not recommended for sensitive data. The credential should not be stored in the user data field because it could be exposed to anyone with access to the EC2 instance metadata. - Rejected Reason: Storing credentials in EC2 user data poses a security risk. Even though the Lambda function can rotate credentials, using the EC2 user data for storage contradicts best practices for credential management. Option B: Install a database on an Amazon EC2 instance. Enable third-party disk encryption to encrypt the Amazon Elastic Block Store (Amazon EBS) volume. Store the database credentials in AWS CloudHSM with automatic rotation. Set up TLS for the connection to the database. - Explanation: This option uses EC2 for hosting the database and encrypts the EBS volume with third-party encryption, while storing credentials in AWS CloudHSM, which provides hardware-based security for secrets. However, managing database credentials and rotating them manually through CloudHSM requires significant overhead and is more complex compared to other AWS services designed specifically for this purpose. - Rejected Reason: While CloudHSM provides secure key management, it’s more complex to manage, especially for credential rotation. CloudHSM is typically used for cryptographic operations rather than storing and rotating application credentials. Using a solution like AWS Secrets Manager is much simpler and integrates well with automatic credential rotation. Option C: Enable Amazon RDS encryption to encrypt the datab...

Author: RadiantJaguar56 · Last updated Aug 14, 2026

A company is using Amazon Route 53 Resolver for its hybrid DNS infrastructure. The company has set up Route 53 Resolver forwarding rules for authoritative domains that are hosted on on-premises DNS servers. A new security mandate requires the company to implement a solution to log and query DNS traffic that goes to the on-premises DNS servers. The logs must show details of the source IP address o...

To meet the security mandate for logging and querying DNS traffic to on-premises DNS servers, the solution must log DNS queries, including the source IP address and the requested DNS names, while providing a way to run queries on these logs. Let's review each option: Option A: Use VPC Traffic Mirroring. Configure all relevant elastic network interfaces as the traffic source, include amazon-dns in the mirror filter, and set Amazon CloudWatch Logs as the mirror target. Use CloudWatch Insights on the mirror session logs to run queries on the source IP address and DNS name. - Explanation: This option uses VPC Traffic Mirroring, which can capture network traffic, including DNS queries, and send it to CloudWatch Logs. CloudWatch Insights can then be used to query the logs. - Rejected Reason: While VPC Traffic Mirroring can capture DNS traffic, it's generally more suitable for debugging or detailed network traffic analysis rather than specifically logging DNS queries. Also, this method does not directly provide a solution tailored for logging DNS queries at the DNS service level, which is the requirement here. It would involve more complexity and overhead than necessary for logging DNS queries to on-premises servers. Option B: Configure VPC flow logs on all relevant VPCs. Send the logs to an Amazon S3 bucket. Use Amazon Athena to run SQL queries on the source IP address and DNS name. - Explanation: VPC flow logs can capture information about the IP traffic in your VPCs, but they don't specifically capture DNS query details, such as the DNS names being requested. The flow logs capture metadata like source IP, destination IP, and traffic type but not the actual DNS queries. - Rejected Reason: VPC flow logs do not capture the DNS query content or the specific DNS names being requested. This option would not meet the requirement to log the DNS name requested by Route 53 Resolver. Option C: Configure Route 53 Resolver query logging on all relevant VPCs. Send the logs to Amaz...

Author: Andrew · Last updated Aug 14, 2026

A security engineer is configuring account-based access control (ABAC) to allow only specific principals to put objects into an Amazon S3 bucket. The principals already have access to Amazon S3. The security engineer needs to configure a bucket policy that allows principals to put objects into the S3 bucket only if the value of the Team tag on the object matches the value of the Team tag that is associated with the principal. During testing, the security engineer notices that a pr...

Let's go through the options one by one, focusing on the key factors in the context of ABAC (Attribute-Based Access Control) and S3 bucket policies, and the specific scenario where the tag values do not match: A) The principal's identity-based policy grants access to put objects into the S3 bucket with no conditions. - Explanation: Identity-based policies are attached directly to the principal (user/role) and specify the actions that the principal can perform. If the identity-based policy has a statement that allows the `s3:PutObject` action with no conditions, this will grant access to the principal without considering any tags. - Rejection: This option doesn't address the mismatch of tag values directly, but rather points to the fact that the principal might have an unrestricted permission to perform `PutObject` on the S3 bucket, regardless of the tag condition. B) The principal's identity-based policy overrides the condition because the identity-based policy contains an explicit allow. - Explanation: Identity-based policies can override resource-based policies if they explicitly allow the action. This could explain why the principal can still perform the `PutObject` action even though the bucket policy includes a condition related to tags. - Rejection: While it's true that an explicit "Allow" in the identity-based policy can override a resource-based policy's restrictions, this is more likely the case if the identity-based policy allows the `PutObject` operation with no conditions or conflicts with the tag-based condition in the bucket policy. C) The S3 bucket's resource policy does not deny access to put objects. - Explanation: If the S3 bucket policy doesn’t include a `Deny` statement for the `PutObject` action with the tag conditio...

Author: Noah · Last updated Aug 14, 2026

A company is hosting multiple applications within a single VPC in its AWS account. The applications are running behind an Application Load Balancer that is associated with an AWS WAF web ACL. The company's security team has identified that multiple port scans are originating from a specific range of IP addresses on t...

Let's review each option carefully, taking into account the scenario where the security engineer needs to deny access from a specific range of IP addresses that are originating port scans: A) Modify the AWS WAF web ACL with an IP set match rule statement to deny incoming requests from the IP address range. - Explanation: The AWS WAF provides an IP set match rule that allows you to block traffic from specific IP addresses or IP address ranges. This would work perfectly in this case because the security team has already identified the offending IP addresses. Using an IP set rule in the AWS WAF will effectively block traffic from these IPs at the web application level. - Why this is selected: This approach directly addresses the requirement to deny access from specific IPs. The WAF rule can be configured to specifically block the offending IP range, and since the Application Load Balancer is already associated with an AWS WAF web ACL, this solution integrates seamlessly into the existing infrastructure. B) Add a rule to all security groups to deny the incoming requests from the IP address range. - Explanation: Security groups in AWS are stateful and operate at the instance level. Security groups do not allow for an explicit Deny rule (only an Allow rule can be configured). Therefore, while you could modify security group rules to allow only specific IP addresses and implicitly block others, you cannot directly create a Deny rule for the identified IP range. - Why this is rejected: Security groups are not designed to explicitly deny traffic. Additionally, modifying security groups on all instances might require significant changes across multiple applications and could lead to unintended disruptions. C) Modify the AWS WAF web ACL with a ra...

Author: IronLion88 · Last updated Aug 14, 2026

A company has contracted with a third party to audit several AWS accounts. To enable the audit, cross-account IAM roles have been created in each account targeted for audit. The auditor is having trouble accessing ...

Let's go through each option step by step to determine the most likely causes for the auditor having trouble accessing some AWS accounts: A) The external ID used by the auditor is missing or incorrect. - Explanation: When using cross-account IAM roles, an external ID is often used as an added layer of security to prevent the "confused deputy" problem. The external ID is provided by the trusting (destination) account and must be used correctly by the auditor when assuming the role. If the external ID is missing or incorrect, the auditor won't be able to assume the role, resulting in access issues. - Why this is selected: This is a common problem in cross-account IAM role scenarios. If the external ID is missing or incorrect, the auditor won't be able to successfully assume the role and access the resources in the target account. B) The auditor is using the incorrect password. - Explanation: The auditor is trying to assume a role using IAM, which doesn't typically involve password-based authentication. Role assumption is done using IAM policies and temporary security credentials, not by logging in with a username and password. - Why this is rejected: This option is not relevant in the context of cross-account role assumption. The issue is not about passwords but about assuming a cross-account role using IAM policies. C) The auditor has not been granted `sts:AssumeRole` for the role in the destination account. - Explanation: In order for the auditor to assume a cross-account role, they must be explicitly granted the `sts:AssumeRole` permission for that role in the destination account. If the IAM policy associated with the auditor's role or user doesn't grant this permission, the auditor will not be able to assume the role. - Why this is selected: This is a very likely cause for the access issues. If the auditor does not have the required permission (`sts:AssumeRole`), they will not be able to access the target account,...

Author: CrimsonViperX · Last updated Aug 14, 2026

A security engineer needs to configure an Amazon S3 bucket policy to restrict access to an S3 bucket that is named DOC-EXAMPLE-BUCKET. The policy must allow access to only DOC-EXAMPLE-BUCKET from only the following endpoint: vpce-1a2b3c4d. The policy must deny all access t...

Author: Sofia · Last updated Aug 14, 2026

A company has a group of Amazon EC2 instances in a single private subnet of a VPC with no internet gateway attached. A security engineer has installed the Amazon CloudWatch agent on all instances in that subnet to capture logs from a specific application. To ensure that the logs flow securely, the company's networking team has created VPC endpoints for CloudWatch monitoring and CloudWatch logs. The networking team has attached the endpoints to the VPC. The application i...

To troubleshoot the issue of logs not appearing in CloudWatch despite the EC2 instances being in a private subnet with VPC endpoints for CloudWatch monitoring and CloudWatch logs, let's carefully evaluate each of the troubleshooting steps: A) Ensure that the EC2 instance profile that is attached to the EC2 instances has permissions to create log streams and write logs. - Explanation: The EC2 instance profile (IAM role) attached to the EC2 instances must have the necessary permissions to interact with CloudWatch logs, including the ability to create log streams and write log data. If the instance profile doesn't have these permissions, the CloudWatch agent won't be able to send logs to CloudWatch. - Why this is selected: This is a critical permission check. If the EC2 instances can't interact with CloudWatch due to a missing permission, the logs won't be transmitted. This is the first thing to verify because proper IAM permissions are required to send logs to CloudWatch. B) Create a metric filter on the logs so that they can be viewed in the AWS Management Console. - Explanation: Metric filters are used to create CloudWatch metrics based on log data. While this is useful for creating metrics from logs, it does not directly address the issue of logs not appearing in CloudWatch. The logs must first be successfully sent to CloudWatch before they can be processed into metrics. - Why this is rejected: This step is not relevant for the current issue, which is that logs are not appearing in CloudWatch in the first place. Metric filters come into play after the logs are successfully ingested by CloudWatch. C) Check the CloudWatch agent configuration file on each EC2 instance to make sure that the CloudWatch agent is collecting the proper log files. - Explanation: The CloudWatch agent must be correctly configured to collect the intended log files. If the configuration file is misconfigured or the wrong log files are being specified, the logs won't be collected and sent to CloudWatch. - Why this is selected: If the CloudWatch agent is not correctly configured to capture the logs, the logs will not be sent to CloudWatch. This is a key troubleshooting step to ensure that the correct log files are being collected. D) Check the VPC endpoint policies of both VPC endpoin...

Author: Stella · Last updated Aug 14, 2026

A company uses AWS Signer with all of the company's AWS Lambda functions. A developer recently stopped working for the company. The company wants to ensure that all the code that the developer wrote can no ...

The goal here is to ensure that the code written by the developer can no longer be deployed to the Lambda functions. Let's analyze each option in detail: A) Revoke all versions of the signing profile assigned to the developer - Explanation: AWS Signer uses signing profiles to ensure the integrity and authenticity of Lambda functions. If the developer has access to a signing profile and the code is signed using that profile, revoking all versions associated with that profile would ensure that no further deployment of that code is possible, as the code would no longer pass the verification step in AWS Signer. - Reasoning: Since the issue revolves around ensuring that the developer’s code can’t be deployed, revoking the signing profile versions associated with them directly addresses this. This effectively prevents the code from being redeployed if it's signed using that specific profile. B) Examine the developer's IAM roles. Remove all permissions that grant access to Signer. - Explanation: IAM roles grant permissions to interact with AWS services, including AWS Signer. By removing the developer's permissions to Signer, the developer would be unable to sign new Lambda function versions. However, this doesn’t address the code already signed by the developer that is already deployed. - Reasoning: This is a step toward ensuring that the developer can no longer sign or deploy code in the future but does not impact the previously deployed Lambda functions signed by the developer. It on...

Author: RadiantPhoenixX · Last updated Aug 14, 2026

A company plans to use AWS Key Management Service (AWS KMS) to implement an encryption strategy to protect data at rest. The company requires client-side encryption for company projects. The company is currently conducting multiple projects to test the company's use of AWS KMS. These tests have led to a sudden increase in the company's AWS resource consumption. The test projects include applications that issue multiple requests each second to KMS endpoints for encryption activities. The company needs t...

Let's analyze the options based on the requirements: preventing throttling, improving key usage for client-side encryption, and optimizing costs. A) Use keyrings with the AWS Encryption SDK. Use each keyring individually or combine keyrings into a multi-keyring. Decrypt the data by using a keyring that has the primary key in the multi-keyring. - Explanation: Keyrings in the AWS Encryption SDK allow for multiple encryption keys to be used to wrap or encrypt the data. Using a multi-keyring helps with flexibility, allowing different wrapping keys for the encryption process. However, it is primarily designed for the encryption part, not directly addressing the issue of throttling or caching to optimize client-side encryption performance. - Reasoning: While keyrings are useful for managing multiple encryption keys, this option doesn’t directly address reducing the load on KMS endpoints or improve key usage in a way that optimizes performance under high request rates. It's more about flexibility in key management than resource optimization or caching to avoid throttling. B) Use data key caching. Use the local cache that the AWS Encryption SDK provides with a caching cryptographic materials manager. - Explanation: Data key caching allows the encryption SDK to cache the data encryption keys locally after they are fetched from KMS. This reduces the need to repeatedly call KMS for the same encryption key, which can significantly lower the number of KMS API requests and mitigate throttling. The cached keys can be reused for a period before refreshing, which is ideal for reducing both cost and the risk of hitting rate limits. - Reasoning: This option directly addresses the problem of throttling by reducing the number of calls to KMS for the same data key, leading to better key usage, cost optimization, and avoidance of throttling due to frequent KMS requests. ...

Author: Isabella · Last updated Aug 14, 2026

A security team is working on a solution that will use Amazon EventBridge to monitor new Amazon S3 objects. The solution will monitor for public access and for changes to any S3 bucket policy or setting that result in public access. The security team configures EventBridge to watch for specific API calls that are logged from AWS CloudTrail. EventBridge has an action to send an email notification through Amazon Simple Notification Service (Amazon SNS) to the security team immediately with details of the API call. Specifically, the security team wants EventBridge to watch for the s3:PutObjectAcl, s3:DeleteBucketPolicy, and s3:PutBucketPolicy API invocation logs from CloudTrail. While developing the solution in a single account, the security team discovers that the s3:PutObjectAcl API call does not invoke an EventBridge event However, the s3:DeleteBucketPolicy API call and the s3:PutBucketPolicy API call do invoke an event. The security team has enabled CloudTra...

To solve the issue where the s3:PutObjectAcl API call is not invoking an EventBridge event, we need to address how CloudTrail is logging API events and how EventBridge is listening to those events. Let's review each option in detail: A) Modify the EventBridge event pattern by selecting Amazon S3. Select All Events as the event type. - Explanation: By selecting All Events as the event type, the EventBridge pattern would capture all S3-related events, including read, write, and ACL operations. This broad selection will include the s3:PutObjectAcl event. - Reasoning: This option is effective because it allows EventBridge to capture a wider range of S3 events, including the s3:PutObjectAcl API call. However, this approach might generate false notifications for a variety of other S3 events that are not relevant to the security team’s monitoring needs. While it ensures the event is captured, it doesn't guarantee the level of granularity needed to avoid unwanted notifications. B) Modify the EventBridge event pattern by selecting Amazon S3. Select Bucket Level Operations as the event type. - Explanation: By selecting Bucket Level Operations, the event pattern would only capture events related to S3 bucket configurations, such as changes to bucket policies and permissions, not individual object-level changes (like the s3:PutObjectAcl event). - Reasoning: This option is not suitable because the s3:PutObjectAcl is an object-level operation (not a bucket-level operation), and therefore, it will not be captured by the "Bucket Level Operations" event type. This option would work for the other API calls (like s3:DeleteBucketPolicy and s3:PutBucketPolicy) but not for s3:PutObjectAcl. C) Enable CloudTrail Insights to i...

Author: Sophia Clark · Last updated Aug 14, 2026

A company uses Amazon GuardDuty. The company's security team wants all High severity findings to automatically generate a ticket in a third-party ticketing system t...

Let's break down each option and see which one would best meet the requirement to automatically generate a ticket in the third-party ticketing system when High severity findings are detected by Amazon GuardDuty. A) Create a verified identity for the third-party ticketing email system in Amazon Simple Email Service (Amazon SES). Create an Amazon EventBridge rule that includes an event pattern that matches High severity GuardDuty findings. Specify the SES identity as the target for the EventBridge rule. - Explanation: This option involves using Amazon SES (Simple Email Service) to send an email to the third-party ticketing system. EventBridge will capture the GuardDuty findings, and SES will send an email based on those findings. - Reasoning: While this solution does meet the requirement of sending an email, using SES directly requires the email system to be pre-configured in SES, and it may introduce complexity when interacting with the third-party ticketing system. It also may not provide as flexible or as clean an integration as using SNS (which is designed for notification purposes). This method may require additional work on email formatting and integration with the ticketing system. B) Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the third-party ticketing email system to the SNS topic. Create an Amazon EventBridge rule that includes an event pattern that matches High severity GuardDuty findings. Specify the SNS topic as the target for the EventBridge rule. - Explanation: This option uses Amazon SNS, a service that is designed for sending notifications. The third-party ticketing system can be subscribed to the SNS topic, and an EventBridge rule will send the High severity findings to the SNS topic, which will then email the ticketing system. - Reasoning: This is a clean and effective solution because SNS is specifically designed to handle notifications, including emails, and integrating it with EventBridge and GuardDuty is straightforward. It ensures that when GuardDuty generates a High severity finding, the notification is sent to the third-party system in the required format (email). This option is well-suited for the integration between AWS services and third-party systems. C) Use the GuardDuty CreateFilter API operation to build a filter in GuardDuty to monitor for High severity findings. Export the results of the filter to an Amazon Simple Notif...

Author: Leah · Last updated Aug 14, 2026

A company is using AWS Organizations to implement a multi-account strategy. The company does not have on-premises infrastructure. All workloads run on AWS. The company currently has eight member accounts. The company anticipates that it will have no more than 20 AWS accounts total at any time. The company issues a new security policy that contains the following requirements: * No AWS account should use a VPC within the AWS account for workloads. * The company should use a centrally managed VPC that all AWS accounts can access to launch workloads in subnets. * No AWS account should be able to modify another AWS account's application resources within the centrally managed VPC. * The centrally managed VPC should reside in an existing AWS acc...

Let's break down the requirements and options in order to find the most suitable solution for the company’s scenario. Requirements Summary: 1. No AWS account should use a VPC within the AWS account for workloads: Workloads should not run directly in each AWS account’s VPC. 2. Centralized VPC management: The company should use a centrally managed VPC that all AWS accounts can access. 3. Account isolation for application resources: No AWS account should be able to modify another account’s resources in the centralized VPC. 4. Centrally managed VPC resides in Account-A: The centrally managed VPC should reside in Account-A. Now let's evaluate each option: A) Use a CloudFormation template in the member accounts to launch workloads. Configure the template to use the Fn::ImportValue function to obtain the subnet ID values. - Explanation: This solution suggests using CloudFormation in member accounts to deploy workloads and retrieve subnet IDs from Account-A’s VPC using `Fn::ImportValue`. - Reasoning: While using `Fn::ImportValue` can import outputs like subnet IDs from another account’s CloudFormation stack, this approach would still require that the CloudFormation templates in the member accounts be able to launch resources directly within the shared VPC. This doesn’t enforce the level of isolation needed between accounts for resource modification or prevent direct use of VPCs within the member accounts, making this approach insufficient. B) Use a transit gateway in the VPC within Account-A. Configure the member accounts to use the transit gateway to access the subnets in Account-A to launch workloads. - Explanation: A Transit Gateway (TGW) allows multiple VPCs to communicate with each other through a central hub. This solution would involve setting up a transit gateway in Account-A and allowing member accounts to connect to it to access subnets for launching workloads. - Reasoning: This solution enables centralized connectivity and meets the requirement of no workloads running directly in member account VPCs. However, it doesn’t fully ensure that member accounts cannot modify resources in the centralized VPC. The transit gateway enables communication but does not address resource isolation in terms of access control at the application level, which the security policy demands. Therefore, this option isn’t sufficient by itself for enforcing the required resource i...

Author: BlazingPhoenix22 · Last updated Aug 14, 2026

A company's security team needs to receive a notification whenever an AWS access key has not been rotated in 90 or more days. A security engineer must develop a solution that provides these notifications auto...

Let's break down each option to evaluate its suitability for this task based on simplicity, effort, scalability, and integration with AWS services. Option A: AWS Config Managed Rule and EventBridge - AWS Config provides an automated way to monitor configuration compliance of AWS resources, which fits the requirement to track the rotation of access keys. - By using the access-keys-rotated managed rule and setting the maxAccessKeyAge parameter to 90 days, this option directly addresses the need to track when keys are rotated. - EventBridge can then listen to non-compliant events and trigger an SNS notification to the security team. - Key Benefits: - Minimal effort: The AWS Config rule is already built and just needs to be configured. - Automation: EventBridge automatically triggers actions based on AWS Config’s compliance state. - Scalability: AWS Config and EventBridge are fully managed, meaning they will scale automatically as your environment grows. - Drawback: It requires AWS Config to be enabled, which may incur additional cost if not already set up. Option B: Script with Trusted Advisor, Lambda, S3, and Athena - AWS Trusted Advisor provides recommendations for best practices, including IAM access key rotation, but it is not specifically designed for continuous monitoring. - The workflow involves exporting data, uploading it to S3, running Athena queries, and sending notifications via SNS. - Key Drawbacks: - This is a complex and manual solution, requiring custom scripting, exporting data, and maintaining the pipeline. - Additional complexity: Managing Athena queries and S3 buckets introduces unnecessary overhead when a simpler, more integrated solution like AWS Config exists. - Not scalable: This solution requires manual intervention to ensure the script is regularly updated or maintained, which increases the risk of errors or missed rotations. Option C: Script with IAM Credentials Report, Lambda, EventBridge, and SNS - This approach involves generating the IAM credentials report, filtering it using a Lambda function, and sending an SNS notification if any access keys have...

Author: Isabella · Last updated Aug 14, 2026

A company maintains an open-source application that is hosted on a public GitHub repository. While creating a new commit to the repository, an engineer uploaded their AWS access key and secret access key. The engineer reported the mistake to a manager, and the manager immediately disabled the access key. The company needs to assess the impact of the exposed...

Let's evaluate each option based on simplicity, relevancy, and required overhead to assess the impact of the exposed access key. Option A: AWS Identity and Access Management (IAM) Use Report from AWS Trusted Advisor - AWS Trusted Advisor provides recommendations and best practices but does not directly track the use of IAM access keys. - While it can help identify security issues like unused access keys or weak permissions, it does not provide detailed information about the specific usage of an access key after it has been exposed. - Key Drawback: The IAM use report from Trusted Advisor is not designed for tracking individual access key usage, so it would not be useful in this case. Option B: Analyze Amazon CloudWatch Logs for Activity by Searching for the Access Key - CloudWatch Logs capture application logs and AWS service logs. However, it does not directly track access key usage unless the application explicitly logs the access key in the logs. - While CloudWatch could potentially be configured to log API calls or authentication events, it is not designed to monitor access key usage out of the box. - Key Drawback: Using CloudWatch Logs would only be effective if the application or AWS services are set up to log such events, which is not always the case and would involve manual setup or additional logging configuration. Option C: Analyze VPC Flow Logs for Activity by Searching for the Access Key - VPC Flow Logs track traffic going to and from network interfaces in a VPC but...

Author: Sara · Last updated Aug 14, 2026

A company plans to create individual child accounts within an existing organization in AWS Organizations for each of its DevOps teams. AWS CloudTrail has been enabled and configured on all accounts to write audit logs to an Amazon S3 bucket in a centralized AWS account. A security engineer needs to ensure t...

Let's evaluate each option in terms of enforcement of the security requirement that DevOps team members should not be able to modify or disable the CloudTrail configuration, and analyze its suitability: Option A: Create an IAM Policy that Prohibits Changes to the Specific CloudTrail Trail and Apply the Policy to the AWS Account Root User - IAM policies applied to the root user are not recommended. The root user has broad administrative permissions and applying a policy to restrict root user actions is contradictory to the purpose of the root account, as root typically requires unfettered access for managing critical resources. - Key Drawback: Applying policies to the root user is not a best practice because the root account should be used minimally and with caution. Furthermore, root user access cannot be easily restricted, which poses a security risk. Option B: Create an S3 Bucket Policy in the Specified Destination Account for the CloudTrail Trail that Prohibits Configuration Changes from the AWS Account Root User in the Source Account - The S3 bucket policy would help restrict access to the logs stored in the bucket, but it doesn’t prevent changes to the CloudTrail configuration itself (such as disabling the trail or changing settings). - Key Drawback: This approach does not prevent changes to CloudTrail in the source account, such as modifying the configuration of CloudTrail itself. It only controls access to the logs in S3, which is a different level of control than needed to prevent CloudTrail modifications. Option C: Create an SCP that Prohibits Changes to the Specific CloudTrail Trail and Apply the SCP to the Appropriate Organizational Unit or Account in Organizations - Service Control Policies (SCPs) are a powerful tool in AWS Organizations that enable central management of permissions across multiple accounts. SCPs allow you to define and enforce permissions across the entire organization or specific organizational units (OUs). - By creating an SCP...

Author: Sophia Clark · Last updated Aug 14, 2026

A company's policy requires that all API keys be encrypted and stored separately from source code in a centralized security account. This security account is managed by the company's security team. However, an audit revealed that an API key is stored with the source code of an AWS Lambda...

To securely store and manage the API key, the solution needs to comply with the company's policy of encrypting and storing the key separately from the source code, and in a centralized security account managed by the security team. Let's evaluate each option based on its security, simplicity, and alignment with the company's policy. Option A: Create a CodeCommit Repository in the Security Account Using AWS KMS for Encryption. Require the Development Team to Migrate the Lambda Source Code to This Repository. - Key Drawbacks: - Inconvenient for DevOps workflow: This option would require the development team to move their Lambda code to a separate repository in the security account. It adds significant complexity to the development workflow. - Inappropriate for API key storage: Storing the API key within a CodeCommit repository, even if encrypted, does not align with the goal of separating sensitive information from the source code. The key should be managed separately from the application code, ideally in a service that specializes in secret management. - Why rejected: It violates the policy of keeping API keys separate from source code and introduces unnecessary overhead for the development team. Option B: Store the API Key in an Amazon S3 Bucket in the Security Account Using Server-Side Encryption with Amazon S3 Managed Encryption Keys (SSE-S3) to Encrypt the Key. Create a Presigned URL for the S3 Key, and Specify the URL in a Lambda Environmental Variable in the AWS CloudFormation Template. - Key Drawbacks: - Insecure access method: Presigned URLs are typically used for temporary access to specific objects and might not be the best way to securely retrieve an API key in production. Additionally, the URL would expose the key, even if temporarily. - Not ideal for secret management: Using S3 for storing API keys is not best practice. AWS offers services like Secrets Manager that are specifically designed for securely storing and managing secrets like API keys. - Why rejected: S3 is not a dedicated solution for storing sensitive information like API keys, and using presigned URLs adds unnecessary complexity and security risks. Option C: Create a Secret in AWS Secrets Manager in the Security Account to Store the API ...

Author: Isabella1 · Last updated Aug 14, 2026

A security engineer is asked to update an AWS CloudTrail log file prefix for an existing trail. When attempting to save the change in the CloudTrail console, the security engineer receives the following error message: "There i...

Let's evaluate each option based on the error message "There is a problem with the bucket policy" when trying to update the log file prefix in CloudTrail. Option A: Create a New Trail with the Updated Log File Prefix, and Then Delete the Original Trail. Update the Existing Bucket Policy in the Amazon S3 Console with the New Log File Prefix, and Then Update the Log File Prefix in the CloudTrail Console. - Key Drawbacks: - This option suggests creating a new trail and deleting the original one, which is inefficient and unnecessary. It introduces additional work and does not address the underlying issue, which likely lies with the existing bucket policy preventing the update of the log file prefix. - Unnecessary complexity: Creating and deleting trails just to change the log file prefix is overcomplicating the task. There's no need to delete the original trail if the underlying issue with the bucket policy is addressed correctly. - Why rejected: This is more of a workaround and does not solve the problem with the bucket policy itself. Option B: Update the Existing Bucket Policy in the Amazon S3 Console to Allow the Security Engineer's Principal to Perform PutBucketPolicy, and Then Update the Log File Prefix in the CloudTrail Console. - Key Drawbacks: - PutBucketPolicy allows changes to the S3 bucket policy, but the issue here is not with modifying the bucket policy itself. The error indicates a problem with the existing permissions or configuration rather than a need to modify the bucket policy to allow putting a new policy. - Unnecessary action: The problem seems to be with the permissions for CloudTrail to interact with the bucket, not with changing the policy itself. Giving permissions to modify the bucket policy could lead to more privileges than needed. - Why rejected: The error likely arises from incorrect permissions between CloudTrail and the bucket, rather than a need to modify the bucket policy for putting a new policy. Option C: Update the Existing Bucket Policy in t...

Author: Leo · Last updated Aug 14, 2026

A company uses AWS Organizations. The company wants to implement short-term credentials for third-party AWS accounts to use to access accounts within the company's organization. Access is for the AWS Management Console and third-party software-as-a-service (SaaS) applications. Trust must be enhanced to prevent two external accounts f...

To meet the requirements of providing short-term credentials to third-party AWS accounts while ensuring trust and minimal operational effort, let's evaluate each option based on the key factors of trust, operational effort, and scalability. Option A: Use a bearer token authentication with OAuth or SAML to manage and share a central Amazon Cognito user pool across multiple Amazon API Gateway APIs. - Trust: This approach would rely on external authentication mechanisms like OAuth or SAML. However, the trust model in this case doesn't align directly with AWS accounts and roles. - Operational Effort: Although Cognito and API Gateway are powerful, managing a central user pool and integrating it across services can lead to increased operational complexity, especially for managing temporary access credentials. - Scalability: It’s a bit over-engineered for just providing access to the AWS Management Console and third-party SaaS applications. Conclusion: This solution adds unnecessary complexity and operational overhead, so it’s not ideal. Option B: Implement AWS IAM Identity Center (AWS Single Sign-On), and use an identity source of choice. Grant access to users and groups from other accounts by using permission sets that are assigned by account. - Trust: IAM Identity Center provides a central identity management solution that integrates well with AWS accounts and external users. You can enforce identity federation (via SAML or other identity providers) to control who can access AWS resources. - Operational Effort: Using IAM Identity Center simplifies access management for multiple AWS accounts, as permission sets are assigned centrally. It requires minimal operational effort to manage users and permissions. - Scalability: IAM Identity Center supports managing external identities at scale, including integration with third-party SaaS applications, which fits well for the needs of this solution. Conclusion: This option is well-suited for managing short-term credentials and external access, with minimal operational overhead. Option C: Create a unique IAM role for each exter...

Author: Ava · Last updated Aug 14, 2026

A company is evaluating its security posture. In the past, the company has observed issues with specific hosts and host header combinations that affected the company's business. The company has configured AWS WAF web ACLs as an initial step to mitigate these issues. The company must create a log analysis solution for the AWS WAF web ACLs to monitor problematic activity. The company wants to process all the AWS WAF logs in a central location. The company must have the ability to filter out request...

To meet the company's requirements of processing AWS WAF logs efficiently and being able to filter out requests based on specific hosts, let's evaluate the options based on key factors such as operational efficiency, ease of use, and cost-effectiveness. Option A: Specify Amazon Redshift as the destination for the access logs. Deploy the Amazon Athena Redshift connector. Use Athena to query the data from Amazon Redshift and to filter the logs by host. - Operational Efficiency: This approach involves using Amazon Redshift to store logs, then utilizing Athena with the Redshift connector to query them. Setting up Redshift requires configuration of the database, and while Athena can query the data, the overhead of managing Redshift as a data warehouse for logs adds complexity and operational burden. - Scalability and Cost: Redshift is a powerful database, but using it for log storage is unnecessary and may incur high costs, especially if logs are large or frequent. Redshift is better suited for analytics workloads rather than real-time log analysis. - Complexity: Deploying and maintaining Amazon Redshift and the Athena Redshift connector introduces unnecessary complexity, especially when other more lightweight solutions (like CloudWatch or S3) are available for log processing. Conclusion: This option is over-engineered and not optimal for log analysis from AWS WAF due to unnecessary complexity and higher costs. Option B: Specify Amazon CloudWatch as the destination for the access logs. Use Amazon CloudWatch Logs Insights to design a query to filter the logs by host. - Operational Efficiency: CloudWatch is a native AWS service and integrates well with AWS WAF. CloudWatch Logs Insights is a powerful query engine that allows you to easily filter and analyze logs based on specific conditions, such as the host. - Scalability and Cost: This solution is cost-efficient as CloudWatch Logs is a managed service designed for log collection, and CloudWatch Logs Insights allows you to query logs directly. No need to manage external storage or complex connectors. - Simplicity: Setting up CloudWatch as the destination and using Logs Insights for querying is straightforward. There is no need for additional infrastructure or external services, reducing complexity. Conclusion: This option is the simplest, most efficient, and cost-effective choice. It directly...

Author: Samuel · Last updated Aug 14, 2026

A security engineer is trying to use Amazon EC2 Image Builder to create an image of an EC2 instance. The security engineer has configured the pipeline to send logs to an Amazon S3 bucket. When the security engineer runs the pipeline, the build fails with the following error: "AccessDenied: Access Denied status code: 403". The security engineer must resolve the error b...

To resolve the "AccessDenied: Access Denied status code: 403" error and ensure that the EC2 Image Builder pipeline can run successfully with proper least privilege access, we need to address both the permissions for the EC2 instance and the permissions for the security engineer’s IAM role, specifically for accessing the S3 bucket. Let’s evaluate the options: Option A: Ensure that the following policies are attached to the IAM role that the security engineer is using: EC2InstanceProfileForImageBuilder, EC2InstanceProfileForImageBuilderECRContainerBuilds, and AmazonSSMManagedInstanceCore. - Explanation: These policies are intended for an EC2 instance profile, not the security engineer’s IAM role. The EC2InstanceProfileForImageBuilder and related policies allow the EC2 instance to perform operations such as image building, interacting with ECR for container image builds, and using SSM (Systems Manager) for instance management. - Reasoning: The security engineer’s IAM role typically manages the permissions for orchestrating the EC2 Image Builder pipeline but not for the instance's actions directly. Therefore, this option is not appropriate because it’s focusing on the instance role’s policies, not the engineer’s permissions. Conclusion: This option is not correct. Option B: Ensure that the following policies are attached to the instance profile for the EC2 instance: EC2InstanceProfileForImageBuilder, EC2InstanceProfileForImageBuilderECRContainerBuilds, and AmazonSSMManagedInstanceCore. - Explanation: These policies are for the EC2 instance, which is required for the instance to carry out specific tasks like building the image, interacting with Amazon ECR, and communicating with Systems Manager. This setup would allow the EC2 instance to perform the actions needed during the image building process. - Reasoning: This is an important step, but it's not the only step needed to resolve the access issue because it doesn’t address the necessary permissions related to the S3 bucket where logs are stored. Conclusion: This option is partially correct but needs additional steps to address the S3 access issue. Option C: Ensure that the AWSImageBuilderFullAccess policy is attached to the instance profile for the EC2 instance. - Explanation: Th...

Author: FrostFalcon88 · Last updated Aug 14, 2026

A security engineer must use AWS Key Management Service (AWS KMS) to design a key management solution for a set of Amazon Elastic Block Store (Amazon EBS) volumes that contain sensitive data. The solution needs to ensure ...

To meet the requirement of automatically expiring the key material in 90 days, we need to carefully consider the available options in the context of AWS Key Management Service (KMS). Let’s evaluate each option based on the need for automatic key expiration and key management best practices. Option A: A customer managed key that uses customer-provided key material - Explanation: A customer managed key (CMK) with customer-provided key material allows the customer to bring their own encryption keys to AWS. However, this option does not inherently support automatic expiration of the key material. While the key material can be manually rotated or replaced, AWS KMS does not provide a native mechanism to automatically expire or delete the key material after a specific period like 90 days. - Reasoning: This option requires manual intervention to delete or rotate the key material, making it unsuitable for the requirement of automatic expiration. Conclusion: This option is not suitable because it lacks automatic expiration support. Option B: A customer managed key that uses AWS-provided key material - Explanation: A customer managed key (CMK) that uses AWS-provided key material allows AWS to manage the key material. This provides more convenience and security, as AWS handles key rotation and availability. However, AWS KMS does not offer automatic expiration of key material. Key rotation is done by AWS on a regular schedule, but expiration based on a fixed timeline (like 90 days) is not supported. - Reasoning: While this option allows for automated key rotation, it does not support automatic expiration of the key material in the way that the scenario requires. Conclusion: This option is not suitable because it does not allow for key expiration within a specific timeframe. Option C: An AWS managed key - Explanation: AWS managed keys are cr...

Author: Elizabeth · Last updated Aug 14, 2026

A security engineer is building a Java application that is running on Amazon EC2. The application communicates with an Amazon RDS instance and authenticates with a user name and password. Which combination of steps can the engineer ...

To protect the database credentials and minimize downtime when they are rotated, let's evaluate the options based on key principles such as security, automation, and minimizing operational overhead. Option A: Have a database administrator encrypt the credentials and store the ciphertext in Amazon S3. Grant permission to the instance role associated with the EC2 instance to read the object and decrypt the ciphertext. - Explanation: Storing credentials in Amazon S3 encrypted by a database administrator could work, but it introduces additional complexity, such as manual encryption and decryption steps. The credentials would need to be manually updated and rotated, which can increase the operational overhead. - Security Considerations: Storing credentials in S3 and relying on the EC2 instance to decrypt them could potentially expose the credentials to unauthorized access if not properly configured. Additionally, it doesn't integrate well with automated credential rotation. - Operational Efficiency: This solution is not automated and requires the database administrator to handle encryption and rotation manually. This leads to higher operational overhead and potential human errors. Conclusion: This option is not ideal due to manual management, increased operational complexity, and lack of automated credential rotation. Option B: Configure a scheduled job that updates the credential in AWS Systems Manager Parameter Store and notifies the engineer that the application needs to be restarted. - Explanation: This option involves creating a scheduled job to update the credentials in Systems Manager Parameter Store. However, it requires the application to be restarted every time the credentials are updated. - Operational Efficiency: The need to restart the application adds downtime, which is against the goal of minimizing downtime. This method also involves more manual intervention (notification to the engineer and restarting the application). - Security Considerations: While storing credentials in Parameter Store can be secure, the need for manual updates and restarts reduces the efficiency of this solution. Conclusion: This option is not optimal due to the manual intervention required and the added downtime for the application restart. Option C: Configure automatic rotation of credentials in AWS Secrets Manager. - Explanation: AWS Secrets Manager allows for automatic credential rotation, which helps ensure that credentials are regularly rotated without manual intervention. This option is fully integrated with AWS services and supports built-in automation for credential management. - Security Considerations: Secrets Manager is designed to securely store and manage secrets, including automatic encryption and rotation of credentials. It provides better security than manual management, as it automatically handles the lifecycle of credentials. - Operational Efficiency: This solution minimizes operational overhe...

Author: Oscar · Last updated Aug 14, 2026

A company uses SAML federation to grant users access to AWS accounts. A company workload that is in an isolated AWS account runs on immutable infrastructure with no human access to Amazon EC2. The company requires a specialized user known as a break glass user to have access to the workload AWS account and instances in the case of SAML errors. A recent audit discovered that the company did not create the break glass user for the AWS account that contains the workload. The company...

To meet the requirements of providing a break glass user access to an isolated AWS workload account while logging the activities, let's evaluate each option carefully based on the key factors involved: Key Factors: 1. Access Control: The break glass user must be able to access the workload in the event of SAML errors. This implies that the break glass user must have appropriate permissions. 2. Logging Activities: The actions of the break glass user must be logged for security and audit purposes. 3. Automating Notifications: Security teams need to be notified in case of activities involving the break glass user. --- Evaluation of Options: A) Create a local individual break glass IAM user for the security team. Create a trail in AWS CloudTrail that has Amazon CloudWatch Logs turned on. Use Amazon EventBridge to monitor local user activities. - Access Control: A local IAM user can be created specifically for break glass purposes, allowing access to the AWS account in case of SAML errors. - Logging Activities: Using CloudTrail with CloudWatch Logs enabled will log all activities performed by the break glass user, which is necessary for auditing. - Notifications: Amazon EventBridge can be used to monitor the activities of the break glass user and trigger notifications to the security team. - Conclusion: This option meets the requirements, as it provides a method for controlled access, logging, and sending notifications to the security team. B) Create a break glass EC2 key pair for the AWS account. Provide the key pair to the security team. Use AWS CloudTrail to monitor key pair activity. Send notifications to the security team by using Amazon Simple Notification Service (Amazon SNS). - Access Control: This option provides EC2 key pair access to the break glass user, which isn't ideal for AWS account-level user access management. EC2 key pairs are typically used for instance-level SSH access and don't provide the same level of IAM-based access control as an IAM user or role. - Logging Activities: CloudTrail can track API calls but will not monitor SSH activity on instances, which limits the scope of logging for this solution. - Notifications: SNS notifications can be configured but are limited in the context of logging IAM activities compared to using CloudTrail with EventBridge. - Conclusion: This option is rejected because EC2 key pairs are not ideal for managing user access at the account level and don't provide sufficient logging for this use case. C) Create a break glass IAM role for the account. Allow security team members to perform the AssumeRoleWithSAML operation. Create an AWS CloudTrail tra...

Author: Ava · Last updated Aug 14, 2026

A security engineer is working with a product team building a web application on AWS. The application uses Amazon S3 to host the static content, Amazon API Gateway to provide RESTful services, and Amazon DynamoDB as the backend data store. The users already exist in a directory that is exposed through a SAML identity provider. Which combi...

To allow users to authenticate into the web application and call APIs, the security engineer must ensure that user identities from the SAML identity provider are mapped correctly to the application’s resources in AWS. The engineer should also ensure secure access control to the resources such as DynamoDB and API Gateway, leveraging AWS services like Amazon Cognito. Key Factors to Consider: 1. Authentication: The users are already in a directory that is exposed through a SAML identity provider, meaning the solution needs to integrate with the existing identity provider. 2. Authorization: The engineer needs to allow authenticated users to access API Gateway and DynamoDB securely. 3. Efficient Integration: The integration should involve using managed services like Cognito to handle user authentication and authorization, avoiding complex custom solutions unless necessary. --- Evaluation of Options: A) Create a custom authorization service using AWS Lambda. - Reasoning: This option suggests building a custom authorization solution, which is more complex and may require additional maintenance. While AWS Lambda is powerful and can provide flexible solutions, using it to create a custom authorization system might not be the most efficient approach when there are managed services like Cognito available. - Conclusion: This option is rejected because it adds complexity and doesn’t fully leverage AWS managed services for authentication and authorization. B) Configure a SAML identity provider in Amazon Cognito to map attributes to the Amazon Cognito user pool attributes. - Reasoning: This is a valid solution, as Cognito can act as a broker between the SAML identity provider and other AWS services. By configuring the SAML identity provider in Amazon Cognito, the engineer can map SAML attributes to Cognito user pool attributes. This allows users to authenticate via SAML and have their identity recognized in Cognito, which integrates easily with other AWS services. - Conclusion: This option is selected because it provides a seamless integration between SAML authentication and AWS resources using Cognito. C) Configure the SAML identity provider to add the Amazon Cognito user pool as a relying par...

Author: Ethan · Last updated Aug 14, 2026

A company needs to improve its ability to identify and prevent IAM policies that grant public access or cross-account access to resources. The company has implemented AWS Organizations and has started using AWS Identity and Access Management Access Analyzer to refine overly broad access to accounts in the organization. A security engineer must automate a response in the company's organization for any newly created policies that are overly permissive. T...

To address the requirements of automating a response to newly created IAM policies that grant overly permissive access (public or cross-account access), the security engineer needs a solution that ensures quick detection, remediation, and notification of such policies. Let’s evaluate the proposed options and their relevance to the scenario. Key Factors: 1. Automated Detection and Remediation: The process should identify policies that grant overly broad access and take action to remediate them automatically (e.g., blocking external access). 2. Notification: The security team must be notified of the actions taken to remediate the policy. 3. Integration with IAM Access Analyzer: The solution should integrate with AWS IAM Access Analyzer, which identifies findings related to public or cross-account access. --- Evaluation of Options: A) Create an AWS Step Functions state machine that checks the resource type in the finding and adds an explicit Deny statement in the trust policy for the IAM role. Configure the state machine to publish a notification to an Amazon Simple Notification Service (Amazon SNS) topic. - Reasoning: This option uses AWS Step Functions to automate the remediation by adding an explicit "Deny" statement in the trust policy of the affected IAM role. Additionally, the state machine can send notifications via SNS, keeping the security team informed. - Conclusion: This is a valid option as it integrates the automation of remediation with IAM Access Analyzer findings, applying the "Deny" rule, and notifying the team via SNS. B) Create an AWS Batch job that forwards any resource type findings to an AWS Lambda function. Configure the Lambda function to add an explicit Deny statement in the trust policy for the IAM role. Configure the AWS Batch job to publish a notification to an Amazon Simple Notification Service (Amazon SNS) topic. - Reasoning: This option suggests using AWS Batch to forward findings to Lambda for remediation. While AWS Batch could be used, it is not an ideal choice for this scenario because it is typically used for large-scale batch processing rather than event-driven responses. Lambda can be directly triggered by EventBridge for real-time processing, which is more suitable. - Conclusion: This option is rejected because using AWS Batch is unnecessary in this context, and it adds unnecessary complexity when simpler solutions like Step Functions or EventBridge can directly address the requirement. C) In Amazon EventBridge, create an event rule that matches active IAM Access Analyzer findings and invokes AWS Step Functions for resolution. - Reasoning: This option directly integrates EventBridge with IAM Access Analyzer findings. EventBridge can trigger Step Functions to handle the ...

Author: ShadowWolf101 · Last updated Aug 14, 2026

A security engineer is configuring a mechanism to send an alert when three or more failed sign-in attempts to the AWS Management Console occur during a 5-minute period. The security engineer creates a trail ...

Key Requirements: - Detect failed sign-ins: The solution must identify failed sign-in attempts to the AWS Management Console. - Track failed attempts: It must specifically track three or more failed sign-in attempts within a 5-minute period. - Alerting: The solution must send an alert when this condition is met. Evaluation of Options: A) In CloudTrail, turn on Insights events on the trail. Configure an alarm on the insight with eventName matching ConsoleLogin and errorMessage matching "Failed authentication''. Configure a threshold of 3 and a period of 5 minutes. - Reasoning: CloudTrail Insights events help identify unusual activity in your AWS environment. However, CloudTrail Insights are used for detecting anomalous behavior, such as unusually high activity, rather than for tracking specific event patterns like failed logins. While this can work for detecting irregular patterns, it may not be as effective for specifically counting failed sign-in attempts for alerting, as Insights doesn't offer fine-grained control over specific event conditions like matching failed login attempts. - Conclusion: This option is not ideal because CloudTrail Insights is more focused on anomalies and won't provide the fine-grained control needed to track specific failed sign-ins based on event patterns. B) Configure CloudTrail to send events to Amazon CloudWatch Logs. Create a metric filter for the relevant log group. Create a filter pattern with eventName matching ConsoleLogin and errorMessage matching "Failed authentication". Create a CloudWatch alarm with a threshold of 3 and a period of 5 minutes. - Reasoning: This solution uses CloudTrail events sent to CloudWatch Logs, which allows for detailed filtering of specific events, such as `ConsoleLogin` with an error message indicating "Failed authentication". You can then create a metric filter based on this pattern and set a CloudWatch alarm to trigger when the count of such events reaches 3 within a 5-minute window. This directly meets the requirement to track failed login attempts and generate alerts. - Conclusion: This is the best option because it uses CloudTrail to capture login attempts and CloudWatch to monitor and create alerts based on failed login even...

Author: Vikram · Last updated Aug 14, 2026

A company's security engineer is developing an incident response plan to detect suspicious activity in an AWS account for VPC hosted resources. The security engineer needs to provide visibility for as many AWS Regions as possibl...

Key Requirements: - Detect suspicious activity: The incident response plan should identify and provide visibility into suspicious activity in AWS accounts, particularly for VPC-hosted resources. - Visibility across AWS Regions: The solution should offer visibility into as many AWS Regions as possible. - Cost-effectiveness: The approach should be cost-efficient while fulfilling the requirements. Evaluation of Options: A) Turn on VPC Flow Logs for all VPCs in the account. - Reasoning: VPC Flow Logs capture network traffic information for resources in the VPC, which is useful for detecting suspicious activity such as unusual traffic patterns or unauthorized access. By enabling VPC Flow Logs for all VPCs, the security engineer can monitor traffic across the account in multiple regions. However, enabling VPC Flow Logs for all VPCs can generate large amounts of data, which can become costly. Nonetheless, this is a highly valuable step for gaining visibility into network traffic. - Conclusion: This is a good option for providing visibility into network activity in all regions, though the associated cost of storing and analyzing the logs should be carefully considered. B) Activate Amazon GuardDuty across all AWS Regions. - Reasoning: Amazon GuardDuty is a threat detection service that continuously monitors for suspicious activity across AWS accounts. By activating GuardDuty in all regions, the security engineer can detect anomalies and suspicious activities, including unauthorized API calls, unusual network traffic, and potential compromises. GuardDuty is region-specific, but enabling it across all regions ensures visibility across the entire AWS environment. It provides a highly effective way to monitor and respond to suspicious activity and does so with relatively low operational overhead. - Conclusion: This is a highly efficient and cost-effective solution for detecting suspicious activity across regions. It doesn't require manual monitoring and scales automatically with AWS workloads. C) Activate Amazon Detective across all AWS Regions. - Reasoning: Amazon Detective helps analyze, investigate, and visualize suspicious activities detected by GuardDuty. While it is useful for in-depth investigation, it doesn't help in the initial detection of suspicious activi...

Author: Olivia · Last updated Aug 14, 2026

A company stores images for a website in an Amazon S3 bucket. The company is using Amazon CloudFront to serve the images to end users. The company recently discovered that the images are being accessed from countries where the company does not have a distribution...

To secure the images and limit their distribution to only allowed countries, the company can use a combination of CloudFront and S3 configurations. Let's analyze the options provided: A) Update the S3 bucket policy to restrict access to a CloudFront origin access control (OAC). - Reasoning: This option helps to ensure that only CloudFront (and not direct users) can access the S3 bucket, improving security by not allowing direct access to the bucket from unauthorized sources. - Why it's not fully relevant for restricting countries: While this option helps prevent direct access to the S3 bucket, it does not restrict access based on geography. It focuses on controlling access by ensuring requests only go through CloudFront. B) Update the website DNS record to use an Amazon Route 53 geolocation record deny list of countries where the company lacks a license. - Reasoning: Route 53 geolocation routing can direct traffic based on the geographic location of users, but it's not designed for denying or restricting access to specific countries for static content served by CloudFront. - Why it’s not a good fit: This is more relevant to routing requests to different services rather than restricting access to content. It does not control content delivery or provide an easy mechanism for enforcing deny lists based on countries. C) Add a CloudFront geo restriction deny list of countries where the company lacks a license. - Reason...

Author: Oliver · Last updated Aug 14, 2026

A company has deployed servers on Amazon EC2 instances in a VPC. External vendors access these servers over the internet. Recently, the company deployed a new application on EC2 instances in a new CIDR range. The company needs to make the application available to the vendors. A security engineer verified that the associated security groups and network ACLs are allowing the re...

To troubleshoot why the vendors cannot connect to the application, we need to consider the security mechanisms in place, including security groups, network ACLs, and traffic routing. Let’s review the options: A) Modify the security group that is associated with the EC2 instances to have the same outbound rules as inbound rules. - Reasoning: Security groups are stateful, meaning if an inbound connection is allowed, the corresponding outbound traffic is automatically allowed. The security group should not require the outbound rules to be explicitly modified to mirror the inbound rules for basic internet access. - Why it’s rejected: Security groups do not need to have the same outbound rules as inbound rules. If the inbound traffic is allowed and the return traffic is part of the same session, it will be allowed by default. Hence, this does not directly solve the issue with vendor access. B) Modify the network ACL that is associated with the CIDR range to allow outbound traffic to ephemeral ports. - Reasoning: Network ACLs are stateless, and they control both inbound and outbound traffic separately. Ephemeral ports (ports typically used for response traffic) are often dynamically assigned in the range of 1024–65535. If the network ACL does not allow these outbound ephemeral ports, the response to the vendors' requests will be blocked. - Why it’s selected: This is a good solution because if the network ACL does not allow outbound traffic on the ephemeral port...

Author: Ravi Patel · Last updated Aug 14, 2026

A company uses infrastructure as code (IaC) to create AWS infrastructure. The company writes the code as AWS CloudFormation templates to deploy the infrastructure. The company has an existing CI/CD pipeline that the company can use to deploy these templates. After a recent security audit, the company decides to adopt a policy-as-code approach to improve the company's security posture on AWS. The company must prevent the depl...

To prevent the deployment of any infrastructure that violates a security policy, such as unencrypted Amazon EBS volumes, the company needs a solution that provides policy enforcement before resources are created or modified. Let’s evaluate the options based on the goal of enforcing security policies as part of the infrastructure deployment process. A) Turn on AWS Trusted Advisor. Configure security notifications as webhooks in the preferences section of the CI/CD pipeline. - Reasoning: AWS Trusted Advisor provides recommendations for optimizing AWS resources, including security best practices. However, it only works after the resources are deployed and can only suggest improvements. - Why it’s rejected: Trusted Advisor is a post-deployment tool and doesn't prevent the creation of non-compliant resources. It also doesn't integrate well directly into a CI/CD pipeline for proactive policy enforcement before resource creation. B) Turn on AWS Config. Use the prebuilt rules or customized rules. Subscribe the CI/CD pipeline to an Amazon Simple Notification Service (Amazon SNS) topic that receives notifications from AWS Config. - Reasoning: AWS Config tracks configuration changes and compliance with rules. It can notify about non-compliance, but it is also a post-deployment tool. While it provides notifications, it doesn't prevent resources from being deployed that violate policies. - Why it’s rejected: AWS Config monitors resources and alerts when they are non-compliant but does not stop non-compliant resources from being deployed in the first place. This doesn’t provide the pr...

Author: Max · Last updated Aug 14, 2026

A company is running an Amazon RDS for MySQL DB instance in a VPC. The VPC must not send or receive network traffic through the internet. A security engineer wants to use AWS Secrets Manager to rotate the DB instance credentials automatically. Because of a security policy, the security engineer cannot use the standard AWS Lambda function that Secrets Manager provides to rotate the credentials. The security engineer deploys a custom Lambda function in the VPC. The custom Lambda function will be responsible for rotating the secret in Secrets Manager. The security engineer edits the DB instan...

In this case, the security engineer is facing an issue where the custom Lambda function, deployed in the VPC, cannot communicate with AWS Secrets Manager due to networking constraints. Let's evaluate the possible solutions. A) Add an egress-only internet gateway to the VPC. Allow only the Lambda function's subnet to route traffic through the egress-only internet gateway. - Reasoning: An egress-only internet gateway allows IPv6 traffic to flow from the VPC to the internet, but it does not work for IPv4 traffic. Since AWS Secrets Manager endpoints are typically accessed over IPv4, this would not solve the issue. - Why it’s rejected: This solution does not address the need for access to AWS Secrets Manager via IPv4, and the egress-only internet gateway is not appropriate in this context. B) Add a NAT gateway to the VPC. Configure only the Lambda function's subnet with a default route through the NAT gateway. - Reasoning: A NAT gateway allows instances in a private subnet to initiate outbound connections to the internet (including AWS service endpoints) while preventing inbound internet traffic. This is useful for situations where you need to access services like Secrets Manager but cannot directly access the internet. - Why it’s rejected: Although the NAT gateway would allow outbound communication, it introduces unnecessary complexity and potential security concerns (routing traffic through the internet). The goal is to avoid sending tr...

Author: Mia · Last updated Aug 14, 2026

The security engineer is managing a traditional three-tier web application that is running on Amazon EC2 instances. The application has become the target of increasing numbers of malicious attacks from the internet. What steps should th...

To check for known vulnerabilities and limit the attack surface of the application, the security engineer needs to take steps that enhance security, reduce exposure, and identify vulnerabilities. Let's evaluate the options: A) Use AWS Certificate Manager to encrypt all traffic between the client and application servers. - Reasoning: AWS Certificate Manager (ACM) can be used to provision and manage SSL/TLS certificates, which is important for encrypting traffic between clients and servers. However, while this is a good security practice for ensuring data encryption, it does not directly check for vulnerabilities or reduce the attack surface. - Why it’s rejected: While encryption is important for protecting data in transit, it doesn’t help identify vulnerabilities or limit the attack surface on its own. It only addresses confidentiality and integrity, not the broader issue of vulnerability management. B) Review the application security groups to ensure that only the necessary ports are open. - Reasoning: Reviewing and updating security groups to ensure that only necessary ports are open is an essential step in reducing the attack surface. By limiting which ports are open, you prevent unnecessary exposure to malicious actors, which can mitigate attacks such as port scanning or exploiting open ports. - Why it’s selected: This option directly limits the attack surface by ensuring only necessary communication channels are open. Properly configured security groups are an effective method to control access to EC2 instances and can reduce the overall risk of exposure to known vulnerabilities. C) Use Elastic Load Balancing to offload Secure Sockets Layer encryption. - Reasoning: Elastic Load Balanci...

Author: Noah · Last updated Aug 14, 2026

A company is using Amazon Elastic Container Service (Amazon ECS) to run its container-based application on AWS. The company needs to ensure that the container images contain no severe vulnerabilities. The company also must ensure that only specific IAM roles and specific AWS acco...

Key Factors for Selection: 1. Security (Vulnerability Scanning): The company needs to ensure that container images are free from severe vulnerabilities. This means the solution must include automatic scanning and the ability to detect vulnerabilities in the container images. 2. Access Control: The solution must enforce tight control over which IAM roles and AWS accounts can access the images, ensuring proper security and limited access to authorized principals. 3. Management Overhead: The company wants the solution with the least management overhead, meaning it should minimize manual interventions and avoid managing additional infrastructure components like EC2 instances or self-hosted tools. 4. Centralization and Scalability: The solution should ideally support a centralized approach for managing images, allowing for easy scaling to multiple AWS accounts. Evaluating the Options: Option A: Pull images from the public container registry. Publish to Amazon ECR repositories with scan-on-push configured. Use a CI/CD pipeline. - Vulnerability Scanning: Amazon ECR offers built-in image scanning for vulnerabilities when using scan on push. This ensures container images are scanned automatically as they are pushed to the registry. - Access Control: IAM policies can be used to restrict which IAM principals have access to the images. Additionally, ECR provides repository policies for more granular control, but this is handled separately. - Management Overhead: This solution is highly automated. With the scan on push feature and managed CI/CD pipeline deployment, there is minimal manual management. - Scalability: The solution scales well across multiple accounts as ECR supports cross-account access configurations. - Recommendation: Least overhead since Amazon ECR manages the scanning, and IAM policies and repository policies handle access control. The CI/CD pipeline automates the deployment to multiple accounts. Option B: Pull images from the public registry. Publish to a private EC2-hosted container registry. Host-based container scanning tools. Basic authentication. - Vulnerability Scanning: This solution requires the deployment and maintenance of host-based container scanning tools. This introduces significant overhead in managing, updating, and maintaining these scanning tools. - Access Control: Basic authentication over HTTPS is less secure than using AWS-managed IAM roles and policies. Managing this authentication method also adds complexity. - Management Overhead: High management overhead due to the need for manually managing EC2 instances, container scanning tools, and securing authenticat...

Author: Daniel · Last updated Aug 14, 2026

A company's data scientists want to create artificial intelligence and machine learning (AI/ML) training models by using Amazon SageMaker. The training models will use large datasets in an Amazon S3 bucket. The datasets contain sensitive information. On average, the data scientists need 30 days to train models. The S3 bucket has been secured appropriately. The company's data retention policy...

Key Factors for Selection: 1. Data Retention Policy: The policy requires that data older than 45 days must be removed from the S3 bucket. This means we need an automatic mechanism to enforce this deletion without manual intervention. 2. Security and Compliance: The data contains sensitive information, so it’s important to ensure that the deletion process is automated, reliable, and compliant with company policies. 3. Management Overhead: The solution should minimize the operational overhead. The simpler and more automated the solution, the better. 4. Cost and Efficiency: Since training takes an average of 30 days, and retention is for up to 45 days, a mechanism should be set up that does not incur unnecessary cost or complexity. Evaluating the Options: Option A: Configure an S3 Lifecycle rule on the S3 bucket to delete objects after 45 days. - S3 Lifecycle Rules: Amazon S3 provides an automatic and managed way to enforce retention policies through Lifecycle rules. These rules can be configured to delete objects older than 45 days, meeting the data retention requirement. - Management Overhead: This is the simplest solution with minimal management overhead, as S3 Lifecycle rules are automatically applied, and no additional infrastructure or Lambda functions are needed. - Scalability and Reliability: Lifecycle policies are designed to work at scale and are fully managed by AWS, making this a scalable and reliable solution for ensuring compliance with the data retention policy. - Recommendation: Best option, as it directly addresses the need to delete objects older than 45 days with minimal setup and operational overhead. Option B: Create an AWS Lambda function to check the last-modified date of the S3 objects and delete objects that are older than 45 days. Create an S3 event notification to invoke the Lambda function for each PutObject operation. - Lambda Function with S3 Event Notification: While a Lambda function could be used to check and delete objects older than 45 days, triggering this function on every `PutObject` operation would result in unnecessary overhead. Every time an object is added to the S3 bucket, Lambda would be invoked, which is not efficient for the task at hand. - Management Overhead: This option introduces significant complexity by re...

Author: FrozenWolf2022 · Last updated Aug 14, 2026

A security engineer is troubleshooting an AWS Lambda function that is named MyLambdaFunction. The function is encountering an error when the function attempts to read the objects in an Amazon S3 bucket that is named DOC-EXAMPLE-BUCKET. The S3 bucket has the following bucket policy: ...

Key Factors for Selection: - Lambda Permissions: The Lambda function needs permission to access the S3 bucket objects. The bucket policy must explicitly allow the Lambda function to perform the necessary actions (like reading objects). - Principal: The Principal in the bucket policy should specify who is allowed to perform actions on the bucket. If it's Lambda, the IAM role or service associated with Lambda needs to be specified as the Principal. - Action: The Action element specifies what operations are allowed. To read objects in an S3 bucket, the action should be `s3:GetObject`. - Resource: The Resource should refer to the specific S3 objects or the entire bucket, depending on the requirement. Evaluating the Options: Option A: Remove the Condition element. Change the Principal element to the following: - Explanation: This option suggests removing the `Condition` element and changing the `Principal` to a new value, which is not provided in the prompt. - Why Rejected: Without specific changes to the Principal and Condition, this option is unclear and incomplete. The `Principal` must match the IAM role or AWS service that is invoking the Lambda function (in this case, the Lambda function's IAM role or `AWS:Lambda`). Additionally, just removing the Condition may not address the underlying issue unless it’s the Condition causing the failure. Option B: Change the Action element to the following: - Explanation: The action in the S3 bucket policy should allow Lambda to read the objects, which means the action must be `s3:GetObject`. This option doesn’t provide a concrete change and lacks detail about the Action value. - Why Rejected: This option lacks specificity and would be incomplete unless the action is explicitly defined as `s3:GetObject` for reading objects. Without a concrete action specified, it's not...

Author: IronLion88 · Last updated Aug 14, 2026

An IAM user receives an Access Denied message when the user attempts to access objects in an Amazon S3 bucket. The user and the S3 bucket are in the same AWS account. The S3 bucket is configured to use server-side encryption with AWS KMS keys (SSE-KMS) to encrypt all of its objects at rest by using a customer managed key from the same AWS account. The S3 bucket has no bucket policy defined. The IAM user has been granted permissions through an IAM policy that allows the kms:Decrypt permission to the customer ...

Key Factors for Selection: - Permissions to access objects in S3: The IAM user must have the necessary permissions both for the S3 actions (e.g., `s3:List`, `s3:Get`) and for the encryption/decryption of objects (using the `kms:Decrypt` permission on the KMS key). - Encryption with SSE-KMS: If the S3 bucket is using SSE-KMS for encryption, the IAM user must be authorized to decrypt the objects using the associated customer-managed KMS key. - KMS Key Policy: Even though the IAM policy grants the `kms:Decrypt` permission, KMS key policies can override IAM policies and restrict access to the KMS key. - Bucket Policy: The S3 bucket has no bucket policy defined, so this is not likely to be the issue unless explicitly mentioned. Evaluating the Options: Option A: The IAM policy needs to allow the kms:DescribeKey permission. - Explanation: The `kms:DescribeKey` permission is used to describe the key itself (e.g., to view its metadata), but it is not required for decrypting data. To decrypt data, the required permission is `kms:Decrypt`, which the IAM policy already allows. The IAM user already has the appropriate permission for decryption, so this is not the cause of the issue. - Why Rejected: The `kms:DescribeKey` permission is unnecessary for decrypting objects in the S3 bucket. The issue is more likely to be with the KMS key policy or S3 permissions. Option B: The S3 bucket has been changed to use the AWS managed key to encrypt objects at rest. - Explanation: The problem states that the S3 bucket is using server-side encryption with a customer-managed key (SSE-KMS), and there is no indication in the prompt that it has been changed to use the AWS managed key (`aws/s3`). - Why Rejected: If the S3 bucket were using the AWS-managed KMS key, the IAM user would still need appropriate permissions on ...

Author: Madison · Last updated Aug 14, 2026

A company has a guideline that mandates the encryption of all Amazon S3 bucket data in transit. A security engineer must implement an S3 bucket policy that denies any S3 operations i...

Key Factors for Selection: - Encryption in Transit: The company mandates encryption of all Amazon S3 data in transit. For S3, this means that the operations (such as `s3:GetObject` and `s3:PutObject`) must be performed over HTTPS (which is inherently encrypted in transit). - S3 Bucket Policy: To enforce this requirement, the S3 bucket policy should explicitly deny any operations that are attempted over HTTP (non-encrypted). - Policy Syntax: The policy should use conditions to check if the request is using HTTPS. The condition key to check for HTTPS is `aws:SecureTransport`. Evaluating the Options: Option A: A policy that denies all operations unless the request is made using HTTPS. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:", "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/", "Condition": { "Bool": { "aws:SecureTransport": "false" } } } ] } ``` - Explanation: This policy explicitly denies all S3 operations (`s3:`) if the request is not using HTTPS (`aws:SecureTransport: "false"`). This ensures that all requests must be encrypted in transit (over HTTPS). - Why Selected: This policy correctly enforces the encryption in transit requirement by denying access if the request is not made using HTTPS. It directly meets the company's guideline. Option B: A policy that denies all operations unless the request is made using SSL. ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "s3:", "Resource": "arn:aws:s3:::DOC-EXAMPLE-BUCKET/", "Condition": { "StringNotEquals": { "aws:RequestSource": "ssl" } } } ] } ``` - Explanation: This policy attempts to enforce SSL, but the condition key (`aws:RequestSource`) is incorrect. There's no `aws:RequestSource` condition key for SSL, so this policy will not work as expected. - Why Rejected: This policy is inco...

Author: SilverBear · Last updated Aug 14, 2026

A security engineer wants to use Amazon Simple Notification Service (Amazon SNS) to send email alerts to a company's security team for Amazon GuardDuty findings that have a High severity level. The security engineer also wants to deliver these ...

To address the requirements of sending email alerts for high-severity Amazon GuardDuty findings and delivering these findings to a visualization tool for further analysis, let's evaluate each option based on the following criteria: 1. Integration with GuardDuty: GuardDuty can send findings to other AWS services like EventBridge, CloudWatch, or CloudTrail. In this case, GuardDuty findings need to be processed and sent to both a notification mechanism (SNS for email alerts) and a data visualization tool (e.g., OpenSearch or QuickSight). 2. Event Filtering (High Severity): The security engineer specifically wants to send only High severity findings. Therefore, the solution must support filtering and event pattern matching to ensure that only High severity events are triggered for email alerts. 3. Visualization Tool: The selected solution should allow for a visualization tool (e.g., OpenSearch Dashboards or QuickSight) to analyze the GuardDuty findings. 4. Stream Processing: The solution must be capable of streaming the GuardDuty findings to a destination like OpenSearch for further analysis, using Kinesis Data Streams or Kinesis Data Firehose. --- Evaluating Each Option: - Option A: - GuardDuty to CloudWatch: GuardDuty can send findings to CloudWatch, but CloudWatch is not typically used for storing or visualizing large datasets (such as findings from GuardDuty) over long periods. It's more suited for monitoring metrics and setting alarms. - SNS for Email Alerts: The SNS setup for email alerts is valid here. - Kinesis Data Streams to OpenSearch: While feasible, Kinesis Data Streams is more commonly used for high-throughput, real-time streaming scenarios. In this case, it's not optimal because the flow of GuardDuty findings could be handled more easily by Firehose, which is better suited for streaming data directly into OpenSearch for storage and analysis. - QuickSight: QuickSight is a good choice for visualization, but OpenSearch Dashboards would typically be a more natural choice since the data is already in OpenSearch. - Option B: - GuardDuty to CloudTrail: GuardDuty findings are not generally sent to CloudTrail; CloudTrail records API calls. This makes this option unsuitable as CloudTrail is not meant for processing GuardDuty findings. - SNS for Em...

Author: Joseph · Last updated Aug 14, 2026

A security engineer needs to implement a write-once-read-many (WORM) model for data that a company will store in Amazon S3 buckets. The company uses the S3 Standard storage class for all of its S3 buckets. The security engineer must ensure that objects cannot be overw...

To implement a write-once-read-many (WORM) model for data stored in Amazon S3 that prevents overwriting or deletion of objects, the security engineer needs to select the correct solution for locking the data in place. Let's evaluate each option based on the requirements: Key Requirements: - Prevent objects from being overwritten or deleted. - The solution should work for the S3 Standard storage class. - Prevent deletion or modification by all users, including the root user. --- Option A: Create new S3 buckets with S3 Object Lock enabled in compliance mode. Place objects in the S3 buckets. - S3 Object Lock in compliance mode is designed to prevent deletion or modification of objects for a specified retention period, even by the root user. - Compliance Mode ensures that objects cannot be overwritten or deleted until the retention period expires, offering a true WORM model. - This option meets the requirements because it guarantees that objects cannot be altered or deleted, even by the AWS root user. Conclusion: This is the correct solution, as it locks objects in place and ensures compliance with a WORM model. --- Option B: Use S3 Glacier Vault Lock to attach a Vault Lock policy to new S3 buckets. Wait 24 hours to complete the Vault Lock process. Place objects in the S3 buckets. - S3 Glacier Vault Lock applies to Glacier or Glacier Deep Archive storage classes, not S3 Standard. This means it’s not applicable for objects in the S3 Standard storage class. - While Glacier Vault Lock offers WORM functionality, it is not suitable for S3 Standard. Conclusion: This option is not valid because Glacier Vault Lock applies only to Glacier storage, not to S3 Standard. --- Option C: Create new S3 buckets with S3 Object Lock enabled in governance mode. P...

Author: Vikram · Last updated Aug 14, 2026

A company needs complete encryption of the traffic between external users and an application. The company hosts the application on a fleet of Amazon EC2 instances that run in an Auto Scaling group behind an...

To meet the requirement of complete encryption of traffic between external users and the application hosted on Amazon EC2 instances behind an Application Load Balancer (ALB), the security engineer needs to ensure that traffic between users and the ALB is encrypted (SSL/TLS) and that traffic between the ALB and the EC2 instances is also encrypted if needed. Key Requirements: - Encryption of Traffic: The traffic from external users to the application must be encrypted. - ALB and EC2 Instances: The ALB should handle encryption for traffic coming from external users, and the EC2 instances should be secured as well. - Proper Certificate Management: The solution must handle the necessary SSL/TLS certificates for encryption. --- Evaluating Each Option: - Option A: Create a new Amazon-issued certificate in AWS Secrets Manager. Export the certificate from Secrets Manager. Import the certificate into the ALB and the EC2 instances. - AWS Secrets Manager is not typically used for storing SSL/TLS certificates. It's primarily used for storing and managing secrets like API keys or database credentials. - This option is not optimal because Secrets Manager is not the right service for managing SSL/TLS certificates and does not directly integrate with the ALB for secure certificate management. Conclusion: This option is not suitable. - Option B: Create a new Amazon-issued certificate in AWS Certificate Manager (ACM). Associate the certificate with the ALB. Export the certificate from ACM. Install the certificate on the EC2 instances. - AWS Certificate Manager (ACM) is the correct service for managing SSL/TLS certificates. - Associating the certificate with the ALB will ensure that traffic from external users to the ALB is encrypted (SSL/TLS). - However, exporting the certificate and installing it on EC2 instances is not required if the EC2 instances do not need to handle direct SSL/TLS traffic from clients (i.e., if the ALB terminates SSL/TLS). This adds unnecessary complexity and overhead to the EC2 instances. Conclusion: T...

Author: Isabella · Last updated Aug 14, 2026

A company has an organization with SCPs in AWS Organizations. The root SCP for the organization is as follows: The company's developers are members of a group that has an IAM policy that allows access to Amazon Simple Email Service (Amazon SES) by allowing ses:* actions. The account is a child to an OU that has an SCP that allows Amazon SES. The developers are receiving a not-authorized er...

The issue here is that the developers are receiving a "not-authorized" error despite having the appropriate IAM policy allowing access to Amazon SES and being within an OU that allows SES access via SCP. The reason for this "not-authorized" error can be traced back to how Service Control Policies (SCPs) interact with IAM policies. Key Concepts: 1. IAM Policies: These policies grant permissions to users, groups, or roles for accessing AWS services. 2. SCPs (Service Control Policies): SCPs set permission guardrails within an AWS Organization. They restrict what IAM users and roles within an organization can do, regardless of their individual IAM policies. 3. AWS Organizations: SCPs apply to accounts, Organizational Units (OUs), or the root of the organization. In this case, developers have an IAM policy that grants access to ses: actions, and there is an SCP that allows SES at the OU level. However, the "not-authorized" error suggests that something is blocking access, and this could likely be an issue with the root SCP that is overriding the allowed permissions for Amazon SES, making it inaccessible. --- Evaluating Each Option: - Option A: Add a resource policy that allows each member of the group to access Amazon SES. - Resource-based policies (like those for Amazon S3, SES, or Lambda) are generally used to grant permissions to specific resources, but IAM policies and SCPs govern access to AWS services across the board. The issue is not with the resource policy; it's more likely related to the overarching restrictions imposed by SCPs. - Conclusion: This is not the correct approach to fix the issue since the root cause is more likely tied to SCPs, not resource policies. - Option B: Add a resource policy that allows "Principal": {"AWS": "arn:aws:iam::account-number:group/Dev"}. - Similar to Option A, this approach involves modifying a resource-based policy. However, SCPs control access to services ...

Author: Zara · Last updated Aug 14, 2026

A company hosts a public website on an Amazon EC2 instance. HTTPS traffic must be able to access the website. The company uses SSH for management of the web server. The website is on the subnet 10.0.1.0/24. The management subnet is 192.168.100.0/24. A security engineer must create a security group for the EC2 inst...

To secure the EC2 instance properly, we need to focus on controlling access based on the requirements, which are: 1. HTTPS traffic should be allowed to access the website. 2. SSH should be allowed only from the management subnet for secure server management. 3. The website is hosted on the subnet 10.0.1.0/24. 4. The management subnet is 192.168.100.0/24. We need to create a security group that allows HTTPS access from all internet traffic (since it's a public website) but restricts SSH access to only the management subnet. Step-by-Step Analysis: 1. HTTPS traffic: - HTTPS (port 443) needs to be accessible from the public internet for the website to be available to users. - The correct configuration would be to allow traffic on port 443 from 0.0.0.0/0 (i.e., anywhere on the internet). 2. SSH traffic: - SSH (port 22) should only be allowed from trusted sources, specifically the management subnet, to ensure that only the security engineers (from the management subnet 192.168.100.0/24) can access the server for management purposes. - Allowing port 22 from 0.0.0.0/0 would be highly insecure, as it would expose the server to the entire internet. Therefore, SSH access should be restricted to 192.168.100.0/24. 3. Other subnet options: - Port 22 should not be opened to the web server subnet (10.0.1.0/24), as the goal is to allow SSH only from the management subnet, not from the web server subnet itself. Evaluating Each Option: - Option A: Allow port 22 from source 0.0.0.0/0: - Rejected: This wou...

Author: Sophia · Last updated Aug 14, 2026

A security engineer wants to forward custom application-security logs from an Amazon EC2 instance to Amazon CloudWatch. The security engineer installs the CloudWatch agent on the EC2 instance and adds the path of the logs to the CloudWatch configuration file. However, CloudWatch does not receive the logs. The security e...

To resolve the issue of the EC2 instance not forwarding custom application-security logs to Amazon CloudWatch, we need to ensure the EC2 instance has the necessary permissions to send logs to CloudWatch. Let’s analyze the options: A) Add AWS CloudTrail to the trust policy of the EC2 instance. Send the custom logs to CloudTrail instead of CloudWatch. - Why it's rejected: CloudTrail is used for logging API calls and actions made on AWS resources, not for forwarding custom application logs. This option would not resolve the issue because CloudTrail is not intended for handling application logs in the way CloudWatch is. B) Add Amazon S3 to the trust policy of the EC2 instance. Configure the application to write the custom logs to an S3 bucket that CloudWatch can use to ingest the logs. - Why it's rejected: While logs can be written to S3 and then ingested into CloudWatch Logs using Lambda or other mechanisms, this solution is more complex and unnecessary for this use case. The question specifies using the CloudWatch agent, which is intended to directly push logs to CloudWatch without needing S3 as an intermediary. C) Add Amazon Inspector to the trust...

Author: James · Last updated Aug 14, 2026

A systems engineer is troubleshooting the connectivity of a test environment that includes a virtual security appliance deployed inline. In addition to using the virtual security appliance, the development team wants to use security groups and network ACLs to accomplish various security req...

To troubleshoot the connectivity of a test environment involving a virtual security appliance, the key factor to consider is how the virtual security appliance routes traffic while using security groups and network ACLs. The virtual security appliance must be able to process and route traffic through different layers of the network, while also interacting with the security groups and network ACLs effectively. Let’s evaluate the options: A) Disable network ACLs. - Why it's rejected: Disabling network ACLs entirely would be an inappropriate approach because network ACLs are an important layer of security for controlling traffic at the subnet level. Simply disabling them would remove an additional security layer, which isn’t necessary for the virtual security appliance to route traffic. It’s better to allow the security appliance to work in conjunction with network ACLs rather than disable them. B) Configure the security appliance's elastic network interface for promiscuous mode. - Why it's rejected: Promiscuous mode would allow the virtual security appliance to capture all traffic on the network, but it is not necessary for routing purposes. This mode is typically used when the appliance needs to inspect traffic, not route it. Additionally, promiscuous mode could have unnecessary overhead and isn’t typically required for inline routing of traffic in a scenario like this one. C) Disable the Network Source/Destination check on the security appliance's elastic network interface. - Why this is selected: The Network Source/...

Author: IronLion88 · Last updated Aug 14, 2026

A security engineer needs to create an Amazon S3 bucket policy to grant least privilege read access to IAM user accounts that are named User1, User2, and User3. These IAM user accounts are members of the AuthorizedPeople IAM group. The security engineer drafts the following S3 bucket policy: When the security engineer tries to add the policy to the S3 bucket, the following error message appears: "Missing required field Principa...

The error message "Missing required field Principal" indicates that the policy is missing a Principal field, which specifies the IAM entities (users, groups, or roles) that the policy applies to. In the context of an S3 bucket policy, you need to define the IAM users (User1, User2, and User3) that the policy will grant access to. Here’s a breakdown of the available solutions: Options to consider: A) Use IAM group ARN (AuthorizedPeople group) as the Principal. - Why this is rejected: A bucket policy typically specifies individual IAM users or roles as the Principal, not an IAM group. While the group `AuthorizedPeople` is used to organize users in the IAM system, S3 bucket policies require specific IAM user ARNs (Amazon Resource Names) or roles as principals, not groups. Therefore, using the group ARN is not a valid solution for applying specific access to individual users. B) Use the specific IAM user ARNs (User1, User2, and User3) in the Principal field. - Why this is selected: This solution directly addresses the requirement to grant least privilege read access to the individual users: User1, User2, and User3. In an S3 bucket policy, you must specify the Principal as the ARNs of the IAM users. The policy can list the ARNs of User1, User2, and User3 to grant them the specific access needed. For example, the policy would look like this: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::bucket-name/", ...

Author: Leo · Last updated Aug 14, 2026

A security engineer recently rotated all IAM access keys in an AWS account. The security engineer then configured AWS Config and enabled the following AWS Config managed rules: mfa-enabled-for-iam-console-access, iam-user-mfa-enabled, access-keys-rotated, and iam-user-unused-credentials-check. The security engineer notices that all resources ar...

Let's evaluate the possible causes for the noncompliant status after invoking the GenerateCredentialReport API operation and enabling AWS Config rules. Options Analysis: A) The IAM credential report was generated within the past 4 hours. - Why this is rejected: The IAM credential report being generated recently (within the past 4 hours) shouldn't cause the noncompliant status. AWS Config rules typically assess compliance based on the most recent credential data. The timing of the report doesn't generally affect whether AWS Config identifies compliance, as the report reflects the current state of IAM users, access keys, and MFA settings. Therefore, this option is not the root cause of the issue. B) The security engineer does not have the GenerateCredentialReport permission. - Why this is rejected: The GenerateCredentialReport permission is needed to generate the IAM credential report, but the fact that the report was successfully generated indicates that the security engineer must have this permission. If the engineer didn't have this permission, the API request would have failed, so this is not the cause of the noncompliant status. C) The security engineer does not have the GetCredentialReport permission. - Why this is selected: The GetCredentialReport permission is r...

Author: Emily · Last updated Aug 14, 2026