Terraform, Ansible, Pulumi, CloudFormation: infrastructure as code tools appear on most resumes from DevOps, SRE, cloud and platform engineers, and increasingly on those of backend developers. For a platform team lead, however, the list of tools is not enough. What they want to know is what was managed as code: how many environments, which services, what share of the infrastructure, with what level of review and automation. The same word, Terraform, can mean occasionally editing a file written by others or designing the modules shared by an entire organisation. This article explains how to describe that scope, with before-and-after examples.
What infrastructure as code covers
Infrastructure as code means describing infrastructure (networks, machines, databases, access rights, clusters, managed services) in versioned files, rather than configuring it by hand in a console. These files are reviewed, tested and applied automatically, like application code.
Two families of uses are generally distinguished.
- Provisioning: creating and evolving infrastructure resources, particularly in the cloud. This is the territory of Terraform 🔗, its open source equivalent OpenTofu 🔗, Pulumi 🔗 or each provider’s own tools.
- Configuration management: installing and configuring software on existing machines and maintaining their state. This is the territory of Ansible 🔗 and comparable tools.
To these two families are added GitOps approaches, where the desired state of a Kubernetes cluster is described in a repository and applied continuously by a tool such as Argo CD 🔗. Our article on Kubernetes on a resume details how to present that level.
A recruiter wants to understand which of these uses you practise, at what scale and with what autonomy.
Terraform, Ansible, Pulumi: what each tool says about you
Each tool sends a slightly different signal, which is useful to know when building your skills section.
- Terraform or OpenTofu: the most widespread provisioning tool, multi-cloud, with a declarative language. It signals cloud practice and state management (the state 🔗 file that describes what actually exists). It is often the tool job ads mention first.
- Ansible: signals practice in server configuration, common in hybrid environments, on premises or at hosting providers. It is popular with profiles coming from systems administration.
- Pulumi: lets you write infrastructure in a general-purpose programming language (TypeScript, Python, Go). It often signals a profile close to development, in a team that shares the application’s language.
- CloudFormation, Bicep and providers’ own tools: signal a specialisation in a particular cloud.
- Helm, Kustomize and GitOps tools: signal practice in deploying to Kubernetes.
Listing them is not enough: what counts is what you did with them. Group these tools in an "Infrastructure and automation" line in your skills section, as suggested in our article on presenting your tech stack, then prove their use in the experience section.
Describing a scope rather than a tool
A good description of infrastructure as code answers five questions.
- What? The resources managed as code: network, compute, databases, clusters, access rights, DNS, monitoring.
- How many? The number of environments, cloud accounts or projects, services, servers.
- What share? Is everything in code, or only part of it? Did you migrate resources created by hand?
- How? Shared modules, conventions, pull request review, automatic plans, tests.
- With what effect? Time to create an environment, incidents avoided, drift detected, autonomy gained by teams.
You do not need to answer all five in every bullet, but at least three. A recruiter who reads "4 environments and 3 AWS accounts managed entirely as code, with pull request review" immediately understands your level.
Before-and-after examples
A backend developer who touches infrastructure
Before: "Terraform, Docker, AWS."
After: "Added and maintained my service’s resources in the platform team’s Terraform modules (message queue, managed database, access rights), with review by the platform team before each apply."
This version is honest about the role (contributor, not designer) and shows real practice.
A DevOps engineer
Before: "Set up infrastructure as code with Terraform and Ansible."
After: "Brought the infrastructure of three hand-built environments under Terraform (network, databases, load balancers) and configured one hundred and twenty servers with Ansible; time to create a new client environment cut from two days to two hours."
The scope, the migration and the effect are explicit. The DevOps or SRE engineer resume template contains bullets of this kind, with Terraform and Ansible.
A platform engineer
Before: "Designed Terraform modules."
After: "Designed a library of versioned Terraform modules (network, cluster, database, monitoring), used by fifteen product teams to create their environments on their own; automated module tests and a documented upgrade policy."
Here, the recruiter reads an organisational responsibility: internal users, versions, tests and a policy.
A profile moving on from systems administration
Before: "Automation scripts."
After: "Replaced Bash deployment scripts with tested Ansible roles, then provisioned the hosting provider’s virtual machines with Terraform; documentation and training for two colleagues in the operations team."
CI/CD and code review for infrastructure
A sign of maturity that platform teams look at closely: is infrastructure treated as code, with the same guarantees?
Practices that deserve a mention:
- pull request review of every infrastructure change;
- automatic plans shown in the pull request, to see the effect of a change before applying it;
- automated application from a continuous integration pipeline, rather than from a personal machine;
- shared, locked state management, and separation of environments;
- tests and checks: syntax validation, security rules, detection of drift between the code and the real infrastructure;
- secrets management, outside versioned files.
One line is often enough to express it: "Every infrastructure change goes through a pull request with an automatic plan and is applied from CI; weekly drift detection."
Certifications can complete the picture. HashiCorp offers a Terraform Associate certification 🔗, and cloud providers’ associate certifications validate knowledge of the services you describe in code; our article on cloud certifications helps you choose.
For this scope to be read, the resume must also be extracted correctly by recruitment software, which often filters on "Terraform" or "Ansible". The TechCV editor keeps your tools and bullets as plain text, in a one-column layout, so they are not lost along the way. You can rework your resume starting from the DevOps template.
Frequently asked questions
Should I list Terraform if I have never designed a module?
Yes, if you have really used it, specifying your role: contributing to existing modules, adding resources, reviewing. It is a sought-after skill even at that level, and honesty about the scope reassures.
Terraform or OpenTofu: which should go on the resume?
List the one you have used. The two tools share much of their language and concepts; mentioning "Terraform (and OpenTofu)" is reasonable if you have practised both or followed a migration.
Does infrastructure as code belong on a developer’s resume?
Yes, increasingly. Many teams ask developers to describe their service’s resources as code. A bullet showing this practice distinguishes a developer who is autonomous in getting to production.
How do I show the effect of infrastructure as code?
Through operational indicators: time to create an environment, number of environments managed, incidents caused by manual changes, disaster recovery time. Choose those you actually tracked.