Continuous Delivery to AWS, Azure, Google Cloud, and Kubernetes: Core Concepts and Mental Model

1. The delivery problem starts after release evidence exists

Chapter 25 ended with a release chain that linked an exact source SHA to exact artifact bytes. Continuous delivery begins from that verified subject. The deployment job should not silently run another build and hope the new bytes are equivalent. Its task is to authorize, authenticate, promote, observe and—if necessary—recover the same artifact identity.

Cloud providers and Kubernetes expose different APIs, but the GitHub Actions integration problem is remarkably consistent: prove the artifact, prove the job identity, prove the intended target, perform a bounded rollout, then prove target health. A green workflow job is not itself proof that users are receiving the intended revision.

2. Mental model: verified subject → governed identity → target rollout → health

Read the model as a chain of gates. The artifact digest enters delivery as immutable evidence. The deployment job references an environment, which may impose approval and branch/tag rules. Only that job receives the federated or narrowly scoped target credential. The adapter then calls the provider or Kubernetes API, receives a deployment/revision handle, waits for rollout, and verifies health before recording success.

flowchart TD
  A[Verified artifact + digest] --> B[Deployment job]
  B --> C[GitHub environment / approval]
  C --> D[OIDC or narrow target credential]
  D --> E[Provider API or Kubernetes API]
  E --> F[Deployment / rollout revision]
  F --> G[Health verification]
  G --> H[Deployment evidence + target state]
  G --> I[Failure evidence]
  I --> J[Rollback to known-good identity]

Every arrow crosses a state boundary. Artifact verification does not authorize deployment. Environment approval does not authenticate to AWS, Azure or Google Cloud. OIDC token minting does not grant a cloud role unless the provider trust policy accepts the claims. A successful API response does not prove the rollout is healthy.

3. Define the state before changing it

4. Inspection first: prove identity and target without mutation

Before a deploy step, print bounded non-secret metadata and use read-only identity commands. For Kubernetes, kubectl config current-context, kubectl cluster-info, namespace inspection and the current Deployment image are target proofs. For cloud sandboxes, aws sts get-caller-identity, az account show and gcloud config get-value project are examples of read-only account/project confirmation after authentication.

set -euo pipefail
printf 'run=%s attempt=%s sha=%s ref=%s
'   "$GITHUB_RUN_ID" "$GITHUB_RUN_ATTEMPT" "$GITHUB_SHA" "$GITHUB_REF"
sha256sum dist/release-subject.bin
kubectl config current-context
kubectl cluster-info
kubectl get namespace lab-delivery -o name 2>/dev/null || true

5. One contract, four adapters

6. OIDC grants token minting, not provider authorization

The deployment job normally needs id-token: write only when it will federate to a provider. That permission lets the job request a GitHub OIDC token; it does not give AWS, Azure or Google Cloud rights by itself. The provider trust relationship must accept the actual issuer, audience and subject/claims, then the resulting role or service account still needs its own least-privilege resource permissions.

As of September 10, 2026, repositories created after July 15, 2026 use the immutable default OIDC subject form with owner and repository IDs; older repositories keep the legacy name-only form unless migrated. An environment-scoped job also changes the subject context. Production trust policies must therefore match the actual current token format, not a copied tutorial string.

7. Environment approval is a governance gate, not deployment success

A job that references environment: production may wait for required reviewers, branch/tag restrictions, wait timers or custom protection rules depending on repository visibility and plan. Environment secrets are not available until the job is allowed to start under the environment rules. Once approved, the provider can still reject OIDC, the rollout can still fail, and the application can still be unhealthy.

Use target-specific concurrency such as deploy-production rather than one global group that serializes unrelated staging and production systems. Concurrency controls overlap; it does not prove the previous deployment completed successfully or that the new artifact is safe.

8. Evidence must link GitHub state to external state

9. Common wrong model: “deploy latest from main”

A workflow that checks out main, rebuilds, logs into a cloud account with a permanent admin key and deploys image:latest collapses four independent identities into mutable aliases. A later commit, tag move, base-image update or registry retag can change the bytes without changing the workflow text. Recovery then becomes guesswork.

The production pattern is the opposite: immutable artifact identity in, bounded target identity, short-lived deployment identity, exact rollout record out. Human-friendly aliases may exist for discovery, but the evidence packet retains the digest and target-side revision.

10. DevOps connection: promotion preserves evidence across boundaries

Delivery is not “CI plus credentials.” It is the operational handoff between verified software and a stateful external system. The same discipline used for source SHA, pinned actions, artifacts and attestations now extends to cloud account/project/subscription/cluster identity, rollout revisions and health. This is what makes a deployment independently auditable and safely repeatable.

11. Lesson summary

Continuous delivery should preserve one artifact identity while changing only authorized target state. Environments govern entry, OIDC or narrow credentials establish caller identity, provider/cluster APIs create rollout state, and health/rollback evidence closes the loop.

Knowledge check

Official references and version notes

• GitHub OIDC overview — Why short-lived federation is preferred to long-lived cloud secrets.
• OIDC reference — Current claims, immutable subject format, audiences, reusable-workflow behavior and token-request permissions.
• OIDC in AWS — Current AWS trust conditions and official authentication action pattern.
• OIDC in Azure — Current Microsoft Entra workload identity federation pattern.
• OIDC in Google Cloud — Current Workload Identity Federation integration.
• Managing environments — Environment protection, deployment branches/tags, secrets and target governance.
• Deployments and environments — Conceptual distinction between deployment records, environment gates and external target health.
• kind quick start — Pinned local Kubernetes cluster tool used by the free lab.
• kind local registry — Current localhost registry/network model when digest-addressable local images are needed.
• Kubernetes Deployments — Rollout, revision and rollback model.
• kubectl rollout — Status, history, undo and restart operations.