Version control is not just a place to store code. Repository structure, branch permissions, review rules and automation triggers determine how software moves from a developer’s idea to a production artifact. The AZ-400 DevOps examination covers source-control strategy alongside build, delivery, security and feedback; Microsoft updated the English objectives in July 2026. A useful repository strategy balances safe collaboration with enough speed that teams do not bypass it. The best approach is seldom the most restrictive branch model or the largest monorepo. It is one that makes dependencies, ownership and the release path understandable under the organization’s real change patterns.
Choose repository boundaries based on change coupling
A monorepo can make coordinated changes easier when several services share tooling, interface contracts or deployment timing. It can also become slow and confusing if every small change triggers the entire organization’s test suite. Multiple repositories allow services to evolve independently but create versioning and compatibility challenges when shared libraries and contracts change. Before choosing, examine which components usually change together, who reviews them, how releases are coordinated and whether isolation provides a security or regulatory benefit. Organizational preferences alone are a weak substitute for evidence from actual workflows.
Consider a web application, background worker and shared API contract. If a change to the contract frequently requires simultaneous updates to all three, keeping them in a coordinated repository may reduce cross-project drift. If the worker is independently operated and has a different security boundary, a separate repository with a versioned contract may be safer. Document ownership and release interfaces either way. A repository strategy must include the dependency version policy; simply dividing files into folders does not establish how consumers learn about breaking changes or how teams will reproduce an earlier release.
Trunk-based development and branches serve different rhythms
Long-lived feature branches can preserve work in isolation, but they often accumulate merge conflicts and hide incompatibilities until late integration. Trunk-based development favors smaller changes integrated frequently into a protected mainline, often using feature flags for incomplete behavior. This can shorten integration feedback, provided tests and review controls are reliable. More structured release branches can still be appropriate for supported product versions or regulated maintenance cycles. The decision is not a contest between labels; it is about integration frequency, rollback requirements and the cost of maintaining multiple lines of code.
Set clear rules for branch protection. Require review for sensitive code, checks that genuinely test the change, and restrictions on direct modification of protected branches. Avoid granting exception authority so broadly that an urgent release bypasses every control. For emergency fixes, create a documented path with constrained approvers and post-incident review. Use small pull requests where possible; a 20,000-line change with mixed refactoring and security modifications is difficult to assess meaningfully. Review process quality is measured by defects prevented and clarity of ownership, not by the average number of approval clicks.
Code owners should correspond to accountable expertise
Ownership rules can route database migrations to data engineers and identity configuration to security specialists. But an owners file only helps when the people named have enough context and time to review. A central team required to approve every trivial change can create a queue that developers eventually circumvent. Define which paths or change categories warrant specialized review and keep ordinary refactoring within capable product teams. Revisit ownership when staff or architecture changes. Orphaned repositories and unavailable approvers are governance defects, not small administrative inconveniences.
Reviewers need meaningful evidence. Tests, security analysis and dependency changes should be visible alongside the code. A generated lockfile or configuration diff can contain subtle security implications that are easy to overlook in a large review. Use automated summaries as aids, not as final attestations. If AI-assisted code suggestions are used, verify licensing, security, performance and business behavior exactly as for human-written changes. A reviewer should not assume a plausible explanation accompanying a change proves that the change is correct.
Secrets and automation create invisible trust paths
Repository workflows often have broader privileges than contributors realize. A build job may hold access to package registries, cloud environments and deployment systems. Inspect where automation tokens can be used and which events invoke those workflows. Untrusted code from a pull request should not inherit production credentials. Prefer short-lived, scoped credentials and separate deployment jobs with explicit approval or trusted ref conditions. Check permissions of reusable workflows and shared actions; a convenient third-party dependency can become a supply-chain route into production if it is allowed to run with excessive authority.
Secret scanning helps detect accidental exposure, but teams also need a response process for rotation and investigation. Removing a secret from the latest commit does not ensure it disappeared from repository history or downstream logs. Treat an exposed credential as potentially compromised and revoke it as appropriate. Review whether contributors can alter security-sensitive workflow files without independent approval. If a service identity is granted blanket access to all subscriptions because it is easier to set up, the repository’s permission model has quietly become an infrastructure-administration policy. That risk belongs in design review.
Dependencies need ownership and update discipline
Modern software relies on open-source packages, container base images and internal libraries. A project can have clean source code and still ship a vulnerable or incompatible dependency. Track declared dependencies and their versions, scan for known vulnerabilities and licenses where appropriate, and review updates before promoting them. Automatic update proposals can reduce delay but need tests and sensible limits. A major-version upgrade that changes data handling or API behavior is not equivalent to a patch update. Keep an accurate bill of materials where the organization’s risk profile warrants it.
Supply-chain integrity also depends on where packages are fetched, which registries are trusted and how release artifacts are signed or verified. Use controlled package sources when appropriate and resist “temporary” workarounds that disable checksum validation. When a dependency incident occurs, the team should be able to identify affected builds and where they were deployed. A repository without reliable build provenance makes incident response expensive because operators cannot map a suspect dependency to actual production services.
Organize work around traceability
A useful source-control strategy connects requirements, work items, pull requests, test outcomes, build artifacts and deployments. The amount of ceremony should match the organization. Some teams need formal change records; others can use a lightweight issue and pull-request convention. What matters is that an investigator can answer who approved a change, which tests were run and when the new code became active. Unexplained hotfixes applied directly to servers create operational drift even if the immediate bug disappears. Bring emergency changes back into the repository so later deployments do not reverse them silently.
Do not measure repository health solely by commit volume or pull-request speed. Many tiny commits can still contain poor tests and unclear ownership. Better indicators include time to detect a regression, frequency of conflicts, release reproducibility and how often urgent changes bypass the normal path. Review repeated failures to see whether architecture or repository boundaries are causing friction. An organization may need to split a monorepo, improve test selection or clarify interface contracts rather than enforce another mandatory approval layer.
Repository choice affects incident isolation
A vulnerable shared authentication library is discovered on Friday evening. In a monorepo, the organization may be able to find affected references and coordinate fixes quickly, but its deployment process might be coupled in ways that slow independent releases. In a multi-repository environment, owners can patch and ship services separately, yet security responders may struggle to identify which repositories use the vulnerable package version. This is a concrete tradeoff for repository strategy. Build an inventory of critical dependencies and deployment ownership, and ensure the organization can search from a component to its running consumers.
Incident response tests whether conventions are real. Ask the team to find every service that depends on the library, identify the last deployed versions, determine who may approve emergency changes, and update build artifacts under controlled credentials. Record how long those tasks take and which step relies on undocumented personal knowledge. A repository structure that looks elegant in architecture diagrams but makes component impact impossible to trace is not serving the delivery organization. Source-control strategy should be judged by the clarity it provides during both ordinary collaboration and exceptional events.
A source-control design exercise
Imagine three teams maintaining an API, a mobile client and an infrastructure module. They release on different cadences but share authentication contracts. Define who owns breaking changes, how consumer compatibility is tested, and which branches can deploy to production. Next simulate a developer submitting a change that alters a shared schema and a workflow file in the same pull request. Decide which reviewers are necessary, which automated tests must run, and whether the proposed deployment identity would be safe if the change came from an untrusted contributor.
The point of Microsoft’s broader DevOps certification path is not merely to know Git commands. It is to design a collaboration system that continuously creates trustworthy artifacts. When source-control boundaries, automated checks and release governance express one coherent policy, teams can move quickly without turning every deployment into an exceptional event. A repository should make doing the right thing easier than doing an undocumented workaround.