How to Write the Skills Section on a Cloud CV

The skills section is one of the first things recruiters scan on a cloud CV. Done well, it communicates your technical context in five seconds and helps you appear in automated keyword searches. Done badly, it reads like a copy-paste of a job description and tells a hiring manager almost nothing. This guide covers what to include, how to organise it, and the mistakes that undermine an otherwise strong CV.

Why the skills section matters

Two things happen when someone reads your skills section:

ATS (applicant tracking systems) scan for keyword matches between your CV and the job description. A skills section with specific tool names — AWS, Kubernetes, Terraform — increases the probability that your CV surfaces in automated screening.

Recruiters use the skills section as a quick orientation tool. Before reading your experience section, they want a mental map of your technical context. A clear, grouped skills section gives them that in seconds.

But here’s the problem: many cloud engineers either list too many skills (diluting the signal) or list them in a flat, unsorted way that makes the section hard to read. Both approaches undermine the purpose.

Grouped vs flat format

The most common skills section mistake is the flat format: a comma-separated wall of text listing every tool in one long line.

Flat format (harder to read):

Skills: AWS, GCP, Azure, EC2, S3, IAM, VPC, Lambda, RDS, Terraform, Pulumi, Ansible, Docker, Kubernetes, Helm, Kustomize, GitHub Actions, Jenkins, CircleCI, ArgoCD, Python, Bash, Go, Prometheus, Grafana, Datadog, ELK stack, CloudWatch, Linux, Windows Server, Git, Jira, Confluence

Grouped format (easier to scan):

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

The grouped format shows technical breadth without creating noise. The reader can see at a glance that this person covers cloud, IaC, containers, CI/CD, and monitoring — the core stack for most cloud engineering roles.

What to include

Include skills that meet both of these criteria:

You have used them in a real context — a job, a real project, or significant hands-on study
You could discuss them in an interview beyond a surface-level explanation

The interview test is the most useful filter. If an interviewer said “tell me about your experience with X” and you would struggle to say more than a couple of sentences, X does not belong on your skills section yet.

What level of use counts?

You do not need to be an expert in every listed skill. The question is whether you have enough practical experience to be useful and credible in a conversation about it. General rules:

Daily use in a job: definitely include
Used in a real project you built independently: include
Studied and practised with hands-on labs: include with a qualifier if you feel you need one (“Ansible — working knowledge from self-directed study”)
Watched a tutorial or completed a course but never built with it: do not include
Read the documentation but never deployed it: do not include

What to leave out

The following types of items commonly appear in cloud CV skills sections and should be removed or reconsidered:

Generic soft skills

“Communication,” “teamwork,” “problem-solving,” “time management” — every candidate lists these. They are not screening criteria for cloud roles, they add length without value, and they look like placeholder content. Remove them.

Basic tools that every technical person is expected to know

Listing “Microsoft Word,” “Google Docs,” or “email” in a cloud engineer skills section signals a lack of judgment about what belongs there. Similarly, “Git” on its own is expected knowledge, not a differentiating skill.

Every cloud service you have ever opened in the console

Listing 40 AWS services in your skills section is not impressive — it suggests you’ve logged in and clicked around rather than genuinely worked with each service. Be selective. List the services you have production or project experience with.

Outdated technology that isn’t relevant to modern cloud roles

If you worked with something five years ago and have not touched it since, consider whether it is relevant to the roles you are applying for. If it’s not, cut it. If it is (for example, legacy system knowledge that is genuinely rare), keep it but note the context.

How long the section should be

The skills section should not take up more than one quarter of your CV. For most engineers, six to ten grouped categories with three to six items each is right.

If you are genuinely strong across a wide range, you may have more. If you are early in your career, you may have fewer. Both are fine — what matters is that every item on the list belongs there.

Tailoring the skills section for specific roles

When applying to roles you care about, review the job description and make sure the specific tools and services mentioned are present in your skills section — if you genuinely have experience with them. ATS systems match against the exact words in job descriptions, so if a role says “ArgoCD” and your CV says “GitOps,” you may not match on that term.

This does not mean adding things you don’t know. It means making sure that skills you genuinely have are named in a way that matches how the employer describes them.

For the overall CV structure and how the skills section fits, see the complete cloud engineer CV guide. For guidance on what you should be able to demonstrate in interviews, see the cloud engineer skills explained guide.