DOP-C02 SDLC Automation Practice Question
A DevOps team uses AWS CodePipeline with an S3 source action and CodeBuild as a build provider. The pipeline has a manual approval step before deployment. Recently, the team noticed that the pipeline automatically starts when a new object is uploaded to the S3 bucket, even if the object is not the source code. They want to ensure that the pipeline only triggers on changes to the source code directory. What is the MOST efficient solution?
⚠ Common exam trap
The trap here is that candidates may overcomplicate the solution by choosing CloudWatch Events (Option A) or versioning (Option B), not realizing that S3 event notifications already have built-in prefix filtering that directly solves the problem without extra services or configuration.
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 the S3 event notification to use a prefix filter that matches the source code directory.
S3 event notifications support prefix and suffix filters, allowing you to specify that only objects uploaded to a particular directory (e.g., 'source-code/') trigger the event. By configuring the S3 event notification with a prefix filter matching the source code directory, the pipeline will only start when a new object is uploaded to that specific path, ignoring uploads to other directories. This is the most efficient solution as it avoids unnecessary pipeline executions without adding extra components or manual intervention.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use Amazon CloudWatch Events to create a custom rule that matches the source code path and triggers the pipeline.
Why it's wrong here
Using Amazon CloudWatch Events to trigger the pipeline would not address the existing S3 source action's broad triggering behaviour. CloudWatch Events provides a separate mechanism to *start* a pipeline, but it does not modify or filter the events that the CodePipeline's native S3 source action already processes. This option is tempting because CloudWatch Events is excellent for creating custom, granular rules to trigger AWS services, including CodePipeline, based on various event patterns, such as specific S3 object key prefixes or suffixes, offering advanced control over pipeline initiation for complex scenarios.
- ✗
Enable versioning on the S3 bucket and configure the pipeline to use the latest version.
Why it's wrong here
Enabling S3 bucket versioning merely creates new immutable object versions for every write; it does not apply any prefix or suffix filtering to the S3 event notification stream. CodePipeline's S3 source action is still triggered by any ObjectCreated event in that bucket, and new versions generate events for every object key. Even if you point the pipeline at the latest version, that setting only selects which object revision to download, not which uploads start the pipeline.
- ✓
Configure the S3 event notification to use a prefix filter that matches the source code directory.
Why this is correct
S3 event notifications natively support prefix and suffix filters, so you can create an s3:ObjectCreated:* notification whose prefix corresponds to the source code directory (for example, 'source/'). This scopes the event stream so CodePipeline is invoked only when objects are created under that specific path, while uploads to any other directory in the same bucket are ignored. This directly corrects the over-broad triggering behaviour at the storage layer.
- ✗
Disable the S3 trigger and manually start the pipeline after each code commit.
Why it's wrong here
Disabling the S3 trigger and manually firing the pipeline after each commit removes the continuous integration aspect entirely, because every deployment depends on a human remembering to start it. This manual workflow is error-prone, does not scale across multiple developers or repositories, and obscures the audit trail of why a pipeline ran at a given time. It effectively abandons the automated event-driven architecture that CodePipeline’s S3 source is designed around.
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
This DOP-C02 question is part of Courseiva's 251-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.