As you may have gathered from the title, I did NOT pass the CKA exam. The title is not some clickbait where I turn things around and explain how I passed the exam by doing X, Y, and Z. Nope, I failed. And failure is important. You learn more from your failures than your successes, as anyone who has tried to build a CI/CD pipeline or write a piece of code can attest. There’s always going to be a lot of red before you see a hint of green. In this post I want to talk about what I did to prepare, what I should have done, and what I plan to do before retaking the exam. Yes, dear reader, I am going to retake the exam and this time I will PASS!
Before I dive into the CKA exam proper, I think it’s important to give some background. I’ve been taking certification exams for a long time, starting with the Windows 2000 Professional exam back in 2002. Without exception, all of the exams I had taken before the CKA were basically paper exams. There were a few sad attempts by Microsoft and Citrix to provide a “real” environment to do tasks in. But they were severely crippled. You knew you weren’t in a real environment, and functionality was highly limited.
The CKA exam is not that. You are not answering multiple choice questions, fill in the blank, drag-and-drop, or any other such nonsense. You are given a full server running Ubuntu that is connected to multiple Kubernetes clusters and they give you tasks to accomplish. You have a single terminal session into the environment and no GUI. Everything is going to be done at the command line level. This is a daunting prospect to a former Windows administrator who is used to answering multiple choice questions about esoteric components in Microsoft applications.
So I tried and failed. But like I said, there’s a lot to learn from failure. Let’s break it down.
It’s not like I didn’t study before the exam. I started studying back in December. Here’s what I did for studying:
- Went through the whole CKA path from Anthony Nocentino on Pluralsight
- Did the exercises on this GitHub repo and this one
- Built two K8s clusters on Ubuntu, one in Azure and one in my home lab
In the process I learned a TON about Kubernetes. While I had been working on K8s in one respect or another during the previous year, my knowledge was specific to accomplishing a single task. The courses and practice gave me the background knowledge I needed to fill in the gaps.
There’s a few things I think are worth pointing out. First, while I have been using command line tools for many years, they have mostly been in the Windows context. Linux has always been secondary in my professional life and as a result I’ve never been as familiar with it. I am still not great with basic tools like
awk. The practical upshot is that taking an exam entirely at a Linux shell is not a comfortable thought – in fact it strikes terror in my heart.
There are things that I just don’t know or am not comfortable with, and if you are a Windows admin, you may be in the same boat. Allow me to give you a brief list of things you should probably get comfortable with.
- Autocomplete – You need to know how to set this up, it will save you tons of typing in real life and the exam. The directions are in the K8s official docs. You don’t have to memorize them, just remember where they are.
- Terminal multiplexing – I used
tmux, but this applies to any similar program. You only get one terminal in the exam. Having a tool like
tmuxis going to save you time and let you reference multiple screens at once.
- Text editor – The default is
vim, which is what I first learned to use when I was introduced to Linux. It’s also the default editor for
kubectlwhen you edit an existing configuration. The default config for
vimdoesn’t work well with YAML, and that’s a problem. You either need to edit the default config for
vimor use a different editor.
- General Linux knowledge – You should really know how to use the most common Linux tools to parse and manipulate output. Things like
grep, and output redirection are all important. If you’ve worked in Linux for years, these are all probably second nature to you. They are not for me.
- Ubuntu – The nodes are all going to be running Ubuntu. You need to know a bit about using Ubuntu if you want to get by. Not deep knowledge, but you should know what
systemctlis, how systemd organizes stuff, using the apt package manager, and the overall layout of the filesystem.
- Docker – Despite the fact that Docker is “deprecated”, the exam nodes will be using Docker for the container runtime. You should know a little about using Docker to check on containers.
- Other software – You should know how to use
etcdctlto work with the logs on the nodes and the
Like I said, the main problem here for me is that Linux is not my daily driver. I am not deeply steeped in using bash, tmux, vim. Sure, I’m familiar enough to get by, but there’s still a cognitive penalty to using these tools that I don’t have with most Windows tools and PowerShell commands.
What I learned
There are three key things I am taking from the exam: muscle memory, Linux fluency, and exam strategy.
The more you use a technology, the more you build up a muscle memory when it comes to commands. I’ve started to develop that muscle memory with
kubectl, but it isn’t enough. Basically, I need to spend more time going through exercises with kubectl and the most common commands memorized. I definitely spent too much time looking up command structure during the exam, and that was wasted time. For instance, I should know what objects you cannot create imperatively with kubectl. Instead, I wasted precious time trying to use autocomplete; looking up the command in help; finding it wasn’t there; and then looking up the YAML for a declarative manifest.
Key takeaway: Spend more time doing exercises until common tasks become ingrained in my memory.
There’s a certain point you reach with tools where you don’t feel constrained by them. It’s like riding a bike. At first you are just trying to balance on two wheels without falling over. Then you get a bike with gears, and now you’re thinking about shifting. Once that becomes second nature, you start considering the road and how to get where you are going. With many Linux tools, I feel like I am still trying not to fall over, while with others I am trying to figure out all the gears. I need to get to the point where the tool disappears, and now I am using it to arrive at the desired destination. The only way I can think of improving is by practicing and perhaps taking a Linux course with exercises that force me to get better with Linux in general, and Ubuntu specifically.
There’s also a case to be made for selecting the right tool for the job. I definitely lost time using
vim during the exam, because the default in
vim is to treat a tab like five spaces and not two. Which means, when you past YAML into
vim, the whitespace in the file is completely wrong. Unfortunately, that’s kind of important in YAML. You can change the
vim config with a
.vimrc file, but the entries are not exactly easy to remember and you can’t look them up during the exam. If you’ve got them memorized, go for it. I plan to use
nano next time, since it doesn’t mess with the spacing. It doesn’t help either, but that’s better than actively making my life harder.
Key takeaway: Become fluent with Linux and your chosen shell to the point they start to disappear.
I sort of alluded to some of my strategy, which is to reduce wasted time during the exam. I need to be more comfortable with the tooling and common resources, so I don’t spend too much time looking up structures or commands. The tasks in the exam are also weighted differently, and that should inform which tasks I should start with. It probably would have made more sense to flip through all the tasks, knock out the easiest ones first, and then comes back to the ones with the highest weight that I feel most confident about. You don’t have to clear every task, in fact you only need a 66% to pass. I bet that if I had focused on a troubleshooting task that was weighted highly over some of the other tasks, I might have passed.
The exam environment has some weird quirks that also mess with me. First, there is a visual indicator showing how much time you have left, but you don’t see the actual value. You know the bar is shrinking, but it doesn’t say you have 10 minutes left. Instead, the proctor tells you every once in a while that you have XX amount of time left. I found that disruptive and annoying. You can still see your own system clock, and you can do the math. I’d rather the proctor didn’t break my train of thought to make me panic more than I already am.
You also cannot use Ctrl+C and Ctrl+V to copy and paste. Why? I dunno. Other browser terminals have figured this out. It adds cognitive dissonance and additional stress to go against your own muscle memory. Plus, the replacement command sequence for Windows is Ctrl+Insert to copy and Shift+Insert to paste. I was using a laptop without a dedicated Insert key (You have to hold down Fn and hit the Del key), adding even more dissonance to my mental process. Mac users, which I am assuming is the bulk of the exam writers, can blissfully use Apple+C and Apple+V without problems. When I retake the exam, I am going to plug a full-size keyboard into my laptop to avoid this issue.
Some tasks require that you do things declaratively, and there are great examples on the official Kubernetes docs site. However, you need to be able to find those examples without too much effort. Next time I am going to make a mental map of how to find things on the docs site easily and avoid wasting time clicking around. You also have access to the GitHub page for Kubernetes. I didn’t look at it closely, and I plan to investigate it for useful resources before I try the exam again.
Key takeaway: Review all tasks before starting, use a better setup, and review the online resources in-depth.
Failing sucks. There’s really no other way to put it. It’s hard to pick yourself up and get back on the bike. I feel I wasted a bunch of effort just to come up short. But that’s the wrong approach, and I know that in my mind, if not in my heart. After a weekend of reflection, I am ready to learn from my mistakes, work hard to improve, and pass this exam.
I hope this has been helpful to you as well. If you have questions, hit me up on Twitter or leave a comment. Thanks for reading!