Terraform + GitHub Actions

Goal and scope

This implementation will deliver the shared AKS application environment with Terraform + GitHub Actions. It is planned, not deployed. The application, acceptance criteria, and failure exercise will match the other implementation, while all live Azure resources remain separately managed.

Planned implementation

I will start with a small application and a reproducible development target, then add delivery automation, monitoring, and recovery checks. DEV and TEST will be configurable targets. Only the target needed for the current exercise needs to run.

Infrastructure structure and environment configuration

The proposed repository will separate application code, Kubernetes manifests, Terraform modules, environment configuration, and GitHub Actions workflows. Modules will describe AKS, the registry, and supporting monitoring resources. DEV and TEST configuration will select names, location, sizing, and the target environment.

Remote state will use a dedicated Azure Storage backend with state locking. Each target will have its own state key and resources. The backend bootstrap, access controls, recovery, and eventual removal will be documented. State may contain sensitive values and will not be committed to Git or published as portfolio evidence.

This implementation will own different resource groups, identities, and resource names from the Bicep implementation. The two tools will never compete to manage the same resource.

GitHub Actions workflow stages

Code and workflows will live in this implementation’s own public GitHub repository. Proposed workflow, subject to refinement:

1. Validate infrastructure — check formatting and Terraform configuration.
2. Plan changes — create a plan for the selected target and review its effect.
3. Authorize apply — make an explicit deployment decision against the reviewed revision.
4. Apply infrastructure — apply the reviewed plan with state locking and controlled concurrency.
5. Test and build application — run tests and build a versioned container image.
6. Publish image — push the image to ACR.
7. Deploy application — deploy that image version to Kubernetes.
8. Verify — wait for readiness and run the smoke test.

The intended control is a reviewed plan followed by a deliberately authorized apply. Availability of environment approvals and repository protection features will be checked against the eventual repository and account configuration before choosing the mechanism. No paid feature or existing approval gate is assumed. Plan artifacts will be treated as sensitive, and concurrent writes to one target will be prevented.

Authentication and permissions

I plan to use GitHub Actions OIDC federation with Microsoft Entra ID for Azure authentication. Trust will be scoped to the intended repository and deployment context. Workflows will request only the token and repository permissions they need, with separate checks for infrastructure access, ACR publishing, and Kubernetes authorization.

The remote-state backend and federated identity require an explicit bootstrap step. I will document who performs it and which permissions remain after setup. Long-lived Azure client secrets will not be the normal pipeline authentication mechanism.

Deployment and rollback

The application will use readiness and liveness probes, a rolling-update strategy, and identifiable image versions. A release will be accepted only after rollout checks and a smoke test pass. A failed rollout must make the pipeline failure visible.

The rollback procedure will explicitly select the previously verified image or deployment revision, restore it, and rerun the smoke test. It will be exercised with a deliberately broken release. Rolling updates do not guarantee zero failed requests, and an application rollback does not undo database changes. Automatic rollback is not assumed.

Monitoring and troubleshooting

I plan to collect application logs and relevant AKS/application metrics, then configure one alert tied to the controlled failure scenario. A small investigation guide will connect the alert to pipeline output, Pod events, health probes, and application logs. The exact alert signal and threshold will be chosen during implementation and recorded with evidence.

Verification evidence

Results will be added after implementation. The shared acceptance criteria cover infrastructure validation and preview, deployment and smoke test, an application update, a broken release and explicit recovery, monitoring of that failure, and cleanup. Each recorded result should identify the environment, code revision, pipeline run, and observation. Screenshots will be added only when they document real runs.

Decisions and trade-offs

Terraform adds explicit state management and a backend lifecycle to the project. GitHub Actions keeps code and workflow definitions together, but permission boundaries, plan handling, and deployment controls still need deliberate design. I will record their operational impact after implementing them.

The project favors a small, explainable environment over production-platform breadth. Both toolchains will be judged against equivalent requirements; conclusions will follow the evidence.

Costs, limitations, and cleanup

No measured costs are available yet. Running AKS nodes, registry storage, networking, monitoring ingestion, and any pipeline usage may contribute to cost. The implementation will document selected sizes, runtime duration, retained resources, and actual charges where available.

DEV and TEST will be created on demand. Cleanup will remove only resources owned by this implementation and check for leftover disks, public IPs, registry images, and monitoring resources. The state backend must remain available while Terraform destroys managed resources. Backend deletion will be a separate, deliberate final step after checking that no remaining environment depends on it.

This is a portfolio lab, not a production availability or security claim. Operating limits and lessons will be recorded once they are observed.