An authorized vulnerability scanner runs weekly from a fixed set of internal addresses and generates a large volume of GuardDuty reconnaissance findings. The security team wants those findings to stop reaching Security Hub and the team's EventBridge pipeline, but it must still be able to show an auditor that GuardDuty detected and recorded the scanning activity. What should the engineer configure?
- A.
A GuardDuty trusted IP list containing the scanner's addresses, uploaded to the detector in the administrator account.
- B.
An EventBridge rule with an event pattern that excludes the scanner's addresses so that matching findings are dropped before delivery.
- C.
A GuardDuty suppression rule matching the finding type and the scanner's addresses.
- D.
A Security Hub automation rule that sets the workflow status of matching findings to SUPPRESSED after they are imported.
Show answer
Answer: C
A suppression rule still generates the finding and archives it automatically, and archived findings are not exported to Security Hub, S3, Detective, or EventBridge.
- A. A trusted IP list prevents the findings from being generated at all, so there is no record for the auditor.
- B. Filtering in EventBridge only cleans one consumer; Security Hub still receives the findings and the noise remains.
- C. Suppressed findings are generated and auto-archived, so they remain visible in GuardDuty for audit but are not exported to Security Hub, S3, Detective, or EventBridge.
- D. An automation rule acts after import, so the findings have already reached Security Hub and the EventBridge pipeline.
