---
title: "Terraform | Skills We Assign For | Azendo"
description: "Terraform for infrastructure as code — drift, state and review discipline, and the Azendo roles assigned for cloud work."
url: "https://azendo.co/skills/terraform/"
---

[Skills](https://azendo.co/skills/) Cloud and infrastructure 

# Terraform.

Terraform defines cloud infrastructure as code: resources are declared in files, version-controlled and applied through a reviewable plan. It replaces changes made by hand in a console with changes made through a pull request.

## Where Terraform fits on a long engagement.

The reason to adopt it is not automation, it is auditability. Infrastructure built by hand cannot be recreated, reviewed or explained six months later. Infrastructure in Terraform has a history, a diff before every change, and a path to rebuilding an environment that someone deleted.

Two things decide whether an estate stays healthy: where state lives and whether anyone still changes things by hand. State in a shared remote backend with locking, and a rule that the console is read-only, are what prevent the drift that makes a plan output untrustworthy.

## What an assigned team does with Terraform.

Infrastructure as code only stays true if nobody edits the console. That is a discipline rather than a tool, and it survives exactly as long as the people who agreed it do — which is why drift is the standard condition of estates that changed hands.

The recovery work is unglamorous and worth doing: import what exists, establish state, and close the console. It is assigned under [DevOps as a service](https://azendo.co/services/cloud-and-devops/), in your accounts, with the permissions held by the assigned specialist rather than by us.

## What we use Terraform for.

* Environments that actually match Staging and production built from the same definitions, so a test result means something.
* Bringing an existing estate under control Importing infrastructure that was clicked together, which is slower than starting fresh and worth doing anyway.
* Change with a review step A plan attached to a pull request, so somebody sees a destructive change before it runs rather than after.

## How Terraform capacity is assigned.

Infrastructure-as-code work is assigned under DevOps as a service, working in your accounts under your own billing and permissions. An Azendo [service delivery manager](https://azendo.co/how-it-works/) answers for what that capacity delivers.

## Roles we assign Terraform for

* [Cloud Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/cloud-engineer/)
* [DevOps Engineer Cloud and DevOps](https://azendo.co/services/cloud-and-devops/devops-engineer/)
* [ML Platform Engineer MLOps engineering](https://azendo.co/services/mlops-engineering/ml-platform-engineer/)

## Service lines it sits in

* [Cloud and DevOps](https://azendo.co/services/cloud-and-devops/)
* [MLOps engineering](https://azendo.co/services/mlops-engineering/)

Capacity is agreed as a committed monthly capacity across a discipline, not per skill.

## Related in cloud and infrastructure

* [Terraform modules — skill we assign for](https://azendo.co/skills/terraform-modules/)
* [Pulumi — skill we assign for](https://azendo.co/skills/pulumi/)
* [CloudFormation — skill we assign for](https://azendo.co/skills/cloudformation/)
* [Crossplane — skill we assign for](https://azendo.co/skills/crossplane/)
* [Ansible — skill we assign for](https://azendo.co/skills/ansible/)
* [Helm — skill we assign for](https://azendo.co/skills/helm/)
* [EKS — skill we assign for](https://azendo.co/skills/eks/)
* [Backstage — skill we assign for](https://azendo.co/skills/backstage/)

## Tell us what your roadmap needs Terraform for.

A service delivery manager replies with the disciplines we would assign, the monthly capacity and what the first month looks like.

[All skills we assign for](https://azendo.co/skills/)