200-901 Infrastructure and Automation Practice Question
A platform team stores network device configuration templates in a Git repository and wants every proposed change to be reviewed and validated before it reaches production devices. The team also needs an audit trail of who approved each change. Which Git-based workflow best meets these requirements?
⚠ Common exam trap
The trap here is equating version control with change control, when review gates and approval records come from the pull-request workflow rather than from Git storage alone.
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
✓
Developers commit to short-lived feature branches, open pull requests, require peer approval and CI validation, then merge to main for deployment.
Git-based change control with review and auditability is achieved through short-lived feature branches, pull requests with required approvals, automated CI validation, and merges to a protected main branch that triggers deployment. Direct pushes, personal-fork deployments, and tagging alone all skip the review gate and produce no approval record, so they cannot satisfy the validation and audit-trail requirements.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Developers each maintain a personal fork and deploy from their fork to production after local testing, merging upstream only monthly.
Why it's wrong here
Deploying from personal forks means unreviewed, divergent code reaches production, and monthly upstream merges create long-lived drift. There is no enforced review gate and no reliable record tying a production change to an approval, so both the validation and audit-trail requirements are unmet.
- ✓
Developers commit to short-lived feature branches, open pull requests, require peer approval and CI validation, then merge to main for deployment.
Why this is correct
Feature branches isolate work, pull requests create a review gate, required approvals and CI checks validate changes before merge, and the merge history plus review records form an audit trail. This workflow uses Git's native collaboration model to enforce review and traceability before templates reach production.
- ✗
Developers commit directly to main but tag each commit with a version number, and deployments always reference the latest tag.
Why it's wrong here
Tagging provides version identification but no review or validation step, so any commit still flows straight to production. Tags also do not capture who approved a change or whether tests passed, leaving the audit-trail and validation requirements unfulfilled despite tidy versioning.
- ✗
Developers push directly to the main branch, and a post-receive hook deploys the templates to devices immediately.
Why it's wrong here
Pushing straight to main bypasses review and validation entirely, and a post-receive hook that deploys on push would send unreviewed changes to production. There is also no approval record, so the audit-trail requirement fails even though the templates are versioned in Git.
Go deeper
Related to this question
About these practice questions
One of 975 original 200-901 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Cisco exam blueprint
This 200-901 practice question is part of Courseiva's free Cisco 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 200-901 exam.