DOP-C02 Monitoring and Logging Practice Question
A DevOps engineer is setting up monitoring for an Amazon S3 bucket that stores sensitive data. The engineer needs to be notified whenever an object in the bucket is accessed by a user or application, including read and write operations. Which AWS service should the engineer use to capture these events and trigger notifications?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Configure S3 event notifications to send events to an SNS topic for object-level operations.
Amazon S3 can be configured to send event notifications to SNS, SQS, or Lambda for object-level operations (e.g., PutObject, GetObject). This provides real-time notifications for read and write access. Option B is incorrect because CloudTrail data events capture object-level API calls but do not provide real-time notifications; they require additional setup with CloudWatch Logs and alarms. Option C is incorrect because AWS Config records configuration changes, not individual object access events. Option D is incorrect because CloudWatch metrics track bucket-level statistics, not per-object access, and cannot trigger notifications for individual object access.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Configure S3 event notifications to send events to an SNS topic for object-level operations.
Why this is correct
S3 event notifications are the most direct service for this use case: they emit near-real-time events for object-level operations such as s3:ObjectCreated:*, s3:ObjectRemoved:*, and s3:ObjectRestore:*, and can deliver them to an SNS topic without any polling or forensic analysis. By configuring an SNS topic as the destination, the DevOps engineer can receive immediate notifications for each action on objects, with optional prefix/suffix filtering to reduce noise. This provides operational awareness of who/what performed an operation, which CloudTrail and Config cannot do in real time.
- ✗
Enable AWS CloudTrail data events for the S3 bucket and configure CloudWatch alarms on the log group.
Why it's wrong here
While CloudTrail data events do record object-level operations like GetObject and PutObject, they are written to CloudWatch Logs asynchronously — typically with several minutes of latency — and require a metric filter and alarm to be built on top of the log group before any alert can fire. The log-based approach therefore cannot provide the near-real-time alerting that S3 event notifications offer, and it is better suited for audit and compliance forensics than for triggering immediate operational responses. Even with a CloudWatch alarm, the detection delay and the need for filter patterns make this an inferior monitoring choice for the requirement.
- ✗
Use AWS Config to record S3 resource changes and trigger an SNS notification.
Why it's wrong here
AWS Config is designed to track configuration changes to the S3 bucket itself — such as bucket policies, encryption settings, lifecycle rules, and tags — and to evaluate those changes against rules, not to emit events for every GET, PUT, or DELETE on individual objects. When a Config rule detects a noncompliant bucket configuration, it can trigger an SNS notification, but that notification has nothing to do with object-level access operations. As a result, this approach would remain silent for the exact operations the engineer needs to monitor, because Config has no insight into data events occurring inside the bucket.
- ✗
Use Amazon CloudWatch metrics for the S3 bucket and set an alarm on the NumberOfObjects metric.
Why it's wrong here
The NumberOfObjects metric in Amazon CloudWatch reports the total count of objects stored in the bucket and is updated only periodically (often daily for storage metrics), so it cannot reflect individual access attempts or object-level operations such as object creation or deletion in real time. Setting an alarm on this metric would only detect large changes in total object count, not a specific PUT or GET, and it provides no detail about the caller, the object key, or the time of the operation. Therefore, this metric is irrelevant for monitoring object-level operations and would miss the alerts the engineer needs.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 1,013 original DOP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DOP-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DOP-C02 exam.