cvharbor editorial

Cloud and DevOps career change: the CV that survives the interview

A hiring manager reading a cloud or DevOps CV is trying to work out one thing: can this person be trusted near production. A wall of certification logos does not answer that. A described project, honestly labelled, does.

You almost certainly have more relevant experience than you think, and it is buried under a job title that does not say "cloud" anywhere. Sysadmin, helpdesk, network engineer, QA, even IT support: all of these involve infrastructure, troubleshooting under pressure and systems that have to keep running. The CV problem is not a shortage of substance. It is that none of it has been translated into terms a cloud or DevOps hiring manager recognises on a skim.

Stop collecting certifications

Certifications are a filter, not a hire. Recruiters and applicant-tracking searches do use them to shortlist, so leaving out an obviously relevant one costs you a search match. The mistake is treating the certification as the achievement, when the achievement is what you did after passing it.

Which certifications actually move the needle

This varies by target role and employer, but a few patterns hold up. Associate-level certifications from the major providers, AWS Solutions Architect Associate, Azure Administrator, Google Associate Cloud Engineer, are recognised and searched for. Entry-level "Fundamentals" or "Practitioner" badges signal that you have read the marketing material, and hiring managers generally know the difference. Kubernetes' CKA and Terraform's associate certification carry real weight for DevOps roles specifically because they are hands-on exams, not multiple choice.

• Worth the study time: one cloud provider's associate-level certification, chosen to match the job postings you are actually applying to rather than whichever one has the cheapest exam voucher.
• Worth it for DevOps specifically: CKA (Certified Kubernetes Administrator) or the Terraform Associate, both practical exams that test configuration rather than recall.
• Padding, not proof: multiple "Fundamentals" or "Practitioner" badges from different providers. One is a reasonable starting point; three says you are avoiding the harder exam.
• Skip unless the job posting asks for it by name: vendor-specific certifications several levels above your current experience, or certifications in a tool your target employers do not use.

Lab projects: describe them like what they are

A home lab or a personal project is legitimate evidence. Pretending it is production experience is the fastest way to lose credibility in an interview, because the follow-up questions, "what was the traffic volume", "how did you handle an incident", "who else was on call", have no honest answer if the project was solo and unmonitored. Describe the project accurately and let its content do the work.

The honest version is more persuasive, not less. It names specific tools, shows you thought about failure, and links to something the interviewer can actually check. The overstated version invites a question it cannot survive: which enterprise, whose SLA.

Put lab and personal projects in their own clearly labelled section, separate from your employment history. Mixing them into a chronological work timeline as if they were jobs is the kind of thing that gets a CV set aside once noticed, and it will be noticed.

Translate your current role into infrastructure language

Helpdesk and sysadmin work already involves the skills a DevOps job posting asks for. The gap is usually vocabulary, not substance. A ticketing system is an incident workflow. A patch schedule is configuration management. Writing the same experience in the target field's terms is not exaggeration, it is accurate description using words the reader will recognise.

Both describe a real job. The first surfaces the parts that matter to a DevOps hiring manager: automation, scale, measurable time saved, documentation. Nothing in it is invented; it is the same role read for what it actually contained.

What genuinely transfers from adjacent IT roles

• Scripting anything, even basic Bash or PowerShell for repetitive tasks, is the same instinct that drives infrastructure-as-code.
• Network fundamentals from helpdesk or network engineering, subnets, DNS, load balancers, map directly onto cloud networking concepts and rarely need relearning from zero.
• On-call and incident response experience, even informal, is closer to SRE work than most people realise. Being the person who gets paged and has to triage under pressure is the actual job.
• Linux administration, package management, systemd, log files, transfers almost unchanged into cloud and container environments.
• Documentation habits: someone who already writes runbooks and change tickets will pick up infrastructure documentation faster than someone starting from nothing.

You can list your certifications and lab projects in dedicated sections while keeping your employment history chronological and honest. Build your CV

What a lab project cannot substitute for

Be honest with yourself about the gap between a personal project and production operations at scale. A solo Terraform deployment does not involve code review, change approval, an on-call rotation, or a postmortem culture. Naming that gap in an interview, and describing how you would approach it, reads as self-awareness. Pretending the gap does not exist reads as inexperience the moment a real scenario question arrives.

Before you send it

• Is every certification connected to a project on the same CV, rather than listed alone?
• Are lab and personal projects clearly labelled as such, in their own section, not blended into your employment history?
• Has your current or most recent IT role been rewritten in infrastructure vocabulary, without inventing scale or responsibility that was not there?
• Does each project description name specific tools and at least one thing that went wrong or was tested, rather than only what was built?
• Is the seniority you are applying for realistic given what your projects and certifications actually demonstrate?