How to prove your DevOps skills without a CKA

The CKA costs US$445 to sit. One free retake if you fail. Two hours, live cluster, 15 to 20 performance-based tasks. A commonly cited range is 30 to 60 hours of prep for someone who already works with Kubernetes day to day, and more for someone who does not.

If you have the budget and the bandwidth, it is a defensible line on a CV. If you do not, the internet will tell you that you have no way to prove you know Kubernetes. That is wrong, and the people who tell you that are usually selling a course.

This post is about what actually signals DevOps competence to a hiring manager who knows what they are looking for, and what you can do this week to demonstrate skill you already have.

What the CKA tests, and what it does not

The CKA tests whether you can, under time pressure, on a prepared cluster, do things like: create a deployment from a YAML spec, troubleshoot a broken node, configure an Ingress, set up an RBAC role, install a cluster component with Helm. These are useful things to know. They are also well-bounded, repeatable tasks on an environment someone else set up for you.

Things the CKA does not test:

• Designing a cluster topology for a workload you have not seen before
• Deciding whether Kubernetes is even the right answer
• Running a production incident on day 47, when Prometheus is noisy, nobody can agree what changed, and the CEO is in the Slack channel
• Writing a runbook good enough that the on-call engineer at 3am does not escalate
• Explaining to a non-technical stakeholder why the migration will take three weeks instead of three days
• Living with a decision you made 18 months ago

The CKA is a competence floor, not a ceiling. Passing it proves you can operate inside a known frame. It does not prove you can operate a cluster in production, any more than a driving test proves you can drive in a snowstorm with a flat tyre and a toddler screaming in the back seat.

The inverse is also true. Plenty of engineers run real Kubernetes clusters at real companies and would not pass the CKA on a first sitting without revision, because they have not looked at kubectl create role syntax in eighteen months. They use the docs, like everyone else. This does not make them bad at their jobs.

Memorisation drills vs demonstrated skill

The CKA, like most timed certifications, rewards a specific skill: rapid navigation of syntax, documentation and familiar workflows under pressure, on a curriculum you have seen in advance. That is a skill. It is not the skill most hiring managers are actually trying to hire for.

The skill most good hiring managers are trying to hire for is: can this person take an ambiguous problem, investigate it, form a hypothesis, test it, and communicate the result to a team? A two-hour performance exam cannot test all of that. It does not try to. It tests the floor.

If your goal is to clear a recruiter's keyword filter, the CKA works. If your goal is to convince a strong engineering manager that you can do the job, you need to show them the work, not the certificate.

What actually signals DevOps competence

Every senior engineer or hiring manager we have spoken to about this converges on roughly the same list. In rough order:

1. A history of specific, dated, traceable work - a PR that migrated a service from a VM to k3s with before-and-after metrics. A repo that shows how your Terraform evolved over two years. A write-up of an incident you resolved, including what you got wrong.
2. The ability to explain tradeoffs out loud - why StatefulSet vs Deployment for this workload, why Helm vs Kustomize for this team, why you rejected the obvious answer and took the harder one.
3. Evidence of ownership under pressure - a post-mortem you wrote, a bug you triaged and fixed in something you did not build, a failure you handled badly the first time and better the second.
4. Familiarity with the unglamorous - backups that actually restore, secrets rotation that actually rotates, a staging environment that actually resembles production. The parts that take a year to care about because nothing goes wrong until it does.
5. Taste - the judgement to pick boring tools for boring problems, and the restraint to not introduce a service mesh because someone wrote a blog post about one.

None of those are on the CKA. All of them can be demonstrated in public.

Show your work

The single most undervalued move for a self-taught or non-credentialled DevOps engineer is to make their thinking visible. Not a manicured portfolio site. Actual artefacts that a hiring manager could read in twenty minutes and form an opinion.

A few concrete forms this can take:

• A GitHub repo of your homelab or personal cluster, with commits that tell a story. Not one commit titled "initial commit". A history of fix: loki was OOMing because retention was misconfigured and refactor: switch from helm to kustomize after the umpteenth values.yaml merge conflict. Real commits from a real engineer.
• A short write-up of an incident or migration you worked on. Anonymise what you need to. Three to five hundred words. What happened, what you thought was happening, what was actually happening, what you would do differently. One of these is worth more than any certification.
• A public list of opinions. Not hot takes. A page that says "here is what I think about Argo CD vs Flux, here is what I think about service meshes, here is when I think Kubernetes is the wrong answer." Recruiters will not read it. The engineering manager on the hiring panel will, and that is the person who decides.
• Answers to real questions, on a real forum. A handful of substantive Stack Overflow or Reddit replies over twelve months signals more than a thousand-word LinkedIn post. Stack Overflow karma is hard to fake.
• Contributions, however small, to tools you actually use. A docs fix to the kube-prometheus-stack chart. A one-line bug fix to a Helm chart. These do not need to be impressive. They need to exist.

If you are worried this takes more time than prepping for the CKA, it does not. It takes the time you are already spending doing the work, plus maybe an hour a week to write it down.

What hiring managers look for beyond CKA certification

A good hiring manager reviewing a candidate without a CKA will look at the same evidence they would look at for a candidate with one. The CKA just slightly lowers the bar for how much other evidence they need to see before they take the call with you. It does not replace the other evidence.

Specifically, on a thirty-minute call, they will usually:

• Ask you to describe a real production incident in detail. Not a textbook one. Yours. They are listening for specificity, honesty about what you did not understand at the time, and what you learned.
• Give you a vague problem ("our deploys are slow, how would you start investigating") and listen to your questions. They are looking for whether you narrow down before you solve, or whether you jump to a fix.
• Ask what you would not use Kubernetes for. The candidates who cannot answer this honestly are usually the ones who have only used Kubernetes.
• Ask about the worst decision you made that you had to live with. They are looking for self-awareness, not blamelessness.

None of those are on the exam. All of them are gettable with practice, but the practice is the work, not a course.

Five things to do this week

If you are reading this and thinking "fine, but I need something concrete to do by Friday", try one of these:

1. Write the incident post-mortem you never wrote. Pick an incident from the last twelve months. 500 words. Publish it somewhere, even if it is a gist. Link it from your CV.
2. Fix your commit messages. Go back through your last six months of commits. Are they wip, fix, more changes? Next month, write them like a human. A recruiter scrolling your repo will not read your code, but they will read your commit messages.
3. Pick one tool you use and file a docs PR. Wrong example in the README. Missing flag in the CLI help. Anything. It takes an hour. It puts your name in a commit history on a tool a real hiring manager has used.
4. Record yourself solving a real problem. Not a tutorial. You, debugging something in your homelab, thinking out loud. Ten minutes. Unedited. Upload unlisted. Send the link when asked about how you approach problems.
5. Write one opinion. Not "10 Kubernetes best practices". One thing you believe, with the reasoning. "I do not use a service mesh in teams under 20 engineers, because..." Publish it on your own site, or a Gist, or LinkedIn if you must.

Each of these takes under three hours. Together they do more to prove your skill to a thoughtful hiring manager than a US$445 exam.

There is a catch. Public work takes sustained effort, employer confidentiality puts some of your best examples off limits, and none of this clears an ATS keyword filter as neatly as a certification line. Evidence helps once a human sees it; getting past the machine is a different problem.

Where we fit in

We built SkillBricks for exactly the candidates this post is about - people with real skill and no prestigious credential to wave at it. Your wall is a verified record of work in real Kubernetes environments, not a multiple-choice score. It is one way to show the evidence we have been talking about, and it stays free for candidates forever. There are other ways. GitHub works. A personal site works. Stack Overflow works. Use any of them. Use several.

Yes, your wall is anonymous to hiring teams by default. That is deliberate - if everyone's name was visible from the start, the candidates with quieter walls would get drowned out by the ones with the noisiest profiles, and the list would just get scraped and recruited through LinkedIn the next morning. Anonymous-by-default is how we keep the signal useful, and how you stay in control of when your identity gets shared.

If any of this is interesting, read how it works or start your wall - it is free for candidates, and it stays free. Either way, the post-mortem is still worth writing.