Source control for infrastructure and configuration

Why this matters

CompTIA's bullet is managing code with source control techniques, and in a cloud context "code" means rather more than application source. Templates, pipeline definitions, policy documents, configuration, runbooks and dashboards all belong in version control, because all of them are things that change production and all of them benefit from history and review.

Everything in the earlier domains assumes this. Infrastructure as code needs somewhere for the code to live. Immutable infrastructure needs a mapping from a running environment to an exact revision. The audit evidence in objective 4.4 comes largely from commit and review history. This lesson is that foundation.

The lesson

Repositories, commits and history as the record of who changed what and why

A repository holds files and their complete history. A commit records a set of changes with an author, a timestamp and a message. That history is the part with operational value, and it answers questions nothing else can:

• What changed? The diff, exactly.
• When? A timestamp on every change.
• Who? An author on every commit — and this is one of the strongest audit trails an organisation has.
• Why? The commit message, which is where most teams under-invest. A message saying "fix" is a lost explanation; one saying "raise the connection pool to 40; the previous 20 exhausted under the month-end batch" answers the question that will be asked in a year.
• What did it look like then? Any past state can be recovered exactly, which is what makes "roll back to the last known good" a real operation.

The first question of most incidents is what changed? (objective 3.3). An estate where everything is in source control answers it by reading the log; an estate where half the changes were made in a console does not.

Two practical disciplines:

• Commit small and often. A commit changing one thing is reviewable and revertible. A commit changing forty is neither, and when one part turns out to be wrong the whole thing has to be unpicked.
• Never commit generated artefacts, state files or secrets. State files in particular hold credentials in plain text (objective 2.2). Use an ignore file so it is not left to memory.

How to organise repositories is a genuine trade: a monorepo keeps everything together with consistent tooling and atomic cross-cutting changes; multiple repositories give independent lifecycles, narrower access control and clearer ownership. For infrastructure, the useful principle matches objective 2.2's: separate by blast radius and rate of change, so a routine application change cannot touch the network.

Branching strategies, and the one a small team can actually keep to

A branch is an independent line of work that can be merged back. Strategies differ in how many long-lived branches exist and how long work stays separate.

Trunk-based development. Everyone works on short-lived branches off a single main branch and merges within a day or two. Main is always releasable; incomplete features are hidden behind feature flags. Simple, minimal merge pain, and it is what continuous integration actually requires.

GitHub flow. Main plus feature branches, merged via pull request, deployed from main. Essentially trunk-based with an explicit review step — and the right default for most teams, including small ones.

Gitflow. Long-lived develop and main branches plus release, feature and hotfix branches. Designed for versioned software with scheduled releases and supported older versions. Powerful, heavy, and a poor fit for continuously deployed cloud services — it is frequently adopted by teams who do not need it and then generates constant merge conflict.

Environment branches — a branch per environment, promoted by merging. It sounds tidy and it drifts: branches diverge, cherry-picking begins, and you lose the guarantee that what is in staging is what will be in production. The better pattern is one revision promoted through environments with configuration supplied per environment (objective 2.2).

The honest recommendation, and the exam-safe one: short-lived branches merged frequently. The longer a branch lives, the more it diverges and the more painful and risky the merge — which is the reasoning behind continuous integration in the next lesson.

Pull requests and review, and the infrastructure change that needs a second pair of eyes

A pull request proposes a change and invites review before merging. It is the single most valuable practice in this lesson.

What it delivers:

• A second pair of eyes on a change that will alter production. For infrastructure this is the control that the console never had.
• A place for automated checks — lint, validate, policy scan, plan, security scan — with the results visible in the review.
• A durable record of what was proposed, what was discussed, who approved it and when. This is exactly the change-approval evidence an auditor samples (objective 4.4).
• Knowledge sharing, which matters more than it sounds in a team where one person knows the network.

Reviewing infrastructure changes well means looking at things application reviews do not:

• The plan output, not just the diff. What will actually happen, and particularly anything marked for replacement rather than update (objective 2.2).
• Blast radius. Which environments and which resources this touches.
• Security implications — a widened security group, a broadened policy, a disabled log, a removed encryption setting.
• Whether it is reversible, and how.
• Cost, since a change to an instance type or a storage class is a recurring financial commitment.

Enforce the important parts with branch protection: require review, require checks to pass, prevent direct pushes to main, and require signed commits where provenance matters. A policy that depends on people remembering is not a policy.

One caution worth keeping honest: review is a quality practice, and treating it as a security boundary has limits when the same small team writes and approves everything. Where separation of duties is genuinely required, it has to be enforced by who is permitted to approve, not by the existence of a review step.

Tags and releases, so a deployed environment maps to an exact revision

A tag is a permanent name for a specific commit. Releases build on tags with notes and artefacts.

Why this matters operationally: you must be able to answer "what exactly is running in production?" with a specific revision, not a branch name. A branch moves; a tag does not.

The chain to keep intact: commit → build → artefact → deployment. Every deployed thing should be traceable back to the exact commit it came from, and the usual mechanism is embedding the commit identifier into the artefact and exposing it — in an image tag, in a version endpoint, in the instance's tags. That turns "which version is this?" into a lookup rather than an investigation, and it is what makes a rollback precise.

Two related points:

• Semantic versioning — major.minor.patch, where major signals a breaking change. Essential for shared modules and libraries (objective 2.2), where consumers pin a version and upgrade deliberately.
• Promote the artefact, not the source. Build once, then move that exact artefact through environments. Rebuilding per environment means the thing tested is not the thing deployed, which quietly undermines all the testing.

Secrets that must never be committed, and the scan that catches them before push

The final rule, and it is the one with the most expensive failures.

A secret committed to a repository must be treated as compromised, even if the commit is amended or the repository is private. The reasons are specific and worth knowing:

• History is permanent. Deleting the line in a later commit leaves it in the history, exactly like the container layer problem in objective 1.4.
• Clones are distributed. Anyone who pulled has a copy, and removing it from the server removes nothing from their laptop.
• Public repositories are scanned continuously by automated tooling. Credentials pushed publicly are found and used in minutes, not days.
• Private is not safe. Repositories are made public by accident, access is broad, and forks persist.

So the response is always: rotate the secret first, then clean the history if you wish — in that order, because cleaning history without rotating changes nothing about the exposure.

Prevention, in layers:

• Pre-commit hooks that scan for credential patterns before a commit is made. The cheapest point to catch it.
• Server-side push protection, which rejects a push containing a detected secret. Better, because it does not depend on each developer's setup.
• Continuous scanning of the repository and its history, catching what got through and what was committed before scanning existed.
• An ignore file covering environment files, state files, key files and credential caches.
• Short-lived credentials everywhere (objectives 2.4 and 4.2), which is the structural fix: a credential that expires in an hour is a much smaller incident than one that does not expire at all.

The same reasoning extends to what else does not belong in a repository: customer data, production database dumps, private keys and internal network diagrams. A repository is widely readable within an organisation, and its history is forever.

What to take into the exam

• History answers what, when, who and why — and what changed? is the first question of most incidents.
• Short-lived branches merged frequently. Gitflow is heavy for continuously deployed services; environment branches drift — promote one revision instead.
• Pull requests provide review, automated checks and the change-approval evidence auditors sample. Enforce with branch protection.
• Review infrastructure changes for plan output, blast radius, security, reversibility and cost.
• Tags are permanent; branches move. Keep commit → build → artefact → deployment traceable, and promote the artefact rather than rebuilding.
• A committed secret is compromised: history is permanent, clones are distributed, private is not safe. Rotate first, then clean. Prevent with pre-commit hooks, push protection and continuous scanning.