Lesson 349 · AWS Learning Path

AWS 349: Pull requests, peer review, protected branches, and separation of duties

Anil Jalela · Published Jun 9, 2026 · 7 min read

Why this lesson matters

A pull request is a conversation and integration proposal, not automatically a control. The control exists only when identity, branch rules, required independent approvals, status checks, ownership, override handling, and audit evidence make bypass difficult and visible.

This lesson separates Git mechanics from hosting-platform enforcement. You will design a review policy, inspect a change as a reviewer, model branch protection, test bypass scenarios, and handle emergency change without pretending that speed eliminates accountability.

Learning outcomes

You will be able to:

• explain pull request head, base, diff, review, approval, merge, and resulting commit;
• distinguish peer review, code ownership, branch protection, CI checks, and deployment approval;
• define separation of duties by risk instead of title alone;
• identify stale approval, self-approval, administrator bypass, bot, fork, and compromised-token risks;
• map GitHub, GitLab, Bitbucket, or CodeCommit controls to one platform-neutral policy;
• design a controlled emergency path with retrospective review;
• prove that source approval and production deployment authorization are separate decisions.

The change-control chain

authenticated author -> feature branch -> proposed diff
       -> automated checks -> independent human review
       -> protected merge -> immutable commit/artifact
       -> environment approval -> deployment -> runtime evidence

Every arrow needs an identity, policy, evidence source, owner, and failure response. A reviewer approves a defined diff at a specific revision. New commits can invalidate that decision. A successful build proves only what its checks actually measured.

Vocabulary and boundaries

Risk-based policy design

Create repository classes rather than one rule for everything:

• Class 1: documentation or low-risk examples; one peer and basic checks.
• Class 2: application code; independent review, tests, security checks, protected branch.
• Class 3: infrastructure, IAM, network, database schema, release workflow; specialist owner plus independent reviewer and stronger checks.
• Class 4: security controls, production credentials integration, organization policies, break-glass automation; two-person control and explicit deployment authorization.

Define these policy fields for every class: protected branches/tags, direct-push rule, force-push/deletion rule, minimum approvals, author/self-approval behavior, ownership paths, stale-approval behavior, conversation resolution, required checks, check source, merge methods, signed revision requirement, bot behavior, administrator scope, emergency procedure, audit retention, and periodic review.

Separation of duties means no single identity can make, approve, and deploy a high-risk change without an independently controlled path. It must include service accounts, administrators, and temporary elevation, not just ordinary developers.

Build the review exercise

Reuse the local repository from AWS348 or create a new owned lab. Create a base branch and a proposal:

git switch main
git switch -c feature/validate-release
mkdir -p tests .github
printf '%s\n' '#!/usr/bin/env bash' 'set -u' 'test -f config/release.env' 'grep -q "^service=" config/release.env' 'grep -q "^version=" config/release.env' > tests/validate.sh
chmod 0755 tests/validate.sh
printf '%s\n' '* @platform-reviewers' '/config/ @release-owners' '/tests/ @quality-owners' > .github/CODEOWNERS
git add tests/validate.sh .github/CODEOWNERS
git commit -m "test: validate release manifest"

.github/CODEOWNERS is a GitHub-shaped example, not universal Git syntax. It routes review only when the hosting platform, repository location, branch rule, identities, and ownership settings support it. A local file alone enforces nothing.

Review from evidence

The reviewer should fetch the exact proposal and record base/head commit IDs:

base_ref=main
head_ref=feature/validate-release
git rev-parse "$base_ref"
git rev-parse "$head_ref"
git log --oneline --left-right "$base_ref...$head_ref"
git diff --stat "$base_ref...$head_ref"
git diff --check "$base_ref...$head_ref"
git diff "$base_ref...$head_ref"
bash -n tests/validate.sh
bash tests/validate.sh

Three-dot diff uses the merge base to show the proposal relative to where it diverged. Review generated files, renamed files, binaries, workflow changes, dependency lock files, IAM/policy changes, and deletion as deliberately as application code.

Use a checklist:

1. Does the change satisfy a linked requirement?
2. Is the diff minimal and understandable?
3. Are trust boundaries, data handling, permissions, and secrets safe?
4. Do positive, negative, and failure tests cover the changed behavior?
5. Are logs useful without leaking sensitive values?
6. Is migration backward compatible and rollback realistic after writes?
7. Are costs, quotas, availability, and ownership affected?
8. Are documentation and runbooks updated?
9. Does the exact reviewed revision match the revision proposed for merge?

Model required checks

For this local lesson, produce a check manifest rather than claiming branch enforcement:

Checks that run attacker-controlled code on privileged runners can become a credential-exfiltration path. Untrusted pull requests must not automatically receive production secrets or trusted network access. Pin or govern reusable workflows/actions and control who can change CI definitions.

Test bypass and failure scenarios

For each scenario, state whether it is prevented, detected, both, or neither; then provide evidence and response:

1. The author approves their own change.
2. A reviewer approves, then the author pushes another commit.
3. An administrator directly pushes to main.
4. A force push removes an approved commit.
5. A required check name is duplicated by an untrusted workflow.
6. A bot token can both update dependencies and merge them.
7. A CODEOWNERS rule is changed in the same proposal it governs.
8. A forked proposal executes on a runner with cloud credentials.
9. A validly reviewed artifact is rebuilt from a different commit before deployment.
10. The source-control provider is unavailable during a critical incident.

Strong policy normally dismisses stale approvals, restricts bypass, protects policy/workflow files with specialist ownership, separates automation identities, limits untrusted runners, and promotes a verified immutable artifact digest rather than rebuilding.

Platform mapping

Map the policy to the actual platform without assuming equivalent names:

CodeCommit is currently documented as available to new customers again. Its concepts and APIs differ from GitHub protection semantics; design IAM, approvals, notifications, and pipelines explicitly. Never claim a control exists until a denied-path test proves it.

Emergency change

Emergency access is a controlled exception, not a permanent bypass. Define incident ID, severity, authorized requester, two-person approval when feasible, time-bounded elevation, exact scope, captured commands/diff, automated minimum checks, rollback, monitoring, post-change validation, credential/session revocation, and retrospective review deadline.

If the source platform is unavailable, use a preapproved signed artifact or controlled repair path. Do not invent an unaudited personal repository during the incident. Every emergency change must return to normal history and controls.

Findings and metrics

Measure control health without rewarding superficial approval speed:

• percentage of protected branches matching policy;
• direct-push and bypass attempts;
• stale approvals correctly dismissed;
• review depth for high-risk paths;
• check failure escape rate;
• emergency-change frequency and overdue retrospectives;
• deployed artifacts with commit/digest/provenance linkage;
• mean time to review alongside change failure rate.

Do not rank individual reviewers by raw comments or speed; that encourages noise and rushed approval.

Independent challenge and acceptance

Produce a policy for four repository classes, platform mapping, proposed diff, review transcript, check manifest, ten bypass tests, emergency procedure, artifact-provenance flow, audit query plan, metrics, and residual-risk register.

Pass requires exact base/head IDs, independent review evidence, stale-approval behavior, denied direct-push evidence in an approved sandbox or documented simulation, specialist ownership for sensitive paths, no untrusted secret exposure, immutable revision-to-artifact linkage, and explicit separation between source merge and production deployment authorization.

Official sources

• Git diff documentation
• GitHub protected branches
• GitHub code owners
• CodeCommit approval rules
• CodeCommit authentication and access control