AWS Cloud & DevOps Tutorial 0/70 lessons ~6 min read Lesson 25“IAM, VPC, EC2, Lambda, ECS, EKS, Terraform, CI/CD, and AWS operations”

Git Workflows and Repository Governance

[DevOps Principles and AWS Delivery Architecture](/learn/aws-cloud-devops-engineering/devops-principles-and-aws-delivery-architecture) gave TechLearningPro a delivery loop. This le

Course progress0%

Focus

15 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Git Workflows and Repository Governance

AWS Cloud & DevOps Engineering · Lesson 25 · DevOps Automation and IaC

Lesson Overview

DevOps Principles and AWS Delivery Architecture gave TechLearningPro a delivery loop. This lesson hardens the source side of that loop: how application and infrastructure repositories are branched, reviewed, owned, protected, versioned, and tagged so that AWS pipelines promote the right change for the right reason.

Git is not “developer tooling” separate from cloud operations. A CloudFormation template that opens a security group, an IAM policy JSON, a Terraform module, a Dockerfile base pin, and a Lambda handler are all production changes. If anyone can force-push main, bypass reviews, or commit long-lived AWS keys, your CodePipeline and GitHub Actions sophistication is theater. Repository governance is blast-radius control expressed as branch rules.

You will design workflows for app repos and infra repos—sometimes separate, sometimes monorepo—with CODEOWNERS, protected branches, required status checks, signed commits where policy demands, semantic version tags, and release discipline that maps to ECR digests and stack change sets. Primers in /learn/git cover general hygiene; this course applies an AWS and IaC lens without cloning that course. Next, CI/CD Pipeline Fundamentals turns these review gates into pipeline stages.

Learning Objectives

By the end of this lesson you will be able to:

Explain why Git governance is a production control for AWS workloads, not a nice-to-have.
Compare trunk-based habits with release-branch workflows and choose deliberately for TechLearningPro services.
Separate or combine app and infrastructure repositories with clear ownership boundaries.
Write CODEOWNERS rules that route IAM, networking, and payment paths to the right reviewers.
Configure protected branches: no force-push, required reviews, required status checks, linear history options.
Define pull request norms for IaC diffs (readable plans, blast-radius notes, rollback thoughts).
Use tags and versioning that map to immutable AWS artifacts (images, template packages).
Keep secrets out of Git; rotate anything that leaked; prefer OIDC later over committed keys.
Design break-glass merge procedures with audit and retroactive review.
Map repository events (PR open, merge to main, tag) to CI/CD triggers without trusting branch names alone.
Apply least privilege to bot accounts and machine users that commit or open PRs.
Budget and clean up unused GitHub/org resources and any AWS resources created while testing hooks.
Produce a branching and release policy document for multiple TechLearningPro services.
Connect governance failures to real AWS incident classes (wrong stack, wrong account, secret exposure).

Prerequisites

DevOps Principles and AWS Delivery Architecture: build → test → deploy → observe; immutable artifacts.
Comfort with basic Git: clone, branch, commit, push, pull request—as covered in /learn/git primers.
AWS Identity and Access Management: knowing why IAM JSON in Git is high risk.
Module 2 awareness: Dockerfiles, task definitions, ASL, and secrets patterns will appear in diffs.
A sandbox GitHub (or CodeCommit) org/repo you can configure; do not experiment with protections on production orgs without change windows.
Budget alert still active in the AWS sandbox for any webhook or CodeStar Connections tests that create billable resources.

Detailed Core Concepts

Git as the control plane for AWS changes

Every merge to a protected trunk is a candidate for deployment. That means:

Review quality equals production quality.
Bypass equals untracked change—similar to console drift.
History is an audit artifact alongside CloudTrail.

TechLearningPro platform policy: no anonymous prod. If it runs in AWS, its definition lived in Git at some SHA—or you have an incident-level exception with a deadline to reconcile.

App repos vs infrastructure repos

Separate repos (common enterprise pattern):

tlp-enrollment-api — application code, unit tests, Dockerfile.
tlp-platform-infra — accounts, VPC modules, shared pipelines, OIDC providers.
tlp-enrollment-infra — service-specific stacks referencing platform modules.

Benefits: different CODEOWNERS, different release cadences, clearer blast radius. Costs: cross-repo version coupling (API needs IAM permission that lands in infra first).

Monorepo (also valid):

Paths like services/enrollment/, infra/modules/, pipelines/.
CODEOWNERS per path; path-filtered CI.
Benefits: atomic cross-cutting PRs. Costs: tooling complexity; noisy clones; stricter ownership discipline required.

Neither is morally superior. Document the choice in an ADR. Hybrid is normal: platform infra separate; product monorepo for several services.

Branching strategies with an AWS lens

Trunk-based (preferred default for TechLearningPro product teams):

Short-lived feature branches.
Frequent merges to main.
Feature flags for incomplete work.
Tags mark releases; pipelines promote artifacts from SHAs.

GitFlow-style long release branches:

Useful when you must support multiple production versions (rare for pure SaaS APIs; more common for on-prem agents).
Risk: cherry-pick debt; “hotfix” culture that skips gates.
If used, bind release branches to protected rules equal to main.

Environment branches (dev, staging, prod as long-lived branches):

Often an anti-pattern for AWS delivery: encourages rebuild-per-environment and drift.
Prefer environment promotion of artifacts over merging code between env branches.
If legacy requires env branches, treat them as deploy refs only with extreme caution and sunset plans.

Pull requests as change records

A good TechLearningPro PR for AWS-related work includes:

Why (ticket/ADR link).
What changes in AWS terms (new IAM action, wider SG, new queue).
Risk and blast radius (account, region, data class).
Test evidence (unit, cfn-lint, terraform plan summary, screenshot of staging smoke).
Rollback plan (previous tag, previous template, disable flag).

“LGTM” without reading an IAM diff is a governance failure. Reviewers own the merge as much as authors.

CODEOWNERS

CODEOWNERS maps paths to teams or users who must review. Examples:

text
# Infrastructure and identity — platform + security
/infra/iam/              @tlp/platform @tlp/security
/infra/network/          @tlp/platform
**/cloudformation/**     @tlp/platform

# Payment and enrollment critical paths
/services/payments/      @tlp/payments-guild
/services/enrollment/    @tlp/enrollment-guild

# Pipelines
/.github/workflows/      @tlp/platform
/buildspec.yml           @tlp/platform

Rules:

Keep the file in the default branch; protect it itself.
Prefer teams over individuals.
Do not CODEOWN everything to one hero engineer.
For IaC, require platform review on networking and IAM even if a product team authors the change.

Protected branches

Typical main protections for TechLearningPro:

Require pull request before merge.
Require N approving reviews (often 1 for low risk, 2 for IAM/network/payments).
Dismiss stale approvals on new commits.
Require status checks to pass (CI build, lint, IaC validate, secret scan).
Restrict who can push; deny force-push; deny deletions.
Optionally require linear history / squash merges for readable SHAs.
Optionally require signed commits if org policy demands.

Protected tags prevent rewriting release history that pipelines trust.

Status checks and truthful green

Status checks must mean something. A check named build that only echoes “ok” teaches lying. Required checks should include at least:

Compile/unit for apps.
Formatter/linter.
IaC validate / plan (non-apply) for infra.
Secret scanning.
For container paths: image build (and ideally scan).

Flaky checks destroy governance: engineers pressure admins to remove requirements. Fix flakes; do not hollow out protection.

Versioning and tags

Map Git tags to AWS artifacts:

enrollment-api@1.14.2 → ECR image tagged 1.14.2 and digest recorded.
infra-platform@2026.11.11 or semver for modules.
Annotated tags with message linking changelog.

Pipelines should deploy by digest even when humans talk in tag language. Tags are pointers; digests are truth.

Avoid moving tags (latest, floating prod). Mutable tags break forensic “what was live?”

Secrets and credential hygiene

Never commit:

AWS access key IDs/secrets.
OAuth tokens, private keys, .env with prod credentials.
Connection strings with passwords.

If committed: rotate immediately; purge from history if policy requires; treat as incident. Prefer Secrets Manager / Parameter Store references in code and OIDC in GitHub Actions for AWS Deployments.

Pre-commit hooks and secret scanning are gates, not substitutes for education.

Machine users and bots

Dependabot, Renovate, pipeline bots that open PRs need constrained permissions. A bot that can push to main bypasses human governance. Prefer bots that open PRs into protected branches with required reviews—auto-merge only for low-risk, policy-approved update classes.

CodeCommit vs GitHub/GitLab (awareness)

AWS CodeCommit integrates tightly with IAM and CodePipeline. GitHub/GitLab dominate ecosystem tooling and Actions. TechLearningPro examples in later lessons use both CodePipeline and GitHub Actions. Governance principles are portable: protected default branch, owners, reviews, no keys in repo. Connection resources (CodeStar Connections) are AWS resources—tag and budget them.

Monorepo path filters

When one repo holds many services, CI should not rebuild the universe on a docs typo. Use path filters so enrollment changes do not redeploy payments. Governance still requires that shared module changes notify all consumers—CODEOWNERS on libs/ and explicit ownership of breaking changes.

Release policy multi-service

Document per service:

Branch model.
Review requirements.
Tag scheme.
Cadence (continuous delivery vs scheduled).
Hotfix path.
Who can approve prod-affecting merges for IAM/network.

This document is the practical exercise deliverable for this lesson.

Architecture and Design Diagrams

PR-to-trunk governance flow:

mermaid
flowchart TB
  Dev[Developer branch]
  PR[Pull request]
  Own[CODEOWNERS review]
  CI[Required status checks]
  Prot{Protected branch rules}
  Main[main / trunk]
  Tag[Release tag]
  Pipe[CI/CD trigger]
  AWS[AWS environments]

  Dev --> PR --> Own --> CI --> Prot
  Prot -->|pass| Main --> Tag --> Pipe --> AWS
  Prot -->|fail| Dev

App + infra dual-repo coordination:

mermaid
sequenceDiagram
  participant App as App repo PR
  participant Infra as Infra repo PR
  participant Review as CODEOWNERS
  participant CI as Status checks
  participant Stg as Staging
  participant Prod as Production

  Infra->>Review: IAM permission change
  Review->>CI: validate template
  CI->>Stg: apply infra first
  App->>Review: code using new permission
  Review->>CI: tests
  CI->>Stg: deploy app digest
  Stg->>Prod: promote after gates

CODEOWNERS blast-radius map:

mermaid
flowchart LR
  subgraph high [High blast radius]
    IAM[IAM policies]
    Net[VPC / SG / NACL]
    Pipe[Workflow / buildspec]
  end
  subgraph med [Medium]
    API[Enrollment API]
    ASL[Step Functions ASL]
  end
  subgraph low [Lower]
    Docs[Docs / copy]
    UI[Non-auth UI strings]
  end
  high --> PlatSec[Platform + Security]
  med --> Guild[Service guild]
  low --> Any[Any reviewer + CI]

Technical Explanation

Why force-push is forbidden on trunk

Force-push rewrites SHAs that pipelines, tags, and incident timelines reference. After a force-push, “deploy commit abc” may not exist, breaking forensics and artifact lineage. Protected branches deny force-push for this reason. Recovery from bad commits uses revert commits, not history rewriting on shared trunks.

Required reviews vs rubber stamps

Two approvals that never read the diff are worse than one careful review—they create false confidence. Pair quantitative rules (N approvals) with qualitative norms (IAM diffs need platform comments; “approve” implies you understand blast radius). Rotate reviewers to avoid buddy stamping.

Dismiss stale approvals

Author adds a “small” IAM * after approval. Without dismiss-stale, the old approval ships the new risk. Always enable dismiss stale approvals on protected production trunks.

Status check naming stability

If you rename a required check, merges break until admins update the protection rule. Version check names carefully; treat renaming as a platform change with CODEOWNERS on the workflow files.

Annotated tags and evidence

bash
# Example pattern — verify git options in your environment
git tag -a enrollment-api-1.14.2 -m "Release 1.14.2: Retry-After headers"
git push origin enrollment-api-1.14.2

Pipelines listening to tag pushes should still resolve the tag to a SHA and build or promote the artifact for that SHA. Prefer promote-on-tag of an already-built digest from trunk CI when possible (build once).

CODEOWNERS syntax pitfalls

Last matching pattern wins in CODEOWNERS—order matters.
Teams must be visible to the repo.
Optional owners vs required depends on platform settings—know whether ownership is advisory or blocking.
Do not own binary assets with individuals who leave the company; use teams.

Branch naming and least privilege for humans

Developers need write to their branches, not to main. Admins who can bypass protections should be a tiny set; every bypass should be logged and rare. Org owners are not exempt from culture—even if the tool allows bypass.

Linking PRs to AWS accounts

PR templates should ask: which account(s) does this affect? Sandbox-only changes still need review if they alter shared modules. Production account paths need higher bar. This question prevents “I tested in sandbox” merges that change a module used by prod.

Git hooks vs server-side enforcement

Client hooks help; they are optional. Server-side branch protection and required checks are mandatory enforcement. Never rely only on “everyone installed the pre-commit hook.”

Submodules and vendoring (awareness)

Submodules complicate SHA lineage and CI. Prefer packages or monorepo paths unless you have a strong reason. If used, pin submodule SHAs and review submodule pointer bumps as first-class changes.

Infrastructure PR review heuristics

Reviewers should ask:

Does this widen network exposure?
Does this add * IAM actions or resources?
Does this change encryption or public access blocks?
Is there a destroy path / retain policy for stateful resources?
Will apply order break dependents?
Is the plan attached or reproducible in CI?

Application PR review heuristics for AWS

Are resource names/ARNs hard-coded to the wrong account?
Do logs risk PII?
Are retries idempotent?
Does the Dockerfile use floating latest bases?
Are new env vars actually secrets?

Mapping to pipeline triggers

Git event	Typical pipeline use
PR opened/updated	Build + test + plan; no prod apply
Merge to main	Build artifact; deploy non-prod; maybe staging
Tag	Promote / release to prod after gates
Hotfix branch	Rare; same protections; expedited review SLA

Do not trigger prod apply on every commit message containing “prod.” Triggers must be explicit and protected.

Practical Implementation or Design Walkthrough

Problem

TechLearningPro has three services (enrollment API, payments adapter, lesson player) and shared infra modules. Reviews are inconsistent; main allows direct pushes; a secret was committed last quarter and “cleaned” with a new commit (key still in history). Leadership wants a branching and release policy.

Steps

Inventory repos and classify: app, infra, shared library, pipeline templates.
Choose trunk-based default; document exceptions.
Draft CODEOWNERS per repo/path with teams.
Enable protected branch on main: PR required, 1–2 reviews by risk, dismiss stale, required checks, no force-push.
Add PR template with blast-radius and rollback sections.
Add secret scanning; rotate any discovered credentials; document incident.
Define tag scheme and changelog expectations.
Define hotfix path: still PR into protected branch; on-call deputies; post-hoc ADR if bypass used.
Publish multi-service release policy; socialize in guild meeting.
Verify budget alert before creating any AWS connection resources for webhook tests; clean up test connections.

Sample PR template (Markdown)

markdown
### Why
### AWS blast radius (account/region/services)
### Rollback
### Test evidence
### Secrets check (none added)

Sample release policy excerpt

Enrollment API: continuous delivery; prod gate in pipeline; Git tag optional for marketing versions.
Platform infra: batched weekly unless security fix; dual review (platform + security) for IAM.
Hotfix: PR + one platform approver + expedited CI; no laptop apply.

Failure paths

Engineer force-pushes with admin bypass → CloudTrail/org audit; revoke unnecessary admin; retrospective.
CODEOWNERS team empty → merges blocked or ownership ineffective; keep teams populated.
Required check removed to “unblock” → treat as severity event; restore check; fix root flake.

Enterprise Real-World Scenarios

The weekend IAM widening

A tired engineer merges Action: "*" to unblock a demo. Monday learners are fine; attackers love the key they phish Tuesday. Governance fix: IAM path requires security CODEOWNER; policy-as-code gate in CI (lesson 35); no merge without plan commentary.

Monorepo without path owners

Everyone owns everything; nobody reviews deeply. Fix: path CODEOWNERS; smaller PRs; architecture guild for shared libs.

Env branches forever

prod branch is twelve commits ahead of main with hotfixes never backported. Staging lies. Fix: abolish env branches; promote artifacts; backport discipline via tags.

Secret in history

Deleting a line is not rotation. Keys in Git history remain until rotated and optionally history-rewritten with org-wide coordination. Teach incident playbook.

Bot with admin

A dependency bot has permission to push to main. Supply chain compromise becomes silent trunk poison. Fix: bot opens PRs only; humans or strict auto-merge rules for known-safe packages.

Review theater before audits

Teams add CODEOWNERS the week before SOC2 evidence gathering but allow admin bypass daily. Auditors eventually notice CloudTrail. Fix: minimize bypassers; monitor bypass events.

Best Practices

Protect default branches; deny force-push.
Require PR reviews sized to blast radius.
Dismiss stale approvals.
Require meaningful status checks.
CODEOWNERS for IAM, network, workflows, payments.
Prefer trunk-based short-lived branches.
Promote artifacts; avoid env branches.
Annotated tags; immutable artifact correlation.
PR templates with rollback and blast radius.
Secret scanning + rotation playbook.
Teams over individuals in ownership.
Constrain bots; no silent trunk writes.
Document hotfix and break-glass merges.
Keep ownership files themselves protected.
Clean up test webhooks/connections; watch budgets.

Common Mistakes and Anti-Patterns

Direct pushes to main — Symptom: missing PR context. Fix: branch protection.
Rubber-stamp reviews — Symptom: incidents after “approved” merges. Fix: norms + accountability.
CODEOWNERS pointing at departed users — Symptom: stuck PRs. Fix: teams + quarterly cleanup.
Floating tags as release mechanism — Symptom: unknown prod versions. Fix: immutable tags + digests.
Committing .env “temporarily” — Symptom: credential leaks. Fix: scanning + education + rotation.
Bypassing checks for speed — Symptom: normalized insecurity. Fix: fix CI speed; keep gates.
Infra and app in uncoordinated repos without contracts — Symptom: permission races. Fix: sequence rules + ADRs.
Using /learn/git patterns without AWS blast-radius thinking — Symptom: great commits, terrible IAM. Fix: this lesson’s review heuristics.

Troubleshooting and Design Review

Merges blocked unexpectedly. Check required checks renamed; CODEOWNERS team membership; branch name mismatch (master vs main).

CI green on PR but red on main. Rebase issues; flaky tests; different secrets available to fork PRs—use caution with secrets on fork workflows.

Nobody can merge IAM changes. Owners too strict or team empty; designate deputies; do not remove protection.

Design review questions: Can a compromised laptop push to main? Can a secret enter history undetected? Do tags map to digests? Is hotfix documented? Are app/infra ownership boundaries clear?

Verify protection settings in the hosting UI or API; do not assume defaults after org migrations.

Interview Questions and Answers

Q1: Why protect main for IaC repos?
A: Infra merges change cloud reality; protection enforces review and CI before that blast radius expands.

Q2: CODEOWNERS vs branch protection?
A: CODEOWNERS routes who must review paths; branch protection enforces PR, checks, and push rules. Use both.

Q3: Trunk-based vs GitFlow for a SaaS API?
A: Trunk-based with feature flags usually fits continuous delivery; GitFlow adds overhead unless multiple supported versions require it.

Q4: Why dismiss stale approvals?
A: Prevents shipping new risky commits under an old approval.

Q5: How do tags relate to ECR?
A: Tags name human releases; deploy by image digest for immutability; record both.

Q6: What do you do if AWS keys were committed?
A: Rotate/deactivate immediately; treat as incident; remove from future commits; consider history purge with coordinated rewrite; add scanning.

Q7: Why avoid long-lived environment branches?
A: They diverge, encourage rebuild-per-env, and obscure artifact promotion.

Q8: How should bots interact with protected branches?
A: Open PRs; limited auto-merge for approved update classes; never unrestricted push to main.

Q9: What belongs in an IaC PR description?
A: Blast radius, plan/test evidence, rollback, data/encryption impact.

Q10: App change needs new IAM—order of operations?
A: Land infra permission first (or coordinated release); or feature-flag app until permission exists; never hope staging’s looser role matches prod.

Q11: How does this connect to CodePipeline/Actions?
A: Triggers and trust depend on branch/tag integrity; weak Git governance undermines pipeline security.

Q12: What is break-glass merge?
A: Emergency bypass with audit, time limit, and retroactive PR/review—exception, not habit.

Hands-On Exercises

Exercise: Define branching and release policy for multiple services

Goal: Publish a policy covering enrollment API, payments adapter, and platform infra repos (or monorepo paths).

Tasks:

Choose trunk-based or document an exception.
Write CODEOWNERS draft for IAM, network, workflows, each service.
Specify protected branch rules and required checks by repo.
Define tag/version scheme mapping to artifacts.
Write hotfix and secret-leak playbooks.
Confirm AWS budget alert still on; note cleanup for any test connection resources.
Peer-review another learner’s policy for bypass loopholes.

Evidence: Policy Markdown in a repo PR; CODEOWNERS file; screenshots/export of branch protection settings; ADR for app/infra repo split.

Challenge ADR

Constraint: stricter compliance—dual approval for any IAM change; no admin bypass except two-person rule; multi-account module versions pinned. Explain throughput impact and mitigation (better CI speed, deputies, smaller IAM PRs).

Lab evidence checklist

Narrative: the force-push incident

An engineer rewrites main to remove a bad commit. Pipelines cannot find SHAs; ECR provenance breaks; overnight rollback guesses wrong digest. Write the postmortem outline: detection, impact, correct fix (revert), prevention (deny force-push), communication to on-call.

Connecting /learn/git without cloning it

Use that course for rebase/merge mechanics vocabulary. Your graded artifacts here must include AWS blast-radius language and CODEOWNERS for cloud paths—not only pretty commit messages.

Deep dive: writing CODEOWNERS for a monorepo

Draft patterns for services/*/, infra/modules/iam/, .github/workflows/, docs/. Explain last-match-wins with an example where a broad rule accidentally overrides a tight rule—and how you reorder to fix it.

Dual-repo release train exercise

Schedule: infra PR Monday, app PR Tuesday. Define failure if app merges first. Add a checklist gate in the app PR template: “Required infra version / stack output present in staging.”

Status check matrix

Build a table: check name | runs on | blocks merge? | owner | flake SLO. Empty owner is a finding.

Annotated tag rehearsal

Create a tag naming scheme for three services; show how a pipeline would parse the tag; show how you still pin digest in ECS task definition. No need to deploy yet—clarity first.

Secret leak tabletop

Walk the room through: key committed → scanner alert → deactivate key → audit CloudTrail for use → notify → purge guidance → add pre-receive controls. Assign roles.

Reviewer checklist card

One-page checklist for IAM diffs and one for Dockerfile diffs. Keep them in /docs/review/ via PR—governance dogfooding.

Measuring governance health

Propose metrics: % merges with bypass; median time to review; incident rate after merge; secret scan true positives. Avoid vanity “number of PRs.”

Bot permission worksheet

List bots; for each: token scope, can push main?, can approve?, can create repos? Goal: all “no” to push main.

Migration plan from env branches

Steps: freeze prod branch; ensure main has all fixes; tag; switch pipeline triggers; read-only old branches; delete after soak. Risks and rollbacks documented.

Cross-link to pipelines

Explain which Git events will later trigger CI/CD Pipeline Fundamentals stages. Ambiguous events (“any branch”) are a design smell for prod applies.

Ownership of pipeline definitions

Why .github/workflows/** and buildspec.yml need platform CODEOWNERS: they are privileged code that can exfiltrate secrets or deploy anywhere the role allows. Treat workflow edits like IAM edits.

Student/learner data in fixtures

Forbid real PII in test fixtures committed to Git. Synthetic learners only. Governance includes privacy.

Quarterly access review

Calendar item: review who can bypass; who is in owner teams; which deploy keys exist. Record evidence for audits.

Conflict resolution norms

When CODEOWNERS disagree, escalation path: guild lead → staff engineer → security for IAM. Do not “just merge.”

Documentation as code

Runbooks and policies live in Git beside code. Wiki-only policies drift. Link from README.

Hands-on: break-glass drill (paper)

Simulate needing an emergency merge: who approves, what is logged, what PR follows within 24 hours, how CloudTrail is checked. No real bypass required in class orgs if not permitted—paper drill counts.

Performance of reviews

Slow reviews kill trunk-based flow. Set SLA (e.g., business-day 4 hours for standard PRs); staff reviewer rotation; keep PRs small. Governance that ignores throughput will be bypassed.

Anti-pattern: giant monthly release PR

Thousands of lines, one approval, no one understands. Split by service; use feature flags; prefer continuous delivery from lesson 24.

Mapping tags to CloudFormation change sets (preview)

A tag may trigger packaging a template and creating a change set for review before execute—lesson 29. Governance ensures the tag is immutable and reviewed.

Org vs repo rule layers

Org-level rules provide baseline; repo rules tighten for payments. Document inheritance so teams do not think repo settings alone define reality.

Final oral check

Explain in two minutes how a malicious workflow PR would be stopped (CODEOWNERS + review + required checks + no self-approval + OIDC least privilege later). If any layer is missing, note it as tech debt.

Rubric mapping

Conceptual accuracy: strategy choice. Implementation: CODEOWNERS + protections. Security: secrets + bypass control. Reliability: hotfix clarity. Docs: policy completeness. Score yourself before submission.

Cleanup

Delete experimental repos only if allowed; remove unused deploy keys; close test CodeStar Connections; confirm no access keys created for the exercise; keep budget alert enabled for Module 3 continuation.

Bridge to lesson 26

With governance in place, CI/CD Pipeline Fundamentals defines artifacts, environments, gates, and promotion—assuming trunk integrity you just enforced.

Extended scenario: payments dual control

Payments guild + security must approve services/payments/** and infra/**/payments*. Write the CODEOWNERS lines and the PR template checkbox. Explain how an emergency rate-limit change still gets one security deputy at 2 a.m.

Extended scenario: platform template version bump

A shared workflow template bumps Actions versions. All consumer repos receive PRs from a bot. Describe review load management and canary consumer repos before fleet-wide merge.

Glossary

Protected branch: server-enforced rules on who can change a ref. CODEOWNERS: path-based review routing. Annotated tag: named release pointer with message/metadata. Bypass: admin exception to protections. Provenance: lineage from commit SHA to running AWS artifact.

Practice: rewrite a bad PR description

Take “fixed stuff” and rewrite it with blast radius, evidence, rollback. Peer critique.

Practice: identify mutable tag risk

Given ECR tags latest, prod, 1.2.3, and digest sha256:…, explain which references belong in production task definitions and why Git tags must not be moved after release.

Practice: map CloudTrail to Git

During an incident, you have deploy time T. Find pipeline execution → Git SHA → PR → reviewers. Write the exact navigation path you would use (UI or CLI) for your chosen CI system—even if you only simulate screenshots in this lesson.

Policy appendix: merge methods

Choose squash vs merge commit vs rebase merge for TechLearningPro trunks. Justify with bisectability and required linear history settings. Document the choice in the ADR so teams stop arguing per PR.

Policy appendix: draft releases

Optional GitHub Releases as narrative changelog layered on tags. They do not replace digests. Keep release notes free of secrets.

Security appendix: fork PR caution

Forks may not receive secrets; that is good. Do not weaken protections to make fork contributions “easier” for private enterprise repos that should use branch permissions instead.

Operations appendix: repo archival

When a service dies, archive the repo; revoke deploy roles tied to its pipelines; delete ECR repos per retention; update CODEOWNERS teams. Governance includes endings.

Leadership communication

Explain in five sentences why forcing PRs slows individuals slightly and speeds the organization: fewer Sev-1s, clearer audits, safer enrollment weeks. This is how you sell governance without fearmongering.

Worked example: enrollment API feature branch lifecycle

An engineer creates feat/rate-limit-headers from current main. They commit small, tested changes. They open a PR; CI runs unit tests and a Dockerfile build. CODEOWNERS requests enrollment-guild review. A reviewer asks whether 429 responses leak internal service names; the author fixes and pushes; stale approval dismisses; reviewer re-approves. Merge uses squash per policy, producing one SHA on main. Trunk CI publishes an image tagged with that SHA. Staging deploys automatically. A release tag enrollment-api-1.14.2 is cut after staging soak when product wants a named version; production promotion still uses the digest. The Git history answers every auditor question about who changed rate limiting and who approved it.

Worked example: IAM policy change in infra repo

Platform engineer opens PR adding sqs:SendMessage on a specific queue ARN for the enrollment task role. Security CODEOWNER reviews resource ARN specificity. CI runs template validation and a policy linter. Merge triggers a non-prod apply pipeline. Only after staging enrollment succeeds does a prod change set wait for approval. The app PR that starts sending messages is blocked by its template checkbox until staging shows the permission. This sequencing is governance as architecture.

Deep comparison: squash vs merge commits for AWS forensics

Squash keeps main linear and maps one PR to one SHA—pleasant for “what deployed.” Merge commits preserve branch topology and individual commit SHAs—pleasant for detailed archaeology. Either works if the pipeline records the trunk SHA that produced the artifact. The failure mode is deploying a feature-branch SHA that never existed on the protected trunk after rebase. Always build release artifacts from protected trunk SHAs or from tags that point at those SHAs.

Repository rulesets evolution

Modern GitHub rulesets can layer org and repo constraints. When TechLearningPro migrates from classic branch protection to rulesets, treat it as a platform change: verify required checks still match workflow job names; verify CODEOWNERS enforcement still on; run a canary repo first. Do not migrate all payment repos on Friday afternoon before enrollment week.

Signed commits and verified merges

Signing proves the author key held a private key—not that the change is safe. Use signing when compliance asks for stronger authorship evidence; still require reviews and CI. Unsigned emergency commits should be exceptional and followed by verification in the incident review.

Handling large binary assets

Do not store large video lesson masters in app repos. Use LFS only with discipline or keep media in S3 content pipelines. Huge binaries blow clone times, break CI minutes budgets, and obscure code review. Governance includes repo fitness for purpose.

CODEOWNERS for generated files

If code generation creates IAM JSON, own the generator inputs and the CI that validates outputs—not only the generated file. Otherwise humans rubber-stamp generated blobs they cannot read.

Cross-account module versioning etiquette

When a shared module tag v3 breaks backward compatibility, communicate in a #platform-announce channel, provide a migration guide in the module repo, and use CODEOWNERS to ensure consumers’ version bumps get platform eyes. Semantic versioning is a social contract enforced by review.

Practical: inventing required checks list for three repos

For enrollment-api: unit, lint, docker-build, secret-scan. For platform-infra: cfn-lint or terraform-validate, policy-check, secret-scan. For workflow-templates: actionlint, secret-scan, platform-review. Write these into the policy doc with owners.

Practical: PR size budget

Suggest soft limit of 400 changed lines for standard review SLA; above that, require summary architecture notes or split. IaC destroys/creates of stateful resources always require extra scrutiny regardless of line count—ten lines can drop a database.

Practical: mapping ticket IDs

Require ticket keys in PR titles or branch names when your org uses that trail for change management. Pipelines can parse them into deployment annotations. Consistency beats cleverness.

Incident pattern: wrong repo, right intent

Engineer patches a hotfix in a fork of an archived repo; production still runs the live repo. Governance includes archive banners, disabling Actions on archived repos, and clear README pointers to the canonical remote. Add this check to the hotfix playbook.

Incident pattern: submodule SHA surprise

A submodule pointer advances to an unreviewed commit. Treat submodule bumps as dependency upgrades with changelog review. Prefer packages with lockfiles when possible for AWS tooling libraries.

Teaching exercise: rewrite CODEOWNERS anti-patterns

Given a file that owns * to one person and never owns .github/workflows, rewrite it. Explain every change aloud to a peer.

Teaching exercise: protection settings peer audit

Exchange screenshots of branch protection. Score: force-push denied? stale dismiss? required checks real? admins restricted? CODEOWNERS enforced? Missing items become homework.

Cost note for Git providers and AWS connections

GitHub seats and Actions minutes are not AWS bills, but CodeStar Connections, CodeBuild triggers, and ECR traffic are. When testing webhooks, delete unused connections; set budgets; tag resources Project=tlp-lesson25. Do not leave duplicate connections “for later.”

Accessibility of governance docs

Policies should be readable by new hires in one sitting. If your policy needs a lawyer to interpret, engineers will bypass it. Short rules, clear examples, links to deeper ADRs.

Ethical note: surveillance vs safety

Branch protections and audit logs exist for safety and accountability, not for punishing speed. Blameless culture from lesson 24 still applies when someone uses break-glass correctly during a real outage.

Closing synthesis

Git workflows are how TechLearningPro encodes trust: who may change what, with whose review, under which automated proofs, producing which immutable references for AWS. Without that, Module 3’s pipelines accelerate chaos. With it, pipelines accelerate learning platform delivery.

Appendix: sample multi-service policy outline

Purpose and scope
Branch model
Protection rules matrix
CODEOWNERS principles
PR standards
Tagging and versioning
Hotfix and break-glass
Secrets and scanning
Bot permissions
App/infra coordination
Metrics and quarterly review
References to /learn/ci-cd-automation concepts and this course’s pipeline lessons

Fill each section with TechLearningPro-specific names. Submit the filled outline as the primary deliverable.

Appendix: reviewer comment bank for IAM

Useful review comments: “Please scope Resource to the enrollment queue ARN”; “Avoid * on Action for prod roles”; “Confirm staging role matches intended prod role shape”; “Add tag enforcement for new roles”; “Where is the rollback (previous policy version)?” Reuse these until they become culture.

Appendix: reviewer comment bank for Docker/ECR

“Pin base image digest”; “Omit secrets from build args”; “Confirm non-root user”; “Tag with Git SHA”; “Do not push latest to prod registry namespace.” Align with Amazon ECR and Container Image Supply Chain.

Extended lab: implement protections on a sandbox repo

Create a throwaway repository named tlp-lesson25-sandbox. Add a trivial README and a sample CloudFormation snippet under infra/. Configure main protection with PR required, one approval, dismiss stale, and a trivial required check (even a workflow that runs true is enough pedagogically—then replace with a real lint job). Add CODEOWNERS assigning @yourself temporarily and a classmate team if available. Open a PR that widens an IAM action to *; practice rejecting it with a written comment citing least privilege. Open a second PR that scopes the action correctly; approve and merge. Attempt a force-push and record the denial. Delete the sandbox repo when done if your org allows; document screenshots in your evidence pack. Confirm no AWS access keys were created for this Git-only lab; if you created a CodeStar Connection by mistake, delete it and verify the budget dashboard.

Extended lab: policy diff review game

In pairs, author a deliberately risky infra PR (public S3 ACL, 0.0.0.0/0 on SSH, inline plaintext password in template parameters default). Partners must catch every issue before “merge.” Debrief which issues CODEOWNERS would have routed to security versus platform. This game builds reviewer instinct faster than reading another checklist silently.

Why Git governance shows up in system design interviews

Interviewers ask how you prevent a junior engineer from taking production down with a bad IAM change. Strong answers cite protected branches, CODEOWNERS, required policy checks, and pipeline promotions—not “we trust people.” Practice a sixty-second answer that names TechLearningPro controls specifically.

Relationship to continuous delivery

Lesson 24’s continuous delivery promise collapses if trunk is untrustworthy. Governance makes “main is releasable” a believable statement. When someone asks why merges feel heavier than personal projects, point at enrollment-week blast radius and learner trust.

Final self-check questions

Can anyone push to main without a PR? Who owns IAM paths? What happens when approvals go stale? Which tag scheme maps to ECR? What is the secret-leak first action? What is the hotfix SLA for reviewers? If you hesitate, reread the matching section and update your policy draft before submission.

Enrollment-week freeze protocol

Some organizations freeze low-priority merges during peak enrollment. Document what “freeze” means: still allow security fixes; still require protections; never mean “laptop deploy instead.” A freeze without a hotfix path causes shadow IT. Pair freezes with clearer reviewer SLAs and pre-approved rollback digests standing by.

Personal action item

Add one improvement to your own repos this week: enable dismiss-stale, or add a blast-radius section to the PR template, or move a personal access token out of a private gist into a proper secret store. Governance starts with the repos you control, not only the ones platform owns.

Expansion pack: governance under time pressure

When enrollment error rates spike, engineers feel tempted to disable required checks “for fifteen minutes.” Write a pre-approved emergency protocol that keeps protections on, names deputies for fast review, and allows only a narrow class of revert PRs. Measure how often the protocol is used; if weekly, your normal review SLA is the real outage.

Expansion pack: aligning CODEOWNERS with AWS Organizations

Platform teams owning Organizations SCPs should also own repo paths that propose SCP or permission-boundary changes. Product teams should not merge org-level controls. Reflect that in CODEOWNERS and in the release policy matrix so social structure matches cloud structure.

Expansion pack: verifying lesson completion

Re-read your branching policy aloud. Confirm it names trunk rules, CODEOWNERS, tags-to-digests, secrets response, hotfix, and cleanup. Confirm word-of-mouth knowledge is written. Then proceed to CI/CD fundamentals with a trustworthy source control plane. Confirm evidence includes screenshots of denied force-push and a merged policy PR.

Lesson Summary

Repository governance makes Git a trustworthy control plane for AWS delivery: protected trunks, CODEOWNERS for high-blast-radius paths, meaningful status checks, immutable tags correlated to digests, secret hygiene, and constrained bots. Prefer trunk-based workflows and artifact promotion over long-lived environment branches. App and infra may live in separate repos or a monorepo, but ownership and review bars must be explicit.

Next: CI/CD Pipeline Fundamentals turns these commits and tags into artifacts, environments, gates, and promotions—still without long-lived cloud keys as a habit.