DOP-C02 SDLC Automation Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Increase the repository size limit in CodeCommit settings.

  Why it's wrong here

  CodeCommit enforces a hard service quota of 10 GB per repository, and this limit cannot be increased through any configuration setting or support request. Even if the quota could be raised, enlarging the limit would not address the underlying problem of repository bloat; every clone and fetch would still have to transfer the entire history, including all large binaries, causing poor performance and higher storage costs. The correct approach is to prevent large files from ever entering the Git object database.

• ✓

  Use Git LFS (Large File Storage) and configure it to store binaries in S3.

  Why this is correct

  Git LFS solves the binary bloat problem by replacing each large file in the repository with a tiny text pointer, while the actual file content is stored in a separate, scalable LFS store—in this case, an S3 bucket you configure. During checkout, the Git LFS client retrieves the real file from S3 transparently, so developers see the full content without the repository itself growing. This keeps CodeCommit clones fast, avoids the 10 GB limit, and integrates smoothly with existing Git branching and merging workflows.

• ✗

  Periodically run a script to remove large files from the commit history.

  Why it's wrong here

  Rewriting history to remove large files typically requires using git filter-branch or git filter-repo, which creates new commit IDs for every affected commit and forces a force push that invalidates all existing clones. This is highly disruptive for other developers and can cause repository divergence or accidental data loss. Moreover, it is a reactive, one-time cleanup that does not prevent future large files from being added, and the removed blobs can remain in the reflog until garbage collection, so it is not a sustainable solution.

• ✗

  Use S3 directly for storing binaries and reference them in code.

  Why it's wrong here

  Storing binaries directly in S3 and referencing them via URLs or file paths in code is a manual pattern that shifts the burden of upload, download, access control, and versioning to the developers. This approach lacks Git's built-in provenance, atomic commit semantics, and code-review integration, making it easy to break builds when a referenced object is missing or overwritten. Git LFS provides a standardized, transparent client-side mechanism that keeps the Git workflow intact while relocating the heavy data, making it a much more robust solution.