Exam AWS Certified DevOps Engineer - Professional DOP-C02 topic 1 question 30 discussion

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 )

Goal: Detect and notify when Block Public Access is turned off on any S3 bucket across all AWS accounts in an organization. AWS Config tracks resource configuration changes, like changes to S3 bucket access settings. The s3-bucket-level-public-access-prohibited managed rule evaluates whether S3 buckets have Block Public Access settings enabled. Conformance packs allow deployment of these rules organization-wide in a managed way. A Systems Manager automation document can be triggered on noncompliance to publish to an SNS topic for notifications. Central management via a delegated administrator ensures member accounts can't disable the rule or notification.

GuardDuty Policy Policy:S3/BucketBlockPublicAccessDisabled "An IAM entity invoked an API used to disable S3 Block Public Access on a bucket." "Data source: CloudTrail management events" "This finding informs you that Block Public Access was disabled for the listed S3 bucket. When enabled, S3 Block Public Access settings are used to filter the policies or access control lists (ACLs) applied to buckets as a security measure to prevent inadvertent public exposure of data." https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-s3.html#policy-s3-bucketblockpublicaccessdisabled

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." https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html

It's A. GuardDuty echieves this with no effort.

A DevOps engineer must implement this change without affecting the operation of any AWS accounts.

I was sure the answer was "C" until I started reading through some of the requirements and comments. The words "implementation must ensure that individual member accounts in the organization cannot turn off the notification" incline me to lean towards "A", because with "C", someone with admin privileges on a single account could turn off the notification in that account. As pointed out by others, there are a number of GuardDuty findings associates with S3 public access. Having GuardDuty and EventBridge pattern trigger SNS for some key words such as "s3" and "Public" seems to make sense in enforcing this across an organization. I don't have enough experience with GuardDuty in an Organization to be 100% confident, but the emphasis on SNS requirement makes me think this could be a trick question.

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.