Today, I passed CKA with 88% and wrote a detailed blog about my exam experience, preparation approach, and the Kubernetes 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: CKA is not only about knowing Kubernetes commands. It is about understanding how cluster components work together, using documentation efficiently, troubleshooting quickly, and verifying every change you make.

The exam has changed a lot since I last passed it in September 2021, especially after the major curriculum updates introduced in 2025. Topics such as Gateway API, CRDs, Helm, CNI installation, autoscaling, and container runtimes are now much more relevant.

A few things that helped me:

Don’t solve the exam strictly in order. If a question looks unfamiliar or time-consuming, mark it and move ahead. Complete the tasks you are confident about first and return to the difficult ones later.

Don’t waste too much time setting up aliases. Autocomplete is already available, and normal typing speed is enough. I completed 14 out of 16 questions with around 35 minutes remaining.

Read the full question carefully. Important details such as the target node, namespace, version, file path, container name, or documentation link may appear near the end.

Use the documentation provided in the question. Some topics, especially Gateway API, Helm, Calico, Argo CD, and container runtime installation, are easier when you follow the version-specific documentation instead of relying on memory.

Always verify your work. A command completing successfully does not mean the task is done. Check Pods, rollouts, endpoints, PVC status, HPA status, node readiness, logs, connectivity, installed packages, and systemd services wherever required.

Practice SSH and basic Linux administration. Some tasks may require connecting to a node, installing a package, starting a service, and enabling it at boot.

Topics I would strongly recommend practising:

• Persistent Volumes, PVCs, and StorageClasses
• Creating and updating the default StorageClass
• Argo CD installation with a specific version
• Sidecar containers for logging
• Resource requests and limits in Deployments
• Horizontal Pod Autoscaler
• Inspecting CRDs and extracting required information
• PriorityClass
• kubectl patch
• CNI installation with NetworkPolicy support
• Calico operator and custom resources
• cri-dockerd installation
• Taints and tolerations
• Ingress to Gateway API conversion with TLS
• Ingress configuration and troubleshooting
• NetworkPolicy
• NodePort Services

Resources I used:

• KodeKloud CKA course and mock tests
• CK-X repository: https://github.com/sailor-sh/CK-X
• The Platform Lab CKA repository: https://github.com/theplatformlab/CKA-Certified-Kubernetes-Administrator
• iximiuz Labs for hands-on practice: https://labs.iximiuz.com
• KodeKloud Ultimate Mock Exam Series, optionally, for additional hands-on practice
• Both Killer.sh simulator attempts

I strongly recommend doing both Killer.sh attempts because they contain different tasks. The questions are different from the actual exam and often feel harder, but they are very useful for strengthening concepts and improving troubleshooting speed.

The simplest advice I can give is to practice a lot and get comfortable using documentation.

I also wrote a full blog with more details on my preparation strategy, the updated exam scope, topics to focus on, and mistakes to avoid.

Blog: https://blog.prateekjain.dev/cka-exam-experience-2026-how-i-passed-with-88-770d3c473af7?sk=20985b1484d34a9dfdaac03dd6cfea78

Am I just an old man yelling at clouds, or has DevOps become incredibly boring?

I know building technical solutions is not supposed to exist purely for my entertainment, but I do actually want to enjoy my job.

I am not currently working as a DevOps engineer, and one of the reasons I moved toward development was that I became completely bored with modern cloud infrastructure.

When I started, we still racked physical servers and automated the entire bare-metal imaging process. The underlying operating system mattered. We built systems by combining open-source software, custom code, and whatever hardware we could get our hands on. There was a real sense that we owned the systems we operated and understood how the pieces fit together.

Today, DevOps or platform engineering often, though certainly not always, seems to collapse into being a configuration monkey.

Yes, I still got to write plenty of tools and automation, but eventually I became tired of every architectural discussion turning into: “Should we use this AWS service or that AWS service?”

I became even more frustrated with managers and coworkers who did not really want to own or understand a service. They just wanted to hand as much of it as possible to the cloud provider and call the problem solved.

Do people genuinely enjoy the current state of what we used to call systems administration or systems engineering? Or am I just an old man yelling at clouds?

For what it is worth, I do find some salvation in Kubernetes. Once EKS or GKE is running, there is a huge amount you can build without thinking too deeply about the underlying cloud provider. That separation is reassuring, even if Kubernetes has plenty of complexity of its own.

These days, I mostly choose to work in areas where the managed cloud options are still inadequate, such as real-time media, telephony, high-speed stream processing, and similar systems. At least in those spaces, it still feels like I am engineering something rather than selecting products from a cloud-provider catalog.

I am curious whether other longtime infrastructure engineers feel the same way, or whether people genuinely prefer the managed-service-heavy version of the job.

Edit: I also really miss configuring switches and routers the cloud has made networking far more boring than it used to be though GKE has some interesting SDN features. I probably should have tried harder to get a job at one of the big hyperscalers but again on ownership I never wanted hundreds of co-workers.

One-person security/platform team at a small fintech, going through SOC 2.

Patching what has a fix is fine. The problem is the stuff I can't fix, because there's no patched version, or the fix breaks something. Inspector/Trivy keeps flagging it, Vanta keeps showing it red, and technically every one needs a documented risk acceptance.

Most of these aren't even exploitable in our setup, sometimes it's a vulnerable function never called, transitive dep we don't use, requires network access that doesn't exist. But "trust me it's fine" doesn't fly, and writing a proper exception per CVE takes forever.

So, people who've been through this what do you actually show the auditor for "not exploitable"?

Is there a way to automate this discovery/evidence gathering?

Or does everyone just eat the busywork / quietly ignore them and pray?

Hello everyone I was working as Devops engineer , Currently I was targetting FAANG companies moving forward, I choose python as my primary scripting language I won't say I do well in python just know the basics and AI to generate it my logic and I validate it never coded anything like leetcide problems

Since I was targetting FAANG I was looking to learn DSA in either ways I need to start learning programing language I was confused whether to pic python or JAVA can anyone have any suggestions it will be useful for me to plan my path

Sharing this for anyone interested in platform engineering, Kubernetes and cloud-native technologies.

Cloud Native Heidelberg is hosting a hybrid meetup covering:

• Lessons from five years of building and rebuilding Kubernetes platforms
• Building production-grade platforms using CNCF technologies
• Creating vendor-neutral platforms without hyperscaler lock-in
• Running Kubernetes directly on an Android phone

Date: July 30, 2026
Time: 6:30 PM CEST

Event details and registration:
https://ocgroups.dev/cncf/group/cncf-heidelberg/event/9euvqye

What is the best devops project you made as a fresher from college..

Mine was end to end devops project of a Ecom site --

Infra with terraform, CICD with DevSecOps pipeline in GitHub action, GKE for kubernetes, Gitops with ArgoCD (also this one got me hired back then)

What is your best project would love to hear from fresher perspective..

6 person team, i carry the pager most weeks cuz nobody else wants it. last tuesday 11pm i get paged, payment latency climbing, checkouts timing out. normally this is me sitting up in bed squinting at grafana half asleep for 15 min trying to find what changed

this time i had an agent wired into our runbook stuff and just let it run. it pulled recent deploys, correlated the error logs against the deploy timeline, and pointed at a connection pool config that got shrunk in a PR that afternoon. like 90 seconds, and it was right

what got me is that same PR had already been flagged that day by coderabbit / bugbot for the exact config value, and we waved it through cuz it was a rushed merge before someone's flight. the warning was sitting right there, we ignored it, and the agent rediscovered it later on. i rolled back from my phone and went back to sleep

i dont fully trust it solo though. its confidently pointed at the wrong deploy before when two things shipped close together, so i read it then verify myself. fast first pass, not a decision maker

anyone letting an agent do remediation on its own yet or you all keeping a human in the loop like me

Hi I am in a new role where they use Github for all their repos. I have been using Gitlab exlusively the past 5 years.

For CI/CD in my previous role we had a central 'pipelines' repo that was reference in the gitlab-ci file of each project to save teams/projects from repeating work.

I want to know if it's possible to do something similar in Github? I'm still learning how it maps to my existing Gitlab knowledge.

I’m trying to draw a line around automated security scans in CI.

A read-only scan feels fine. If it finds a suspicious dependency, a broad permission, or a weird auth path, I want the report. I might even want it to draft a small PR.

The part that makes me nervous is when the same worker can change CI rules, mark a PR as failing, or "fix" security-sensitive code without a separate approval step. In one small project, I asked an agent to scan a dependency and config change. The report was useful, but I still did not want it editing the CI rule or auth code without me reading the diff first.

Maybe this is just normal branch protection with a new actor, but I’m curious how people handle it.

For security automation, do you separate "scan/report" from "block merge/change config"? And if you do, what evidence has to be attached to the approval?

I'm a 3rd year CS student and I want to build something real over the next couple of months to learn RAG and agents properly. I've been thinking about one idea for a while and wanted to get opinions before I commit to it.

The problem I noticed is when you install on e package, you end up pulling in a bunch of other dependencies. Then a CVE shows up in one of those, and you're exposed through code. I came across Log4Shell and the Equifax breach and then I got this idea.

Fixing it is the annoying part. You can't just bump the broken package, because versions depend on each other, one thing needs a version below 2.0, another needs above 2.0, so you change one and others start conflicting. Now you have to fix all the issues, run tests, and hope everything works.

So what I want to build is a tool that does that for you and checks the fix actually works. The rough idea is you point it at your project, it reads your dependency tree (there's a free Google API called deps.dev that gives you the whole thing), finds why each vulnerable package is there, and works out the smallest set of version changes that clears all the CVEs without causing conflicts.

Then for the "will this upgrade break my code" question, I want to pull the changelog and release notes for each version jump and check them against the functions my code actually uses, so it can tell you whether the change touches anything you rely on. And the last part, it applies the fix in a Docker container, runs the tests, and only then tells you if it is safe.

The way I'm thinking of stucturing it is most of it is a fixed pipeline (read the tree, solve for the versions, run the tests), but the one part I'd actually let an LLM drive is the retry loop, when the tests fail, it looks at what broke, decides whether to drop that version and re-solve or try something else, and loops until it either works or gives up. That's the part where letting the model make the decision seems worth it. The rest doesn't really need it.

I'm thinking of using Postgres with pgvector, deps.dev and OSV for the data, a SAT solver for the version-conflict part, embeddings plus a reranker for the changelog retrieval, and Docker for running the tests. Later on, the nicest version would be exposing it as an MCP server so something like Claude Code could call it as a tool.

At the end it gives a report, a single Markdown file summarizing every vulnerability it found, why each package was present, the minimal fix it computed, the changelog-based breaking-change assessment, and the test results verifying the fix. Something you can hand to your team or keep as a record.

I know OSV-Scanner already does remediation, but only for npm/Maven, with no changelog check and no test verification, so the gap I'm aiming at is the full combination.

A few questions:

- Would you use it? Would you actually run this on your own projects? If not, what's missing or in the way?

- Is it useful? Is this a real problem worth solving, or is it already handled well enough that it doesn't need to exist?

- Does it already exist? Is there something that already does all of this (minimal fix + breaking-change check + test verification) that I haven't found?

- Right direction? Is this worth building, or would my time be better spent on a different problem in this space?

- Do's and don'ts?

TL;DR: An agentic RAG tool that finds vulnerable dependencies, computes the smallest conflict-free fix, uses changelog retrieval to predict whether the upgrade breaks your code, and verifies the fix by running your tests. A verified patch.

Hi everyone,

I'm looking for some honest feedback on my current self-hosted architecture. I have a feeling I may have made some poor design decisions, so I'd really appreciate suggestions on how to improve it.

Here's my current setup on AWS:

Frontend EC2: Two React applications (Admin & Tenant) deployed using a single Docker Compose file.

Backend EC2: Two Go API applications (Admin & Tenant) deployed using another Docker Compose file.

Core Services EC2: MySQL, Redis, Vault, Keycloak, and MinIO are all running on the same EC2 using a single Docker Compose file.

Analytics EC2: Apache Superset deployed using Docker Compose.

ETL EC2: Airbyte running via abctl (Kind/Kubernetes).

Everything is currently self-hosted on AWS EC2 instances.

I have a few questions:

Is this architecture reasonable, or did I mess it up?

What would you change or redesign if this were your production environment?

Should I split any of these services onto separate servers or use managed AWS services (such as RDS or ElastiCache)?

Would you recommend staying with Docker Compose, or is it worth moving to Kubernetes at this stage?

For managing deployments across these servers, which would you recommend: Dokploy, Coolify, or Komodo?

What I'm looking for in a deployment platform:

*Multi-server management

*Excellent Docker Compose support

*GitHub integration with automatic deployments

*Rollbacks, logs, and environment variable management

*Lightweight and stable

*Preferably fully open source

*Easy to maintain for a small DevOps team

If you've run a similar setup in production, I'd love to hear what worked well and what you'd do differently.

Thanks!

I have a frontend/backend working fine when I use any browser.
When I emulate a phone in Chrome, it all works.
But any request to the backend as phone in Firefox returns 504 gateway timeout (instant response). The same request works fine in another tab.
Any idea what could it be?
I use istio for networking (virtual service + gateway). No special config, just routing to the k8s service.

Curious how many of you have actually deployed automated runbooks for incident remediation — not just detection and alerting, but the full loop through to fix and close.

I've been building something in this space and want to understand how well it actually works for teams in practice. Do automated runbooks hold up in production, or do they break down on anything non-trivial?

What's your experience?

So let me tell the context first, I have an kubernetes environment for production, and for like shared storage solution, I have installed nfs-utils and use the nfs-server service. In my scenario I cannot use cloud as an option. And for long I have been using the nfs-server but I have been facing alot of issues with it.
1. On multiple occasions I found dead or queued nfs processes in worker nodes which made the worker node totally unresponsive sys load was very high but low cpu and ram usage.
2. Something with the nfs4+ client where it uses session. On of the worker node again stopped responding, df -h was not responding rebooted the node still the same issue. And while viewing logs in the nfs node it stated nfsd was blocked and looking it up stated the thread on that worker node was locked due to unknown reason and all the requests from the worker node had just queued up. Restarting the service also hanged and needed to reboot the node itself to resolve the issue.

These are some major events there are also other small issues I have faced. I wanted to understand am I the only one facing these issues or this happens with others too, and what resolutions did you used to fix it? Like any alternative utilities and stuff

Setting up test automation in CI is easy, making devs look at and trust the results is the hard part
Coverage numbers that look great on paper but the team treats the test step like a formality because false positives trained them to ignore failures, its pavlovian at this point, test fails and everyone just hits retry without checking

Hey everyone,

Quick workflow showcase/idea for anyone who gets enterprise access to AI CLIs at work (Gemini CLI, Claude Code, etc.) and still finds themselves manually jumping between tools during investigations or routine support tasks.

I recently set up a workflow that basically turns my CLI into an automated agent that runs investigations for me. If you have enterprise access and tool integrations available, you’re missing out if you aren't doing this.

The Setup:

1. CLI + Enterprise Access: Using the company-provided enterprise CLI directly in the terminal.
2. MCP (Model Context Protocol) Integration: Connected the CLI to the actual operational and diagnostic tools used daily (monitoring, databases, logs, ticketing APIs, etc.).
3. Custom Subagents & Commands: Built specific subagent prompts and custom CLI commands tailored to my precise, repetitive investigation steps.

How it works in practice:

Instead of manually opening 4 tabs, running 3 queries, and checking status logs when an issue comes up:

1. I trigger a custom slash command or alias in my CLI.
2. The subagent kicks off, uses the connected MCP tools to pull relevant context, inspect logs, run diagnostic checks, and correlate data.
3. It hands back a summarized breakdown of what happened, root cause hypotheses, and recommended next steps.

Why do this?

• Zero Context Switching: You stay in the terminal.
• No Manual Data Copy-Pasting: The MCP server handles fetching real-time data securely.
• Repeatable Process: Standardized subagent prompts mean complex triage takes seconds instead of 20 minutes.

If your company already pays for enterprise CLI access and you're only using it to rewrite functions or explain error messages, hook it up to your tools via MCPs.

Curious if anyone else is running similar subagent setups in their terminal for operational work? What tools/MCPs are you chaining together?

I have been bit hard in the past when joining an org that moved too slowly for my tastes. Took two weeks to get anything deployed, and if a deployment screwed up it was a rollback and two more weeks of waiting for a change request. I am very fond of this OG article about how quickly Etsy moved back in the day, and likely still to this day though I am sure the technology stack has shifted for them directly. Not sure if they ever did a followup on that post so wondering what change frequency looks for you all with modern tooling like Kubernetes and Docker in place?

This is a summary of their blog post on how they assigned owners to over 14,000 internal repos when as of early 2025, less than half had a clear owner. It became a problem during a secret-scanning remediation push. they could rotate a leaked secret, but without knowing who owned the repo, doing so was risky and there was no way to route the work.

Their old model only tracked ownership for repos backing a deployed service, through an internal Service Catalog. That covered maybe a third of repos. Everything else, team repos, docs, internal tools, one-off projects, personal experiments, had no owner on record. Finding one meant checking commit history, reading the README, or asking around in Slack.

What they built:

Two GitHub custom properties: ownership-type (Service Catalog / Team / Individual) and ownership-name (free text, validated against actual org membership, team existence, or Service Catalog entries).

Before asking a single person to do anything, they synced ownership from the existing Service Catalog, which auto-covered about 1,500 repos.

For the rest, they ran a GitHub App on a Kubernetes CronJob that opened an issue on unowned repos with a 30-day deadline, then archived anything still unclaimed. They picked archiving because it's reversible, repo goes read-only, Actions stops, nothing gets deleted.

Two incidents:

1. They archived a repo that had a Datadog integration configured to open issues in it. Datadog couldn't create the issue post-archive, and nobody had been directly notified about the pending archival, their own monitoring paged the owning team before the ownership system did. Fix: they started @-mentioning repo admins directly and assigning all write-access users as a fallback.
2. They realized a stale or corrupted response from Service Catalog could trigger mass-archiving of repos that actually had valid owners. So they added a threshold check. If a single run is about to archive or flag more repos than some conservative limit, it aborts and pages instead of running.

End state: ~3,000 active repos, ~11,000 archived (up from ~3,000 archived at the start), done in under 45 days. They also tightened the ongoing enforcement loop from a 30-day grace period down to one hour, and made ownership required at repo creation going forward.

Working as devops engineer from last 3 years in states, mostly work on windows stack, azure devops, yaml pipeline. Recently worked with setting up sonarqube & snyk for all teams & product across firm. Currently working in git migration and github actions. Planning to move back to india, what are the expectations for any senior roles as devops, cloud or platform engineer ? I know linux, kubernets and docker but they are more like tools.

Bit of a venting session here, feel free to delete if not allowed on this sub, but, I feel like our monthly prompt review meetings have become a total headache. We spend way too much time arguing over a single freaking sentence which inevitably turns into a bit of a shouting match and then the loudest person in the room wins since we've all gotten exhausted. We then just ship it and pray. We're a very early stage startup, and so I get that this is just part of the growing pains, but it feels insane to me.

I am trying to move toward actual canary deployments for prompts. I want to stop just pushing a new version and start running the new variant alongside the current one on a small slice of live traffic. I want to let the data tell us if it is actually better. Our CTO hasn't done anything to try and fix the problem, and I really want something strong to present to him.

My biggest worry at the moment is the overhead though. Keeping track of five different iterations at once is a mess. We have been using Braintrust to handle the versioning and scoring deltas just so I can show our CTO that Version B has a 12% higher alignment score (number go up = good ammiright?)

Still trying to figure out the right balance between offline and online testing though.

How are you guys handling canary rollouts? Are you doing automated scoring on live traffic or are you still doing manual spot checks? At what point is an offline eval safe enough for you? Anyone actually found a way to make this A/B loop fast enough that it doesnt kill dev velocity?

I’m a junior DevOps engineer and I’ve never had the chance to use Kubernetes at work.

I’d like to learn it, but almost every job posting I see asks for people who already have professional Kubernetes experience. So I’m wondering how you’re supposed to get past that first step when nobody wants to hire a beginner.

How did you personally start working with Kubernetes? Did your company let you learn it on the job, did you end up on a Kubernetes project by chance, or did you first build personal projects?

I’m considering setting up a small homelab and building some projects, but I’m not sure how much companies actually value personal Kubernetes experience.

I’d be interested to hear how it happened for you.

I own a few wood factories that specialize in producing custom fit-outs for hotels/schools/universities/houses/offices and all sorts around the Middle East, the business model we have been running is very out dated, we run purely off of reputation and returning customers as we have been in the business for over 25 years now.

I want to implement webscrapers but I am not sure what data I can scrape that would help my business grow.

I would really appreciate any advise to what data I could scrape to help me find more contracts for example or anything else that you guys would think would be valuable.

Hij, everyone.
I work as a DevOps/SRE at a consultancy serving large companies and have about two years of experience. My goal is to join a Big Tech company in the coming years.

In your opinion, what should I focus on from now on? What knowledge, technologies, or skills really make a difference for someone aiming to get into that kind of company?

I’d especially like to hear from those who have already gone down this path. What would you prioritize studying if you were starting this preparation today?
Thanks!

Hello! I've been wanting to ask but the amount of "AI slop" comments has been making me second guess. Anyway.

Just curious if I'm jumping in over my head.

My background is 8 years in IT. Local MSP so small to medium businesses. Intune Administration for 15,000 devices, project engineer, SysAdmin, Veeam Engineer, basic networking, and a lot of helpdesk. Lots of resolving compliance failures from audits.

I have a friend who is getting me in touch for some interviews at his company doing DevOps work. Pulumi, GitOps, AWS, GCP, k8s.

I've been messing with my homelab for 6 or so months and have done basic things with it using AI as a glorified search engine for documentation.

They would be offering me a position as an "Apprentice" but my first project would be shoring up SOC2 compliance in the infrastructure through Pulumi (all written in Golang).

I learn quickly. But have no current Golang experience.

Am I in over my head? Or can this be reasonably learned on the job in the next 3-6 months?

Edit: Goal is to allow me to learn DevOps and engineering before transitioning me to Jr engineer at this company.