Turn a threat alert into a careful investigation — GuardDuty

Your goal

Plan how to investigate a suspicious cloud activity finding.

Why this matters

An alert suggests unusual use of a cloud resource. You will identify what the detector reports, gather supporting evidence, and choose a response that can be checked and reviewed.

Words you will use

A finding is a reported security concern. A signal is evidence used to detect it. Triage means deciding how urgent an issue is and what to investigate first.

How to proceed

Read each situation and choose an answer. The lesson explains the result. Try again if needed, then continue through all three decisions and finish the tour.

1. Understand the alert source

Your team needs a managed service that analyzes supported activity and threat signals for suspicious behavior. Choose the fitting role.

What does GuardDuty provide?

Threat detection findings from supported signals.

GuardDuty analyzes supported data sources and protection features to report potential threats. Review which coverage is enabled in your accounts and Regions. Detection helps investigation; it does not prove every resource is safe.

The team understands what the detector is watching.

Configured coverage → analyzed signals → findings

2. Read the context

A finding names a resource and suspicious activity. Deleting the resource immediately might interrupt the business or remove useful evidence. Choose the first investigation step.

What should you examine?

The finding details, affected resource, timing, and related activity.

Use the finding’s evidence and related logs to understand the event and its possible impact. Confirm ownership and expected behavior. The urgency can be high without treating the first alert as the whole story.

The response is based on evidence and impact.

Finding context + related evidence → triage decision

3. Make response deliberate

The team wants to automate a response to this finding type. An overly broad action could isolate legitimate production workloads. Choose the next design step.

How should automation begin?

Define narrow actions, test them, and record what happened.

Response automation needs its own permissions, conditions, and review. Test it on representative cases and keep an audit trail. A finding is not a promise that the problem has already been fixed.

The team has a testable and reviewable response plan.

Qualified finding → scoped response → recorded outcome

Practice, then check your understanding

In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.

Read the official AWS documentation for service behavior and production details.