Question.31 A company has hundreds of AWS accounts in an organization in AWS Organizations. The company operates out of a single AWS Region. The company has a dedicated security tooling AWS account in the organization. The security tooling account is configured as the organization’s delegated administrator for Amazon GuardDuty and AWS Security Hub. The company has configured the environment to automatically enable GuardDuty and Security Hub for existing AWS accounts and new AWS accounts. The company is performing control tests on specific GuardDuty findings to make sure that the company’s security team can detect and respond to security events. The security team launched an Amazon EC2 instance and attempted to run DNS requests against a test domain, example.com, to generate a DNS finding. However, the GuardDuty finding was never created in the Security Hub delegated administrator account. Why was the finding was not created in the Security Hub delegated administrator account? (A) VPC flow logs were not turned on for the VPC where the EC2 instance was launched. (B) The VPC where the EC2 instance was launched had the DHCP option configured for a custom OpenDNS resolver. (C) The GuardDuty integration with Security Hub was never activated in the AWS account where the finding was generated. (D) Cross-Region aggregation in Security Hub was not configured. |
31. Click here to View Answer
Answer: B
Explanation:
The reason the GuardDuty finding wasn’t created in the Security Hub delegated administrator account is likely due to the EC2 instance using a custom DNS resolver (option B). Here’s why:
GuardDuty relies on VPC flow logs and DNS logs to detect malicious activity. When an EC2 instance performs a DNS lookup, GuardDuty analyzes these requests to identify potentially harmful domains. If the EC2 instance uses the default Amazon DNS server, GuardDuty has full visibility. However, if a custom DNS resolver, like OpenDNS, is configured via DHCP options in the VPC, the DNS requests are routed to that external resolver, bypassing GuardDuty’s direct analysis of the DNS query itself.
GuardDuty primarily ingests DNS queries from the VPC’s DNS resolver. By using a custom DNS resolver, the VPC’s DNS resolution functionality isn’t utilized, preventing GuardDuty from observing the DNS request to example.com
and generating the expected finding. The query leaves the VPC before GuardDuty can analyze it.
While VPC Flow Logs (option A) are important for GuardDuty’s functionality, DNS queries are primarily analyzed directly as opposed to relying on information gleaned solely from flow logs. The GuardDuty-Security Hub integration (option C) and Cross-Region aggregation (option D) are not directly related to GuardDuty’s ability to detect DNS-related findings within a single AWS account and Region when the DNS resolution is external to AWS. They relate to propagation of the findings once they exist.
In summary, the EC2 instance bypassing the default Amazon DNS server prevented GuardDuty from seeing the DNS query for example.com
and generating the anticipated finding.
Further research:
Amazon VPC DHCP Options Sets: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html
AWS GuardDuty DNS Log Monitoring: https://docs.aws.amazon.com/guardduty/latest/ug/dns_log_monitoring.html
Question.32 An ecommerce company has a web application architecture that runs primarily on containers. The application containers are deployed on Amazon Elastic Container Service (Amazon ECS). The container images for the application are stored in Amazon Elastic Container Registry (Amazon ECR). The company’s security team is performing an audit of components of the application architecture. The security team identifies issues with some container images that are stored in the container repositories. The security team wants to address these issues by implementing continual scanning and on-push scanning of the container images. The security team needs to implement a solution that makes any findings from these scans visible in a centralized dashboard. The security team plans to use the dashboard to view these findings along with other security-related findings that they intend to generate in the future. There are specific repositories that the security team needs to exclude from the scanning process. Which solution will meet these requirements? (A) Use Amazon Inspector. Create inclusion rules in Amazon ECR to match repositories that need to be scanned. Push Amazon Inspector findings to AWS Security Hub. (B) Use ECR basic scanning of container images. Create inclusion rules in Amazon ECR to match repositories that need to be scanned. Push findings to AWS Security Hub. (C) Use ECR basic scanning of container images. Create inclusion rules in Amazon ECR to match repositories that need to be scanned. Push findings to Amazon Inspector. (D) Use Amazon Inspector. Create inclusion rules in Amazon Inspector to match repositories that need to be scanned. Push Amazon Inspector findings to AWS Config. |
32. Click here to View Answer
Answer: A
Explanation:
Here’s a detailed justification for why option A is the correct answer, along with supporting concepts and links:
The requirement calls for continual and on-push scanning of container images in Amazon ECR, a centralized dashboard for findings, and the ability to exclude specific repositories from scanning.
Option A utilizes Amazon Inspector, which supports both on-push and continuous scanning of container images stored in ECR. Amazon Inspector assesses container images for software vulnerabilities and unintended network accessibility. The inclusion rules within Amazon ECR allows precise specification of which repositories should be included in the scan, effectively fulfilling the exclusion requirement. Amazon Inspector integrates seamlessly with AWS Security Hub. Security Hub aggregates security findings from various AWS services (including Inspector), providing a centralized dashboard to view security issues across the entire AWS environment. This fulfills the centralized dashboard requirement.
Option B suggests using ECR basic scanning, however, this option is not flexible enough to specify inclusion rules, which is a key requirement. ECR Basic scanning does not offer the ability to customize which repositories are scanned.
Option C also suggests ECR Basic scanning and pushes finding to Inspector, which doesn’t satisfy the requirement of a centralized dashboard for all findings. Findings need to go to Security Hub for centralized reporting.
Option D proposes using Amazon Inspector but pushes findings to AWS Config. While AWS Config is a valuable service for compliance and configuration management, it is not designed to act as a centralized dashboard for security findings. Security Hub is the intended AWS service for this purpose.
Therefore, Option A is the only solution that correctly implements continual/on-push scanning with Amazon Inspector, allows for selective scanning through inclusion rules, and consolidates findings in AWS Security Hub for centralized visibility.
Supporting Links:
Amazon ECR Image Scanning: https://docs.aws.amazon.com/AmazonECR/latest/userguide/image-scanning.html
Amazon Inspector: https://aws.amazon.com/inspector/
AWS Security Hub: https://aws.amazon.com/security-hub/
Question.33 A company has a single AWS account and uses an Amazon EC2 instance to test application code. The company recently discovered that the instance was compromised. The instance was serving up malware. The analysis of the instance showed that the instance was compromised 35 days ago. A security engineer must implement a continuous monitoring solution that automatically notifies the company’s security team about compromised instances through an email distribution list for high severity findings. The security engineer must implement the solution as soon as possible. Which combination of steps should the security engineer take to meet these requirements? (Choose three.) (A) Enable AWS Security Hub in the AWS account. (B) Enable Amazon GuardDuty in the AWS account. (C) Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the security team’s email distribution list to the topic. (D) Create an Amazon Simple Queue Service (Amazon SQS) queue. Subscribe the security team’s email distribution list to the queue. (E)Create an Amazon EventBridge rule for GuardDuty findings of high severity. Configure the rule to publish a message to the topic. (F) Create an Amazon EventBridge rule for Security Hub findings of high severity. Configure the rule to publish a message to the queue. |
33. Click here to View Answer
Answer: BCE
Explanation:
Here’s a detailed justification for why the combination of steps B, C, and E is the correct solution:
B. Enable Amazon GuardDuty in the AWS account: GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior to protect your AWS accounts and workloads. It analyzes VPC Flow Logs, CloudTrail event logs, and DNS logs to identify suspicious behavior, such as EC2 instances serving malware. Given the scenario states the EC2 instance was compromised and serving up malware, GuardDuty is perfectly suited to detect this kind of activity and alert the security team. https://aws.amazon.com/guardduty/
C. Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the security team’s email distribution list to the topic: SNS is a messaging service that allows you to send notifications to a variety of endpoints, including email. By creating an SNS topic and subscribing the security team’s email distribution list, any message published to the topic will be sent to all members of the email list, facilitating rapid notification of security events. This satisfies the requirement for notifying the team. https://aws.amazon.com/sns/
E. Create an Amazon EventBridge rule for GuardDuty findings of high severity. Configure the rule to publish a message to the topic: EventBridge (formerly CloudWatch Events) allows you to create rules that react to events in your AWS environment. GuardDuty findings are published as events. By creating an EventBridge rule that filters for high-severity GuardDuty findings and configures it to send a message to the SNS topic created in step C, you automate the process of notifying the security team only when a high-severity threat is detected. This ensures that the team is alerted to critical security incidents without unnecessary noise. https://aws.amazon.com/eventbridge/
Why the other options are incorrect:
- A. Enable AWS Security Hub in the AWS account: While Security Hub is a valuable security service, its primary function is to provide a central view of your security state across multiple AWS services and accounts and compliance with security best practices. It aggregates findings from other services like GuardDuty but doesn’t directly detect the type of compromise described in the scenario as effectively and immediately as GuardDuty.
- D. Create an Amazon Simple Queue Service (Amazon SQS) queue. Subscribe the security team’s email distribution list to the queue: SQS is a queuing service, ideal for decoupling components of an application. While messages could be sent to a queue and then processed to send emails, it adds unnecessary complexity. SNS provides a direct and more suitable mechanism for sending email notifications. Email subscriptions to SQS queues are not a native feature.
- F. Create an Amazon EventBridge rule for Security Hub findings of high severity. Configure the rule to publish a message to the queue: While Security Hub can surface high severity findings, using it as the primary trigger adds a layer of indirection. Furthermore, using an SQS queue with a subsequent email mechanism is less efficient than directly utilizing SNS.
In summary, enabling GuardDuty for threat detection, using SNS for email notifications, and connecting them with EventBridge for automated alerting based on severity provides a rapid and effective solution to meet the requirements.
Question.34 A company uses identity federation to authenticate users into an identity account (987654321987) where the users assume an IAM role named IdentityRole. The users then assume an IAM role named JobFunctionRole in the target AWS account (123456789123) to perform their job functions. A user is unable to assume the IAM role in the target account. The policy attached to the role in the identity account is: ![]() What should be done to enable the user to assume the appropriate role in the target account?A.Update the IAM policy attached to the role in the identity account to be: ![]() B.Update the trust policy on the role in the target account to be: ![]() C.Update the trust policy on the role in the identity account to be: ![]() D.Update the IAM policy attached to the role in the target account to be: ![]() |
34. Click here to View Answer
Explanation:
Answer B
In IAM roles, use the Principal element in the role trust policy to specify who can assume the role.
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html
Question.35 A company is using AWS Organizations to manage multiple AWS accounts for its human resources, finance, software development, and production departments. All the company’s developers are part of the software development AWS account. The company discovers that developers have launched Amazon EC2 instances that were preconfigured with software that the company has not approved for use. The company wants to implement a solution to ensure that developers can launch EC2 instances with only approved software applications and only in the software development AWS account. Which solution will meet these requirements? (A) In the software development account, create AMIs of preconfigured instances that include only approved software. Include the AMI IDs in the condition section of an AWS CloudFormation template to launch the appropriate AMI based on the AWS Region. Provide the developers with the CloudFormation template to launch EC2 instances in the software development account. (B) Create an Amazon EventBridge rule that runs when any EC2 RunInstances API event occurs in the software development account. Specify AWS Systems Manager Run Command as a target of the rule. Configure Run Command to run a script that will install all approved software onto the instances that the developers launch. (C) Use an AWS Service Catalog portfolio that contains EC2 products with appropriate AMIs that include only approved software. Grant the developers permission to access only the Service Catalog portfolio to launch a product in the software development account. (D) In the management account, create AMIs of preconfigured instances that include only approved software. Use AWS CloudFormation StackSets to launch the AMIs across any AWS account in the organization. Grant the developers permission to launch the stack sets within the management account. |
35. Click here to View Answer
Answer: C
Explanation:
Here’s a detailed justification for why option C is the best solution:
The problem requires controlling which software developers can deploy on EC2 instances within the software development AWS account. It also requires ensuring that the developers can only deploy EC2 instances with approved software.
Option C, using AWS Service Catalog, directly addresses these requirements. AWS Service Catalog allows organizations to create and manage catalogs of IT services that are approved for use on AWS. These services can include EC2 instances preconfigured with approved AMIs.
Here’s why it’s effective:
- Standardization: Service Catalog promotes standardized deployments of approved resources. You can ensure that developers only deploy EC2 instances based on predefined, approved AMIs.
- Governance and Control: Service Catalog enables central governance. By granting developers permission to access only the Service Catalog portfolio containing the approved EC2 products, you restrict their ability to launch instances with unapproved software. They can only launch what is defined in the Catalog.
- Self-Service Provisioning: Developers can easily self-provision approved instances, simplifying their workflow while maintaining control.
- Auditing and Compliance: Service Catalog helps maintain compliance by ensuring that only approved resources are deployed. You have a clear audit trail of what was deployed and by whom.
- Single AWS Account Scope: Service Catalog focuses on the software development account, which aligns with the problem statement’s requirement to control deployments only in that specific account.
Here’s why the other options are less suitable:
- Option A (CloudFormation Templates within software development account): While CloudFormation can be used, managing and updating templates to enforce approved AMIs can become complex. It doesn’t provide the centralized governance and cataloging capabilities of Service Catalog, and it doesn’t prevent developers from bypassing the template and launching instances directly.
- Option B (EventBridge and Systems Manager Run Command): This approach reacts after the instance has been launched. While it can install approved software post-launch, it doesn’t prevent the initial launch of an instance with unapproved software. Also, the target SSM Run Command can fail, resulting in the instance being deployed with unapproved software. This does not meet the requirement.
- Option D (CloudFormation StackSets from the Management Account): This approach is overly complex. StackSets are generally used for deploying resources across multiple accounts, which is not a requirement in this scenario. Also, managing developers’ permissions within the management account is generally undesirable, as it can introduce security risks. This will also provision EC2 instances across every single AWS account instead of just the software development account.
In summary, AWS Service Catalog offers the most comprehensive solution for controlling EC2 instance deployments within the software development AWS account, ensuring that developers can only use approved software while maintaining a streamlined self-service provisioning process.
Relevant Links:
AWS Organizations: https://aws.amazon.com/organizations/
AWS Service Catalog: https://aws.amazon.com/servicecatalog/