How to write a CV for a DevOps engineer role

What a hiring manager scans for first

A DevOps hiring manager reads a CV looking for evidence of two things before anything else: which parts of the toolchain you've actually operated, and whether you've carried production responsibility or just touched it in a sandbox. They are scanning, not reading, on the first pass. That means the first third of the page needs to answer 'what have they run in production, and at what scale' without the reader having to hunt for it.

This is different from a software engineering CV, where the scan is for languages and system design. A DevOps or SRE hiring manager wants to see the specific orchestration and provisioning tools (Kubernetes, Terraform, Ansible, Pulumi), which cloud (AWS, Azure, GCP — and which services within it, because 'AWS' alone tells them little), the CI/CD tooling (Jenkins, GitLab CI, GitHub Actions, CircleCI, ArgoCD), and whether you've owned on-call. If your CV opens with a generic summary about being a 'results-driven professional', you've used the six seconds you had on something that tells them nothing.

Put the stack you used, and your specific responsibility within it, in the first job entry, in the first two lines. 'Owned Terraform modules provisioning EKS clusters across three AWS accounts' does the job. 'Responsible for infrastructure and deployment processes' does not, because it would survive being copied onto a sysadmin's CV or a build engineer's CV unchanged. That's the test: if a sentence would sit equally well on a different occupation's CV, cut it.

Certifications and how much they actually count

There's no licence to practise as a DevOps engineer — no professional registration body, nothing equivalent to a Bar qualification or a Gas Safe number. So certifications here function as a signal, not a gate, and hiring managers vary a great deal in how much weight they give them. It's worth being honest about that variation rather than pretending there's a settled answer.

The certifications that actually get recognised in this field are narrow: AWS Certified DevOps Engineer – Professional, AWS Certified Solutions Architect, Microsoft's Azure Administrator (AZ-104) or Azure DevOps Engineer Expert (AZ-400), Google's Professional Cloud DevOps Engineer, the Certified Kubernetes Administrator (CKA) and Certified Kubernetes Application Developer (CKAD) from the CNCF, and HashiCorp's Terraform Associate. If you hold one of these, list it with the year — certifications in this field age, because the services and exam content change every year or two, and a 2019 associate-level cert reads differently from one taken in 2025.

What doesn't help: listing every Udemy or Coursera course you've completed. A hiring manager who has to work out whether 'Docker & Kubernetes: The Complete Guide' is a vendor-recognised credential or a weekend course will assume the latter and move on. If self-directed learning is genuinely relevant, put it in a short 'currently learning' line rather than dressing it up as equivalent to a certification — the difference is visible immediately to anyone in the field, and pretending otherwise costs you credibility on everything else on the page.

One thing worth naming directly: there is no good evidence that certifications correlate with on-the-job performance in this field, and plenty of experienced engineers in senior roles hold none. Treat them as useful shorthand for a recruiter doing a first pass, not as proof of competence for someone technical doing the second one.

How experience is normally evidenced in this field

DevOps work doesn't produce the kind of portfolio a designer or a writer can point to. Nobody can look at your Terraform state file. So the CV has to do the evidencing job itself, through specifics that are checkable in principle even if the reader doesn't check them.

The specifics that carry weight:

• Scale: number of nodes, clusters, services, or environments you were responsible for. 'Managed the Kubernetes platform' is vague; 'ran a 40-node EKS cluster serving 12 production services' is not.
• Before-and-after operational metrics you can actually attribute to your work: deployment frequency, lead time for changes, mean time to recovery (MTTR), change failure rate — the four DORA metrics are the closest thing this field has to a shared measurement language, and naming which one you moved, and by roughly how much, is far stronger than 'improved deployment efficiency'.
• Incident ownership: whether you were the person paged, not just someone on a team that had an on-call rota. 'Primary on-call for payments infrastructure, one week in four' is specific. 'Participated in incident response' is not.
• Migration and platform work: moving from EC2 to containers, from a monolith to microservices, from self-managed Kubernetes to a managed control plane, from Jenkins to GitOps with ArgoCD. Migrations are natural CV material because they have a clear before, after, and duration.
• Cost: cloud cost optimisation is something FinOps-literate hiring managers specifically look for and it's rarely mentioned. If you right-sized instances, moved workloads to spot, or renegotiated reserved capacity and it reduced spend, say so — this is one of the few places a number belongs, provided it's one you can stand behind in an interview.

What doesn't evidence experience: a bare list of tool names with no context. 'Skills: AWS, Docker, Kubernetes, Terraform, Jenkins, Prometheus, Grafana' at the top of the page tells a hiring manager you've heard of these tools. It doesn't tell them what you did with them. Every tool named should appear again, attached to a task, somewhere in the experience section — if it doesn't, the hiring manager reasonably assumes exposure rather than ownership.

What belongs on the page, specifically

• The cloud provider and the depth within it. Not just AWS — which services. EC2 and S3 is basic; EKS, RDS, IAM policy design, VPC peering, and Lambda for automation is a different level of the platform.
• Infrastructure-as-code tooling and whether you wrote modules or consumed them. There's a real difference between writing a reusable Terraform module used by other teams and applying someone else's.
• Container orchestration specifics: Kubernetes distributions matter (vanilla, EKS, GKE, AKS, OpenShift), as do the surrounding tools — Helm, Kustomize, service meshes like Istio or Linkerd if you've used them.
• Observability stack: Prometheus, Grafana, Datadog, the ELK/EFK stack, OpenTelemetry. Say what you instrumented, not just what dashboard you looked at.
• CI/CD platform and pipeline design, including whether pipelines were something you configured within an existing template or something you designed from scratch, including artefact management and rollback strategy.
• Security and compliance touchpoints relevant to this role: secrets management (Vault, AWS Secrets Manager), SOC 2 or ISO 27001 audit support, least-privilege IAM work. If you've been through a compliance audit as the engineer who had to produce evidence for it, that's worth a line — auditors and hiring managers both recognise it as a specific kind of pressure.
• Language used for automation and tooling — Python, Go, Bash — named as tools for a purpose (writing custom operators, automation scripts, internal CLIs), not as a generic 'programming languages' list.

What candidates from this background routinely leave out

The most common gap is team and organisational context. DevOps sits between development and operations by definition, and a CV that doesn't say who you worked with — 'embedded with two product teams', 'sole platform engineer supporting 30 developers', 'part of a four-person SRE team covering follow-the-sun on-call' — leaves the hiring manager unable to judge scope. The same infrastructure work means something different done alone versus done as part of a twelve-person platform team.

The second gap is failure. Engineers in this field are often uncomfortable putting an outage on their CV, but a well-handled incident, with a clear description of what broke, what you did, and what changed afterward, is stronger evidence of seniority than another line about 'maintaining uptime'. Anyone can claim high availability; not everyone can describe what they did the one time it wasn't available.

The third is the boring maintenance work that keeps a platform running — patching, dependency upgrades, certificate rotation, backup and restore testing. It's unglamorous, so people cut it, but a hiring manager building an ops-heavy team will often care more about whether you've actually run a disaster recovery drill than whether you've used the newest tool in the stack.

Finally, people leave out what they decided not to do. Platform engineering is as much about saying no to unnecessary complexity as building things. A line like 'recommended against a service mesh migration on cost and operational overhead grounds' signals judgement that a list of tools never will.

What to do next

Go through your current CV line by line and ask, for each bullet: could this sentence, unchanged, sit on a systems administrator's CV or a backend developer's CV? If yes, add the specific tool, the specific scale, or the specific metric until it couldn't. Then check that every tool you've named in a skills list also appears attached to a task in your experience section — if it doesn't, either add the task or remove the tool.

If you're sending applications and hearing nothing back, it's worth checking whether the gap is the CV or the fit — a lot of DevOps roles advertised under one title cover quite different actual work, from platform engineering to release management to pure SRE, and a CV tuned for one reads as a mismatch for another. jobmarket.pro reads each advert in full and prepares the application from your actual experience, matched to what that specific role is asking for, rather than sending the same CV at every posting with the job title changed.