DOP-C02 SDLC Automation Practice Question
A company is using AWS CodeCommit with multiple repositories. Developers are required to create pull requests for all changes, and the pull request must be associated with a JIRA issue key (e.g., PROJ-123) in the commit message. A DevOps engineer needs to enforce this policy automatically. Which approach meets the requirement with minimal operational overhead?
⚠ Common exam trap
A common mix-up: candidates choose Option C (CodeBuild) because they assume build-time validation is sufficient, but they overlook that CodeBuild runs after the pull request is merged, not before, making it ineffective for pre-merge enforcement.
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
✓
Create a CodeCommit trigger that invokes an AWS Lambda function to validate the pull request description and reject if missing JIRA key
CodeCommit triggers can invoke an AWS Lambda function on pull request events (e.g., created or updated). The Lambda function can parse the pull request description or commit messages for a JIRA key pattern (e.g., regex `[A-Z]+-\d+`) and, if missing, automatically reject the pull request by updating its status or adding a comment. This serverless approach enforces the policy without requiring any changes to developer workflows or additional infrastructure, minimizing operational overhead.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Store JIRA keys in an S3 bucket and configure a CloudWatch Events rule to check commits
Why it's wrong here
Storing JIRA keys in S3 and using CloudWatch Events (now Amazon EventBridge) to monitor CodeCommit commits is a fragile, off-band design. CloudWatch Events can relay repository events, but it cannot block or reject a pull request; you would need a separate Lambda to parse every commit message and then correlate it to a pull request, while the JIRA keys in S3 are not referenced by any native CodeCommit feature. This approach adds unnecessary moving parts and fails to enforce the policy at the point the pull request is created or updated.
- ✓
Create a CodeCommit trigger that invokes an AWS Lambda function to validate the pull request description and reject if missing JIRA key
Why this is correct
A CodeCommit trigger can be configured for pull-request events such as pullRequestCreated or pullRequestSourceBranchUpdated, invoking a Lambda function asynchronously. The Lambda parses the pull request description with a regex for a JIRA key such as [A-Z]+-[0-9]+, and if the key is missing it calls the CodeCommit API UpdatePullRequestStatus with status CLOSED to reject the PR and posts a comment explaining the failure. Because the logic runs in AWS managed services on every qualifying pull request event, enforcement is centralized and cannot be bypassed by individual developers.
- ✗
Use AWS CodeBuild to run a validation script during the build phase
Why it's wrong here
Running a validation script in AWS CodeBuild on the pull request branch is a post-commit check: the code is already committed and the PR already exists, so a build failure does not automatically close or reject the pull request. Even if you wire the build status as a required check, CodeBuild still evaluates source code and commit data, not the PR description field, and you would need separate custom logic to translate a failed JIRA-key condition into an API call to reject the PR. It also adds compute cost and slower feedback compared to a lightweight trigger-based Lambda.
- ✗
Require developers to install a pre-commit hook script locally
Why it's wrong here
A pre-commit hook is installed only on each developer's workstation and runs before a commit is created; it can be skipped with git commit --no-verify, and it is not present on shared build environments or other contributors' machines. Crucially, it fires at commit time, not when a pull request is opened or updated, so it cannot validate the pull request description. A client-side hook therefore provides no centralized, auditable enforcement for a company policy requiring JIRA keys.
Quick reference
Cloud Service Model Comparison
| Model | You Manage | Provider Manages | Examples |
|---|---|---|---|
| IaaS | OS, runtime, apps, data | Hardware, hypervisor, networking | EC2, Azure VMs, GCP Compute Engine |
| PaaS | Apps and data | OS, runtime, middleware, hardware | Elastic Beanstalk, Azure App Service |
| SaaS | Data and settings only | Everything else | Microsoft 365, Salesforce, Workday |
| FaaS / Serverless | Function code only | Infra, scaling, runtime | Lambda, Azure Functions, Cloud Run |
| CaaS | Containers and apps | Kubernetes, OS, hardware | EKS, AKS, GKE |
Go deeper
Related to this question
About these practice questions
This DOP-C02 question is part of Courseiva's 1,298-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.