itexamstest.com B is fit :)

Answer is C. * AWS AWS Systems Manager Automation provides predefined runbooks(ex. AWS-PublishSNSNotification ) for Amazon Simple Notification Service - https://docs.aws.amazon.com/systems-manager-automation-runbooks/latest/userguide/automation-aws-publishsnsnotification.html * Running automations in multiple AWS Regions and accounts (https://docs.aws.amazon.com/systems-manager/latest/userguide/running-automations-multiple-accounts-regions.html ) B seems to be old approach. With cloudformation stackset, each account can still change resource config (ex. SNS) that causes drift.... so I choose C because it utilize AWS organization fully with aws systems manager automation in multiple regions and multiple accounts with delegated administrator account( or management account )

C is only correct option.

Technically A would be sufficient here. The question is only asking to be NOTIFIED when block public access gets disabled. See the following GuardDuty finding: https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html#policy-s3-bucketblockpublicaccessdisabled Managing multiple GuardDuty accounts is simplified using the AWS Organizations delegated administrator feature. With this feature, the AWS Organizations management account can designate a member account to be the GuardDuty administrator for the entire organization. The delegated GuardDuty administrator is then granted permission to enable and manage GuardDuty for all existing and future accounts in the organization.

We can leverage AWS Organizations to enable Guarduty in all accounts. There is an S3 finding called Policy:S3/AccountBlockPublicAccessDisabled Then we setup a single EventBrdige rule in the delegated account that publish the event to the SNS topic in the same account. This is the easisest solution to be implemented and monitoring the public access seamlessly across all Organization's accounts This is a common multi-account strategy for GuardDuty with AWS organizations, to collect such finding from hundred of accounts

Amazon GuardDuty is primarily on threat detection and response, not configuration monitoring. A conformance pack is a collection of AWS Config rules and remediation actions that can be easily deployed as a single entity in an account and a Region or across an organization in AWS Organizations. https://docs.aws.amazon.com/config/latest/developerguide/conformance- packs.htmlhttps://docs.aws.

Answer is C A conformance pack is a collection of AWS Config rules and remediation actions that can be easily deployed as a single entity in an account and a Region or across an organization in AWS Organizations. You can also use AWS Systems Manager documents (SSM documents) to store your conformance pack templates on AWS and directly deploy conformance packs using SSM document names.

Hi can somebody with contributors access, would please forward all the questions pdf to me on telegram @rater250 , I'm willing to pay

C is correct: AWS config can only be modify by admin, not member accounts

Option B is also not a valid case because we can direct use config with eventbrige why to go for clod trail we can use aws config rule s3-bucket-public-read-prohibited if rule changes eventbridge will trigger sns

I got confused with option B and C , but Lets think in C option when I will use system manager to trigger SNS I can simply use eventbridge run that checks for config rule compliance change , IF compliance changes then as a target we will specify SNS. Yes , We can also specify system manager automation document to trigger sns but why I will use it I will directly use SNS. So from above I still by looking words B is correct option. Main reason is you do not need system manager here to trigger SNS. Plus there is no mention for eventbridge rule that will trigger system manager , from config we cannot directly trigger it.

I got confused with option B and C , but Lets think in C option when I will use system manager to trigger SNS I can simply use eventbridge run that checks for config rule compliance change , IF compliance changes then as a target we will specify SNS. Yes , We can also specify system manager automation document to trigger sns but why I will use it I will directly use SNS. So from above I still by looking words B is correct option. Main reason is you do not need system manager here to trigger SNS.

This is the type of thing that AWS Config is used for.

It’s not B because other users can turn it off. With AWS config in organisations only the admin in the root can do it.

Answer is C: With B you can deploy fix the problem, but it is installed in every account, so a user with admin rights in that account can delete/modify the configuration

C is right using Config Rules and Conformational Packs with SSM .

I don't have a technical reason but others dumps shows B as the Answer