What should a DevOps engineer resume with Terraform and GitHub Actions include?
Start with the sections recruiters expect: name and contact details, headline, short summary, core skills, professional experience, education, certifications, and links. For this role, links matter more than they do on many other resumes. A hiring manager wants to see a GitHub profile, maybe a sanitized project repo, and sometimes a LinkedIn profile or portfolio page with architecture notes. If you have worked across AWS, Azure, or GCP, make that visible near the top rather than burying it in job bullets. Cloud scope is part of the job, not a footnote.
Your experience section should dominate the page. That is where Terraform modules, GitHub Actions pipelines, Kubernetes clusters, IAM design, container registries, and incident response belong. Keep a separate skills section, but do not let it carry the whole story. Most weak DevOps resumes read like a shopping list of tools. Strong ones show ownership: you built reusable Terraform, standardized GitHub Actions CI/CD, cut deployment risk, improved observability metrics, and supported engineers shipping code every day. Recruiters are not hiring a tool collector. They are hiring someone who makes delivery faster and systems safer.
How should you write a summary that gets interviews?
Use a headline that mirrors the target job, not your current internal title. If the posting says Senior DevOps Engineer, Platform Engineer, or Cloud Infrastructure Engineer, reflect that near the top when it is honest. Then use a three to four line summary that names your environment and your specialization. Mention cloud platform, infrastructure as code, CI/CD, Kubernetes, and one or two outcomes. A recruiter should know within seconds whether you build deployment systems, run production infrastructure, or focus on developer platform work.
A good summary sounds like this: senior DevOps engineer with six years supporting AWS production workloads, building Terraform modules, and running GitHub Actions pipelines for containerized services. Improved release reliability for 40 plus services by standardizing CI/CD templates, tightening secret handling, and instrumenting logs, traces, and alerting. That tells a recruiter more than vague claims about being passionate or results driven. If you are moving toward platform engineering, say so directly and frame your work around paved roads, self-service tooling, and internal developer experience.
Which skills and keywords matter most for ATS?
For ATS matching, group skills by function instead of dumping one giant alphabetized block. A smart layout might use Cloud and Containers, Infrastructure as Code, CI/CD and Automation, Observability and SRE, and Security. Under those, list the terms employers actually search for: AWS or Azure or GCP, Docker, Kubernetes, Helm, Terraform, GitHub Actions, Linux, Bash or Python, Prometheus, Grafana, OpenTelemetry, IAM, secrets management, and policy tooling. That structure reads well to humans and still gives the parser clear text.
Mirror the exact wording from the job description when it is accurate. If the ad says kubernetes and terraform, include that phrase in your summary, skills, or experience. If it says GitHub Actions CI/CD, do not rewrite it as automation pipelines and hope the ATS connects the dots. The same rule applies to observability metrics, incident response, platform engineering, EKS, AKS, GKE, reusable workflows, self-hosted runners, OIDC, and artifact management. Exact matches help filters; context in your bullets convinces the human reviewer.
Do not stuff keywords into a dead block at the bottom. Recruiters can tell when a resume was written for a bot. Put the important terms in three places: the headline or summary, the skills section, and the bullets where you proved the skill in production. If you have used both long and short forms, include both once. Write GitHub Actions and CI/CD, not the same phrase six times. Precision beats repetition, especially on a technical resume where credibility matters.
How do you turn infrastructure work into strong bullet points?
Every bullet should show change, not task ownership. The simplest formula is this: what broke or slowed the team down, what you changed, how broad the system was, and what improved. Instead of wrote Terraform for AWS, write built reusable Terraform modules for VPC, ECS, and IAM used by 12 service teams, cutting new environment setup from two days to two hours. That single line proves scope, architecture, reuse, and business value. Most resume advice on this is wrong because it treats DevOps as a tool stack instead of an operational outcome.
Do the same with delivery pipelines. Weak version: maintained GitHub Actions workflows. Strong version: redesigned GitHub Actions release pipelines with reusable workflows, environment approvals, and self-hosted runners, reducing failed production deployments from weekly fire drills to rare exceptions. For observability, do not stop at implemented monitoring. Say what you instrumented and why it mattered. Example: introduced service-level dashboards and alert tuning for API latency, error rate, and saturation, cutting noisy pages and speeding up incident triage. That is the language hiring managers remember.
What projects, links, and proof belong on the page?
DevOps hiring teams like evidence. Add a links section if you can point to work that is safe to share: a GitHub profile, a Terraform module, a Helm chart, a technical blog post, a conference talk, or a sanitized architecture diagram. You do not need a flashy portfolio. One well-documented repo with a README that explains tradeoffs is more useful than five half-finished side projects. If your best work is private, describe it clearly on the resume and use public projects to prove how you think.
The best project entries look like miniature case studies. Name the problem, the stack, and the result. For example, a home lab project that provisions Kubernetes clusters with Terraform and deploys services through GitHub Actions can show real breadth if you also mention secrets handling, rollback strategy, logs, traces, and cost controls. Keep it honest. A lab is not the same as running 24 by 7 production, but it is still valuable when it demonstrates sound decisions, clean automation, and curiosity that maps to the job.
How should the resume change for senior or platform engineering roles?
If you are targeting senior, staff, or a platform engineering resume, shift the emphasis from hands-on tool use to systems thinking. Yes, keep Terraform and GitHub Actions visible. Then go further: show how you set standards, reduced duplication, created reusable modules or workflow templates, enforced guardrails, coached developers, and improved the developer experience. A senior platform engineer is not hired just to write YAML faster. They are hired to make dozens of engineers faster without making production more dangerous.
This is where internal platforms, governance, and reliability work become resume gold. Good bullets mention migration strategy, service onboarding, golden paths, environment consistency, auditability, and cost visibility. Example: launched a paved-road deployment platform for 80 engineers using Terraform modules, GitHub Actions templates, and Kubernetes conventions, cutting setup drift and speeding up service onboarding. That reads much stronger than managed CI/CD. Scope, enablement, and repeatability are what separate mid-level DevOps work from senior platform work.
What formatting and content mistakes get this resume rejected?
Keep formatting boring. That is not an insult; it is a strategy. Use a single column, standard headings, clear dates, and plain text for skills. Avoid icons, tables, text boxes, and dense sidebars that parse poorly when you apply through Workday, Greenhouse, Lever, or similar systems. Save the file as a clean PDF if the application allows it, and keep a Word version ready in case a form asks for DOCX. Fancy design rarely helps a DevOps resume. Clear architecture thinking does.
The bigger mistake is content bloat. Do not spend a quarter page on every tool you have touched since college. Do not hide your best work under vague verbs like supported or assisted. Do not list certifications above real production results. Before you send the resume, compare it against the job description line by line. If Terraform, Kubernetes, GitHub Actions, observability, and cloud security are the job's center of gravity, they should also be the center of your document. A quick ATS check in HRLens can help catch gaps before a recruiter does.