https://preview.redd.it/qzotj3kgx9kh1.png?width=1246&format=png&auto=webp&s=d399d023247591e1f99eebdd0128cf1b6bfb0151

Today, I passed CKS with 75% (not a good score) and wrote a detailed blog about my exam experience, preparation approach, the resources I used, and the Kubernetes security topics that helped me the most.

DMs are open if you are preparing for the exam. I can help with whatever is still fresh in my memory.

My biggest takeaway: CKS is noticeably harder than CKAD and CKA. It is not only about knowing Kubernetes commands. You need to understand why a configuration is insecure, how to fix it, and how to verify that your change actually worked.

The biggest mistake I made was spending around 10–15 minutes too long on one question because I felt I was close to solving it. That created unnecessary pressure towards the end and probably led to a couple of avoidable mistakes.

So my strongest advice is: if you are stuck and don’t see a clear path after a few minutes, mark the question and move on.

A few things that helped me:

Don’t memorise solutions. Understand the security reasoning behind them. If a NetworkPolicy, API server flag, securityContext, audit policy, or admission control changes slightly, memorised YAML will not help much.

Always verify your work. Security changes can easily break workloads or cluster components. Check Pods, control-plane components, logs, services, NetworkPolicy connectivity, admission behaviour, audit logs, node readiness, and systemd services wherever required.

Be comfortable with Linux as well as Kubernetes. CKS can require you to work with configuration files, systemd services, container runtimes, permissions, certificates, and node-level settings.

Use documentation whenever required instead of trying to remember every flag or custom resource.

Topics I would strongly recommend practicing:

• Kubelet and etcd hardening
• kube-apiserver authentication and authorization
• Admission controls and ImagePolicyWebhook
• Secure Dockerfiles and non-root containers
• Container immutability and securityContext
• Audit policies and API server logging
• NetworkPolicy
• HTTPS Ingress and TLS
• ServiceAccount token security
• Worker node administration and upgrades
• SBOM and software supply-chain security
• Restricted Pod Security Standard
• Docker/container runtime hardening
• Istio STRICT mTLS
• Cilium network security
• CIS benchmarks and kube-bench remediation

Resources I used:

• KodeKloud CKS course
• KodeKloud Ultimate Mock Exam Series
• iximiuz Labs
• KillerKoda
• Killer[.]sh  CKS simulator
• ChatGPT/Claude for topics that needed a simpler explanation or extra practice scenarios

Between the KodeKloud course mocks and Ultimate Mock Exam Series, I had around six mock exams. I found them very useful and reasonably close to the level of difficulty you should prepare for.

Killer

[.]sh felt a little off-track compared with the actual exam in some areas, but I would still recommend doing it. It is useful for practicing under time pressure, discovering knowledge gaps, and improving troubleshooting skills.

I also used ChatGPT and Claude quite a lot during preparation. CKS has many small security topics, and sometimes a course or lab explanation may not immediately click. In those cases, asking AI to explain the concept differently, compare configurations, or generate a small practice scenario was very useful.

The simplest advice I can give is: practice a lot, understand the security reasoning behind what you are doing, verify every change, and don’t let one difficult question consume your exam time.

I also wrote a full blog with more details on my preparation strategy, resources, task areas, mistakes, and lessons from the exam.

Blog: https://blog.prateekjain.dev/cks-exam-experience-2026-preparation-strategy-and-lessons-learned-1fad785a430b?sk=52b58a9c6d812444bc1340f15eda7dd6

https://preview.redd.it/xwwdz2ozw9kh1.png?width=1246&format=png&auto=webp&s=f19f1cfadf6e4e48d2f56a0135f3fd5e49011bd1

Today, I passed CKS with 75% (not a good score) and wrote a detailed blog about my exam experience, preparation approach, the resources I used, and the Kubernetes security topics that helped me the most.

DMs are open if you are preparing for the exam. I can help with whatever is still fresh in my memory.

My biggest takeaway: CKS is noticeably harder than CKAD and CKA. It is not only about knowing Kubernetes commands. You need to understand why a configuration is insecure, how to fix it, and how to verify that your change actually worked.

The biggest mistake I made was spending around 10–15 minutes too long on one question because I felt I was close to solving it. That created unnecessary pressure towards the end and probably led to a couple of avoidable mistakes.

So my strongest advice is: if you are stuck and don’t see a clear path after a few minutes, mark the question and move on.

A few things that helped me:

Don’t memorise solutions. Understand the security reasoning behind them. If a NetworkPolicy, API server flag, securityContext, audit policy, or admission control changes slightly, memorised YAML will not help much.

Always verify your work. Security changes can easily break workloads or cluster components. Check Pods, control-plane components, logs, services, NetworkPolicy connectivity, admission behaviour, audit logs, node readiness, and systemd services wherever required.

Be comfortable with Linux as well as Kubernetes. CKS can require you to work with configuration files, systemd services, container runtimes, permissions, certificates, and node-level settings.

Use documentation whenever required instead of trying to remember every flag or custom resource.

Topics I would strongly recommend practicing:

• Kubelet and etcd hardening
• kube-apiserver authentication and authorization
• Admission controls and ImagePolicyWebhook
• Secure Dockerfiles and non-root containers
• Container immutability and securityContext
• Audit policies and API server logging
• NetworkPolicy
• HTTPS Ingress and TLS
• ServiceAccount token security
• Worker node administration and upgrades
• SBOM and software supply-chain security
• Restricted Pod Security Standard
• Docker/container runtime hardening
• Istio STRICT mTLS
• Cilium network security
• CIS benchmarks and kube-bench remediation

Resources I used:

• KodeKloud CKS course
• KodeKloud Ultimate Mock Exam Series
• iximiuz Labs
• KillerKoda
• Killer.sh CKS simulator
• ChatGPT/Claude for topics that needed a simpler explanation or extra practice scenarios

Between the KodeKloud course mocks and Ultimate Mock Exam Series, I had around six mock exams. I found them very useful and reasonably close to the level of difficulty you should prepare for.

Killer.sh felt a little off-track compared with the actual exam in some areas, but I would still recommend doing it. It is useful for practicing under time pressure, discovering knowledge gaps, and improving troubleshooting skills.

I also used ChatGPT and Claude quite a lot during preparation. CKS has many small security topics, and sometimes a course or lab explanation may not immediately click. In those cases, asking AI to explain the concept differently, compare configurations, or generate a small practice scenario was very useful.

The simplest advice I can give is: practice a lot, understand the security reasoning behind what you are doing, verify every change, and don’t let one difficult question consume your exam time.

I also wrote a full blog with more details on my preparation strategy, resources, task areas, mistakes, and lessons from the exam.

Blog: https://blog.prateekjain.dev/cks-exam-experience-2026-preparation-strategy-and-lessons-learned-1fad785a430b?sk=52b58a9c6d812444bc1340f15eda7dd6

There is a new term going around in AI coding: loop engineering.

At first, it sounds like another buzzword after prompt engineering, context engineering, and harness engineering. But I think there is a real idea behind it.

The old workflow was manual:

Prompt → code → run → fail → paste error → try again.

The human was the loop.

With coding agents like Claude Code, Cursor, Codex, and Windsurf, that loop is slowly moving into the system. Agents can inspect files, make changes, run tests, read failures, fix issues, and continue until the task is done or blocked.

So the skill is shifting from writing better prompts to designing better feedback loops.

A good loop needs a clear goal, the right context, small changes, validation, and a stopping rule.

I wrote more here:
https://blog.prateekjain.dev/loop-engineering-real-ai-coding-skill-or-just-another-buzzword-9bd6d1202f43?sk=312a6db3a07a9bf9ef9bb3bfe593c203

Curious what others think: real shift, or just another AI term?

Software teams spent the last few years asking which AI model writes better code.

But as agents start operating inside CI/CD systems, Kubernetes clusters, Terraform workflows, and production engineering environments, the bigger problem is no longer model capability.

It’s operational reliability.

That’s where Harness Engineering comes in.

Agent = Model + Harness

The model provides reasoning.

The harness provides:

• context
• permissions
• verification
• observability
• rollback boundaries
• approval gates
• sandboxed execution
• policy enforcement

In many ways, DevOps teams have already been building pieces of this for years through CI/CD, RBAC, policy-as-code, ephemeral runners, and platform engineering.

The actor inside the system is what’s changing.

Wrote a deep dive on why harness engineering may become one of the most important DevOps disciplines of the agent era.

Most of us still think of Docker as containers + Compose

But over the last 2 years, Docker added:

• local LLM workflows
• MCP integrations
• AI agents in the CLI
• MicroVM sandboxes
• hardened distroless images
• declarative builds with Bake

This blog breaks down how Docker evolved far beyond container runtime tooling

pnpm 11 feels like the first Node.js package manager update in a while that actually improves supply chain security by default.

Features like:

• minimumReleaseAge
• blockExoticSubdeps
• allowBuilds

directly reduce the risk of malicious package installs in CI/CD pipelines.

I wrote a short deep dive on why I think pnpm is now a better default than npm for production workloads.

Curious what others here are using in production today.

Upgrade your package manager before a supply chain attack makes that decision for you.

pnpm 11 feels like the first Node.js package manager update in a while that actually improves supply chain security by default.

Features like:

• minimumReleaseAge
• blockExoticSubdeps
• allowBuilds

directly reduce the risk of malicious package installs in CI/CD pipelines.

I wrote a short deep dive on why I think pnpm is now a better default than npm for production workloads.

Curious what others here are using in production today.

https://blog.prateekjain.dev/you-should-move-to-pnpm-from-npm-now-6e84b6cc7778?sk=fe3913487a067decbc069234e4e2ad1f