DEV Community: Vinuja Khatode

I Passed the CNPA Exam - Here’s Everything You Need to Know

Vinuja Khatode — Wed, 18 Jun 2025 22:29:34 +0000

I recently became a Certified Cloud Native Platform Engineering Associate (CNPA), a new certification launched by The Linux Foundation that focuses entirely on platform engineering in modern, cloud native environments.

If you're curious about the exam or considering taking it, here’s a quick breakdown of what CNPA is, what’s included, how I approached it, and how you can prepare with confidence.

🧠 What is CNPA?

The CNPA (Certified Cloud Native Platform Engineering Associate) is a certification designed for engineers working in platform, DevOps, and cloud-native roles. It focuses on the full lifecycle of modern platform engineering, from building internal developer platforms (IDPs), managing declarative infrastructure, and enabling GitOps, to securing CI/CD pipelines and measuring team productivity.

It’s not just about Kubernetes internals or CI/CD tools. It’s about how you build scalable, secure, and developer-friendly platforms.

🧩 What’s Included in CNPA?

The exam covers a wide range of topics across multiple core areas. More information can be found here - Official Page

Platform Engineering Fundamentals - Declarative infra, GitOps, CI/CD, platform architecture, DevOps practices, and application environments.
Observability, Security, and Governance - Metrics, traces, logs, secure comms, policy engines, and security in CI/CD.
Continuous Delivery - Incident response, GitOps flows, CI/CD integration with platform teams.
Platform APIs & Infra Provisioning - CRDs, reconciliation loops, Kubernetes-based infra management, operator patterns.
Developer Experience & IDPs - Developer portals, API-driven service catalogs, and AI/ML in platform workflows.
Platform Metrics & Measurement - DORA metrics, platform productivity, and measuring platform outcomes.

The topics go beyond tools, they’re framed around how and why platform teams do what they do.

🧪 My Experience Taking the Exam

What stood out to me was how practical and mindset-driven the exam felt.

It wasn’t focused on memorizing definitions or commands. It tested how you think, what trade-offs you’d make, how you’d approach a problem, or what design choice fits a given scenario.

If you’ve ever built CI/CD pipelines, worked on infra automation, introduced developer self-service, or implemented observability patterns, this exam will feel familiar. It’s not about knowing one “right” tool, but about understanding the ecosystem and choosing responsibly.

I took the exam in beta, and the experience was similar to that of a non-beta exam.

📚 How to Prep for CNPA

Here’s how I’d recommend preparing:

Anchor yourself in platform engineering foundations:
Think GitOps, Terraform, Kubernetes CRDs, CI/CD flows, and developer experience tooling.
Study from what you’ve built:
If you’ve created environments, rolled out infra as code, or scaled apps using platforms, reflect on those experiences. A lot of the exam comes down to applied judgment.
Dive into tools by problem, not popularity:
Don’t just study tools, understand what problems ArgoCD, Backstage, Crossplane, or OpenTelemetry are solving. That’s what CNPA focuses on.
Check out the Official CNCF Platforms Whitepaper
Also, check out the Official CNCF Platform Maturity Model to understand more about how platforms evolve.

📝 Exam Details (Without Spoilers)

Fully multiple-choice
Remotely proctored, online for 120 minutes
Covers practical, scenario-based questions

You can explore and register here:

👉 https://training.linuxfoundation.org/certification/certified-cloud-native-platform-engineering-associate-cnpa/

💡 Tips & Tricks

Think like a platform team, optimize for scale, repeatability, and developer experience. Watch for key phrasing, “declarative,” “secure by default,” “least effort,” “self-service”, they often point toward the right choices. Don’t overcomplicate, many questions have multiple correct answers, but one that’s most aligned with the platform's goals. Know your ecosystem, even if you haven’t used all the tools, understand what they do and where they fit.

Final Thoughts

CNPA is a much-needed addition to the cloud native certification world. It doesn’t test how well you know a tool, it tests how well you think as a platform engineer.

If you’re building platforms, enabling developer teams, or automating infrastructure, CNPA is a great checkpoint to see how aligned your thinking is with modern platform goals.

Feel free to reach out if you’re preparing or want to explore what platform engineering looks like in practice.

🔗 My Credly badge: Link
🌐 My portfolio: vinuja.tech

A Script for Simpler Kubernetes Cluster Management for Lean Teams

Vinuja Khatode — Sat, 07 Jun 2025 20:05:37 +0000

I recently worked through a common infrastructure challenge - how can a small team or startup effectively manage Kubernetes without getting bogged down in operational complexity? My exploration led to the development of a CLI script designed to streamline essential cluster tasks. This post isn't just about the script itself, but the thought process behind it, the trade-offs considered, and the solutions chosen to make Kubernetes a bit more approachable.

What are we trying to solve? Kubernetes Management Overhead for Lean Teams

Imagine a startup or a lean engineering team. They want the power and scalability of Kubernetes, but they don't have a dedicated DevOps army. They need to:

Automate common Kubernetes operations efficiently via a CLI.
Ensure essential tools like Helm (for package management) and KEDA (for event-driven scaling) are consistently installed and configured.
Quickly spin up new deployments that can scale dynamically based on application needs (e.g., message queue length, CPU/memory pressure).
Have a straightforward way to monitor the health and status of these deployments without deep-diving into kubectl enchantments for every check.
Maintain clear documentation for these processes and tools.

This scenario often leads to a significant amount of repetitive manual work or the need to learn multiple complex tools. The goal here was to explore a lightweight, script-based approach to relieve some of this burden.

The Approach: Keep it Simple, Keep it Bash

For this exploration, Bash was chosen for its ubiquity in DevOps environments and its directness for orchestrating system commands. While tools like Python with Kubernetes client libraries or IaC solutions like Terraform offer richer abstractions, the aim was to create a self-contained CLI tool with minimal external dependencies, aligning with the need for simplicity for a smaller team. The focus was on direct command orchestration and native OS integration, rather than abstracting away the underlying Kubernetes primitives entirely.

The script, k8s-manager.sh, is structured modularly, with distinct functions for each core task. This design promotes maintainability and extensibility. It also includes OS detection to ensure compatibility between Linux and macOS environments.

Key Capabilities of `k8s-manager.sh`

Let's look at how k8s-manager.sh addresses some of the common operational tasks. The script uses colored output for clearer operational feedback to make the output user-friendly for better readability and also because it is fun.

1. `check_kubectl()`: Ensuring the Foundation

Any interaction with Kubernetes starts with kubectl. This function ensures it's available, installing it if necessary. This removes a common initial friction point.

You'd run it like this:
./k8s-manager.sh check-kubectl

And here it is in action on Ubuntu:

2. `context()`: Smooth Cluster Navigation

For teams managing multiple environments (dev, staging, prod), switching contexts can be frequent. This function simplifies that, allowing users to specify a kubeconfig and context name.

How to use it:
./k8s-manager.sh context CONTEXT_NAME [path_to_kubeconfig]

Here are some examples:

Trying a non-existent context:

Switching to a valid context:

Running with no arguments:

3. `install_helm()`: Managing Kubernetes Packages

Helm is indispensable for managing third-party applications on Kubernetes. This function automates the installation process, ensuring a consistent setup.

Command:
./k8s-manager.sh install-helm

In action on Ubuntu:

4. `install_keda()`: Enabling Event-Driven Scaling

Modern applications often benefit from scaling based on event queues, metrics, or other triggers beyond just CPU/memory. KEDA enables this. This function handles KEDA's installation via its Helm chart, a common deployment method.

Run it with:
./k8s-manager.sh install-keda

Successful installation:
When things go wrong (e.g., namespace issues):
If kubectl is missing:

5. `create_deployment()`: Streamlined Application Deployment

This is a core piece of the script. Instead of manually crafting multiple YAML files for a deployment, service, and autoscaler, this function interactively gathers the necessary parameters and generates these resources. It aims to reduce boilerplate and enforce consistency. The inclusion of KEDA ScaledObject generation here directly supports the goal of event-driven applications.

The command:
./k8s-manager.sh create-deployment

A successful run: And the HPA gets created too:
When inputs are incorrect:

6. `install_metrics_server()`: Powering Resource-Based Autoscaling

For standard CPU/memory autoscaling (often used alongside KEDA or as a baseline), the Metrics Server is essential. This automates its setup.

Command:
./k8s-manager.sh install-metrics-server

See it in action:

7. `check_health()`: Quick Deployment Status Checks

Post-deployment, check_health() offers a consolidated view of an application's status. Given a deployment name, it searches across namespaces and aggregates critical information:

Deployment status
Pod status
Service status
Resource utilization (if Metrics Server is active)
KEDA ScaledObject status
HPA status
Recent events
Paths to the generated configuration files

This provides a quick and comprehensive health check, invaluable for troubleshooting or routine monitoring.

Command:
./k8s-manager.sh check-health DEPLOYMENT_NAME

An example output:

Reflections and Trade-offs

Developing this script highlighted a few common infrastructure considerations:

Cross-Platform Compatibility: Ensuring script portability between Linux and macOS required careful consideration of shell command variations and installation paths.
Input Validation: Implementing comprehensive validation for create_deployment inputs was critical to prevent malformed resource definitions. This involved handling various Kubernetes naming conventions and resource unit formats.
YAML Management: While the script generates YAML, it doesn't manage state in the way Terraform does. For managing many deployments, a proper stateful tool is generally preferred. This script is more for bootstrapping and ad-hoc management.
Simplicity vs. Abstraction: While Bash offers simplicity, it lacks the robust error handling and testing frameworks of higher-level languages. For more complex scenarios, a Python-based tool or Terraform/Pulumi might be a better trade-off, despite their steeper learning curves for some ops tasks.
Idempotency: Care was taken to make functions like installers check for existing installations. True idempotency in shell scripting can be tricky and is a key reason why declarative IaC tools are popular.

The process reinforced that even for powerful platforms like Kubernetes, simple scripting can still provide significant value in automating repetitive tasks and reducing the cognitive load for common operations, especially for teams that prioritize straightforward, imperative tooling for certain tasks.

Full documentation for the script, outlining its usage in more detail, can be found here.

Interested in the code? The full script is available in my repository: k8s-manager.sh

Future Considerations

If this were to evolve into a more widely used tool, I'd focus on:

Enhanced Input Validation & Error Handling: Making it more resilient to unexpected inputs or cluster states.
RBAC Hardening: Ensuring the script operates with the least privilege necessary.
Testing Framework: Implementing a more formal testing approach.
Configuration Templating: Moving beyond simple cat <<EOF for YAML generation.

Wrapping Up

This exploration into building k8s-manager.sh was a practical exercise in addressing common Kubernetes operational hurdles with a relatively lightweight solution.

If you've reached this point, I'd love to hear your thoughts or if you've tackled similar challenges with different approaches.

Resource References (from original report, for further reading on technologies used):

Scaling Kubernetes Applications: HPA, VPA, KEDA, and Beyond

Vinuja Khatode — Sat, 19 Apr 2025 20:46:39 +0000

Honestly, it's less about choosing one tool over another and more about understanding how each tool links with the next and the existing tooling. As you embark on the Kubernetes scaling journey, remember that this ecosystem is as dynamic as it is complex.🧩

Why Kubernetes AutoScaling is Important?

Imagine yourself organizing a weekend street festival. You start small, a couple of food stalls, local stores, a trickle of visitors. Then word spreads on social media and, overnight, you're dealing with crowds the size of a small concert. Your challenge isn't just more chairs or another coffee shop, it's how you flex your setup on the fly without breaking customer experience 🎠. In Kubernetes, scaling features play the role of your festival crew. The trick is to combine different helpers, Horizontal Pod Autoscaler, Vertical Pod Autoscaler, KEDA, and Node Autoscaling, so they cover each other's blind spots and keep the music playing.

Horizontal Pod Autoscaler (HPA):

The Horizontal Pod Autoscaler monitors metrics such as CPU utilization or custom application metrics, and based on these indicators, it scales out or in by increasing or decreasing the number of pod replicas.

So, how does HPA work in practice?

Imagine you run a small coffee shop. During normal hours, you have 2 baristas handling all the orders. But during peak hours, like in the morning rush, there are too many customers, and the line gets long. What do you do? You bring in more baristas to handle the load and serve coffee faster. When the rush dies down, and it gets quiet again, you send the extra baristas home to save on costs.

Similarly, HPA continuously assesses the workload and, when it senses higher demand, spins up additional pod instances to ensure smooth operations. Conversely, when the load subsides, it scales down to conserve resources.

🧭 Note: This shows how HPA is more flexible than many realize. It isn’t just about CPU, it’s a plug-and-play scaling engine once you hook it to custom or external metrics. Also, lesson learned - always specify CPU & memory requests when configuring resources, if you want reliable reactions.

Vertical Pod Autoscaler (VPA):

While HPA focuses on the number of pods, Vertical Pod Autoscaler modifies the resource requests and limits of individual pods, ensuring that each application instance can handle the workload assigned to it without being over- or under-provisioned.

So what makes VPA essential?

You're still running that coffee shop. But instead of hiring more baristas during peak hours, you try a different approach - Instead of hiring more baristas, sometimes you give them better tools, like faster espresso machines or sharper milk frothers. Train them to be more efficient, so that they can serve more customers per minute. When it’s slow, you let them use simpler tools and take it easy(cost optimization).

While HPA expands your team, VPA tweaks each member's workload capacity. For Kubernetes, this means tuning the pod's CPU and memory allocations according to its needs, preventing wasteful allocation while avoiding resource starvation. While HPA expands your team, VPA tweaks each member's workload capacity. It's like having a personal trainer adjust each performer's stamina and strength so they deliver peak performance—no more, no less.

🧭 Note: The VPA doesn’t update running pods—it replaces them, which is critical to understand if you're running stateful or long-lived jobs.

KEDA: The Event‑Driven

Enter KEDA - the Kubernetes Event-driven Autoscaler, which adds an entirely new dimension to scaling. Imagine a city with pop-up events, a flash mob or a surprise concert that brings an unexpected gathering of people to the coffee shop. KEDA responds to external events or queued messages by scaling your Kubernetes workloads in real-time, independent of traditional resource metrics.

So, how does KEDA work?

KEDA monitors external event sources like message queues, databases, or custom event providers, and triggers scaling based on defined metrics. It integrates seamlessly with HPA, often acting as a complementary mechanism that anticipates sudden surges in demand. It triggers scaling actions even when the HPA detects stable conditions.

KEDA's strength lies in its ability to decouple scaling decisions from the traditional CPU& memory metrics, which makes it perfect for applications that react to irregular but critical events, like an online flash sale or a sudden spike in API calls. Just define a ScaledObject, point it at your queue, and let KEDA do its magic.

🧭 Note: KEDA doesn’t just scale deployments directly; it also feeds metrics to HPA, acting as a bridge between external event systems and Kubernetes-native autoscaling.

Cluster Autoscaler: Scaling the Foundation

All the pod-level magic in the world won’t matter if your cluster nodes themselves are out of breath. Enter the Cluster Autoscaler, Kubernetes' answer to auto-expanding your actual compute fleet.
Node Pools and Labels: Define pools for different workloads (e.g., gpu-node-pool, spot-instance-pool) and let the autoscaler respect node affinities and taints.

Scale Out: When pending pods can’t fit on existing nodes, the autoscaler requests new nodes from your cloud provider or on-prem scheduler.

Scale In: Idle nodes (with no scheduled or low-priority pods) are cordoned and drained, then removed to save costs.

🧭 Note: Tune the scale down delay to avoid premature node deletions during fleeting load dips. A too-aggressive scale-down often leads to rapid spin-up/down cycles, which can hurt performance and billable minutes.

Beyond the Basics: A Holistic Ecosystem Perspective, When to Mix, Match, or Mistrust

Now, while HPA, VPA, and KEDA are powerful individually, the real magic happens when they're orchestrated together. Kubernetes administrators are the conductors who must balance these elements to ensure that applications perform reliably under any condition.

👉 HPA + VPA = Powerful Pair
Combining horizontal breadth with vertical depth usually covers 80% of use cases. I start here for most web‑tier and API services.

👉 KEDA for the Complex Cases
When the traffic patterns are driven by events, like external triggers, KEDA bridges the gap. Just don't expect it to replace HPA, think of it as a safety net.

👉 Cluster Autoscaler
Pods are only as useful as the nodes beneath them. Without node scaling, you risk choking on unfillable pending pods or wasting dollars on oversized clusters.

👉 Interactions in Real-World Scenarios
Imagine an e-commerce platform during Black Friday. HPA can scale the number of pods in response to rising traffic, VPA adjusts each pod's resource allocations based on the varying load from backend processes, and KEDA kicks in to manage sporadic events such as flash sales notifications or rapid order processing bursts. Together, they ensure that the entire system remains robust, responsive, and cost-effective.💸

👉 Observability Is Non‑Negotiable
No matter how many autoscalers you deploy, without clear dashboards and alerts, you're sprinting blind. Tools like Prometheus and Grafana provide the eyes and ears for this orchestration. They allow operators to visualize metrics in real-time, set alerts, and even predict when scaling might become necessary. My favorite trick: a combined alert that fires only when HPA, VPA, and KEDA decisions all point toward trouble.

Glancing Ahead: Smarter, Predictive, Multi‑Cloud

🔮 I won't pretend to have a crystal ball, but I'm excited about:

Predictive Autoscaling:
ML‑driven insights that forecast busy hours and pre‑warm capacity—think of it as deploying extra food stalls based on last year's festival data.
Multi-Cloud Environments Scaling:
As organizations diversify their infrastructure, autoscaling solutions will need to not only manage load within a single cluster but also across geographically dispersed environments.

3 . Intent-Driven Policies:
Imagine declaring, “Optimize for cost under 10% error rate,” and the autoscaler picks the right mix of HPA, VPA, node scaling, and spot instances to meet that goal, now read the first word of this sentence.🌀

Final Thoughts

Scaling Kubernetes isn't about flipping a single switch, it's a well choreographed dance between multiple controllers, each with its quirks and temperament. In my experience, the most resilient systems are those where HPA, VPA, KEDA, and Cluster Autoscaler aren't just enabled, but thoughtfully tuned, and where the team never stops questioning whether the defaults still make sense.

As you refine your own autoscaling symphony, embrace the messiness: the odd spike that breaks patterns, the silent nights when resources sit idle, and those triumphant moments when capacity snaps to attention just in time. After all, true mastery isn't measured by perfect performance, it's proven by how gracefully you recover when everything goes sideways.🕺

⚠️ Implementation walkthrough in the upcoming blogs!🔜

Thanks for reading, I hope you found it interesting and enjoyed it!🎊🥂

📚 Recommended Resources:

DEV Community: Vinuja Khatode

I Passed the CNPA Exam - Here’s Everything You Need to Know

🧠 What is CNPA?

🧩 What’s Included in CNPA?

🧪 My Experience Taking the Exam

📚 How to Prep for CNPA

📝 Exam Details (Without Spoilers)

💡 Tips & Tricks

Final Thoughts

A Script for Simpler Kubernetes Cluster Management for Lean Teams

What are we trying to solve? Kubernetes Management Overhead for Lean Teams

The Approach: Keep it Simple, Keep it Bash

Key Capabilities of k8s-manager.sh

1. check_kubectl(): Ensuring the Foundation

2. context(): Smooth Cluster Navigation

3. install_helm(): Managing Kubernetes Packages

4. install_keda(): Enabling Event-Driven Scaling

5. create_deployment(): Streamlined Application Deployment

6. install_metrics_server(): Powering Resource-Based Autoscaling

7. check_health(): Quick Deployment Status Checks

Reflections and Trade-offs

Future Considerations

Wrapping Up

Scaling Kubernetes Applications: HPA, VPA, KEDA, and Beyond

Why Kubernetes AutoScaling is Important?

Horizontal Pod Autoscaler (HPA):

Vertical Pod Autoscaler (VPA):

KEDA: The Event‑Driven

Cluster Autoscaler: Scaling the Foundation

Beyond the Basics: A Holistic Ecosystem Perspective, When to Mix, Match, or Mistrust

Glancing Ahead: Smarter, Predictive, Multi‑Cloud

Final Thoughts

Key Capabilities of `k8s-manager.sh`

1. `check_kubectl()`: Ensuring the Foundation

2. `context()`: Smooth Cluster Navigation

3. `install_helm()`: Managing Kubernetes Packages

4. `install_keda()`: Enabling Event-Driven Scaling

5. `create_deployment()`: Streamlined Application Deployment

6. `install_metrics_server()`: Powering Resource-Based Autoscaling

7. `check_health()`: Quick Deployment Status Checks