DOP-C02 SDLC Automation Practice Question
A company uses AWS CodeCommit for source control. Developers frequently push large binary files (e.g., compiled JARs) to the repository, causing the repository size to grow rapidly and slowing down clone operations. The team wants to enforce a policy to reject pushes that contain files larger than 50 MB. Which approach should be used?
⚠ Common exam trap
Watch out — candidates often confuse CodeCommit triggers with Git hooks (like pre-receive hooks) or assume IAM policies can enforce content-based rules, when in fact IAM cannot inspect file contents and CodeCommit does not support server-side Git hooks.
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 a CodeCommit trigger that invokes an AWS Lambda function to validate file sizes and reject the push.
AWS CodeCommit supports custom triggers that invoke AWS Lambda functions on repository events, including pushes. By configuring a trigger for the 'push' event, a Lambda function can inspect each file in the push payload, check its size against the 50 MB threshold, and programmatically reject the push by returning an error response. This approach enforces the policy at the repository level without requiring client-side changes.
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 a CodeCommit trigger that invokes an AWS Lambda function to validate file sizes and reject the push.
Why this is correct
A CodeCommit trigger configured for push events can launch a Lambda function that inspects the incoming commits's metadata and calculates the size of each file. While native triggers are asynchronous, the Lambda can quickly delete the offending branch reference or tag, effectively rejecting the large-file push from a server-side governance perspective. This is the only option that applies custom validation logic that actually sees file content and can act to block the push, unlike IAM conditions, which cannot inspect Git payloads, or pre-receive hooks, which CodeCommit does not support.
- ✗
Set up an Amazon CloudWatch Events rule to monitor repository size and alert when it exceeds a threshold.
Why it's wrong here
Setting up an Amazon CloudWatch Events rule to monitor repository size is purely reactive: it can only alert after a problematic push has already succeeded, leaving the large file stored in the repository. Additionally, CodeCommit does not expose a native repository-size CloudWatch metric, so you would need extra custom tooling just to make such a rule work. Even with alerting, the rule cannot prevent a developer from pushing a 50 MB+ file, so it fails the 'reject' requirement entirely.
- ✗
Create an IAM policy that denies the `codecommit:GitPush` action if the file size exceeds 50 MB.
Why it's wrong here
An IAM policy that denies codecommit:GitPush based on file size is impossible because IAM evaluates only the request context—principal, action, resource, and explicit condition keys such as source IP or MFA. There is no condition key like 'FileSize', and AWS would have to inspect the entire Git packfile during policy evaluation, which is not supported. Thus this option is both syntactically invalid and conceptually flawed, as IAM cannot see or judge file sizes.
- ✗
Use a pre-receive hook in the repository to reject large files by generating an S3 pre-signed URL.
Why it's wrong here
CodeCommit is a managed Git service and does not allow customers to install git server-side hooks (pre-receive, update, post-receive), so a pre-receive hook cannot be added to a CodeCommit repository. Furthermore, generating an S3 pre-signed URL is an unrelated mechanism used to upload objects to Amazon S3; in a Git push scenario it would not be invoked by the server and would not return a rejected status to the client. This option incorrectly combines Git hook mechanics with S3 upload preprocessing, and neither part works in a CodeCommit context.
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
One of 1,298 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.