How do CloudTrail and GuardDuty fit into cloud logging and monitoring?

You can't respond to what you can't see, and the cloud is API-driven — so logging and detection are the bedrock of cloud security. This question checks that you know the difference between recording activity and detecting threats in it.

CloudTrail — the audit source of truth

CloudTrail logs every API call made in the account: the identity (principal), the action, the timestamp, the source IP, and the request parameters. This is your authoritative, after-the-fact record.

• It answers "who did what, when, and from where" — essential for incident scoping and compliance.
• It must be protected from tampering. Best practice is to ship logs to a dedicated, locked-down logging account or a write-once (object-lock) bucket, so an attacker who compromises the workload account can't delete their tracks.
• Enable it in all regions plus data events for sensitive resources, or you'll have blind spots.

GuardDuty — the detection layer

Raw logs are huge and not self-interpreting. GuardDuty is a managed threat-detection service that continuously analyzes CloudTrail, VPC flow logs, and DNS logs, applying threat intelligence and ML to produce findings:

• Examples: instance credentials used from an unusual location (likely exfiltration), API calls from known-malicious IPs, crypto-mining traffic, or anomalous IAM behavior.
• It turns terabytes of telemetry into a short list of prioritized alerts you can route to a SOC or automated response.

How they work together

CloudTrail provides the evidence; GuardDuty provides the detection on top of it. During an incident you pivot from a GuardDuty finding back into CloudTrail to scope exactly what a compromised credential touched.

What interviewers look for

Clear separation of audit log vs threat detection, protecting CloudTrail integrity (separate account/object lock), and knowing GuardDuty consumes flow and DNS logs too.