Becoming Kubestronaut 🚀

Becoming a Kubestronaut: More Than a Certification Milestone

I recently received confirmation from the Cloud Native Computing Foundation (CNCF) that I am now a Kubestronaut.

Kubestronaut is a recognition for engineers who hold all five active Kubernetes certifications: CKA, CKAD, CKS, KCNA, and KCSA. It is a meaningful milestone for me, but I do not see it as the end of a certification chase.

I see it as a deliberate commitment to becoming a better cloud-native and security-minded engineer.

You can view my credentials here .

Note: If you are interested only in knowing how to become a kubestronaut: Follow this blog post by sugimura’s blog post. It is written blog with all relevant information. My article is a personal memoire explaining why i took this path. It doesn’t highlight strenths of Kubernetes or CNCF but the circumstances for my choices.

Why Kubernetes?

I have worked as both a developer and a DevOps engineer, including work across AWS and Azure. In service-based companies, I saw customers increasingly move toward hybrid approaches rather than committing everything to a single cloud provider.

The reasons differed: cost, existing systems, compliance requirements, feature availability, and occasionally resilience concerns. Cloud platforms have different terminology and managed services, but many operational problems remain familiar across environments: deploying applications reliably, managing configuration and secrets, observing systems, controlling access, and recovering from failure.

That is what drew me to Kubernetes.

Kubernetes does not remove all cloud-specific complexity. Networking, identity, storage, observability, and cost management still require cloud knowledge and practical experience. But it provides a common operating model for deploying and operating workloads across different environments.

I was not looking for a way to avoid learning cloud platforms. I was looking for a vendor-neutral foundation that would help me work across them more effectively.

That is also why the CNCF ecosystem appealed to me. It is not simply a collection of tools; it represents an open-source approach to building and operating modern systems. If I had to describe the direction I want my career to take, it would be toward open-source, vendor-neutral, cloud-native engineering.

Learning Kubernetes from the ground up

My interest in Kubernetes began in 2018, when I attended an official Kubernetes workshop. It left me convinced that containers and orchestration would shape the future of infrastructure.

At that time, however, none of the companies I worked for was running Kubernetes in production. Hybrid cloud was the dominant conversation, while Kubernetes adoption was still uneven across the organisations around me.

During the pandemic, I decided to build the skill deliberately.

Instead of starting only with exam-focused material, I wanted to understand containers from the ground up. I studied Linux Containers and Virtualization: A Kernel Perspective by Shashank Jain and worked through Kubernetes The Hard Way by Kelsey Hightower.

That approach was slower than following a short certification course, but it gave me something more durable: an appreciation for what Kubernetes is abstracting, where its complexity comes from, and why the underlying Linux, networking, and container concepts matter.

This foundation still shapes how I learn. I am interested not only in making something work, but also in understanding what happens when it fails.

The most important Kubernetes decision I made was not using Kubernetes

Later, I joined an early-stage startup where we had to build the technology stack from scratch. I was eager to use Kubernetes. I had been studying it, I believed in the ecosystem, and it seemed like the natural next step.

But it would have been the wrong technical decision.

The company needed something frugal, simple to operate, and quick to ship while it pursued funding. Building and running a Kubernetes platform at that stage would have introduced operational overhead without providing enough immediate value.

So I built a monolith.

It was the right decision for the business and for the product. If the company secured funding and the system needed to scale or evolve, we could revisit the architecture with clearer requirements and resources.

That experience changed how I think about Kubernetes. Learning it did not make me want to deploy it everywhere. It made me more aware of its trade-offs.

Kubernetes is powerful, but it is not a default answer to every engineering problem. Good engineering means choosing the smallest system that responsibly solves the problem in front of you and being ready to evolve it when the context changes.

The certification journey: learning through failure

I initially planned to take only the Certified Kubernetes Administrator exam, or CKA. I booked it during a discount period and prepared seriously.

I failed my first attempt.

It was disappointing, but it was also useful. The failure made a gap very clear: I did not lack only conceptual knowledge. I lacked speed, precision, and operational muscle memory.

Performance-based exams are different from multiple-choice exams. You need to understand the task, work in a command-line environment, navigate documentation efficiently, make correct changes, and verify the result under time pressure. A partial understanding is often not enough.

Preparing for my next attempt forced me to improve skills that I had postponed for years:

• Working efficiently in Vim
• Using tmux effectively
• Becoming faster and more deliberate with command-line tools
• Reading Kubernetes documentation with a clearer sense of where to look
• Practising troubleshooting rather than only reading about it

I passed CKA on my second attempt. More importantly, I came away with a more disciplined way of working.

I then took CKAD to strengthen my Kubernetes knowledge from a developer’s perspective. This certification helped me think more clearly about how applications should be designed, configured, deployed, and debugged on Kubernetes. I passed CKAD on my first attempt.

CKS was different.

My first CKS attempt was a disaster. It was the most demanding of the Kubernetes certifications for me because security work requires both breadth and repetition. You need to recognise what is wrong, know which control applies, make the change quickly, and validate it without losing time.

I had to practise much more than I expected.

When I passed CKS, it felt especially meaningful because it represented persistence rather than a smooth path. It also clarified the area I want to go deeper into: Kubernetes security and DevSecOps.

I later completed KCNA and KCSA to complete the Kubestronaut requirements. Although they are multiple-choice examinations and aimed at foundational knowledge, they helped me review the broader cloud-native and Kubernetes security landscape.

What each certification strengthened

Certification	What it strengthened for me
CKA	Cluster administration, troubleshooting, operational speed, and command-line confidence
CKAD	Application design and deployment from a developer’s perspective
CKS	Kubernetes security controls, secure configuration, runtime awareness, and the need for repeatable practice
KCNA	Cloud-native concepts, CNCF ecosystem knowledge, and foundational terminology
KCSA	A broader view of Kubernetes security, organisational responsibility, and security practices around the platform

If I had to recommend an order based on my own experience, I would suggest starting with CKA for engineers who want practical Kubernetes administration skills, then CKAD or CKS depending on whether their next priority is application delivery or security.

But the right order depends on your role. A developer may benefit from CKAD earlier. Someone already working in security may want to move toward CKS after building a solid Kubernetes foundation.

Why security is now central to my direction

The rapid growth of AI has made me think more seriously about long-term employability.

AI can accelerate the creation of code, infrastructure configuration, documentation, and prototypes. That does not make engineering judgment irrelevant. In many ways, it makes it more important.

As software can be produced faster, the need for secure defaults, controlled access, policy enforcement, supply-chain security, reliable delivery pipelines, and sound production operations becomes even greater.

In previous DevOps roles, I often worked at the point where development, operations, QA, and security teams met. My responsibility included enabling teams through CI/CD pipelines and access controls, while specialised security testing was often handled separately.

That made me interested in DevSecOps—not as a buzzword, but as a practical need. Security cannot be something added at the end of delivery. It has to be built into how software is developed, deployed, and operated.

This is why CKS became more than another certification for me. It helped me identify a direction: cloud-native security, policy as code, secure software delivery, and practical controls that engineering teams can actually use.

Learning beyond the exams

The five Kubernetes certifications were an important part of this journey, but they were not my only engagement with the CNCF and Linux Foundation learning ecosystem.

I have also completed courses in areas that support the broader direction I want to take:

• Mastering Kubernetes Security with Kyverno
• Developing Secure Software
• Authentication and Authorization for Web/API
• Getting Started with OpenTelemetry
• Introduction to DevSecOps for Managers
• Introduction to Backstage: Developer Portals Made Easy
• Introduction to AI/ML Toolkits with Kubeflow
• Ethical Principles for Conversational AI

These courses reflect the kind of engineer I want to become: someone who can work across platform engineering, application delivery, observability, developer experience, and security—not as disconnected topics, but as parts of one reliable software-delivery system.

I am particularly interested in learning more about policy as code and Kubernetes security controls through hands-on work with tools such as Kyverno.

What certifications are, and are not

I do not believe certifications are more important than real production experience.

A certificate cannot prove that someone has handled a difficult outage, designed the right architecture under business constraints, earned the trust of a team, or operated a system successfully over time.

But I do respect certifications that are scenario-based and performance-based.

Exams such as RHCE, CKA, and CKS require more than memorisation. They require practice, troubleshooting, time management, and the ability to make correct decisions in a working environment. They provide a structured way to learn, reveal gaps quickly, and validate a baseline of practical capability.

For me, the certifications were not shortcuts. They were a framework for disciplined and structured learning.

What comes next

Becoming a Kubestronaut is a milestone, but it is not the destination.

My next goal is to turn this learning into visible, practical work:

• Build and document Kubernetes security proof-of-concepts.
• Explore policy as code with Kyverno.
• Write practical notes on Kubernetes troubleshooting, secure defaults, and DevSecOps.
• Contribute where I can to open-source projects and documentation.
• Connect with the wider cloud-native community, including at future KubeCon events.
• Continue building the production experience that gives these certifications their real value.

I am grateful for the recognition, the learning journey, and even the exam failures that forced me to improve.

Becoming a Kubestronaut is not the end of a certification chase. It is a deliberate commitment to becoming a better cloud-native and security-minded engineer.

Resources that were useful

• kodekloud
• iximiuz, the best investment i ever made
• killerkoda, free labs
• killershell, complementry exam simulators, way more difficult than actuall exam.
• CKA specific resources that helped me
• Falco from Saiyam Pathak
• KCSA mock tests