Task 1.1: Design and implement monitoring and alerting solutions for an AWS account or organization

• AMake the security tooling account the delegated GuardDuty administrator and set auto-enable to all accounts (ALL) in each Region

  Correct

  A delegated administrator sees the findings of its member accounts, and the ALL setting enables GuardDuty for existing accounts and for accounts that join later. Auto-enable preferences are set per Region.

• BMake the security tooling account the delegated GuardDuty administrator and set auto-enable to new accounts only (NEW) in each Region

  Incorrect

  NEW enables GuardDuty only for accounts that join the organization after the setting is saved, so the 140 existing accounts stay uncovered.

• CDeploy a CloudFormation StackSet that creates a GuardDuty detector in every account and in both Regions

  Incorrect

  Each account would run its own standalone detector. Findings are visible centrally only to an administrator account that has the other accounts as members, which a StackSet does not set up.

• DEnable GuardDuty in the security tooling account in both Regions and invite every member account to join it

  Incorrect

  Invitations are the legacy method for accounts outside the organization. Each new account would need its own invitation, and GuardDuty recommends AWS Organizations instead.

Central management plus automatic coverage is the delegated administrator with auto-enable set to ALL. Choose NEW only when existing accounts are already handled some other way.

• AIn each member account, set the frequency for updated findings to 15 minutes

  Incorrect

  Only an administrator account can change this frequency, and the value it sets applies to its member accounts. A member account cannot change it for itself.

• BIn the delegated administrator account, set the updated-findings frequency to 15 minutes

  Correct

  GuardDuty groups later occurrences of a finding and sends them on a schedule that defaults to 6 hours. The administrator can set 15 minutes, 1 hour or 6 hours, and the setting applies to all members.

• CChange the EventBridge rule's event pattern so that it matches findings of every severity

  Incorrect

  The pattern filters events that GuardDuty has already sent. It does not make GuardDuty send updates for recurring findings any sooner.

• DExport findings to an S3 bucket and process each new object with S3 Event Notifications and Lambda

  Incorrect

  The same frequency setting governs updated findings exported to S3, so the S3 path would still deliver recurring findings every 6 hours.

New findings go to EventBridge in near real time; later occurrences of the same finding follow the updated-findings frequency, which only the administrator account can lower.

• ASchedule an Amazon Macie sensitive data discovery job that analyzes all objects in all buckets every day

  Incorrect

  Jobs give deeper, targeted analysis of the objects in their scope. Running one over every bucket is the exhaustive review the team said it does not need.

• BReview the bucket inventory and policy findings that Amazon Macie produces for the buckets

  Incorrect

  Bucket inventory and policy findings describe security and access control, such as public or shared buckets. They do not say whether the objects contain sensitive data.

• CTurn on Amazon Macie automated sensitive data discovery for the organization

  Correct

  Automated discovery continually evaluates the bucket inventory and samples representative objects, giving broad visibility into where sensitive data might reside without analyzing every object.

• DTurn on GuardDuty S3 Protection in every account

  Incorrect

  S3 Protection monitors CloudTrail data events for S3 to detect threats such as exfiltration. It does not inspect object contents.

Macie offers two ways to find sensitive data: automated discovery for a broad, sampled view across the estate, and jobs for deep, targeted analysis of chosen buckets. Start broad, then point jobs at what the broad view surfaces.

• ADeploy the rules as an organization conformance pack from the delegated administrator account

  Correct

  An organization conformance pack is deployed to every member account, including accounts that join later, and member accounts cannot modify its rules and remediation actions.

• BMake sure every account, including new ones, has an AWS Config configuration recorder running

  Correct

  Organization rules and conformance packs need a recorder in the account. If none exists, deployment to a new account is retried only for 7 hours.

• CCreate an AWS Config aggregator in the delegated administrator account for all accounts

  Incorrect

  An aggregator gives a read-only view of configuration and compliance data. It cannot deploy rules to the source accounts.

• DDeploy the conformance pack to each account with a CloudFormation StackSet that uses self-managed permissions

  Incorrect

  Self-managed StackSets do not deploy automatically to accounts added later, and the resulting packs are ordinary resources that the account can change.

• EAttach an SCP that denies config:PutConfigRule to all member accounts

  Incorrect

  An SCP only limits actions; it deploys no rules. Rules from an organization conformance pack are already protected from member accounts.

The organization conformance pack does the deploying and the protecting, but it can evaluate only where AWS Config is recording. Pair it with a recorder in every account, for example through the account baseline.

• AA weekly review of the Access Analyzer console by the team

  Incorrect

  A weekly review is not a notification and adds delay.

• BAn EventBridge rule for Access Analyzer finding events

  Correct

  IAM Access Analyzer sends an event to EventBridge for each finding, and a rule can route it to a notification target.

• CAn IAM credential report generated every day

  Incorrect

  The credential report covers users' credentials, not resource sharing findings.

• DA CloudWatch metric filter on the analyzer's log group

  Incorrect

  Access Analyzer findings are delivered as events, not written to a log group for metric filters.

Most AWS security services publish findings to EventBridge, which is the common hub for alerting and automation.

• AA Security Hub CSPM insight in each of the four Regions

  Incorrect

  Insights group findings within one Region; they do not bring other Regions' data together.

• BAn S3 bucket where each Region exports findings daily

  Incorrect

  Exported files are not managed in Security Hub CSPM and add custom work.

• CCross-Region aggregation with one home Region

  Correct

  Aggregation brings findings, insights, control status and scores from linked Regions into a single home Region.

• DA separate administrator account for each Region

  Incorrect

  More administrators split the view further instead of combining it.

The home Region was formerly called the aggregation Region; some API operations still use the older term.

• AIncrease the GuardDuty finding retention setting to three years

  Incorrect

  GuardDuty keeps findings for 90 days; there is no longer retention setting.

• BExport findings to an S3 bucket encrypted with a KMS key

  Correct

  GuardDuty can export findings to an S3 bucket, using a KMS key to encrypt them, where they can be kept as long as needed.

• CArchive the findings in GuardDuty so they are never deleted

  Incorrect

  Archiving changes a finding's status; it does not extend retention.

• DTurn on GuardDuty Runtime Monitoring for longer history

  Incorrect

  Runtime Monitoring adds a data source; it does not change how long findings are kept.

Long-term retention of security findings belongs in your own storage, with lifecycle rules and access controls you manage.

• ACloudTrail Insights turned on for the trail

  Correct

  Insights learns a baseline of API call and error rates and creates Insights events when current rates deviate from it.

• BLog file integrity validation on the trail

  Incorrect

  Integrity validation proves log files were not changed; it does not analyze activity.

• CAWS Config change notifications to SNS

  Incorrect

  Config reports resource configuration changes, not API call rates.

• DVPC Flow Logs for all subnets in the account

  Incorrect

  Flow logs describe network traffic, not API activity.

Insights events can feed EventBridge rules like any other CloudTrail event.

• ACreate an Inspector suppression rule for findings below CRITICAL

  Incorrect

  A suppression rule hides matching findings from the default console view, which breaks the reporting requirement.

• BAdd a detail.severity filter for CRITICAL to the rule's event pattern

  Correct

  Inspector finding events carry the finding's severity, so the event pattern can match CRITICAL only while Inspector keeps every finding.

• CTag the instances with low findings with the InspectorEc2Exclusion key

  Incorrect

  Excluded instances are not scanned and get no findings at all, including any future critical ones.

• DMatch Inspector2 Scan events instead of Inspector2 Finding events

  Incorrect

  Scan events report that an initial scan finished, with counts per severity; they do not describe individual findings.

Decide where the filter belongs. Narrowing what reaches a target is the job of the event pattern; suppression rules and exclusion tags change what Inspector shows or scans.