B/MBertrand MbanwiENGINEER / BUILDER All workLet’s talk
CLOUD / DEVSECOPSCASE STUDY / 5 minute read

Ephemeral Azure Platform

BUILD IT.PROVE IT.REMOVE IT.

A cloud platform should be able to demonstrate its own lifecycle. This project brings provisioning, application delivery, verification, and teardown into one inspectable workflow.

Personal engineering project · Ephemeral Azure environmentThe 60-second overview
Checked against GitHub
Last successful check · 2026-09-05 22:54 UTCd87fd06Refresh Career Atlas after public repository changes
THE SHORT VERSION

WHAT THIS
DEMONSTRATES.

  1. 01

    Terraform provisions the network, AKS cluster, and Key Vault through GitHub OIDC authentication.

  2. 02

    The workflow checks infrastructure, application delivery, admission policy, and secret synchronization before collecting evidence.

  3. 03

    Cleanup runs in reverse dependency order. A separate janitor workflow provides a recovery path for tagged resources.

01 / CONTEXT

THE PROBLEM.

A successful Terraform apply is only one part of a working platform. The cluster also needs ready nodes, a reachable application, functioning policy controls, and a way to clean up after failure. Keeping a demonstration environment running indefinitely also creates an unnecessary cost commitment.

Constraints that shaped the work

  • No stored Azure client secret in the lifecycle workflow.
  • Separate Terraform state for dependent stacks.
  • Keep verification evidence after the environment is removed.
  • Handle interrupted and failed runs as part of the design.
02 / FOLLOW THE SYSTEM

ARCHITECTURE.

Choose a stage to explore its purpose and supporting source.

ARCHITECTURE WALKTHROUGH01 / 06

Establish identity

The job requests an OIDC identity token and uses configured Azure identity variables. Verification obtains its own Azure login session.

WHAT TO INSPECT

The workflow declares id-token: write and ARM_USE_OIDC, then invokes azure/login for verification.

Read the implementation
03 / ENGINEERING JUDGMENT

THE TRADEOFFS.

01

Serialize changes to state

Use a shared concurrency group with cancel-in-progress disabled.

The tradeoffRuns may wait longer, but a newer run does not deliberately interrupt Terraform while it owns a state lease.

Inspect the decision
02

Verify through different interfaces

Check Azure provisioning state, Kubernetes readiness, and application behavior separately.

The tradeoffThe lifecycle takes more steps and can fail for more reasons. In exchange, an apply result is not mistaken for an operational service.

Inspect the decision
03

Make removal part of delivery

Attempt teardown after failure and keep a separate sweep for tagged resources.

The tradeoffThe environment is unavailable between runs, and recovery still depends on Azure permissions and working cleanup operations.

Inspect the decision
04 / WHAT THE WORK SHOWS

OUTCOMES & LIMITS.

One reviewable lifecycle

The workflow joins infrastructure, GitOps application delivery, policy checks, and secret synchronization in a single ordered sequence.

Supporting source

Failure evidence is designed in

Artifact capture and teardown are configured to run after earlier failures. This makes diagnosis and cleanup explicit parts of delivery.

Supporting source

Operational lessons became controls

The troubleshooting log connects interrupted state leases to serialized runs and unexpected disk cost defaults to pull-request cost review.

Supporting source
THE LESSON

The useful engineering work is in the boundaries: state dependencies, cloud permissions, default resource settings, and the difference between “created” and “working.” The repository records actual troubleshooting examples. Those lessons explain why the lifecycle has more than an apply and a destroy command.

Where the evidence ends

  • This is an ephemeral portfolio environment, not a production availability claim.
  • The current workflow includes a secrets stack and policy checks beyond the older two-stack README overview; the case study follows the workflow where they differ.
  • Workflow definitions and documented troubleshooting are the evidence here. Current run results and cloud spend must be inspected separately.
05 / CHECK THE WORK

THE SOURCEBOOK.

Reviewed 4 September 2026. These links point to the source revision used for this case study.

Source revision 4dc36ec · View current workflow history ↗

KEEP EXPLORING

Actions Runner Control Plane