Exam AWS Certified Security - Specialty topic 1 question 220 discussion

D. Since AWS Organizations is used, then the GuardDuty account in the security account is the "administrative" instance. Member accounts can be invited to join the administrative account to combine findings.

Another question that aims to trick you. The member account does not seem "member to centralized GuardDuty", therefore it needs to be added to centralized GD. The question tries to trick you into thinking that member account is already in centralized GD, but does not send findings. Not sure this kind of questions are legit, cause it is solely based on paying attention to wording. D

Reference: https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html If you have already set up a GuardDuty administrator with associated member accounts by invitation, and the member accounts are part of the same organization, their Type changes from by Invitation to via Organizations when you set a GuardDuty delegated administrator for your organization. Which suggests accounts within Organisations don't have to send an invitation, but *do* still need to be added as members: You can enable GuardDuty in the current Region for all organization accounts by choosing enable in the banner at the top of the page. This action also turns on the Auto-Enable feature that enables GuardDuty in any future accounts that you add to your organization. Alternately, you can use the filter field to filter by Relationship status: Not a member, and then choose every account that doesn't have GuardDuty enabled in the current Region. Answer is D

D is the most efficient way to centralize GuardDuty findings.

Option D suggests using the "aws guardduty get-members" command in the security account to check if the compromised account is listed as a member account. If it is listed, the security engineer can then send an invitation from the security account's GuardDuty to the compromised account's GuardDuty. By accepting the invitation in the compromised account, all future GuardDuty findings from the compromised account will be forwarded to the security account for centralized monitoring. This approach ensures that GuardDuty findings from the compromised account are shared with the security account. It allows the security engineer to detect and monitor any suspicious activities across all member accounts in the centralized security account.

In this situation, it is important to configure a mechanism to centralize all GuardDuty findings in the security account for effective monitoring and management. Option B provides the appropriate solution by using Amazon CloudWatch Events and an AWS Lambda function to forward all GuardDuty findings to the security account and raise findings in AWS Security Hub.

Answer is A. B- GuardDuty is integrated with Security Hub, there is no need to use CWE and Lambda C-not necessary?! D-not external account. it's a a member account. https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_organizations.html

D is the answer. The catch here is the multi-region. Invitation is the only option for multi-region. https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_invitations.html Cross-Regional data transfer may occur when GuardDuty creates member accounts using this method.

The correct answer is D. To ensure that all GuardDuty findings are available in the security account, the security engineer should check if the compromised account is listed as a member of the security account using the aws guardduty get-members AWS CLI command. If the compromised account is not listed, the security engineer should send an invitation from GuardDuty in the security account to GuardDuty in the compromised account and accept the invitation to forward all future GuardDuty findings. Option A involves setting up a CloudWatch Events rule and a Lambda function, but this is not sufficient to ensure that all GuardDuty findings are available in the security account.

GuardDuty does not manage or retain your logs. All data that GuardDuty consumes is analyzed in near real time and discarded thereafter. This allows GuardDuty to be highly efficient and cost effective, and to reduce the risk of data remanence. For log delivery and retention, you should use AWS logging and monitoring services directly, which provide full-featured delivery and retention options.

D should be right. When finished all steps in segment of "Enable GuardDuty in a master account and invite member accounts" .... You have enabled GuardDuty on the member account, and all findings will be forwarded to the master account. You can now monitor the findings about GuardDuty member accounts from the GuardDuty console in the master account. https://aws.amazon.com/blogs/security/how-to-manage-amazon-guardduty-security-findings-across-multiple-accounts/

GuardDuty doesnt need cloudwatch to aggregate findings, once you add members, admin account can see all the findings, it should be D.

Option B doesn't make sense to me and option D does...

I would go for B. Option D would be the correct awsuer if AWS Organizations wasn't in place. Once it is, the invitation process is just for external account. For accounts within the Organization you just need to enable it from the delegated account.

D is the wrong answer. Read carefully : One of the member accounts has incurred an astronomical cost. Meaning that The security engineer does not need to worry about the administrative instance of Guardutty sending invitation to the member account to combine findings. It is no longer his probem. Response E E : The security officer is fired and escorted out of the building.

Use the aws guardduty get-members AWS CLI command in the security account to see if the account is listed. Send an invitation from GuardDuty in the security account to GuardDuty in the compromised account. Accept the invitation to forward all future GuardDuty findings.

D for sure