CV Keywords for DevOps Engineers and SREs (2026)

"DevOps Engineer" is a title that hides at least three different jobs. In one company it means the person who owns the build and release pipeline. In another it means a platform engineer who runs the Kubernetes clusters everyone else deploys to. In a third it is an SRE role with real reliability ownership, error budgets and a pager. The tools overlap enough that the postings look similar at a glance, and a CV written for one of these jobs can read as off-target for the other two.

There is a second problem, and it is close to the opposite of the one that affects system engineer CVs. Infrastructure candidates tend to leave terms out. DevOps candidates tend to put too many in. The tool list is the easiest part of the document to write, everyone in the field has roughly the same ten tools on it, and a page of logos in text form tells a reader nothing about which of the three jobs you can actually do.

This guide lists the term families that recur in platform and reliability postings, explains which part of the work is systematically under-sold, and shows where each family belongs in the document. Everything below applies to a CV and a resume alike, since the screening works the same way.

Work out which job the posting is describing

Before matching keywords, read the posting for one signal: what is the team responsible for when something breaks at three in the morning.

If the answer is nothing, and the posting talks about build times, release frequency and developer tooling, it is a pipeline job. If the answer is the platform, and the posting talks about clusters, self-service and internal developer platforms, it is a platform engineering job. If the answer is the product's availability, and the posting mentions SLOs, error budgets, incident review or on-call, it is an SRE job regardless of what the title says.

All three want Terraform and Kubernetes on your CV. Only the third one cares whether you have ever been woken up by an alert you then had to fix, and that is the part most candidates never write down.

Name the tool, not the practice

Recruiters search the applicant tracking system literally, and "CI/CD pipelines" does not match a search for "GitLab CI". This is the most common way a strong platform CV becomes invisible, and it is covered in more depth in our guide on how ATS systems read your CV.

So write the tool name and let the category follow it:

• "GitHub Actions" or "GitLab CI" rather than "CI/CD pipelines"
• "Terraform" and "Ansible" rather than "infrastructure as code"
• "Prometheus and Grafana" rather than "monitoring and alerting"
• "Amazon EKS" rather than "managed Kubernetes"

Keep the category words too, because a share of postings use only those, but they belong next to the tool names rather than instead of them.

The families that recur

Ordered roughly by how often they turn up in postings under these titles.

Containers and orchestration. Kubernetes is close to universal in this space, to the point that its absence from a CV is itself a signal. Docker, Helm and the managed distributions (EKS, AKS, GKE, OpenShift) belong here. If you have run Kubernetes in production rather than only on a laptop, make the difference visible.

Infrastructure as code. Terraform first by a wide margin, then Ansible, with Pulumi, CloudFormation and Bicep appearing in smaller numbers. State management, modules and reviewed changes to production infrastructure are worth a sentence, because they separate people who apply modules from people who write them.

CI/CD. GitHub Actions, GitLab CI, Jenkins, Azure DevOps, Argo CD. Jenkins still appears far more often than its reputation suggests, usually in companies with a long history and a pipeline nobody wants to touch.

Cloud. AWS leads under these titles, with Azure close behind and Google Cloud third. Name the services, not just the provider. A CV that says "AWS" is weaker than one that says EKS, IAM, VPC and S3 in the context of something you built.

Observability. Prometheus, Grafana, Datadog, the ELK or OpenSearch stack, OpenTelemetry. See below, because this family is asked for far more often than it is written about well.

Languages and scripting. Python and bash are the baseline. Go appears in a meaningful minority and is a genuine differentiator for platform roles, since that is what most of the tooling in this ecosystem is written in.

Version control and workflow. Git is assumed rather than requested, so listing it alone adds nothing. Branching strategy, code review of infrastructure changes and GitOps are the parts worth naming.

Security and supply chain. Secrets management (Vault, cloud key stores), image scanning, SBOMs, least-privilege IAM. This family has grown quickly and many CVs in the field still have nothing to say about it. If security is the part of the job you enjoy, our cybersecurity keyword guide covers the adjacent roles.

Networking. Load balancers, DNS, TLS certificates, ingress, service mesh. Less prominent than in pure infrastructure postings, but it is where a lot of production debugging actually happens.

Databases and stateful services. Managed databases, backups, migrations, and the honest experience of running something stateful on Kubernetes.

What DevOps CVs under-sell

Two things, and both are the parts hiring managers care most about.

The first is incident work. Platform CVs describe what was built and skip what was run. If you have carried a pager, say so plainly: the size of the rotation, the kind of systems, whether you wrote the runbooks or followed them, whether you ran post-incident reviews. An engineer who has led an incident review is describing a level of trust, not a chore. "Reduced mean time to recovery from 45 minutes to 12 by rewriting the alert routing and the on-call runbooks" is a stronger line than any tool list.

The second is cost. Cloud spend is a standing item in most engineering budgets now, and the engineer who reduced it is rare enough on paper to stand out. If you right-sized instances, moved workloads to spot capacity, cleaned up orphaned volumes or put a budget alert in place, that is a result with a number attached, and numbers survive screening better than adjectives.

Certifications help less here than the field assumes

The Kubernetes certifications (CKA and CKAD) and the cloud associate and professional tracks do appear in postings, but rarely as a hard requirement, and they carry less weight in this field than a public repository or a clearly described production system.

Keep the ones you hold in a short section near the end. This matches what we found writing the architect keyword guide: in infrastructure fields certifications are a tiebreaker rather than an entry ticket. Security is the one exception in this series, and the reason is explained in that guide.

Where the terms go

A skills section alone will not do it. Terms carry weight when a recruiter sees them attached to something you did.

1. Title line, under your name: the role you are targeting, next to your real job title.
2. Summary, two or three lines: the platform you run, in scale and tool names. "Kubernetes platform for 30 engineering teams on AWS, Terraform-managed, roughly 200 services."
3. Experience bullets: where the terms should live, each attached to an outcome or a scale.
4. Skills section: the remainder, grouped by family, not one long comma-separated line.

What a rewrite looks like

Before:

DevOps Engineer responsible for CI/CD pipelines, containerization and cloud infrastructure. Technologies: Docker, Kubernetes, Terraform, Jenkins, AWS, Python, bash, Ansible, Prometheus, Grafana, Git.

After:

Ran the deployment platform for 30 engineering teams on AWS: 200 services on EKS, all infrastructure in Terraform modules reviewed through pull requests. Replaced a Jenkins pipeline with GitHub Actions and cut the median build from 22 to 6 minutes. Carried a one-in-five on-call rotation, rewrote the alert routing and the runbooks, and brought mean time to recovery from 45 minutes to 12. Reduced monthly AWS spend by 18% through right-sizing and spot capacity.

Same person, same tools. The second version answers the question the first one leaves open: which of the three DevOps jobs can this candidate do.

Mistakes specific to DevOps CVs

The tool wall. Thirty technologies in a row reads as a keyword dump and dilutes the ones that matter. Cover the families in the posting properly and let the rest go.

Hiding the scale. Number of services, number of teams served, number of clusters, deployments per day. Platform work is judged by scale, and "managed Kubernetes clusters" tells a reader nothing.

Describing the tools instead of the change. "Implemented Terraform" says what you installed. "Moved 140 hand-built resources into reviewed Terraform modules, ending config drift between staging and production" says what changed.

Leaving out the failures you handled. Nobody with production experience believes a CV where nothing ever broke, and the recovery is the interesting part.

Once your terms are in place, the next step is adjusting them per posting rather than sending the same document everywhere. Our 10-minute tailoring routine is the short version of how to do that without rewriting your CV each time.

FAQ

Should my headline say DevOps Engineer or SRE?

Use the title from the posting you are applying to, next to your official one if they differ. The two are often used interchangeably by employers, and a recruiter filtering for one will not find a CV that only contains the other. If the posting mentions SLOs, error budgets or on-call, lead with the reliability side of your experience whichever title you put at the top.

Do I need Kubernetes to be competitive?

For most postings under these titles, yes, or at least you need a credible reason for its absence. It appears in the large majority of platform job descriptions. If your production experience is with ECS, Nomad or plain virtual machines, name that explicitly rather than leaving the space empty, and say what you have run at what scale. Employers distinguish between a candidate who chose a different orchestrator and one who has never operated anything.

How do I show reliability work without a formal on-call rotation?

Describe the incidents anyway. If you were the person called when the service broke, that is on-call regardless of whether there was a schedule with your name on it. Write what broke, how it was found, what you changed so it would not happen the same way again. The absence of a rota is far less interesting to a hiring manager than the absence of any evidence you have operated a system under pressure.

Is a homelab or a personal project worth putting on a DevOps CV?

For a first platform role, yes, and it can carry real weight if it is described as a system rather than a hobby: what it runs, how it is deployed, what happens when a node dies. For a senior role it should sit at the end and stay short, because at that level it competes for space with production experience that answers the same question more convincingly.