What Is the Primary Use Case for Amazon GuardDuty?

Why the Answer Is Correct

Amazon GuardDuty is a fully managed, intelligent threat detection service. It ingests VPC Flow Logs, CloudTrail management and data events, DNS query logs, EKS audit logs, and S3 protection data, then applies machine learning, anomaly detection, and integrated threat intelligence to surface findings. The key word in option C is "automatic monitoring" — GuardDuty requires no agents or sensors to deploy and begins analyzing an account the moment it is enabled. Community commenter alokdixit2006 put it plainly: "threat detection service that continuously monitors your AWS environment." Nothing in the service blocks traffic, patches resources, or creates infrastructure, which is exactly why C is the accurate description of its primary use case.

Why the Other Options Are Wrong

Option A (prevention of DDoS attacks) describes AWS Shield, with AWS WAF handling application-layer filtering — GuardDuty might report reconnaissance activity but it does not mitigate an attack. Option B (protection against SQL injection) is a WAF use case, where managed rule groups inspect and block malicious HTTP payloads; GuardDuty is detective, not preventive. Option D (automatic provisioning of AWS resources) belongs to infrastructure-as-code and deployment services such as CloudFormation, Elastic Beanstalk, or Service Catalog, and has no relationship to GuardDuty's function. Every distractor swaps detection for prevention or provisioning, which is the classic Security pillar confusion on CLF-C02.

Community Comment Notes

All voter feedback on this question converged on C, and no participant argued for a distractor. ShaiTay simply recorded "C. Automatic monitoring for threats to AWS workloads," while d00b229 echoed the identical option text — evidence that the scenario is unambiguous once the detective-versus-preventive distinction is understood. The useful explanatory detail comes from alokdixit2006, who framed GuardDuty as a "continuous" monitor of the AWS environment, reinforcing that coverage is ongoing and account-wide rather than event-triggered. In short, the community consensus aligns with the source key and with AWS's own service definition.