Mid-Level Cloud Engineer CV: How Your CV Should Change at 2–5 Years

What mid-level actually means on a cloud CV

Mid-level in cloud engineering typically covers the 2–5 year range after your first substantive role. But years are a rough proxy. What actually defines mid-level on a CV is demonstrated ownership: you have built systems, not just maintained them. You have made architectural decisions, not just followed playbooks. You have dealt with production problems, not just read about them.

The shift from junior to mid is partly about technical depth, but more importantly it is about scope. A junior engineer works within a system someone else designed. A mid-level engineer starts designing and modifying those systems. That distinction should be visible in your CV.

What changes from a junior CV

The projects section recedes

At the junior level, the projects section often does more work than the experience section. At mid-level, the opposite should be true. Your experience section should now demonstrate enough real-world capability that self-built projects are supplementary rather than central.

You don’t need to remove the projects section entirely, but if you have two or more years of relevant professional experience, the projects section moves to the end of the CV and becomes optional rather than essential.

Experience bullets shift from “what I did” to “what I delivered”

Junior CVs often describe tasks. Mid-level CVs should describe outcomes. This is the single most important difference.

Junior phrasing: “Worked with the team to deploy new services using Terraform and Kubernetes.”

Mid-level phrasing: “Led migration of five legacy services from manual EC2 deployments to containerised workloads running on EKS, reducing deployment time from 3 hours to under 10 minutes and enabling teams to deploy independently without infrastructure team involvement.”

The second version names a specific problem, shows ownership (“led”), describes what changed, and gives a concrete result. At mid-level, you are expected to be able to tell this kind of story because you have actually been responsible for things.

Certifications become supporting evidence, not the headline

At the junior level, a certification might be one of the strongest signals on your CV. At mid-level, the certifications section moves lower on the page, below experience. Real production experience outweighs exam passes for any hiring manager who is being thoughtful about the hire.

That does not mean certifications stop mattering — they remain useful signals, especially for roles at companies where procurement or internal compliance requires certified engineers. But a mid-level engineer who leads with certifications and has thin experience bullets is sending the wrong message.

Example structure and annotated bullets

Profile summary

Cloud infrastructure engineer with three years of experience building and operating AWS-based platforms. Specialised in Kubernetes and Terraform, with production experience across compute, networking, IAM, and observability. Recently migrated a legacy monolith deployment to a containerised microservices architecture. Looking for a senior or senior-adjacent role at a product company.

Commentary: Specific, honest, and contains the primary keywords (AWS, Kubernetes, Terraform). The mention of a specific migration shows real work without overstating seniority.

Experience bullets — what works at mid-level

Cloud Engineer — Greenfield Platform, London (Remote)
April 2023 – Present

• Designed and implemented a GitOps deployment system using ArgoCD across three environments (dev, staging, production) for a 12-service microservices platform, reducing manual deployment steps from 15 to 2 and cutting failed deployments by 70%
• Rebuilt the VPC architecture to enforce network segmentation — private subnets for databases and internal services, public subnets limited to ALBs and NAT Gateways — eliminating a category of misconfiguration that had previously caused two security findings
• Implemented Prometheus and Grafana monitoring across the platform, created SLO-based dashboards for the four most critical services, and set up PagerDuty alert routing that reduced noise by removing 80% of non-actionable alerts
• Ran cost optimisation review that identified and eliminated £18,000/year of waste from over-provisioned RDS instances and unused Elastic IPs

Commentary: Each bullet demonstrates ownership of a system or change. None of them say “worked with” or “helped.” The architecture decision in the VPC bullet and the outcome framing throughout is what separates mid-level from junior CV writing.

The impact vs activity framework

A useful test for every bullet on a mid-level CV: does this describe an activity or an impact?

Activity: “Maintained Kubernetes clusters and resolved issues as they arose.”

Impact: “Upgraded three production Kubernetes clusters from version 1.24 to 1.28 with zero downtime using a rolling node replacement strategy, resolving a version gap that had been blocking adoption of new Kubernetes features.”

The activity version says you existed in a role. The impact version says you made a specific decision, executed a specific plan, and achieved a specific result. Mid-level engineers should be able to produce impact statements for most of their significant work. If you cannot, it may be worth reflecting on what you actually owned in that role.

Handling common mid-level CV weaknesses

You’ve been in the same role for all of your experience

If you have spent three years at the same company, the CV needs to show progression within that time. Break the experience into periods or use subheadings to separate the work you did in year one versus year three. If your title changed, use both title and date range for each. If it didn’t, show the evolution of your responsibilities in the bullets themselves.

Your experience is broad but shallow

A mid-level CV that shows familiarity with 20 tools but no depth in any of them is weaker than one that shows genuine ownership of three or four. Hiring managers for mid-level roles want engineers who have gone beyond surface knowledge. Identify your actual areas of depth and lead with those.

Your previous role was in software engineering, not infrastructure

Career changers from software engineering to cloud roles at mid-level are common. In this case, lead with the cloud infrastructure work you’ve done — whether in the same role, in a previous role, or through significant projects — and frame your software background as a complementary strength rather than something that needs explaining away. Hiring managers for platform or DevOps roles often value the developer empathy that software engineers bring.

Length and format

Two pages is standard for mid-level cloud engineers. One page feels thin if you have three or more years of substantive work. More than two pages is usually unnecessary and suggests difficulty prioritising — not a signal you want to send in a CV.

If you are struggling to fit relevant content into two pages, focus on your most recent two roles and cut older, less relevant work to one or two lines each.

For more on the overall structure and format, see the complete cloud engineer CV guide. For the next step up, see the senior cloud engineer CV guide.