DEV Community: Pravesh Sudha

🌟 The CI Gate Rejected the Terraform Change—but the LLM Still Ran

Pravesh Sudha — Wed, 02 Sep 2026 16:57:13 +0000

How I added a deterministic trace contract to an AI Terraform reviewer so rejected infrastructure changes stop before the model is invoked.

I recently built an AI-powered Terraform review agent that combines Terrascan, GitHub Actions, AWS Lambda and Gemini.

The workflow is straightforward:

A pull request changes Terraform code.
GitHub Actions runs Terrascan.
The scan report is sent to an AWS Lambda function.
Gemini reviews the findings.
The pipeline accepts or rejects the change.

The project worked. A risky change produced REJECT, and GitHub Actions failed the pull request as expected.

But while reviewing the execution path, I noticed an important problem: the correct final verdict did not prove that the control was enforced at the correct boundary.

The pipeline rejected the change—but the LLM had already run.

That distinction matters in DevOps. A policy that says “do not continue” should stop the next action. It should not merely ask the next action to agree that the request should have been stopped.

This article shows how I used AgentInspect to make that path visible and add a deterministic CI contract around it.

Disclosure: I tested AgentInspect independently in the workflow described here. The maintainer reviewed the AgentInspect commands for technical accuracy; the conclusions are my own. AgentInspect did not replace Terrascan, GitHub Actions, AWS controls or the application’s security policy.

The original review architecture

My Terraform review project uses a practical serverless workflow:

Terraform pull request
        ↓
GitHub Actions
        ↓
Terrascan JSON report
        ↓
AWS Lambda
        ↓
Gemini review
        ↓
APPROVE | APPROVE_WITH_CHANGES | REJECT

The Lambda function extracts relevant Terrascan findings and sends a bounded structure to Gemini. The prompt contains explicit decision rules:

Reject when a HIGH or CRITICAL issue exists.
Reject when there are four or more MEDIUM issues.
Reject when the Application Load Balancer has no HTTPS listener.
Approve with changes for one to three MEDIUM issues.
Approve when only LOW or INFO issues remain.

The GitHub Actions workflow then reads the returned verdict and exits with status 1 when the model returns REJECT.

At first, this looked like a security gate. The result was correct and the PR was blocked.

The problem was where the authority lived.

In the original Lambda implementation, the sequence was effectively:

findings = extract_relevant_findings(results)
prompt = build_prompt(findings)

ai_review = call_gemini(prompt)
verdict = extract_verdict(ai_review)

The risk thresholds were described inside the prompt. They were not evaluated as a deterministic control before the provider call.

This creates three different concerns:

An obvious rejection still consumes a model call.
Prompt behavior can change even when the policy has not changed.
A correct final verdict can hide an incorrect execution path.

The third concern is the easiest one to miss in ordinary CI output.

A passing test was not enough

Imagine a fixture containing a HIGH-severity public-access violation. A conventional test might assert:

expect(result.verdict).toBe("REJECT");

That assertion passes whether the pipeline rejects before Gemini or calls Gemini and then accepts its rejection.

Those paths are not equivalent:

Desired
Terrascan → deterministic policy → REJECT → stop

Original
Terrascan → Gemini → parse response → REJECT → stop

The final value is the same. The control boundary is different.

For the blocked test case, I wanted to assert a stronger invariant:

Terrascan and the deterministic policy check must execute, and the LLM path must execute zero times.

That is an execution contract, not an answer-quality evaluation.

Adding a small AgentInspect wrapper

The existing Lambda is written in Python, while AgentInspect is a TypeScript-first toolkit. I did not pretend that it could automatically instrument the Python function.

Instead, I added a small Node.js evidence runner at the CI boundary. It wraps the operations the pipeline owns: reading the scan, evaluating the policy and, only when appropriate, invoking the existing Lambda.

For this test, I used AgentInspect 6.17.4 and pinned the version so the CI behavior would not move underneath the experiment:

npm install agent-inspect@6.17.4

The simplified runner looks like this:

import { inspectRun, step } from "agent-inspect";

const traceDir = ".agent-inspect/terraform-review";

function evaluatePolicy(report) {
  const violations = report.violations ?? [];
  const severities = violations.map((item) =>
    String(item.severity ?? "").toUpperCase()
  );

  const highOrCritical = severities.some(
    (severity) => severity === "HIGH" || severity === "CRITICAL"
  );
  const mediumCount = severities.filter(
    (severity) => severity === "MEDIUM"
  ).length;

  if (highOrCritical || mediumCount >= 4) {
    return { verdict: "REJECT", reason: "risk-threshold" };
  }

  if (mediumCount >= 1) {
    return {
      verdict: "APPROVE_WITH_CHANGES",
      reason: "medium-findings"
    };
  }

  return { verdict: "APPROVE", reason: "low-or-info-only" };
}

const result = await inspectRun(
  "terraform-ai-review",
  async () => {
    const report = await step.tool("terrascan", () =>
      readTerrascanReport("terrascan_report.json")
    );

    const policy = await step.tool("evaluate_policy", () =>
      evaluatePolicy(report)
    );

    if (policy.verdict === "REJECT") {
      return policy;
    }

    const review = await step.llm("gemini-2.5-flash", () =>
      invokeTerraformReviewLambda(report)
    );

    return {
      ...review,
      verdict: policy.verdict
    };
  },
  {
    traceDir,
    silent: process.env.CI === "true",
    metadata: {
      workflow: "terraform-ai-review",
      fixture: "high-severity-public-access"
    }
  }
);

console.log(result);

This example deliberately keeps the policy small. The HTTPS rule needs its own structured input or a stable mapping from specific Terrascan findings. I would not implement it by searching arbitrary free text and call that deterministic.

The important change is architectural: code owns the risk threshold and final CI authority; the model can provide explanation and remediation only after the deterministic gate allows that path.

The trace exposed the difference

I ran a controlled fixture representing a HIGH-severity finding and inspected the local trace:

npx agent-inspect list --dir .agent-inspect/terraform-review
npx agent-inspect view <run-id> --dir .agent-inspect/terraform-review

Before the short-circuit, the execution contained an LLM step:

terraform-ai-review
├─ tool:terrascan              success
└─ llm:gemini-2.5-flash       success

After moving policy enforcement ahead of the provider call, the rejected path became:

terraform-ai-review
├─ tool:terrascan              success
└─ tool:evaluate_policy        success

The absence of the LLM step was now visible, but I did not want reviewers to verify it manually on every pull request. The next step was turning it into a deterministic check.

Defining the blocked-path contract

AgentInspect supports deterministic checks over retained local traces. For this case, I used a JSON check configuration:

{
  "checks": {
    "tool": {
      "required": ["terrascan", "evaluate_policy"]
    },
    "llm": {
      "maxCalls": 0
    }
  }
}

Then CI checks the trace produced by the blocked fixture:

npx agent-inspect check .agent-inspect/terraform-review \
  --config blocked-path.check.json \
  --require-completed \
  --json

The broken path fails because the model call count is greater than zero. The fixed path passes because:

The run completed.
terrascan appeared.
evaluate_policy appeared.
No LLM step appeared.

This is the exact behavior I wanted from CI. It does not ask another model whether the trace looks safe. It evaluates a small, reproducible structural contract and returns a deterministic exit code.

Keeping evidence with the failed build

A CI failure without usable evidence usually starts another debugging cycle. To retain a bounded report, I added an artifact step:

- name: Run blocked-path regression
  run: node scripts/run-blocked-policy-case.mjs

- name: Check blocked-path contract
  run: |
    npx agent-inspect check .agent-inspect/terraform-review \
      --config blocked-path.check.json \
      --require-completed \
      --json > trace-contract-result.json

- name: Build safe trace artifacts
  if: always()
  run: |
    npx agent-inspect artifacts .agent-inspect/terraform-review \
      --output-dir ./agent-inspect-artifacts \
      --github-summary "$GITHUB_STEP_SUMMARY"

- name: Upload review evidence
  if: always()
  uses: actions/upload-artifact@v4
  with:
    name: terraform-agent-trace
    path: |
      agent-inspect-artifacts/
      trace-contract-result.json
    retention-days: 14

AgentInspect creates the local report; GitHub Actions owns the upload and retention. For real pipeline data, I would still review the exact derived artifact before sharing it outside the repository. Redaction and safety scans are safeguards, not compliance certification.

What changed in my mental model

My first implementation treated the final verdict as proof that the gate worked. It was only proof that the workflow ended with the expected string.

The stronger DevOps questions are:

Was the declared control actually executed?
Did it execute before the model or side effect?
Did a rejected path stop immediately?
Can CI prove those facts without another probabilistic judgment?

This is where execution traces are useful. They provide evidence about the path rather than only the answer.

There is also a useful separation of responsibilities:

Layer	Responsibility
Terrascan	Detect infrastructure findings
Deterministic policy code	Enforce explicit risk thresholds
Gemini	Explain findings and suggest remediation on allowed paths
AgentInspect	Record and check the execution path
GitHub Actions	Enforce the build result and retain reviewed artifacts

AgentInspect did not make the Terraform deployment secure. It helped me verify whether my own control flow matched the policy I claimed to enforce.

What this check does not replace

A green trace contract is narrow evidence. It does not prove that every Terraform rule is correct or that the deployed infrastructure is safe.

This workflow still needs:

Terrascan or another infrastructure scanner.
IAM least privilege and protected deployment credentials.
Branch protection and human review.
Tests for malformed and incomplete scan reports.
Provider timeouts, budgets and rate limits.
Prompt-injection and adversarial testing for the explanatory model path.
Production monitoring and incident controls.

It also does not prove that Gemini’s remediation advice is good. That requires separate evaluation.

The contract proves one specific invariant: when deterministic policy rejects a Terraform change, the model path does not run.

Final takeaway

AI can add useful context to DevOps workflows, but it should not own controls that can be expressed clearly in code.

My Terraform review agent already produced the expected rejection. AgentInspect showed me that the route to that answer was weaker than the answer itself suggested.

Moving the risk threshold ahead of the LLM call gave the workflow a cleaner authority boundary. Adding a trace contract made that boundary reviewable in CI.

The lesson is simple:

Do not test only what your agent returned. Test which actions it was allowed to take before returning it.

Project links

🧐 ECS Express Mode vs Traditional ECS: A Hands-on Comparison with Terraform

Pravesh Sudha — Sun, 23 Aug 2026 19:05:08 +0000

Hola Amigos 👋

Welcome to the world of Cloud and Automation!

AWS launched ECS Express Mode in late 2025, and in today’s blog, we will understand how it compares to traditional AWS ECS.

We will use a basic Flask portfolio website with three versions to illustrate how both approaches handle infrastructure operations with Terraform.

Prerequisites

Before we start, make sure you have the following requirements met on your system:

Terraform: Installed and configured with an AWS IAM account that has AdministratorAccess. This is just for the sake of the blog and is not recommended in a production environment. Always follow the principle of least privilege.
Basic understanding of Python and Docker, along with AWS ECS.

Once the above requirements are met, we are good to go with our project!

What is ECS Express Mode?

On November 21, 2025, AWS introduced ECS Express Mode, allowing developers to launch containerized applications with secure HTTPS endpoints within minutes.

It is similar to traditional ECS, but without a lot of the manual configuration required for things like load balancers, target groups, scaling policies, and more.

By providing your container image and an infrastructure role, you can create a complete ECS Fargate-based deployment.

Express Mode automatically creates resources such as a Virtual Private Cloud (VPC), subnets, security groups, a load balancer with listener rules, HTTPS configuration, auto-scaling policies, metrics, alarms, and health checks.

The best part is that there is no additional charge for using ECS Express Mode itself. You pay for the AWS resources that are provisioned and used by your application.

Another interesting feature is that a single Application Load Balancer can be shared by up to 25 Express Mode services, which can help reduce the cost of running multiple services.

Practical Demonstration

We are going to use a Flask portfolio website with three versions:

v1 — Foundation
v2 — Advanced
v3 — Production

We will deploy the application using both a traditional ECS architecture and ECS Express Mode and see the difference between them.

To get started, clone the repository using the following command:

git clone https://github.com/Pravesh-Sudha/terra-projects.git

Navigate inside the ecs-express directory. Inside it, you will find two directories:

ecs-express/
├── traditional/
└── express/

Let's start with the traditional approach.

Traditional ECS

Navigate inside the traditional directory. Here, you will find a bunch of Terraform configurations for ECS:

main.tf — Specifies AWS as the cloud provider.
values.tf — Gets the default VPC and its subnets, along with a security group with port 5000 open. Our Flask portfolio runs on this port.
ecs.tf — Creates our ECS cluster, required IAM roles and policy attachments, task definition, and ECS service.
get_ip.sh — A shell script that uses AWS CLI commands to retrieve the public IP of the task's network interface and generates the URL with port 5000.

One thing to note here is that with the traditional approach, we have already created quite a few resources, but we still have only a bare-minimum infrastructure rather than a recommended production-grade setup.

For example, we haven't configured things like an Application Load Balancer, HTTPS, production-grade monitoring, alarms, or scaling policies.

A note about architecture

For this project, my Docker image is built for the AMD64 architecture.

If you want to try another Docker image, make sure it is also built for AMD64. If you are building the image on an ARM64 machine, such as an Apple Silicon Mac, you can build it for AMD64 by specifying the target platform in your Docker build command.

If you want to use an ARM64 image instead, you will need to make sure the ECS task configuration supports that architecture. Getting ARM64 working with ECS Express Mode can be more complicated depending on the configuration, so for this demonstration, I am keeping things simple and using AMD64.

Deploying Traditional ECS

To apply the configuration, navigate inside the directory and run:

cd ecs-express/traditional

terraform init
terraform plan
terraform apply

After a minute or two, the infrastructure should be up and running.

To get the URL of the website, use the following commands:

chmod u+x get_ip.sh
./get_ip.sh

Open the URL in your browser, and you should see the application up and running.

Updating the Application Version

Now imagine you want to update your application to a newer version.

We can do this simply by updating the Docker image version inside the ECS task definition.

For this demonstration, I initially deployed v2 and then switched the application back to v1. This was actually a small mistake while capturing the screenshots, but it also demonstrates something useful: the infrastructure doesn't really care whether you're moving forward or backward between image tags — Terraform will deploy the version you specify.

For example:

image = "pravesh2003/flask-portfolio:v1"

Now apply the configuration:

terraform apply --auto-approve

Once the deployment is completed, use the shell script again:

./get_ip.sh

Head over to the URL, and you should see the updated version of your application.

ECS Express Mode

With the traditional approach, we created a bare-minimum infrastructure for hosting our application.

And even after writing quite a bit of Terraform code, we are still missing production-oriented features such as:

Metrics
Alarms
Scaling policies
Application Load Balancer
Secure HTTPS connection
Target groups
Health checks

But this is where ECS Express Mode comes in.

To see it in action, head over to the express directory.

You will find the following Terraform configurations:

provider.tf — Specifies that we are using AWS as our cloud provider.
express.tf — Contains the aws_ecs_express_gateway_service resource. This is where most of the Express Mode configuration happens.
vars.tf — Contains variables such as the default VPC and its subnets.
iam.tf — Contains the execution role and infrastructure role required by Express Mode.
outputs.tf — Provides useful outputs, including the application URL.

Deploying ECS Express Mode

To apply the configuration, run:

cd ecs-express/express

terraform init
terraform plan
terraform apply

This deployment takes a little longer than the traditional deployment. In my case, it took around 8–10 minutes.

Once the deployment is complete, Terraform will provide the URL where the application is live.

Open it in your browser, and you should see the same Flask portfolio application running through ECS Express Mode.

Updating the Application Version

Just like with traditional ECS, we can update the application without rebuilding the infrastructure.

Go to express.tf and change the Docker image version.

For example:

image = "pravesh2003/flask-portfolio:v3"

Then simply run:

terraform apply

ECS Express Mode will handle the deployment of the new version.

This gives us a simple progression:

v1 → v2 → v3

Foundation → Advanced → Production

And because the application itself changes between these versions, we can actually see the deployment update in the browser.

Traditional ECS vs ECS Express Mode

Now that we have deployed the same application using both approaches, let's compare them.

With traditional ECS, we had to explicitly configure the different pieces required to run our application.

With Express Mode, we only needed to create an aws_ecs_express_gateway_service, provide the required configuration, and let Express Mode take responsibility for much of the underlying infrastructure.

Express Mode provisions and manages supporting components such as the Application Load Balancer, target group, security groups, HTTPS configuration, scaling policies, metrics, alarms, and health checks.

On top of that, we get a much higher level of abstraction over the infrastructure, which makes the architecture significantly simpler.

And this is where the main difference becomes clear:

Traditional ECS gives you more control, while ECS Express Mode gives you more abstraction.

My Personal Verdict

Even though I think ECS Express Mode is better than traditional ECS when it comes to simplicity and ease of deployment, especially for beginners, I would still recommend learning and using traditional ECS first if your goal is to properly understand ECS.

With traditional ECS, you are forced to understand the underlying components and how they work together.

You learn about task definitions, services, networking, security groups, load balancers, target groups, scaling, and all the other pieces that make an ECS deployment work.

Once you understand those fundamentals, Express Mode becomes much easier to appreciate because you know what it is actually abstracting away.

So, for me:

Learning ECS → Traditional ECS 🧠

Quick and simplified deployments → ECS Express Mode 🚀

Cleanup

Once you are done experimenting with the project, make sure to delete the resources to avoid unwanted AWS costs.

First, destroy the Express Mode deployment:

cd ecs-express/express

terraform destroy --auto-approve

Then destroy the traditional ECS deployment:

cd ../traditional/

terraform destroy --auto-approve

Make sure both deployments are destroyed successfully before finishing.

Conclusion

ECS Express Mode is an interesting addition to the ECS ecosystem because it changes how much infrastructure you need to think about when deploying a containerized application.

With traditional ECS, you have much more control, but that also means more configuration and more AWS components to understand.

With Express Mode, AWS takes care of a large portion of that infrastructure for you, allowing you to focus more on your application rather than wiring everything together.

After building the same Flask application with both approaches, my biggest takeaway is that Express Mode isn't really replacing traditional ECS — it is providing another level of abstraction on top of it.

If you are new to ECS, Express Mode can be a great way to get started quickly. But if you want to understand what is happening behind the scenes and build more customized architectures, traditional ECS is still the better place to learn.

And honestly, that was the main reason I built this project — not just to deploy an application, but to understand what changes when AWS starts managing more of the infrastructure for us.

If you found this comparison useful, feel free to connect with me and follow along as I continue exploring Cloud, DevOps, AWS, and Automation.

Connect with me

GitHub: Pravesh Sudha
LinkedIn: Pravesh Sudha
X/Twitter: @PraveshSudha
YouTube: Pravesh Sudha

Thanks for reading!

Adios Amigos, and see you in the next one! 👋

🚀 API Server: Explained like Never Before (Episode 4)

Pravesh Sudha — Thu, 06 Aug 2026 04:30:00 +0000

Hola Amigos 👋

Welcome to Episode 4 of K8s-With-Pravesh.

In the previous episode, we followed the complete journey of the kubectl apply command and saw what really happens inside Kubernetes when we deploy an application. If you haven't checked it out yet, here it is:

Pravesh Sudha for AWS Community Builders

Jul 21

🤔 What Really Happens When You Run kubectl apply? Episode 3

#devplusplus #devops #kubernetes #cloud

4 min read

In that blog, our journey started with the front-door keeper of the Kubernetes cluster: the API Server.

The API Server is the central administrative hub and the only entry point for managing a Kubernetes cluster. It exposes a RESTful HTTP API that processes, validates, and stores requests for Kubernetes objects like Pods, Services, Deployments, ConfigMaps, and much more.

Interesting Fact: The Kubernetes API Server is completely stateless. It doesn't permanently store anything by itself. Instead, it relies on etcd (Kubernetes' distributed key-value database) to store the entire cluster state.

How does the API Server work?

Whenever we execute a command like:

kubectl apply -f deployment.yml

the request travels through the API Server in a highly structured lifecycle:

[ Request ]
      ↓
[ Authentication ]
      ↓
[ Authorization (RBAC) ]
      ↓
[ Mutating Admission ]
      ↓
[ Schema Validation ]
      ↓
[ Validating Admission ]
      ↓
[ etcd Data Store ]
      ↓
[ Watch Events ]
      ↓
[ Controller Manager ]
      ↓
[ Scheduler ]
      ↓
[ Kubelet ]

Everything inside Kubernetes starts with the API Server.

Once a request reaches the API Server, it is first authenticated using client certificates, tokens, or other authentication methods. After that, authorization checks whether the user has permission to perform the requested action using RBAC (Role-Based Access Control).

Next come the Admission Controllers. These can modify the request, inject default values, or reject it before it reaches the cluster.

The object is then checked against the official Kubernetes schema to ensure it follows the correct structure. If everything is valid, the API Server stores the object inside etcd.

But the story doesn't end there.

Once the object is stored, every Kubernetes component watching the API Server immediately notices the change. The Controller Manager starts reconciliation, the Scheduler decides where the Pod should run, and finally the Kubelet on the selected node creates the container.

Beginner Mistake: Many beginners think kubectl directly talks to a Deployment and creates Pods. In reality, kubectl only sends a request to the API Server. Everything else happens because multiple Kubernetes components continuously reconcile the desired state.

If we simplify what happens after running kubectl apply, the flow looks like this:

kubectl reads the YAML.
Converts it into JSON.
Creates an HTTPS REST request.
Sends it to the API Server.
API Server authenticates the request.
API Server authorizes the request.
Admission Controllers validate and mutate the object.
The object is stored inside etcd.
Controllers notice the change.
The Scheduler assigns a node.
The Kubelet creates the container.

Key functions of the API Server

Single Source of Truth

The API Server is the only Kubernetes component that communicates directly with etcd. No Scheduler, Controller Manager, or Kubelet ever talks to etcd directly.

The Watch Mechanism

Instead of continuously polling etcd, Kubernetes components use the API Server's Watch API. This allows them to receive real-time updates whenever the cluster state changes.

Cluster Synchronization

The API Server acts as the coordinator between the control plane and worker nodes. Every component observes changes through the API Server and works toward making the actual state match the desired state.

Let's see it in action

To see the API Server in real life, start a Minikube cluster and run:

kubectl proxy

Now open:

http://localhost:8001

You will see a list of Kubernetes API endpoints.

This is your Kubernetes API Server exposing RESTful APIs.

If you visit:

http://localhost:8001/api

you'll see the core Kubernetes API information.

Now let's do something even more interesting.

Remember the Deployment we created in Episode 3? Apply that Deployment again using kubectl apply.

Once the Pods are running, open:

http://localhost:8001/api/v1/namespaces/default/pods

You'll see a large JSON document describing every Pod in the default namespace.

This is the same information that kubectl get pods displays in a much cleaner format. kubectl is simply calling the Kubernetes API Server and presenting the response in a human-readable way.

You can even compare the Pod names and IDs with the output of kubectl get pods and see that they're exactly the same.

Why do different Kubernetes objects have different API versions?

When I first started learning Kubernetes, I always wondered why different resources had different API versions.

For example:

Pods use v1
Deployments use apps/v1
Jobs use batch/v1

The reason is simple.

Pods belong to the Core API Group, so they use v1.

Deployments belong to the Apps API Group, so they use apps/v1.

Similarly, Jobs belong to the Batch API Group, so they use batch/v1.

As Kubernetes evolved, related resources were grouped into different API groups, each with its own versioning.

Every communication happening inside a Kubernetes cluster goes through the API Server. Even though etcd stores the cluster data, no component reads or writes directly to it.

For example, when you run:

kubectl get deployments

kubectl sends a request to the API Server.

The API Server reads the Deployment object from etcd and returns the response back to kubectl.

Everything flows through the API Server.

That's the end of our deep dive into the Kubernetes API Server.

I hope this helped you understand how the API Server isn't just the front door of Kubernetes, but also the central communication hub that connects every component inside the cluster.

In the next episode, we'll explore the data hub of Kubernetes—etcd—and understand how Kubernetes stores and manages the entire cluster state.

If you enjoyed this blog, make sure to follow me on LinkedIn, X, YouTube, GitHub, Dev.to, and Medium.

Till then,

Happy Coding 👋

🤔 What Really Happens When You Run kubectl apply? Episode 3

Pravesh Sudha — Tue, 21 Jul 2026 17:38:29 +0000

Follow the complete journey of a Kubernetes Deployment—from your terminal to a running container inside the cluster.

Most Kubernetes tutorials teach us how to create resources:

kubectl apply -f deployment.yaml

A few seconds later, Pods start running.

Simple, right?

But Kubernetes is doing far more work than most people realize.

Hola Amigos! Welcome to the third episode of K8s with Pravesh. Today, we're going to dive into the lifecycle of one of the most commonly used Kubernetes commands: kubectl apply.

Behind this simple command lies a chain of events involving the API Server, ETCD, Controller Manager, Scheduler, Kubelet, and Container Runtime.

Understanding this workflow is one of the biggest steps toward becoming a better Kubernetes engineer. In this article, we'll trace every step that occurs after running kubectl apply and see how Kubernetes transforms a YAML file into a running application.

So, without further ado, let's get started.

How Does the Information Flow?

Before we dive deep, let's first get ourselves familiar with kubectl.

kubectl is the command-line tool that helps us interact with a Kubernetes cluster. Whenever a user runs:

kubectl apply -f deployment.yaml

the YAML file is sent to the API Server, which acts as the front door of Kubernetes.

The API Server authenticates the request, validates the manifest, and processes Kubernetes objects such as Deployments, Services, Pods, ReplicaSets, and many others.

Once the API Server has the YAML, you might wonder:

"Does Kubernetes create the Pods immediately?"

The answer is No.

Instead of creating Pods right away, Kubernetes first stores the desired state of the resources inside ETCD.

ETCD acts as the primary database—and often the "brain"—of the Kubernetes cluster. Just like in GitOps, where Git serves as the single source of truth, ETCD is the single source of truth for the cluster. It stores the complete cluster state, configuration data, and metadata.

Now you might be wondering:

"Okay, the data is stored in ETCD... but who reads it?"

This is where the Controller Manager comes into the picture.

The Controller Manager is one of the core control plane components. It continuously watches the desired state stored in ETCD and compares it with the current state of the cluster. Whenever it detects a difference, it takes action to reconcile them.

This reconciliation loop is also what enables Kubernetes' self-healing capabilities. For example, if a Pod crashes unexpectedly, the Controller Manager notices the mismatch and automatically creates a replacement Pod to restore the desired state.

Inside our manifest, we only created a Deployment. We never explicitly created a ReplicaSet.

Kubernetes takes care of that for us.

The Deployment Controller automatically creates a ReplicaSet, and the ReplicaSet Controller ensures that the desired number of Pods are always running.

Now comes another important question:

"We have the Pods ready, but who decides where they'll run?"

This is the job of the Scheduler.

The Scheduler is responsible for assigning pending Pods to the most suitable node in the cluster.

It does this in two stages:

Filtering – Removes nodes that don't satisfy the Pod's requirements, such as available resources, taints, tolerations, affinity, or node selectors.
Scoring – Evaluates the remaining nodes and selects the best one based on Kubernetes' scheduling algorithms.

Once the Scheduler selects a node, the Kubelet—the primary node agent running on every worker node—takes over.

The Kubelet watches the API Server for Pods assigned to its node. Once it receives the instruction, it communicates with the container runtime (such as containerd) and ensures that the desired state is achieved.

Finally, the container runtime pulls the required container image (if it isn't already available), creates the container, and starts it.

And that's how a simple kubectl apply command works under the hood.

Kubernetes Is Not Magic

When beginners first start learning Kubernetes, it almost feels like magic.

kubectl apply -f deployment.yaml

...and boom! Your application is up and running in no time.

But in reality, Kubernetes is a collection of specialized components working together through a continuous reconciliation process.

Every component has a specific responsibility:

API Server accepts and validates requests.
ETCD stores the cluster state.
Controller Manager reconciles the desired and current state.
Scheduler selects the best node for Pods.
Kubelet manages workloads on each node.
Container Runtime pulls images and runs containers.

Once you understand this flow, troubleshooting Kubernetes becomes much less stressful because you know exactly where to look when something breaks.

Conclusion

And that's the journey of a simple kubectl apply command.

What looks like a single command from our terminal is actually a well-orchestrated sequence of events involving multiple Kubernetes components, each doing one specific job. This separation of responsibilities is what makes Kubernetes powerful, scalable, and resilient.

I hope this article helped you understand not just what Kubernetes does, but how it does it behind the scenes.

This is just the beginning of our Kubernetes Internals journey. In the upcoming articles, we'll dive deeper into individual components like the API Server, ETCD, Scheduler, Kubelet, and many more to understand how they work under the hood.

If you enjoyed this article, consider following me on my socials, where I regularly share content around Kubernetes, AWS, DevOps, and Cloud Engineering.

🌐 Blog: blog.praveshsudha.com
💼 LinkedIn: Pravesh Sudha
🐦 X (Twitter): @praveshstwt
💻 GitHub: Pravesh-Sudha
📺 YouTube: Pravesh Sudha

See you in the next episode of K8s with Pravesh. 🚀

Just uploaded a video on AI Prompting techniques ⬇️: https://dev.to/aws-builders/heres-why-your-prompt-is-wrong-3dlm

Pravesh Sudha — Wed, 08 Jul 2026 15:26:47 +0000

Pravesh Sudha for AWS Community Builders

May 29

Here's why your Prompt is WRONG 😑

#ai #promptengineering #programming #beginners

3 min read

🤔 If Data Survives in Deployments, Why Do We Need StatefulSets? | Episode 2

Pravesh Sudha — Mon, 01 Jun 2026 17:56:01 +0000

Hola Amigos 👋

Welcome to the second episode of K8s with Pravesh. If you're new to the series, check out the first episode where we learned how Deployments and Services work under the hood.

Most people believe that StatefulSets are needed because Deployments lose data. But is that actually true?

In today's blog, we'll answer this question by exploring StatefulSets vs Deployments through a practical hands-on demonstration.

🚀 Getting Started

Head over to my GitHub repository, fork it under your own GitHub account, and clone the code:

git clone https://github.com/<your-username>/K8s_with_Pravesh.git

Navigate to the project directory:

cd K8s_with_Pravesh/part-02-statefulsets/configs

Here you'll find:

Secrets and ConfigMaps
Deployment manifest
StatefulSet manifest

First, apply the Secrets and ConfigMaps. These contain the MySQL password, database name, and MySQL initialization script.

kubectl apply -f secrets-and-config.yml

🧪 Experiment 1: Deployment + PVC

Now let's apply our Deployment manifest.

This file contains:

Persistent Volume Claim (PVC)
Deployment
Service

Apply it using:

kubectl apply -f deployment.yml

Once the pod is running, we'll create a sample record inside MySQL, delete the pod, and verify whether the data survives.

Get the pod name:

kubectl get pods

Connect to MySQL:

kubectl exec -it mysql-XXXXXX-XXXX -- mysql -uroot -p

Enter the password:

Pravesh

(You can change this value in the secrets-and-config.yml file.)

Inside MySQL, run:

USE crud_app;

INSERT INTO users(name,email,password)
VALUES('Pravesh','pravesh@example.com','secret');

Exit MySQL:

exit

Delete the pod:

kubectl delete pod mysql-XXXXXX-XXXX

Wait for Kubernetes to create a replacement pod:

kubectl get pods

Connect to the new pod:

kubectl exec -it mysql-XXXXXX-XXXX -- mysql -uroot -p

Run:

USE crud_app;

SELECT * FROM users;

You'll notice that the data is still there.

Wait... The Data Survived?

At this point, many people expect the data to disappear because we're using a Deployment.

However, the data survived.

So the obvious question becomes:

If data survives in a Deployment, why do we even need StatefulSets?

The answer is simple.

The data survived because we attached a Persistent Volume Claim (PVC) to the MySQL container. The PVC preserved the data, not the Deployment.

In other words:

Pod
 ↓
PVC
 ↓
Persistent Storage

The pod can disappear and be recreated, but the storage remains intact.

🧪 Experiment 2: StatefulSet

Now let's perform the same experiment using a StatefulSet.

Apply the StatefulSet manifest:

kubectl apply -f statefulset.yml

Wait for the pod to start:

kubectl get pods

You'll notice that the pod has a predictable name:

mysql-0

Connect to MySQL:

kubectl exec -it mysql-0 -- mysql -uroot -p

Insert another record:

USE crud_app;

INSERT INTO users(name,email,password)
VALUES('Pravesh','pravesh@example.com','secret');

Exit MySQL:

exit

Delete the pod:

kubectl delete pod mysql-0

Wait for Kubernetes to recreate it:

kubectl get pods

Notice something interesting:

mysql-0

The pod name remains exactly the same.

Connect again:

kubectl exec -it mysql-0 -- mysql -uroot -p

Verify the data:

USE crud_app;

SELECT * FROM users;

The data survived once again.

🤨 So What Is the Real Difference?

Let's inspect the PVCs:

kubectl get pvc

With StatefulSets, each replica gets its own dedicated PVC.

For example:

mysql-data-mysql-0
mysql-data-mysql-1
mysql-data-mysql-2

This creates a stable relationship between a pod and its storage.

StatefulSets manage a group of pods while maintaining a sticky identity for each pod. Unlike Deployments, StatefulSet pods are not interchangeable.

Each pod receives:

A stable hostname
A stable network identity
Persistent storage
Ordered deployment and termination

Even if a pod is rescheduled, it retains its identity.

When Should You Use StatefulSets?

StatefulSets are valuable when your application requires:

Stable, unique network identifiers
Stable, persistent storage
Ordered, graceful deployment and scaling
Ordered rolling updates

Common examples include:

MySQL
PostgreSQL
Kafka
ZooKeeper
Redis Clusters
Elasticsearch

Deployment vs StatefulSet

Feature	Deployment	StatefulSet
Data Persistence	✅ With PVC	✅ With PVC
Stable Pod Name	❌	✅
Stable Network Identity	❌	✅
Dedicated Storage Per Replica	❌	✅
Ordered Startup/Shutdown	❌	✅

Conclusion

A common misconception is that StatefulSets exist because Deployments cannot persist data. As we saw in this blog, that isn't entirely true.

A Deployment can preserve data just fine when paired with a Persistent Volume Claim. The PVC is responsible for data persistence, not the Deployment itself.

The real strength of StatefulSets lies in providing stable identities, predictable networking, dedicated storage per replica, and ordered deployment behavior. These features make StatefulSets the ideal choice for databases and other stateful distributed systems.

If you're running stateless applications such as frontend applications, REST APIs, or microservices, Deployments are usually the right choice. But when your workloads require stable identities and persistent state, StatefulSets become essential.

I hope this hands-on comparison helped clarify the difference between Deployments and StatefulSets.

See you in the next episode of K8s with Pravesh! 🚀

🌟 Connect With Me

Website: https://praveshsudha.com
Blog: https://blog.praveshsudha.com
LinkedIn: https://www.linkedin.com/in/pravesh-sudha/
X (Twitter): https://x.com/praveshstwt
YouTube: https://www.youtube.com/@pravesh-sudha

If you found this article helpful, consider sharing it with your network and following the series for upcoming Kubernetes content.

Here's why your Prompt is WRONG 😑

Pravesh Sudha — Fri, 29 May 2026 17:48:43 +0000

The right prompt is no longer just a skill — it is becoming a necessity in this fast-paced world where almost everything is driven by AI chatbots and agents.

A lot of people think AI gives bad results because the model is not powerful enough, but in most cases, the real issue is the prompt itself.

In today’s blog, we will uncover some of the most useful AI prompting techniques that can help you write better prompts and get significantly better results.

1. Zero-Shot Prompting

This is the most common prompting technique among beginners. Almost everyone starts from this approach.

In Zero-Shot Prompting, you directly ask the AI what you need in a brief and specific way without giving any prior examples.

For example:

Instead of writing:

“Generate me a Kubernetes Deployment file”

You can write:

“Generate ONLY a Kubernetes Deployment file”

This small change cuts out unnecessary explanations, extra commands, and long guides that AI models often generate by default.

Zero-Shot Prompting works best for popular or familiar use cases where the AI already has strong contextual understanding.

Another advantage of this approach is lower token usage. In the screenshots above, you can notice that the token usage is almost 30% lower compared to longer prompts. This becomes extremely important in large organizations where APIs frequently interact with AI systems at scale.

2. Few-Shot Prompting

In this approach, before giving the actual task, we first provide the AI with a few examples.

This helps the model become context-aware and understand the expected style, structure, or format of the output.

Few-Shot Prompting is especially useful when organizations want responses to follow a particular standard rather than simply generating the “ideal” answer.

For example, if a company wants all incident reports, YAML files, or summaries to follow a fixed structure, giving examples beforehand helps maintain consistency.

For Fun: I have attached a SuperHero Example

3. Multi-Shot Prompting

Multi-Shot Prompting is very similar to Few-Shot Prompting, but instead of providing a few examples, we provide many examples for even better contextual understanding.

The advantage is usually better and more refined output quality.

However, the downside is increased token consumption because the input becomes significantly larger due to additional examples.

This is a tradeoff between output quality and cost efficiency.

4. Chain of Thought Prompting

Chain of Thought Prompting encourages the AI to break down complex reasoning tasks into intermediate steps before generating the final answer.

For example:

“Explain why this deployment failed in a step-by-step manner.”

This technique is extremely useful for debugging, analysis, problem-solving, and learning deeply about a topic instead of just scratching the surface.

It is especially beneficial for curious minds who want to understand why something happened rather than simply receiving the final answer.

5. RAG (Retrieval-Augmented Generation)

RAG is not exactly a prompting technique, but more of a workflow approach used alongside prompting.

In this method, the AI is connected to external data sources such as databases, PDFs, internal documents, or APIs.

Instead of relying solely on its internal training data, the model retrieves relevant information from these external sources before generating a response.

This helps produce more accurate, contextual, and up-to-date answers.

RAG is widely used in AI agents, enterprise chatbots, documentation assistants, and knowledge-based systems.

Final Thoughts

Writing an efficient prompt is not as difficult as it seems.

It simply involves understanding which technique works best for your specific use case.

Experiment with different prompting approaches, observe the outputs, and gradually build your own prompting style.

If you liked this blog, make sure to follow me on LinkedIn, Twitter, and YouTube where I regularly share my learnings around AI, DevOps, and technology.

Till then,

Adios 👋

🤫 Firebase Is Quietly Preparing for an Offline-First AI Future

Pravesh Sudha — Fri, 22 May 2026 17:10:50 +0000

Firebase announcements at Google I/O 2026 covered an array of products and features, but the one that grabbed my attention the most was Firebase itself. Most people are understandably focused on Gemini integrations, AI Studio, and the new SQL capabilities inside Firebase, but I believe there is something deeper happening underneath these announcements.

Firebase introduced offline caching support, which helps applications remain responsive even in little or no connectivity. Combined with local and hybrid AI inference, this suggests that Firebase is quietly moving toward an offline-first, hybrid-intelligence model.

A large number of companies are transitioning to the cloud because of the convenience of not managing physical infrastructure and data servers. However, cloud dependency comes with its own trade-offs. Heavy reliance on cloud infrastructure introduces dependence on continuous high-speed internet connectivity, recurring subscription costs, and potential vendor lock-in.

The reality is that not every place in the world has fast and stable internet connectivity. Offline caching can help reduce cloud costs while improving application responsiveness, even in low-connectivity environments.

Modern Applications Are Too Cloud Dependent

Modern applications often assume that users:

have constant internet access,
can perform fast cloud API calls with low latency,
and are always connected to online AI services.

In reality, connectivity is far from universal, especially in rural areas, trains, crowded public networks, and emerging markets such as India.

AI has further increased cloud dependence because AI applications continuously send prompts, images, voice data, and user content to remote servers. This increases:

latency,
cloud costs,
bandwidth usage,
and potential privacy concerns.

As a result, “smart applications” can quickly become fragile applications when internet connectivity is lost. AI features stop functioning, synchronization fails, and the overall user experience degrades significantly.

What Firebase Actually Announced

Firebase introduced custom resolvers, allowing developers to extend Firebase Data Connect beyond Cloud SQL and integrate additional data sources. Alongside this, realtime sync improves application UX by enabling live updates and synchronization across devices.

However, the most interesting feature, in my opinion, is offline cache support, which helps applications remain responsive even with limited or no connectivity. Firebase AI Logic also supports local inference with cloud fallback, allowing certain AI workloads to run directly on-device while heavier tasks can still rely on cloud infrastructure when required.

Additionally, Firebase AI Logic simplifies the integration of generative AI features without requiring extensive server-side setup. It supports multiple programming languages, including Kotlin, Java, Swift, and Flutter.

Taken together, these are not isolated features. Firebase appears to be gradually reducing dependence on centralized cloud execution.

Firebase Is Moving Toward an Offline-First AI Architecture

With offline caching, applications can remain usable even without network connectivity by treating local application state as a first-class component. Synchronization can happen later once connectivity is restored. This improves responsiveness, resilience, and overall application UX while reducing the frequency of frustrating “No Internet Connection” screens.

Local AI inference also changes the compute model. Instead of every AI request depending entirely on cloud APIs, certain AI tasks can now happen directly on-device. For example, in an AI-powered note-taking application, features such as summarization, translation, smart suggestions, and classification could potentially run locally without continuously communicating with remote servers.

For heavier reasoning tasks, hybrid inference becomes important. Lightweight tasks can execute locally, while more computationally intensive operations can seamlessly fall back to cloud models when necessary. This creates a distributed intelligence model where computation is shared between the device and the cloud.

Why This Matters for Emerging Markets

Many cloud-first applications are designed around assumptions that often reflect:

Silicon Valley-like infrastructure conditions,
premium hardware,
and stable high-speed internet connectivity.

However, the ground reality is very different for billions of users around the world. Many people rely on affordable Android devices and unstable mobile networks.

Hybrid architectures can help address this gap by enabling:

lower latency,
reduced bandwidth usage,
partially offline AI experiences,
and better accessibility.

This is particularly important for regions such as India, Africa, and Southeast Asia, where connectivity challenges still exist despite massive growth in smartphone adoption.

The Bigger Industry Shift

With the rapid growth of AI, the industry is gradually moving toward edge AI. Examples include:

on-device Gemini,
Apple Intelligence,
AI NPUs in smartphones,
and local LLMs.

The future of AI may not remain fully centralized. Instead, intelligence may become distributed across devices, edge systems, and cloud infrastructure working together collaboratively.

Critique and Challenges

Like any architectural shift, this approach also comes with trade-offs.

Local AI inference introduces the challenge of device fragmentation. Not all devices are capable of handling local AI workloads efficiently. On-device inference can also increase battery consumption and thermal load.

Hybrid architectures are often more difficult to monitor, debug, and optimize compared to traditional centralized cloud systems.

There is also the issue of vendor lock-in. Heavy dependence on tools such as Firebase, Gemini, and the broader Google Cloud ecosystem could limit developer flexibility over time.

Finally, local models still have computational limitations compared to larger cloud-hosted models.

Conclusion

I believe the Firebase announcements at Google I/O 2026 were not simply about adding more AI capabilities. They reflected a broader shift in how modern applications may operate in the future: less dependent on permanent connectivity, more resilient at the edge, and increasingly capable of running intelligence closer to the user.

The most important AI infrastructure trend may not be larger models alone, but the gradual movement of intelligence from centralized cloud systems toward user devices themselves.

If you liked the blog, consider sharing it among your peers and follow me on Linkedin, Twitter and subscribe to my Youtube Channel.

🚀 Democratizing Frontier AI for Bharat: Gemma 4’s Edge Capabilities in Low-Resource Environments

Pravesh Sudha — Mon, 18 May 2026 12:57:02 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

How Google’s open-weight Gemma 4 models are shifting AI from a Silicon Valley luxury to a practical tool for India’s primary sector and developers working at the edge.

Introduction: The Ground Reality

India is set to solidify its position as the world’s most populous nation. Yet, even in 2025-26, around 43% of its workforce remains employed in the primary sector — agriculture, animal husbandry, and allied activities. For millions of farmers in rural Rajasthan, Haryana, or Bihar, AI is still largely an abstract, distant concept.

A mustard farmer in rural Rajasthan dealing with crop infestation or a livestock owner in a tier-3 town cannot rely on cloud-first AI. High latency, expensive USD-billed APIs, and poor or intermittent internet make frontier models inaccessible. This is where the paradigm must shift — from cloud-first to edge-first architecture.

Google’s Gemma 4 family, particularly its edge-optimized models (E2B and E4B), represents a meaningful step in that direction.

Why Gemma 4 is Different for Bharat

Gemma 4 stands out because of its intentional design for real-world constraints:

Apache 2.0 license — Fully open weights with commercial freedom.
Edge-optimized models — E2B (2.3 billion effective parameters) and E4B are built for phones, tablets, and single-board computers like Raspberry Pi.
Native Multimodal — Text + high-resolution images + audio (especially strong on E2B/E4B).
Multilingual strength — Pre-trained on over 140 languages, with strong performance on Indian languages and dialects.
Long context — Up to 128K tokens on edge models, enabling richer reasoning.

Getting started is surprisingly simple. Download the free Google AI Edge Gallery app (available on Android and iOS), select the Gemma 4 E2B model (~2.5 GB download), and you have a fully offline multimodal AI assistant on your phone. Once downloaded, it works without internet — text chat, image analysis, and voice input all run locally.

Real-World Performance: Benchmarks on Edge Hardware

Performance numbers show why this is viable for low-resource settings:

Model Size & Memory: E2B quantized (INT4/Q4) has a ~2.58 GB footprint and runs in 1.5–3 GB RAM on devices, making it accessible on mid-range smartphones and Raspberry Pi.
Raspberry Pi 5 (16GB): Prefill 133 tokens/sec, Decode 7.6–8 tokens/sec, Peak memory ~1.5 GB. This is usable for batch advice, diagnostic reports, or non-real-time assistance.
High-end Android (e.g., Samsung S26 Ultra): Decode speeds reach 47–52 tokens/sec on CPU and over 50 tokens/sec on GPU, with first-token latency under 2 seconds.
iOS Devices: Similar strong performance, especially on newer flagships.

These benchmarks prove that capable multimodal AI no longer requires expensive cloud GPUs or high-end laptops. A ₹8,000–15,000 smartphone or a ₹5,000–8,000 Raspberry Pi can now deliver practical intelligence offline.

On-the-Ground Use Cases: AI That Farmers Can Actually Use

Visual Diagnostics: A farmer points their phone at diseased leaves or livestock. Gemma 4 processes the image locally and suggests possible issues and remedies.
Voice Interaction in Mother Tongue: Thanks to strong multilingual capabilities, users can speak in Hindi, Rajasthani, Haryanvi, or other regional languages. The model understands intent without clumsy translation layers. “Kos-kos par badle paani, chaar kos par vaani” (The water changes every few miles, and the speech every fourth) — Gemma 4’s broad language coverage helps bridge this diversity.
Agentic Assistance: Beyond simple Q&A, the model supports multi-step reasoning and tool use, making it suitable for practical workflows like “Analyze this crop image, suggest next steps considering common local practices.”
Market & Supply Chain: Quick offline quality assessment of produce or basic price trend insights when connectivity returns.

These capabilities turn a regular smartphone — now owned by a large majority of the population — into a personal Krishi advisor.

The DevOps Reckoning: From Cloud Comfort to Edge Reality

As someone who has spent years in AI + DevOps, I’ve lived the cloud-native comfort zone: auto-scaling clusters, infinite compute, low-latency pipelines on AWS/GCP. That architecture collapses spectacularly when you try shipping frontier AI to rural India.

Deploying Gemma 4 at the edge forces us to relearn core principles:

1. Orchestration: Hard Limits Over Auto-Scaling

Swap EKS/GKE for lightweight solutions like K3s or Docker Compose on edge nodes. Use cgroups and strict memory caps so multimodal inference doesn’t crash the host device (critical on phones or shared village Raspberry Pi hubs).

2. Artifacts: Quantization as a First-Class CI/CD Stage

The model itself becomes the build artifact. Integrate automated INT4/INT8 quantization (using tools like llama.cpp or LiteRT) into your pipelines. Ship deltas and LoRA adapters instead of full models.

3. Delivery: Pull-Based GitOps for Sporadic Networks

Traditional push-based deployments fail offline. Design pull-based agents that sync during network windows — downloading only necessary updates or adapters.

4. New Observability

Monitor battery drain, thermal throttling, and inference latency on diverse low-resource hardware. “High availability” now means the system works when the farmer needs it most — even with zero bars of signal.

Cloud vs Edge: Indian Context Comparison

Aspect	Cloud-First Models	Gemma 4 Edge Models
Cost	Recurring API fees (USD)	One-time hardware, free inference
Internet Requirement	High	Fully offline capable
Data Privacy	Data leaves the device	Stays local
Language Support	English-first	Strong 140+ languages
Latency	Variable (network dependent)	Near-instant local
Deployment Control	Vendor locked	Full ownership (Apache 2.0)
Suitability for Rural Bharat	Limited	Purpose-built

Challenges We Must Address

No technology is perfect. Key issues include:

Risk of hallucinations in critical advice (needs verification loops or hybrid human-AI systems).
Need for domain-specific fine-tuning on Indian crop/livestock datasets.
Energy and thermal constraints on very low-end devices.
Last-mile distribution and digital literacy.

These are engineering + ecosystem problems we can solve together.

Conclusion: Engineering for the 43%

The true frontier of AI is not in multi-million dollar clusters in Silicon Valley. It is being forged at the rugged edge — in the hands of farmers, extension workers, and developers who understand local realities.

Gemma 4 won’t solve every problem overnight, but it lowers the barrier dramatically. By embracing edge-first design with open models, we shift DevOps responsibility from managing cloud bills to solving real constraints: every kilobyte, unpredictable networks, and diverse hardware.

It’s time to stop building only for the comfortable few. Frontier engineering should level the playing field for Bharat.

Let’s build for the 43%.

If you find the Article useful, make sure to share it among your socials, tagging me on Linkedin, Twitter.
Checkout my Youtube Channel

🚀 Kubernetes for Beginners: Deploying an Nginx–Node–Redis Application | Episode 1

Pravesh Sudha — Fri, 03 Apr 2026 12:55:17 +0000

Understanding Services, ConfigMaps, Deployments, and health checks with my WAY!

Hola Amigos! 👋

Today, we are embarking on a brand new series: K8s with Pravesh 🚀 — where we’ll break down Kubernetes, understand what it really is, and more importantly, how you can actually use it in a practical, no-BS way.

In today’s blog, we’ll dive into the fundamentals — Deployments, Services, and ConfigMaps — and use them to deploy a three-tier application on Minikube.

Now you might be thinking… “What’s new here? There are already thousands of blogs doing the same thing.”

And honestly, you’re not wrong.

But hold your horses for a second 🐎

This isn’t just another “apply this YAML and it works” kind of tutorial. We’re going to:

Understand what’s really happening under the hood
Debug real issues (yes, the ones that actually happen)
And build intuition so you don’t just run Kubernetes… you get it

So let’s dive in. 🔥

🛠️ Pre-Requisites

Before we dive deep, there are a couple of things you need to have set up. Nothing fancy — just the essentials to get your Kubernetes playground up and running.

🔹 Docker / Docker Desktop

We’ll be running Minikube using Docker, so make sure you have Docker installed on your system.

👉 Install it from here: https://docs.docker.com/get-started/get-docker/

🔹 Minikube

Think of Minikube as your personal Kubernetes cluster — lightweight, local, and perfect for experimenting and learning all the cool stuff without needing a cloud setup.

👉 Download it from here: https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Farm64%2Fstable%2Fbinary+download

🎥 Practical Demonstration

🤔 What is Kubernetes (K8s)?

At its core, Kubernetes is a container orchestration tool.

Now that sounds fancy, but let’s simplify it a bit.

Think of Kubernetes as a Head Chef in a restaurant 👨‍🍳 It makes sure:

Everyone is doing their job properly
Work is flowing smoothly
And if something breaks… it steps in and fixes it

That’s the layman definition.

The Real Meaning

In technical terms, Kubernetes is responsible for:

Managing containers
Scaling them
Ensuring they are always running
Handling communication between them

You can think of it as an advanced version of Docker Compose — but built for production-grade systems.

The Smallest Unit: Pod

In Kubernetes, the smallest deployable unit is a Pod.

👉 A Pod is basically a wrapper around your container(s)

It can run one or more containers
These containers share:
- Network
- Storage

But here’s the thing…

Managing Pods manually? 😵‍💫 Not a great idea.

Enter Deployments

To solve that, we have Deployments.

A Deployment is like a blueprint for your Pods.

You define:

Container image
Number of replicas
Ports
Volumes
Other configurations

And Kubernetes takes care of:

Creating Pods
Scaling them
Replacing them if they crash

💥 Much easier to manage.

How Do Pods Talk to Each Other?

Back to our restaurant analogy 🍽️

The waiter needs to communicate with the chef, right?

But in Kubernetes… 👉 Pods don’t automatically talk to each other

We need something in between.

Services: The Communication Bridge

Services act as a bridge between Pods.

They provide:

Stable networking
Internal DNS
Load balancing

There are 3 main types:

🔹 ClusterIP

Default type
Used for internal communication only
Not accessible from outside the cluster

🔹 NodePort

Exposes the service on a specific port on the node
Accessible from outside using:
```
<Node-IP>:<Port>
```

🔹 LoadBalancer

Exposes the app to the outside world
Commonly used in cloud environments (AWS, GCP, etc.)

ConfigMaps: Handling Custom Configurations

Back to the restaurant…

Imagine a customer walks in and says:

“I want a Caffè macchiato, with a little bit of soy, enough to make me go OH BOY!” — Kevin Hart fans, you know 😄

Handling custom requests manually can get messy…

But in Kubernetes, we have ConfigMaps for this.

👉 ConfigMaps allow you to:

Store non-confidential data
Use it inside your applications
Keep configs separate from your code

For sensitive data? 👉 Use Secrets

YAML: The Language of Kubernetes

All resources in Kubernetes are defined using YAML files.

You describe:

What you want
And Kubernetes makes it happen

If you want to explore more, check out the official docs: 👉 https://kubernetes.io/docs/setup/

⚙️ Practical Demonstration

Enough with the theory — now let’s get our hands dirty 🔥

So far, we’ve covered:

Deployments
Services
ConfigMaps

And to bring all of this together, we’ll deploy a three-tier application (Nginx–Node–Redis).

I’ve actually used this same app in one of my earlier projects to demonstrate CI/CD workflows with GitHub Actions and Terraform. If you’re curious, check it out here: 👉 https://blog.praveshsudha.com/cicd-for-terraform-with-github-actions-deploying-a-nodejs-redis-app-on-aws

Step 1: Clone the Project

git clone https://github.com/Pravesh-Sudha/nginx-node-redis.git

Open the project in your favorite editor (VS Code works great).

Understanding the App

This is a simple Node.js application that:

Displays a request counter
Increments the count on every refresh
Stores data in Redis
Uses Nginx as a reverse proxy (serving on port 80 instead of 5000)

Step 2: Run with Docker Compose

Before jumping into Kubernetes, let’s run it locally:

docker-compose up --build

Make sure Docker Desktop is installed and running.

You should see logs in your terminal and the app running in your browser.

Once done:

Ctrl + C

Step 3: Move to Kubernetes

Now comes the interesting part.

Inside the project:

cd nginx-node-redis/kube-config/

You’ll find three directories:

nginx/
node/
redis/

Each contains:

Deployment YAML
Service YAML

📦 Nginx Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

        volumeMounts:
        - name: nginx-config-volume
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf

      volumes:
      - name: nginx-config-volume
        configMap:
          name: nginx-config

A Note on AI & YAML

The best thing about AI? 👉 You can generate YAML files instantly.

But what happens when things break?

That’s where fundamentals matter.

Let’s break this down 👇

Understanding the Deployment

1. API Version & Kind

Defines what resource we are creating:

kind: Deployment

2. Labels (IMPORTANT)

Labels appear in three places — and each has a role:

metadata.labels → tagging the Deployment
spec.selector.matchLabels → tells Deployment which Pods to manage
template.metadata.labels → applied to Pods (used by Services)

👉 This is how Kubernetes “connects” resources.

3. Container Spec

image: nginx:1.14.2
ports:
  - containerPort: 80

Defines:

Image
Port

4. ConfigMap Mount

volumeMounts:
- name: nginx-config-volume
  mountPath: /etc/nginx/nginx.conf
  subPath: nginx.conf

👉 This mounts your custom Nginx config into the container.

🌐 Nginx Service

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

Here:

We use ClusterIP
Selector matches:
```
app: nginx
```

👉 This connects the Service to Pods.

⚙️ Nginx ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-config
data:
  nginx.conf: |
    events {}

    http {
      upstream loadbalancer {
        server node-service:5000;
      }

      server {
        listen 80;

        location / {
          proxy_pass http://loadbalancer;
          proxy_set_header Host $host;
          proxy_set_header X-Real-IP $remote_addr;
          proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }

        location = /favicon.ico {
          log_not_found off;
          access_log off;
        }
      }
    }

👉 Here we:

Override default Nginx config
Route traffic to:
```
node-service:5000
```

Step 4: Deploy to Minikube

# Start Minikube
minikube start

# Go to config directory
cd nginx-node-redis/kube-config/

# Deploy Redis
cd redis/ && kubectl apply -f deploy.yml -f svc.yml
cd ..

# Deploy Node
cd node/ && kubectl apply -f deploy.yaml -f svc.yml
cd ..

# Deploy Nginx
cd nginx/ && kubectl apply -f deploy.yml -f svc.yml -f configmap.yaml

Wait for Pods

kubectl get pods -w

Wait until all pods are:

Running

Access the App

minikube service nginx-service

👉 This opens your app in the browser — now running on Kubernetes 🎉

Self-Healing in Action

Here’s where Kubernetes shines.

Let’s break something 😈

kubectl delete pod <pod-name>

Now check:

kubectl get pods

👉 You’ll see:

A new pod automatically created

🧠 What just happened?

Kubernetes ensures:

“Actual state = Desired state”

Even if you:

Delete a pod
Crash a container

👉 Kubernetes will bring it back

🔍 What’s Happening Under the Hood?

Now that everything is up and running, let’s take a step back and understand how things are actually working behind the scenes 👇

1. Accessing the Application

When you run:

minikube service nginx-service

👉 Minikube exposes your service and gives you a URL with a port.

2. Request Hits Nginx Service

Once you hit that URL:

The Nginx Service receives the request
It looks at its selector:
```
app: nginx
```
And forwards the request to all matching Nginx Pods

3. Inside the Nginx Pod

Inside the pod:

Nginx uses the custom config (via ConfigMap)
The request is proxied to:
```
node-service:5000
```

4. Node Service Load Balancing

Now the interesting part 👀

node-service is a ClusterIP Service
It has multiple pods (replicas = 3)

👉 Kubernetes automatically distributes traffic:

node-service
   ↓
 ┌──────────┬──────────┬──────────┐
 │ node-pod1│ node-pod2│ node-pod3│
 └──────────┴──────────┴──────────┘

5. Node App Talks to Redis

Inside your Node app:

It connects to:
```
redis-service
```
Stores:
- Request count
- Cache data

6. Response Flow

Finally, the response travels back:

Redis → Node → Nginx → Browser

🎉 And you see the updated request count

🧠 Key Insight

Notice something important here…

👉 We never used a single IP address.

Everything works using:

Service names
Internal DNS
Labels & selectors

This is called Service Discovery — one of the most powerful features of Kubernetes.

Scaling Made Easy

Want more traffic handling capacity?

Just update:

replicas: 3

👉 Increase or decrease as needed

👉 No changes required anywhere else

Kubernetes handles the rest

Cleanup

Once you’re done experimenting, you can delete the cluster:

minikube delete

🎯 Conclusion

And that’s a wrap for this one! 🚀

In this blog, we didn’t just deploy an application on Kubernetes — we actually understood what’s happening behind the scenes. From Deployments and Services to ConfigMaps and internal service discovery, you now have a solid foundation to start building real-world K8s projects.

More importantly, you saw how:

Kubernetes replaces static setups like Docker Compose with dynamic, scalable systems
Services enable seamless communication without worrying about IPs
And how the system self-heals to match the desired state

This is just the beginning of the K8s with Pravesh series. In the upcoming blogs, we’ll go deeper into more advanced concepts and build even more powerful systems 💥

🔗 Let’s Connect

If you found this helpful, feel free to connect with me and follow along for more DevOps and Kubernetes content:

💼 LinkedIn: https://www.linkedin.com/in/pravesh-sudha
📝 Blog: https://blog.praveshsudha.com
💻 GitHub: https://github.com/Pravesh-Sudha

If you have any questions, got stuck somewhere, or just want to discuss ideas — my DMs are always open 🙌

Until next time… Keep building, keep learning, and keep shipping 🚀

🔥 𝗜 𝗮𝗺 𝗻𝗼𝘄 𝗮𝗻 𝗜𝗕𝗠 𝗖𝗵𝗮𝗺𝗽𝗶𝗼𝗻 / 𝗛𝗮𝘀𝗵𝗶𝗰𝗼𝗿𝗽 𝗔𝗺𝗯𝗮𝘀𝘀𝗮𝗱𝗼𝗿 𝗕𝗔𝗕𝗬!!! 🔥 Excited to announce that I am officially recognised as an IBM Champion earlier known as Hashicorp Ambassador this year.

Pravesh Sudha — Thu, 26 Feb 2026 04:58:00 +0000

🚀 Building an AI-Powered CI/CD Copilot with Jenkins and AWS Lambda

Pravesh Sudha — Tue, 24 Feb 2026 18:15:10 +0000

💡 Introduction

Hey folks, welcome to the world of Agentic Tools and DevOps.

Today, we’re diving into CI/CD pipelines and exploring how we can debug them efficiently and almost instantly using AI. In this project, we’ll build an AI-powered CI/CD Copilot where AWS Lambda serves as the core logic layer. This Lambda function will interact with the Google Gemini API to analyze pipeline failures and help us debug them intelligently.

The goal of this project is not just to integrate AI into a CI/CD workflow, but to help you understand how to build your own AI agent from scratch — one that can assist in real-world DevOps scenarios.

So, without further ado, let’s get started.

💡 Prerequisites

Before we begin, make sure you have the following requirements in place:

Docker & Docker Hub account

We will run parts of this project inside Docker containers. Later, we’ll push our custom image to Docker Hub, so make sure you have both Docker installed and a Docker Hub account ready.
Jenkins (Our CI/CD Tool)

We’ll use Jenkins for demonstration purposes. You can either:
- Run Jenkins as a Docker container, or
- Install it directly from the official website.
Terraform

We will provision our infrastructure — including the Gemini API key (stored securely) and the AWS Lambda function — using Terraform.

Make sure:
- Terraform CLI is installed
- Your AWS credentials are configured
- The IAM user has permissions for AWS Lambda and AWS Secrets Manager
If you’re new to Terraform setup, you can follow this guide:

👉 https://blog.praveshsudha.com/getting-started-with-terraform-a-beginners-guide#heading-step-1-install-the-aws-cli

🎥 Youtube Demonstration

💡 How It Works

The complete source code for this project is available in this GitHub repository:

👉 https://github.com/Pravesh-Sudha/ai-devops-agent

Navigate to the cicd-copilot directory to follow along.

If you’ve been following my work, you might recognize this project. I originally used this same Node.js Book Reader application to demonstrate how Docker works with Node.js. For this AI-powered CI/CD Copilot, I’ve made specific modifications — particularly in the Jenkinsfile and the terra-config directory.

Inside the terra-config directory, you’ll find:

main.tf – Provisions:
- AWS Lambda function
- AWS Secrets Manager secret (to securely store the Gemini API key)
lambda.zip – The packaged Lambda deployment artifact (zipped lambda_function.py)
lambda_function.py – The core of this project.

This file contains the AI agent logic and the structured prompt sent to the Gemini API.
iam.tf – Defines the IAM roles and permissions required for:
- AWS Lambda
- AWS Secrets Manager

Architecture Overview

The core idea behind this project is simple:

Jenkins detects a pipeline failure.
It collects contextual information (stage name, build ID, logs).
It sends that data to AWS Lambda.
Lambda calls the Gemini API.
Gemini analyzes the logs and returns structured debugging insights.

Payload Sent to Lambda

The Lambda function expects a JSON payload in the following format:

{
   stage: $stage,        # Name of the stage where the pipeline failed
   job: $job,            # Job name (e.g., cicd-copilot)
   build_id: $build_id,  # Build ID number (e.g., 1, 2, 3)
   logs: $logs           # Last 200 lines of failure logs
}

This structured input allows the AI agent to understand the pipeline context before analyzing the logs.

Prompt Sent to Gemini API

Inside the Lambda function, we make a POST request to the Gemini API with the following structured prompt:

You are a senior CI/CD Copilot specialized in Jenkins pipelines.

Pipeline context:
- Stage name: {stage}
- Expected outcome: Build an artifact usable by later stages

Your tasks:
1. Identify the failure category (build / runtime / config / infra / dependency / auth / unknown)
2. Identify the most likely root cause
3. Provide actionable fixes
4. Suggest a patch ONLY if clearly inferable

Respond ONLY in valid JSON with this schema:
{{
  "failure_category": "",
  "root_cause": "",
  "actionable_fixes": [],
  "suggested_patch": {{
    "file": "",
    "line": "",
    "fix": ""
  }}
}}

Logs:
{logs}

The prompt dynamically injects two key variables:

{stage} – The pipeline stage name
{logs} – The failure logs

If you’d like to explore the full Lambda implementation, you can view it here:

👉 https://github.com/Pravesh-Sudha/ai-devops-agent/blob/main/cicd-copilot/terra-config/lambda_function.py

How It Integrates with Jenkins

You might be wondering — how exactly does this connect with Jenkins?

Inside the Jenkinsfile, each stage:

Sets an environment variable for the stage name.
Redirects command output (in case of failure) into a LOG_FILE.

If any stage fails:

The post { failure { ... } } block is triggered.
Jenkins constructs the JSON payload.
It invokes the AWS Lambda function.
The AI-generated failure analysis is printed directly into the Jenkins console output.

This gives you instant, structured debugging assistance right inside your CI/CD pipeline.

How to Integrate This in Your Own Workspace

To replicate this approach in your own pipeline:

Append log redirection to each command:
```
${LOG_FILE} 2>&1
```
Define an environment variable for the stage name.
Provision:

*   AWS Lambda

*   IAM roles

*   Secrets Manager (for the Gemini API key)  
    using Terraform.

Add a post failure block in your Jenkinsfile to invoke the Lambda function with the structured JSON payload.

Once configured, your CI/CD pipeline becomes AI-assisted — capable of analyzing its own failures and suggesting actionable fixes.

💡 Practical Demonstration

Enough with the theory — let’s see this in action.

Step 1: Fork and Clone the Repository

First, head over to the GitHub repository and fork it under your own username.

You’ll be intentionally modifying the code later to trigger pipeline failures, so forking is important.

After forking:

git clone https://github.com/your-username/ai-devops-agent.git
cd ai-devops-agent/cicd-copilot/terra-config

Step 2: Initialize Terraform

Inside the terra-config directory, initialize Terraform:

terraform init

Step 3: Generate Your Gemini API Key

To provision the infrastructure, you’ll need a GEMINI_API_KEY.

Go to Google AI Studio
Log in with your Google account
Navigate to the API section
Click Create API Key
Give it a name and generate the key
Store it securely

Now, apply the Terraform configuration:

terraform apply -var="gemini_api_key=<Paste-your-key-here>" --auto-approve

⚠️ Make sure the configured AWS IAM user has the required permissions (Lambda and Secrets Manager access), as mentioned in the prerequisites section.

Once completed, your infrastructure (Lambda function + IAM roles + Secret) will be up and running.

Step 4: Configure Jenkins Pipeline

Open your Jenkins dashboard (usually running on http://localhost:8080).

Click Create New Item
Select Pipeline
Name it: cicd-copilot
Choose Pipeline script from SCM

Configure the following:

SCM: Git
Repository URL:

https://github.com/your-username/ai-devops-agent
Branch Specifier: main
Script Path:

cicd-copilot/Jenkinsfile

Click Save.

Step 5: Install Required Jenkins Plugins

Navigate to:

Manage Jenkins → Plugins

Install the following plugins:

Docker
Docker Pipeline
Docker Commons

Step 6: Add Docker to Jenkins PATH

Ensure Docker is accessible inside Jenkins.

In your terminal, run:

which docker

Copy the output path.

Now go to:

Manage Jenkins → System → Global Properties

Append the copied path to the existing PATH variable using : as a separator. Save the configuration.

Step 7: Add Docker Hub Credentials

Navigate to:

Manage Jenkins → Credentials

Add a new credential:

*   Kind: **Username with password**

*   Username: Your Docker Hub username

*   Password: Your Docker Hub password

*   ID: `docker-cred`

Save it.

Step 8: Trigger the Pipeline

Now go back to your cicd-copilot project and click Build Now.

Open Console Output.

You will notice that the pipeline fails — this is intentional.

The logs are automatically captured and sent to the AI Agent, which returns structured debugging analysis inside the Jenkins console.

In the first failure, the AI identifies a typo in the Dockerfile.

For example:

apine

It should be:

alpine

Fix the typo in your forked repository and commit the changes.

Step 9: Second Failure (Version Mismatch)

Rebuild the pipeline.

This time, the pipeline fails again — but for a different reason. There is a Docker image version mismatch.

The AI analysis might suggest that the image is private or unavailable. However, the real issue is in the Jenkinsfile.

Inside the Run Container stage, change the image version from:

v2

to:

v1

Commit the change and rebuild the pipeline.

Step 10: Successful Pipeline Run

Now, when you trigger the pipeline again:

The build succeeds
The Docker image is pushed to your Docker Hub account
The container starts successfully

Visit:

http://localhost:3000

You should see the Book Reader application running.

Stop the Application

To stop the running container:

docker kill cicd-copilot

Clean Up Infrastructure

To avoid unnecessary AWS charges, destroy the infrastructure:

terraform destroy -var="gemini_api_key=<Paste-your-key-here>" --auto-approve

What We Achieved

In this project, we built an AI-powered CI/CD Copilot using:

Jenkins for pipeline orchestration
AWS Lambda for AI agent logic
AWS Secrets Manager for secure API storage
Google Gemini API for log analysis

The agent receives contextual pipeline information and failure logs, analyzes them intelligently, and provides structured debugging insights directly inside the CI/CD workflow.

Instead of manually scanning logs, you now have an AI assistant that understands context, categorizes failures, identifies root causes, and suggests actionable fixes — making debugging faster, smarter, and more efficient.

💡 Conclusion

Modern CI/CD pipelines are powerful — but when they fail, debugging can quickly become time-consuming and frustrating. In this project, we went a step further by integrating AI directly into the pipeline workflow.

By combining:

Jenkins for orchestration
AWS Lambda for serverless execution
AWS Secrets Manager for secure API handling
Google Gemini API for intelligent log analysis

we built an AI-powered CI/CD Copilot capable of understanding pipeline context, analyzing failure logs, identifying root causes, and suggesting actionable fixes — all automatically.

This isn’t just about log analysis. It’s about shifting from reactive debugging to intelligent, context-aware automation.

As AI continues to evolve, integrating agentic systems into DevOps workflows will become increasingly common. Building projects like this not only strengthens your cloud and automation skills but also prepares you for the next wave of AI-driven infrastructure.

If you found this project helpful, feel free to connect with me and follow my work:

🌐 Website: https://praveshsudha.com
📝 Blog: https://blog.praveshsudha.com
💼 LinkedIn: https://www.linkedin.com/in/pravesh-sudha
🐙 GitHub: https://github.com/Pravesh-Sudha
🐦 Twitter/X: https://x.com/praveshstwt
🎥 Youtube: https://youtube.com/@pravesh-sudha

I regularly share content on DevOps, AWS, Terraform, CI/CD, and building real-world cloud projects from scratch.

If you build your own version of this AI CI/CD Copilot, tag me — I’d love to see what you create.

Happy Building 🚀