Cloud Engineer CV Guide: How to Structure and Write It Well

The two people reading your CV

A cloud CV is read by two very different audiences, often in sequence. Understanding what each one needs changes how you write it.

Recruiters scan for: relevant job titles, company names, certifications, tools, years of experience. They are checking whether you broadly match the role description. This scan takes six to ten seconds. If nothing catches their attention, the CV goes in the no pile.

Hiring managers and senior engineers read more carefully once a CV passes the recruiter’s screen. They want to see real systems you’ve worked with, problems you’ve solved, and outcomes you’ve delivered. A flat list of tools without context doesn’t help them.

A good cloud CV satisfies both audiences. It is structured so the recruiter’s scan picks up the right signals, and substantive enough that the hiring manager learns something real from each section.

The right structure for a cloud CV

There is no single correct format, but for most cloud engineering roles the following order works well:

1. Name and contact details — at the top, including LinkedIn and GitHub if relevant
2. Summary or profile — two to four sentences; optional but useful for career changers
3. Core skills — a compact grouped skills section
4. Experience — roles in reverse chronological order with clear bullet points
5. Projects — for juniors and self-taught engineers, this section is critical
6. Certifications — listed clearly with full exam names and dates
7. Education — brief; usually at the bottom unless you are a recent graduate

The order above puts your strongest material where it gets read. If your work experience is limited but your projects section is strong, consider placing projects above certifications. Hiring managers often stop reading after the first substantive section, so lead with what demonstrates your capability best.

For a systematic section-by-section checklist covering what belongs in each block — with common cuts and a quick reference by experience level — see what to put on a cloud engineer CV.

Contact details and header

Include: full name, city (not full postal address), email, phone, LinkedIn URL, GitHub URL if your profile has real work on it.

Do not include: a photo, date of birth, marital status, national insurance number. These add noise and in some jurisdictions can create legal complications for employers.

If your GitHub is mostly empty or contains only tutorial exercises, leave it out. An empty GitHub signals nothing positive and a tutorial-heavy one signals that you haven’t built independently. Add the link once you have at least two or three real projects.

The summary or profile section

A short profile at the top is optional. It becomes useful when you are in a non-obvious position: a career changer, someone re-entering the market, or someone applying for a role slightly above their current level.

Two to four sentences is right. State your current level, your specialisation, and what you are looking for. Keep it factual.

A strong profile for a junior:

Cloud engineering practitioner with AWS Solutions Architect – Associate certification and hands-on Terraform and Kubernetes projects. Background in IT support. Looking for a junior infrastructure or platform engineering role where I can build on practical cloud skills.

A weak profile:

Passionate, results-driven professional with a proven track record of delivering excellent results in fast-paced environments seeking a challenging new opportunity.

The second example tells the hiring manager nothing useful. Avoid this kind of writing entirely — it is filtered out at the scan stage.

The skills section

Cloud CVs typically include a skills section near the top. It helps with ATS keyword scanning and gives the reader quick context before they reach the experience section.

Group your skills logically rather than listing them as a flat dump. For example:

• Cloud platforms: AWS (EC2, S3, RDS, VPC, IAM, Lambda), GCP (Compute Engine, GKE, Cloud Run)
• Infrastructure as code: Terraform, Pulumi
• Containers and orchestration: Docker, Kubernetes, Helm
• CI/CD: GitHub Actions, Jenkins, ArgoCD
• Monitoring and observability: Prometheus, Grafana, CloudWatch, Datadog
• Languages and scripting: Python, Bash

Be honest. Do not list tools you would struggle to discuss in an interview. If you have only watched a tutorial on something, leave it out. Hiring managers probe skills sections in interviews, and claiming familiarity you don’t have creates an awkward problem.

For a full breakdown of what to include and how to format it, see the guide to writing the skills section on a cloud CV.

Writing the experience section

This is the most important section for anyone with more than a year of professional experience. Each role should include: job title, company name, dates (month and year), and two to five bullet points.

What separates a weak bullet from a strong one

Weak bullet points describe tasks. Strong bullet points describe outcomes.

Weak: Responsible for managing cloud infrastructure using Terraform.

Stronger: Migrated 12 microservices from manual provisioning to Terraform, reducing deployment time from 45 minutes to under 5 minutes and eliminating configuration drift between staging and production.

Not every bullet needs a metric. Some achievements are genuinely hard to quantify. But where you can include a number — time saved, cost reduced, systems managed, incidents reduced — do it. Numbers make vague claims concrete and give the hiring manager something to ask about in the interview.

If you are still in a non-cloud role

Include your current role but be honest about the scope. If your cloud exposure has been through side projects and self-study rather than paid work, say that. Exaggerating responsibilities is easy to detect in an interview and creates a credibility problem that is very hard to recover from.

The projects section

For juniors, career changers, and self-taught practitioners, the projects section can be the difference between a callback and silence. It is your opportunity to show practical capability when your work experience section doesn’t yet demonstrate it.

Include only projects you built independently — not tutorials you followed, not course labs where you copied along. Hiring managers can tell the difference. A single genuine project you built and can explain in detail is worth more than five tutorial completions.

Each project entry should include what you built, what technologies you used, what the project demonstrates, and a link to the GitHub repo if the code is public and readable.

A well-written project entry:

Three-tier web application deployed to AWS using Terraform — VPC, ALB, RDS, and Auto Scaling Groups. CI/CD pipeline via GitHub Actions with automated testing and rolling deployments. github.com/yourname/aws-three-tier-app

See the full guide to writing the projects section on your cloud CV for detailed examples and the mistakes that undermine otherwise good projects.

Certifications

List certifications with the full official name, the issuing organisation, and the date passed. For example:

• AWS Solutions Architect – Associate (Amazon Web Services, January 2026)
• Certified Kubernetes Administrator — CKA (CNCF, November 2025)
• HashiCorp Certified: Terraform Associate (HashiCorp, September 2025)

Use the full official name, not abbreviations. “AWS SAA” means nothing to an ATS and can look sloppy to a hiring manager.

Certifications matter most for juniors who lack paid work experience. For senior engineers, they are useful supporting signals but not the primary decision factor. See how to list certifications on your cloud CV for details on placement and formatting.

What to cut

Most cloud CVs include content that dilutes rather than strengthens the overall impression. Common cuts:

• Objectives that say nothing. “Seeking a challenging role in a dynamic environment” is filler. Replace with a specific profile or remove it.
• Irrelevant old jobs. Once you have five or more years of cloud experience, a hospitality or retail job from ten years ago adds nothing.
• Outdated tools. If you used Ruby on Rails in 2012 and haven’t touched it since, omit it.
• References available on request. Employers know references exist. This line just wastes space.
• Every certification you ever studied for. If one expired, you don’t hold it. Leave expired certifications off unless they are from the last year.
• Long education sections. Once you have paid work experience, your degree doesn’t need module descriptions.

Format and length

Send your CV as a PDF. Word documents can render differently on different systems and sometimes lose formatting entirely.

Use a clean, readable font at 10–12pt. Avoid CV templates with heavy graphics, unusual colours, or multi-column layouts — ATS systems struggle to parse them, and they tend to look busier rather than better.

Sensible length targets:

• Junior (0–2 years experience): one page ideally; two pages only if the projects section genuinely needs the space
• Mid-level (2–5 years): one to two pages, with two being standard
• Senior (5+ years): two pages; more than two is usually excessive and will be skimmed

Tailoring for specific roles

You don’t need a completely different CV for every application, but light tailoring for roles you care about is worth the effort.

Read the job description carefully. Note the specific technologies and tools mentioned. If the role is Kubernetes-heavy and your CV mentions containers but buries Kubernetes in a list, move it up. If the role is AWS-focused and your CV leads with GCP experience, reorder.

Matching the language of the job description to your honest experience improves ATS scoring and signals to the hiring manager that you read the role carefully rather than sending a generic application.

For role-specific CV guidance, see the DevOps engineer CV example or the level-specific guides for junior, mid-level, and senior engineers. For the application process itself, see cloud job application strategy.