AWS CloudTrail — Auditing & API Logging
By Pritesh Yadav 18 min read —
AWS CloudTrail is your audit log: it records the API calls and actions taken in your account — who did what, when, and from where. It answers governance, compliance, and security-investigation questions. The exam loves to confuse CloudTrail (audit "who did it") with CloudWatch (monitor "how is it performing"), AWS Config (track "what is the configuration state"), and VPC Flow Logs (record "network traffic"). Knowing which tool answers which question is the whole game.
Most confused here: CloudTrail = audit/API activity (who did what); CloudWatch = performance metrics & logs (how it's running); AWS Config = resource configuration state & compliance over time (what it's set to); VPC Flow Logs = IP network traffic, not API calls.
Q1 A security team needs to find out which IAM user deleted a production S3 bucket last Tuesday and from what IP address the request came. Which AWS service was purpose-built to answer this question?
- Amazon CloudWatch
- AWS CloudTrail
- AWS Config
- Amazon Inspector
Answer: B
Why B is correct: CloudTrail records API calls and account activity — including the identity (the IAM user), the action (DeleteBucket), the timestamp, and the source IP address. This "who did what, when, and from where" record is exactly what an audit/security investigation needs.
Why the other options are wrong:
- A — CloudWatch collects performance metrics and application/system logs; it tells you how resources are performing, not who issued an API call.
- C — AWS Config tracks the configuration state of resources over time, but it is not the primary tool for identifying the user and IP behind a specific API action.
- D — Amazon Inspector scans workloads for software vulnerabilities and exposure; it does not log who deleted a bucket.
Common trap: Candidates reach for CloudWatch because it "has logs." But CloudWatch Logs hold application/system output, while CloudTrail logs the API activity and identity behind account actions.
Q2 A compliance auditor asks: "Show me the history of how this EC2 security group's rules have changed over the past six months, and whether it ever fell out of compliance with our policy." Which service is the best fit?
- AWS Config
- AWS CloudTrail
- Amazon CloudWatch
- AWS Trusted Advisor
Answer: A
Why A is correct: AWS Config records and tracks the configuration state of resources over time and evaluates them against rules. It can show a timeline of how a security group was configured and flag when it became non-compliant — that is its core purpose.
Why the other options are wrong:
- B — CloudTrail records the API events that caused changes (who called ModifySecurityGroup), but it is not designed to present a continuous compliance-state timeline of a resource's configuration.
- C — CloudWatch monitors performance and operational metrics, not configuration compliance history.
- D — Trusted Advisor gives point-in-time best-practice recommendations, not a per-resource configuration change timeline.
Common trap: CloudTrail and Config overlap in people's minds. CloudTrail = the action/event (who changed it); Config = the state over time and whether it's compliant. The word "configuration history/compliance" points to Config.
Q3 Which statement best describes the difference between CloudTrail "management events" and "data events"?
- Management events log network packets, while data events log API calls
- Management events log control-plane operations like creating resources, while data events log resource data operations like S3 object reads/writes
- Management events are free and data events are also always free with no extra logging cost
- Management events log billing changes, while data events log IAM password changes
Answer: B
Why B is correct: Management events capture control-plane actions — configuring or managing resources (e.g., creating a bucket, launching an instance, changing security settings). Data events capture high-volume data-plane activity, such as reading or writing individual S3 objects or invoking a Lambda function.
Why the other options are wrong:
- A — CloudTrail does not log network packets at all; that is VPC Flow Logs. Both event types are about API calls.
- C — Management events are recorded by default, but data events are high-volume and typically incur additional charges when enabled, so "always free" is false.
- D — This mislabels both categories; data events are object-level data operations, not IAM password changes.
Common trap: People assume "data events" means database events. In CloudTrail, data events mean data-plane operations like individual S3 object access — and they are usually off by default because of their volume and cost.
Q4 A startup wants to retain a full, durable record of all account API activity for several years to satisfy long-term compliance requirements. What is the standard CloudTrail approach to achieve this?
- Rely only on CloudTrail Event history, which keeps all events forever
- Forward every event to Amazon Inspector for archival
- Create a trail that continuously delivers log files to an Amazon S3 bucket
- Store the events in an EC2 instance's local disk
Answer: C
Why C is correct: Creating a trail tells CloudTrail to continuously deliver log files to a durable Amazon S3 bucket. S3 provides long-term, low-cost, highly durable storage, which is the standard way to keep a multi-year audit archive for compliance.
Why the other options are wrong:
- A — CloudTrail Event history (the console view) only retains roughly the last 90 days, so it cannot satisfy multi-year retention on its own.
- B — Inspector is a vulnerability scanner and is not an archive for CloudTrail logs.
- D — Storing audit logs on an EC2 local disk is neither durable nor a managed practice; the instance could be terminated and the data lost.
Common trap: Confusing the 90-day Event history with a long-term archive. Event history is convenient for recent lookups, but for retention you create a trail that ships logs to S3.
Q5 An engineer notices unusual sign-in and API activity and wants a quick look at the most recent account actions without setting anything up in advance. Which CloudTrail capability lets them view activity right away?
- A custom CloudWatch dashboard that must be built first
- VPC Flow Logs enabled on the default VPC
- AWS Config conformance packs
- CloudTrail Event history, which records recent management events automatically
Answer: D
Why D is correct: CloudTrail automatically records management events and makes the last ~90 days viewable in Event history with no setup. An engineer can immediately search recent actions by user, event name, or resource — ideal for a quick investigation.
Why the other options are wrong:
- A — A CloudWatch dashboard must be configured first and shows metrics, not the audit trail of who performed which API actions.
- B — VPC Flow Logs capture network traffic, not account API activity, and must be enabled beforehand.
- C — Config conformance packs assess configuration compliance; they are not an instant feed of recent API actions.
Common trap: Forgetting that CloudTrail logs management events out of the box. You do not have to create a trail just to see recent activity — Event history is already there for the last 90 days.
Q6 A company operates in five AWS Regions and wants a single trail that captures API activity across all of them so nothing is missed during an audit. Which CloudTrail feature satisfies this?
- Enabling AWS Config in one Region only
- A separate CloudWatch alarm in each Region
- A multi-Region trail
- Turning on VPC Flow Logs in every Region
Answer: C
Why C is correct: A multi-Region trail records events from all AWS Regions and delivers them to one S3 bucket. This gives a single, complete audit record so activity in any Region is captured — exactly what's needed for a consistent compliance view.
Why the other options are wrong:
- A — Config tracks configuration state, not the cross-Region API audit log, and one Region wouldn't cover the others anyway.
- B — CloudWatch alarms watch metrics; they don't aggregate API audit events across Regions.
- D — VPC Flow Logs record network traffic, not account API activity, so they don't provide an audit trail at all.
Common trap: Assuming you must create one trail per Region and stitch them together manually. A single multi-Region trail handles all Regions automatically.
Q7 A network engineer wants to investigate which source IP addresses are sending traffic to an EC2 instance and whether packets are being accepted or rejected at the subnet level. Which tool is designed for this — and why is it NOT CloudTrail?
- VPC Flow Logs, because CloudTrail records API calls, not network packet traffic
- CloudTrail data events, because they log all inbound packets
- AWS Config, because it stores network traffic history
- CloudWatch Synthetics, because it records IP-level traffic
Answer: A
Why A is correct: VPC Flow Logs capture information about the IP traffic going to and from network interfaces — source/destination IPs and whether traffic was accepted or rejected. CloudTrail is an API-activity auditor and does not see packet-level network traffic, so this is a Flow Logs job.
Why the other options are wrong:
- B — CloudTrail data events log data-plane API operations (like S3 object access), not raw network packets.
- C — Config tracks resource configuration state, not live network traffic.
- D — CloudWatch Synthetics runs scripted "canary" checks against endpoints; it does not record subnet-level packet flows.
Common trap: Lumping all "logs" together. CloudTrail = API activity; VPC Flow Logs = network traffic. The mention of source IPs and accept/reject decisions is the tell for Flow Logs.
Q8 During an incident, a team wants to be alerted in near real time whenever someone disables a critical security setting via an API call. Which combination matches CLF-C02 best practices?
- Use VPC Flow Logs to trigger an email
- Have CloudTrail deliver events to CloudWatch so an alarm/notification can fire on the specific API activity
- Use AWS Config to send the API call details to S3 only
- Rely on the CloudTrail Event history page to email you automatically
Answer: B
Why B is correct: CloudTrail can send its events to CloudWatch, where you can match a specific API activity and trigger an alarm or notification (for example, via SNS). This pairs CloudTrail's "who did what" record with CloudWatch's alerting to get near-real-time security alerts.
Why the other options are wrong:
- A — VPC Flow Logs see network traffic, not the API call that disabled a security setting, so they cannot detect this action.
- C — Config evaluates configuration state and isn't the mechanism for real-time alerting on a specific API call; "S3 only" provides no notification.
- D — Event history is a searchable view; it does not push automatic email alerts by itself.
Common trap: Thinking CloudTrail alone sends alerts. CloudTrail records the events; you pair it with CloudWatch (and SNS) to actually get notified.
Q9 Which scenario is the clearest example of using CloudTrail for governance and compliance rather than performance monitoring?
- Tracking CPU utilization on an EC2 instance to decide on scaling
- Watching application latency to improve user experience
- Counting the number of visitors to a website per hour
- Producing an audit report of every change made to IAM roles and policies for a security review
Answer: D
Why D is correct: Governance and compliance auditing is about proving who changed what and when. An audit report of every IAM role and policy change is precisely the accountability record CloudTrail provides for a security review.
Why the other options are wrong:
- A — CPU utilization is a performance metric — that's CloudWatch's job, not an audit trail.
- B — Application latency is operational performance monitoring, again CloudWatch territory.
- C — Visitor counts are usage/operational metrics, not an API audit of account changes.
Common trap: Equating "logs" with "monitoring." Anything about metrics, utilization, or latency is CloudWatch; anything about "who changed/accessed what for an audit" is CloudTrail.
Q10 An auditor wants to confirm that an EC2 instance is currently tagged correctly and was always tagged according to policy, and also wants to automatically flag any resource that drifts out of compliance. Which service should they use?
- AWS Config
- AWS CloudTrail
- Amazon CloudWatch Logs
- Amazon Macie
Answer: A
Why A is correct: AWS Config continuously records resource configurations (including tags), keeps a history of how they changed, and evaluates them against rules — automatically marking resources non-compliant when they drift. That matches "always tagged correctly" plus "flag drift."
Why the other options are wrong:
- B — CloudTrail logs the API call that changed a tag, but it does not continuously evaluate compliance state or flag configuration drift.
- C — CloudWatch Logs store operational log data, not resource configuration compliance.
- D — Macie discovers and protects sensitive data in S3; it is not a configuration-compliance tracker.
Common trap: "Always tagged / drift / compliant" phrasing pulls toward Config, even though CloudTrail recorded the underlying tag-change event. Audit of state and compliance = Config; audit of the action = CloudTrail.
Q11 Which statement about CloudTrail is TRUE for a typical AWS account?
- CloudTrail must be manually enabled before any API activity is ever recorded
- CloudTrail only works for Amazon S3 and no other service
- CloudTrail replaces the need for IAM permissions
- CloudTrail records management events and lets you view recent account activity in Event history without creating a trail
Answer: D
Why D is correct: CloudTrail automatically records management (control-plane) events, and you can browse the last ~90 days in Event history without creating a trail. Creating a trail is what you do for long-term delivery to S3, but basic recent activity is already captured.
Why the other options are wrong:
- A — Recent management activity is captured automatically; you don't have to enable anything just to see Event history.
- B — CloudTrail logs API activity across a wide range of AWS services, not just S3.
- C — CloudTrail is an audit tool; it records actions but does not grant or replace IAM permissions, which control who is allowed to act.
Common trap: Believing nothing is logged until you create a trail. Management events are recorded automatically; the trail is mainly for durable storage and broader/long-term capture.
Q12 A manager says: "I want one tool to tell me how fast our app responds, and a different tool to tell me who changed our firewall rules." Which pairing correctly matches those two needs?
- CloudTrail for response speed; CloudWatch for who changed the rules
- Config for response speed; VPC Flow Logs for who changed the rules
- CloudWatch for response speed; CloudTrail for who changed the rules
- Inspector for response speed; Macie for who changed the rules
Answer: C
Why C is correct: CloudWatch monitors performance metrics like latency and response time ("how fast"). CloudTrail records the API call and identity behind a change to security/firewall rules ("who changed it"). That is the textbook split between the two services.
Why the other options are wrong:
- A — This reverses the roles — CloudTrail isn't a performance monitor and CloudWatch isn't the identity-of-change auditor.
- B — Config tracks configuration state, not app response speed; Flow Logs show network traffic, not the user who changed a rule.
- D — Inspector finds vulnerabilities and Macie protects sensitive data; neither measures latency or audits rule changes.
Common trap: Swapping CloudWatch and CloudTrail. Remember: CloudWatch = "watch" performance/metrics; CloudTrail = "trail" of who did what.
Q13 A security analyst wants to enrich an investigation by knowing the exact identity, timestamp, source IP, and the AWS service endpoint for a suspicious API call. Which service field set comes directly from CloudTrail logs?
- The caller identity, event time, source IP address, and the API action that was invoked
- The CPU and memory usage of the instance at the time
- The accepted/rejected status of each network packet
- The number of unread CloudWatch alarms
Answer: A
Why A is correct: CloudTrail event records include the identity that made the call, the time, the source IP address, and the API action requested. These are exactly the fields a security analyst uses to reconstruct who did what during an investigation.
Why the other options are wrong:
- B — CPU and memory usage are performance metrics captured by CloudWatch, not by the CloudTrail audit log.
- C — Packet accept/reject status comes from VPC Flow Logs, which record network traffic rather than API calls.
- D — Alarm counts are a CloudWatch concept and have nothing to do with the contents of a CloudTrail event.
Common trap: Expecting CloudTrail to include performance or packet data. It records the API-call metadata (who/what/when/where), not metrics or network packets.
Q14 By default, CloudTrail records management events but does NOT record S3 object-level reads/writes. Why are these data events off by default?
- Because S3 object access is recorded by AWS Config instead
- Because data events are extremely high volume and can add significant logging cost, so they are opt-in
- Because data events are illegal to log for compliance reasons
- Because CloudTrail cannot technically capture S3 activity at all
Answer: B
Why B is correct: Data events (like individual S3 object GET/PUT operations) happen at very high volume in busy accounts, so logging them all can add meaningful cost. CloudTrail therefore leaves data events off by default and lets you opt in only where you need that detail.
Why the other options are wrong:
- A — Config does not capture object-level S3 read/write activity; that's a CloudTrail data-event capability when enabled.
- C — There is nothing illegal about logging data events; the reason is volume and cost.
- D — CloudTrail absolutely can capture S3 object-level activity when data events are turned on; it just isn't on by default.
Common trap: Assuming CloudTrail logs everything including every file read. Object-level data events must be explicitly enabled, mainly because of their high volume and cost.
Q15 A compliance officer wants assurance that the CloudTrail log files stored in S3 have not been tampered with after delivery. Which idea aligns with CloudTrail's purpose as a trustworthy audit source?
- CloudTrail automatically deletes logs every 24 hours to prevent tampering
- CloudTrail logs cannot be stored in S3, only in CloudWatch
- Integrity can only be confirmed by manually re-creating every API call
- CloudTrail offers log file integrity validation so you can verify logs were not altered after delivery
Answer: D
Why D is correct: CloudTrail provides log file integrity validation, which lets you confirm that delivered log files have not been changed or deleted after CloudTrail wrote them. For an audit source to be trustworthy, this tamper-evidence is exactly what a compliance officer wants.
Why the other options are wrong:
- A — CloudTrail does not auto-delete logs daily; that would defeat the purpose of long-term auditing.
- B — CloudTrail trails commonly deliver log files to S3; that is the standard archive destination.
- C — You don't re-create API calls to verify integrity; CloudTrail's integrity validation handles this for you.
Common trap: Assuming an audit log is automatically trustworthy. The exam wants you to know CloudTrail has integrity validation so the logs themselves can be proven unaltered.
Q16 An exam scenario gives four needs. Which one is best served by CloudTrail rather than the look-alike service named beside it?
- Set a billing budget alert when spend exceeds a threshold — better served by AWS Budgets
- Track CPU and disk metrics to autoscale a fleet — better served by CloudWatch
- Provide an account-wide record of API calls and account activity for a security audit — better served by CloudTrail
- Evaluate whether resources comply with tagging and encryption rules over time — better served by AWS Config
Answer: C
Why C is correct: An account-wide record of API calls and account activity for a security audit is the exact job of CloudTrail. The other three needs each correctly map to a different service, so only this one is genuinely a CloudTrail use case.
Why the other options are wrong:
- A — Budget/spend alerts belong to AWS Budgets (cost management), not CloudTrail, and the option itself says so.
- B — CPU/disk metrics and autoscaling triggers are CloudWatch, not CloudTrail.
- D — Ongoing resource compliance (tagging/encryption rules over time) is AWS Config, not CloudTrail.
Common trap: Each distractor is a real, correct pairing for a different service — the only one that names CloudTrail correctly is the audit/API-activity record. Match the need to the right tool, not just any logging service.