DEV Community: Muskan Bandta

AI Skills Are Now Expected. For Cloud Engineers, That's Actually a Head Start.

Muskan Bandta — Wed, 14 Oct 2026 06:56:42 +0000

Somewhere in the last year, "AI skills" quietly moved from a nice-to-have on a job description to an assumption. Nearly every AI-powered tool is built on the cloud, so the two skill sets have stopped being separate tracks and started being one. If you are a cloud person watching the AI wave and wondering whether you are behind, here is the reframe I want to offer: you are not behind. You are standing on the exact ground everyone else is scrambling to reach. The trick is knowing which "AI skills" actually count, because most of what gets hyped is not the part that matters.

Why "AI skills" and "cloud skills" merged

Every AI product a company actually ships runs somewhere. The model is served on GPUs in a data center, the app around it runs on cloud compute, the data sits in cloud storage, the whole thing is wired together with cloud networking and secured with cloud IAM. AI is not a separate universe floating above infrastructure. It is a workload that runs on infrastructure, and that infrastructure is the cloud.

That is why "AI skills are expected" and "everything is built on the cloud" are the same sentence. The moment AI became something companies deploy rather than demo, the people who understand deployment, cost, security, and scale, cloud people, became central to it. The AI skill the market actually needs is not "can you write a clever prompt." It is "can you run this thing in production without it falling over or bankrupting us," and that is a cloud skill wearing a new label.

The AI skills that actually count (and the ones that do not)

Here is the part worth being clear-eyed about, because the hype points you at the wrong things.

Over-hyped and quickly fading:

Prompt tricks. The elaborate prompt-crafting skill is real but shrinking in value as models get better at understanding intent. It was always scaffolding.
Knowing this week's model rankings. Fun, low-value, stale in a month.

Durable and in demand, and mostly cloud skills already:

Running AI in production. Serving a model, scaling inference, handling the traffic. This is just "running a workload," which you already know. The AI part is a detail on top of infrastructure fundamentals.
The cost of AI. Token spend, GPU economics, inference cost, what things cost at scale. This is FinOps pointed at a new resource, and it is one of the most in-demand skills right now precisely because AI spend is exploding and few people can manage it. If you can already read a cloud bill, you are most of the way there.
Securing AI. What can this agent do, what data can it reach, what is the blast radius if it misbehaves. This is least-privilege and blast-radius thinking, unchanged, applied to a new kind of workload.
Data plumbing. Getting the right data to the model reliably, storage, pipelines, retrieval. Cloud data engineering with an AI destination.

Notice the pattern: the durable AI skills are the cloud skills you may already have, aimed at a new target. The scaffolding skills (prompts, model trivia) are the ones fading. The market is quietly re-pricing exactly the fundamentals cloud people already hold.

How to actually add "AI" to your cloud skills

You do not need to become an ML researcher. You need to point your existing skills at AI workloads deliberately. Concretely:

Deploy one AI thing end to end. Serve a model or wire an app to a model API, on your own cloud, and take it to something that runs. The goal is not the model, it is understanding the workload shape: how it scales, where it costs, how it fails.
Learn how AI costs money. Tokens, GPU-hours, inference pricing, what makes an AI bill spike. This is the single most leverageable skill because so few people have it and every company now needs it.
Apply your security instincts to it. Take one AI agent or integration and ask your normal questions: what can it access, what happens if it is compromised, where is the blast radius. You already know how to do this.
Skip the prompt-guru rabbit hole. Learn enough to be effective, then stop. That is not where the durable value is.

That is a few weekends of pointing skills you already have at a new kind of workload, not starting over.

The mindset shift

The thing I want a cloud person reading this to walk away with: "AI skills are now expected" is not a threat to you, it is a re-pricing of your existing skills upward. The industry spent a year acting like AI was a separate discipline that only ML specialists could touch. Then it turned out that shipping AI is mostly an infrastructure problem, running it, costing it, securing it, scaling it, and those are your problems. The people who feel behind are often the ones who never realized the ground moved toward them.

The take

AI skills are expected now because nearly every AI tool is built on the cloud, which means the two skill sets have merged into one, and cloud engineers are standing on exactly the ground the market is racing toward. The AI skills that actually count, running it in production, managing its cost, securing it, feeding it data, are cloud skills pointed at a new workload, not a new discipline. Deploy one AI thing end to end, learn how it costs money, apply your security instincts, and skip the prompt hype. You are not behind. You are early, and you did not even have to move.

If you are a cloud person, what is the AI skill you keep meaning to pick up, and is it actually a cloud skill in disguise? For most of us the honest answer is AI cost management, which is just FinOps we already know, aimed somewhere new.

Opus 5.5 Made Gummy Bears, Gemini 4 Argon Made Statues: The Real Lesson Isn't Which Won

Muskan Bandta — Wed, 14 Oct 2026 06:55:15 +0000

If you were anywhere near AI circles this week, you saw the gummy bear test. Someone (the account Teortaxes) gave Claude Opus 5.5 and Gemini 4 Argon the same prompt, then put both outputs through the same abuse: pulled a paw, yanked a head, squished them, threw them, poured a bag on top. Opus 5.5's bears behaved like actual jelly, they stretched and snapped back. Argon's came out solid and plastic-like, arms turning into rigid sticks, more statue than gummy. It is a genuinely funny, genuinely striking side by side, and it went everywhere.

I enjoyed it as much as anyone. But I run infrastructure and think about cost, so the part I want to talk about is not "which model won." It is what a viral vibe-test like this should and should not change about how you actually pick a model, because the answer is more useful than the meme.

Vibe-tests are not worthless, and that is the surprising part

The easy, smart-sounding take is "lol, a gummy bear test is not a benchmark, ignore it." Half right. It is not a controlled evaluation, it is one informal prompt run once, and you should not conclude anything about overall capability from it.

But here is what it does do, and why it spread: it reveals a behavioral difference that benchmarks are bad at capturing. Leaderboards give you a number on coding or knowledge or reasoning. They are terrible at showing you how a model behaves on a specific, weird, physical-intuition task, and that behavioral texture is exactly what you feel when you actually use a model on your actual work. The gummy test is a crude proxy for a real question: does this model have the kind of intuition my task needs? That is worth something, even if the gummies are not.

But it is the wrong input for a real decision

The trap is letting a viral anecdote, or a leaderboard, pick your model. Both are someone else's task, not yours. The gummy test tells you about gummy-bear physics intuition. The Artificial Analysis index (which, for what it is worth, puts Opus 5.5 somewhat ahead this round, roughly 58 to 53, while Argon wins some vendor-reported coding tests) tells you about an aggregate of tasks that are probably not your task either.

The only evaluation that actually decides your model is the one run on your workload. Not the gummy test, not the leaderboard, your prompts, your data, your definition of a good answer. This is the same discipline as every "best tool" comparison: the honest answer is always "benchmark it on your own workload," because the aggregate hides the variance that matters to you.

The cost twist the meme buried

Here is the part that made me, specifically, raise an eyebrow. The cost figures attached to the gummy test did not agree. The original post cited roughly a dollar or two in API cost. A Taiwanese write-up of the same comparison listed something like $7.2 for one and $22 for the other. Both models carry a similar standard list price (around $4 in / $20 out per million tokens), and yet the reported per-task cost ranged from "a couple of dollars" to "twenty-plus," for what was ostensibly the same exercise.

That spread is the real lesson for anyone paying the bill. Per-task AI cost is wildly sensitive to things the headline price does not show: effort settings, how many tokens the task actually consumed, reasoning depth, retries. Two people can run "the same" task on the same model and get costs that differ by an order of magnitude. Which means you cannot size your AI spend from the sticker price or from someone else's anecdote. You have to measure your cost on your task, with your settings, the same way you cannot size a cloud bill from an instance's hourly rate without knowing utilization.

So what should actually drive your choice

Put the gummy bears down and the decision is boring and correct:

Evaluate on your workload, not the meme or the leaderboard. Run your real prompts against both, score them your way. The aggregate is a starting filter, not the answer.
Measure your real per-task cost, not the list price. Run your actual task and read the actual token consumption and settings. Expect it to differ from any number you read online, possibly by a lot.
Do not marry one model. Both of these will be leapfrogged in a few months. Build so you can swap, model routing and an abstraction layer, so your architecture is not hostage to this week's winner.
Enjoy the vibe-tests as signal, not verdict. The gummy test is a fun hint that two models have different intuitions. Treat it as a reason to go test them yourself, not as the test itself.

The take

The gummy bear comparison is a great piece of internet, and it genuinely shows that Opus 5.5 and Gemini 4 Argon behave differently in a way no leaderboard captures. But "which made better gummies" is not your decision, and neither is "which tops the index." Your decision is which performs better on your workload at a cost you have actually measured, and the wild spread in the reported costs of this very test is the reminder that you cannot borrow anyone else's number. Watch the vibe-tests for fun, then go run the only benchmark that counts, yours.

Did the gummy test change which model you reach for, or just make you laugh? For me it was a good nudge to go re-run my own eval, which I had not touched since the last two releases, exactly the kind of thing a viral test is actually good for.

Every Copilot Rollout Has Two Numbers. Most Teams Only Ever See One.

Muskan Bandta — Tue, 29 Sep 2026 09:44:57 +0000

A finance lead I know pulled up her Microsoft 365 Copilot renewal a few weeks before it was due. The number was not small. Copilot is priced per seat per month, and her company had bought a lot of seats, because the rollout a year earlier had been enthusiastic: everyone who might benefit got a licence, on the theory that you do not want to be the person who gatekept the productivity tool.

So she asked the obvious question before signing again: how many of these seats are people actually using?

Silence. Not because nobody cared, but because nobody could answer it. She had one number cold, seats purchased, it was on the invoice. The number she actually needed, seats being used, did not exist anywhere she could reach. The admin center showed who had a licence assigned. It did not show who had opened Copilot this month, let alone who had used it enough to justify the cost.

That gap is the whole story of Copilot economics right now, and it is worth understanding whether or not you ever fix it, because almost every team is quietly in her position.

Two numbers, and you can only see the easy one

Every per-seat software rollout has two numbers:

How many people got a licence. Easy. It is on the bill and in the admin center. This is the number everyone has.
How many people actually use it. Hard. It requires connecting "who has a seat" to "who has real activity," and the two live in different places, if the activity data is reachable at all.

The trouble is that the decision, renew, cut, or reallocate, depends entirely on the second number, and the second number is the one nobody has. So renewals get made on the first number by default: "we bought 500 seats, renew 500 seats," with no idea whether 500 or 150 of them do anything. That is not a spending decision. That is a spending reflex.

Why this is a FinOps problem, not an IT one

It is tempting to file this under "IT should track that." But it is really the same shape as every cloud cost problem I deal with: you are paying for provisioned capacity, and nobody is checking utilization. An unused Copilot seat is exactly an idle EC2 instance. It is provisioned, it is billing, and it is doing nothing, and it survives because no one connected "we pay for this" to "is anyone using this."

AI seat licences are just the newest place that pattern shows up. The State of FinOps world has been saying it all year: cost management stopped being about the cloud bill and now covers AI and SaaS spend too. Copilot seats are the poster child, per-seat, AI-priced, enthusiastically over-provisioned, and almost never measured against real use.

What you actually want to see

If you are going to make an honest renewal decision, here is the view you need, and it is a good checklist regardless of what tool you use to get it:

Bought, assigned, used. Three numbers, not one. Seats you pay for, seats handed out, and seats with real activity behind them. The gap between the second and third is your waste.
Per person. Active days, prompts, and when each person last actually touched Copilot. This is what turns "we have low adoption" into "these specific 80 people have not opened it in a month."
Adoption over time. Daily active users against licensed seats over the last couple of weeks, so you can see whether usage is growing, flat, or quietly dead.
App footprint. How many Copilot-enabled apps each person really works across, because a seat used in one app is a different story from one used across many.
Renewal impact. The one that makes it real: what the unused seats cost you each month, stated as a number you can act on.

That is the difference between renewing on a reflex and renewing on evidence.

Where this connects to what we built

I work on ZopNight, and this is a problem we recently made visible, so I will be straight about it rather than coy: if you connect your Microsoft 365 tenant under Settings then Integrations, the Cost Reports AI Estate view now shows exactly the seat-licence picture above, bought vs assigned vs used, per-person activity, adoption over time, app footprint, and what the unused seats cost per month. Not because you need our tool to care about this, but because the data was genuinely hard to assemble and that is the gap we closed.

The reason I am writing this is not the feature though. It is the mindset. Even if you never touch ZopNight, go find your second number. Ask "how many of our Copilot seats have real activity," and if the answer is a shrug, that shrug is costing you every month. The tool that surfaces it matters less than the habit of refusing to renew per-seat AI licences on the purchased number alone.

The takeaway

Every Copilot rollout has two numbers, seats bought and seats used, and the whole renewal decision hinges on the second one, which is exactly the one most teams cannot see. Treat unused AI seats like idle infrastructure: provisioned, billing, doing nothing, and worth reclaiming. Before your next renewal, get the bought-vs-assigned-vs-used picture, look at who actually uses it, and put a monthly dollar figure on the seats that do not. Renew on evidence, not on the invoice.

If you have Copilot, do you know your second number, seats with real activity, or just the number you bought? And if you found the gap, how big was it? I keep hearing "bigger than we expected," which is the whole reason this is worth an afternoon.

The Cloud Skills That Still Matter When the Hype Changes Every Month

Muskan Bandta — Tue, 29 Sep 2026 09:08:04 +0000

Every month there is a new thing you are apparently behind on. A new model, a new framework, a new "X killed Y" headline, a new capex number with more zeros than the last. If you are early in a cloud career, it is exhausting and a little frightening, because it feels like the ground you are trying to stand on keeps moving. So here is the thing I have found genuinely steadying, and it is not a hot take: most of what actually makes you good at this does not change month to month. The hype changes constantly. The fundamentals underneath it barely move. Here is what I mean, and where I would spend my learning time.

The hype layer moves fast. The layer under it does not.

Think of your skills as two layers. The top layer is specific tools and trends: this year's model, this framework, the service that shipped last week. That layer turns over fast, and chasing it is a treadmill, whatever you master is half-stale by the time you are fluent.

The bottom layer is how things actually work: how a request travels, how cost accrues, how systems fail, how you reason about a problem you have never seen. That layer is remarkably stable. The tools sitting on top of it get swapped out; the layer itself is the same as it was years ago and will be years from now. Almost everyone spends their anxiety on the top layer. The people who get good fast invest in the bottom one.

The skills that keep paying off

Here is where I would actually put learning time, because these have not stopped mattering through every hype cycle I have watched:

How a request actually flows. From a user, through DNS, a load balancer, into a service, to a database, and back. Once you can trace that path, you can debug almost anything, on any stack, because the shape is the same whether it is 2020's tech or this month's.
How cost accrues. Not this week's pricing, the mechanics: what bills by the hour, what bills by usage, where the hidden charges hide (data transfer, idle resources, per-request costs). Pricing pages change; the way waste happens does not. This is the skill that made me look senior fastest, and it works on cloud, containers, and now AI spend identically.
How systems fail. Timeouts, retries, cascading failures, the difference between "it is down" and "it is slow." Failure modes are astonishingly consistent across technologies. Learn them once and every new tool's failures look familiar.
Least privilege and blast-radius thinking. "What can this thing do, and what happens if it goes wrong" is the security and safety question, and it applies unchanged to a VM, a container, an IAM role, and an AI agent. New surface, same question.
Reading the docs, especially the boring ones. The skill of going to the source instead of the hype is itself durable. The pricing page, the limits page, the actual documentation, that habit pays off on every new tool, forever.

What the fast-moving layer is actually for

This is not "ignore the new stuff." The new tools matter, and you should know roughly what exists. But you engage with them differently once you have the fundamentals: a new service is just "another thing that runs code" or "another thing that stores data" or "another thing that costs money per unit," and you already know how to reason about all three. The fundamentals turn every new tool from "a scary thing I am behind on" into "a new instance of a pattern I already understand."

That is the actual value of the boring layer: it makes the fast layer learnable. Without it, every new thing is from scratch. With it, every new thing is a variation on something you know.

A note on the current moment

Right now the hype is especially loud, hundred-billion-dollar capex numbers, bubble debates, a new model every few weeks. It is easy to feel like you need to have an opinion on all of it. You do not. What you need is to be the person who understands how the thing works underneath, because whichever way the hype resolves, boom or correction, the person who can trace a request, reason about cost, and understand failure is the one who stays valuable. Hype is a weather report. Fundamentals are the climate.

The take

The tools change every month and it is genuinely impossible to keep up with all of them, so stop trying to. Invest in the layer that does not move: how requests flow, how cost accrues, how systems fail, how to reason about blast radius, how to read the source. Those skills have survived every hype cycle and made every new tool easier to learn, because the new tool is always a variation on a pattern you already know. Learn the climate, not the weather.

What is one fundamental that has paid off for you across multiple hype cycles? For me it is understanding how cost accrues, it made cloud, then containers, then AI spend all feel like the same problem wearing different clothes.

What Actually Happens When You Run kubectl apply

Muskan Bandta — Sat, 26 Sep 2026 18:58:06 +0000

You type kubectl apply -f deployment.yaml, it says created, and a few seconds later your app is running. It feels like magic, and because it feels like magic, most people never learn what happens in between, which is exactly the knowledge that makes Kubernetes debugging possible. Let me trace the whole journey from your terminal to a running pod, step by step. Once you can follow this path, "why is my pod not starting" stops being a mystery.

The cast of characters

A Kubernetes cluster has a control plane (the brain) and worker nodes (where your containers run). The control plane pieces you need to know:

API server: the front door. Everything talks to it. kubectl talks to it, the other components talk to it, nothing bypasses it.
etcd: the database. The cluster's desired state lives here.
Scheduler: decides which node a new pod should run on.
Controllers: the reconcilers that make reality match desired state.

On each worker node:

kubelet: the agent that actually starts and watches containers on that node.
Container runtime: the thing that runs the container (containerd and friends).

The journey, step by step

1. kubectl reads and validates your YAML. Before anything leaves your machine, kubectl parses the file and turns it into an API request. Basic client-side checks happen here.

2. The request hits the API server. kubectl sends it to the API server, authenticated (who are you) and authorized (are you allowed, this is RBAC). If your permissions are wrong, you get rejected right here, this is where a lot of "forbidden" errors come from.

3. Admission control runs. The API server passes your request through admission controllers, which can validate or even modify it (enforce policies, inject defaults, reject non-compliant configs). Then the object is validated against the schema.

4. The desired state is written to etcd. The API server stores your Deployment in etcd. At this moment, kubectl prints created or configured, and here is the crucial insight: your job is done, but the actual work has not started. You have only recorded what you want. apply records intent; it does not run containers. This is why the command returns instantly but the app is not ready yet.

5. Controllers notice the gap. Controllers constantly watch the API server for differences between desired and actual state. The Deployment controller sees "you want 3 replicas, there are 0" and creates a ReplicaSet. The ReplicaSet controller sees "3 pods wanted, 0 exist" and creates 3 Pod objects. Note these pods are still just records in etcd, nothing is running yet.

6. The scheduler assigns pods to nodes. The scheduler sees 3 unscheduled pods and picks a node for each, based on available resources, constraints, and affinity rules. If no node has room, the pod stays Pending, this is the number one reason a pod sits Pending, the scheduler cannot place it.

7. The kubelet starts the containers. The kubelet on each chosen node sees "a pod was assigned to me," pulls the container image, and tells the runtime to start it. If the image name is wrong or the registry is unreachable, you get ImagePullBackOff here. If the container starts and crashes repeatedly, you get CrashLoopBackOff here.

8. Health checks and readiness. The kubelet runs your liveness and readiness probes. The pod only starts receiving traffic once it reports Ready. A pod can be Running but not Ready, which is why "it is running but I get no traffic" happens.

Why this mental model is the whole game

Every common Kubernetes problem maps to a step in that journey:

Forbidden error? Step 2, RBAC.
Rejected by a policy? Step 3, admission control.
Pod stuck Pending? Step 6, the scheduler cannot place it (not enough resources, a taint, a constraint).
ImagePullBackOff? Step 7, the kubelet cannot pull the image.
CrashLoopBackOff? Step 7, the container starts and dies.
Running but no traffic? Step 8, failing readiness.

When something breaks, you do not panic, you ask "how far down the journey did it get?" kubectl get pods tells you the phase, kubectl describe pod tells you the events at each step, and now you know what each step means.

The one idea to keep

Kubernetes is declarative. You do not tell it "start a container." You record "I want this state," and a set of controllers continuously works to make reality match. kubectl apply is just "write my desired state to the database." Everything after is the cluster reconciling toward it, on its own, forever. That is why you can delete a pod and it comes back: the desired state still says it should exist, so a controller recreates it.

The take

kubectl apply does not run your app. It records what you want in etcd, and then a chain of controllers, the scheduler, and the kubelet on each node work to make it real, and that chain is exactly where every common error lives. Learn the journey once, from API server to running pod, and Kubernetes troubleshooting turns from guessing into "which step failed, and what does that step do."

Which Kubernetes error taught you the most about this pipeline? For me it was a pod stuck Pending, chasing it down forced me to actually learn what the scheduler does, and everything else made sense after that.

AWS Storage Explained: S3 vs EBS vs EFS, and When to Use Which

Muskan Bandta — Thu, 24 Sep 2026 05:27:31 +0000

S3, EBS, EFS. Three AWS storage services, similar-looking names, completely different jobs, and using the wrong one for a task is a classic beginner mistake that leads to weird architectures and surprise bills. The good news: once you understand the one thing that separates them, choosing is easy. Let me explain what each is, in plain terms, and give you a rule that picks the right one every time.

The key distinction: how the storage is accessed

The three services differ mainly in how your application talks to the storage. That single distinction drives everything else.

EBS is a disk attached to one server.
EFS is a shared file system many servers can mount at once.
S3 is object storage you access over an API, not a file system at all.

Get that, and the rest follows.

EBS: a hard drive for one instance

EBS (Elastic Block Store) is a block storage volume, essentially a virtual hard drive you attach to a single EC2 instance. Your operating system sees it as a disk, formats it, and reads and writes to it like any local drive.

Key properties:

Attached to one instance at a time (in the normal case). It is that instance's disk.
Lives in one Availability Zone.
This is where your OS, your databases, and anything that needs fast, low-latency block access lives.

Use EBS for: the boot volume of an EC2 instance, and storage for a database or application that runs on that instance and needs a real disk. If you are thinking "my server needs a drive," that is EBS.

EFS: a shared drive many instances can mount

EFS (Elastic File System) is a managed network file system. Unlike EBS, many instances can mount the same EFS file system at once and see the same files. It grows and shrinks automatically, and it spans Availability Zones.

Use EFS for: workloads where multiple servers need to share the same files, a fleet of web servers serving the same content, a shared home directory, a content management system across instances. If your answer to "which server owns this data" is "several of them, together," that is EFS.

The tradeoff: it is more expensive per GB than EBS and has network-file-system latency, so it is not the right home for a high-performance database. Use it for sharing, not for raw speed.

S3: object storage over an API

S3 (Simple Storage Service) is different in kind. It is not a disk and not a file system. You store objects (files plus metadata) in buckets, and you access them over an HTTP API (GetObject, PutObject), not by mounting a drive. Your app talks to S3 with SDK calls, not filesystem reads.

Key properties:

Effectively unlimited scale, extremely durable, cheap per GB.
Accessed over the network by API from anywhere, not tied to an instance.
Not a filesystem, you cannot "cd into" a bucket, you request objects by key.

Use S3 for: backups, static assets (images, videos, downloads), data lakes, logs, anything you access as whole files rather than editing in place, and static website hosting. If you are storing files an application reads and writes as objects, that is S3, and it is usually the cheapest and most scalable choice.

The rule that picks the right one

Ask "who needs to access this, and how?"

One instance needs a fast local disk (OS, database)? EBS.
Multiple instances need to share the same files live? EFS.
You are storing files you access as objects over an API (assets, backups, logs, data)? S3.

Nine times out of ten the answer is obvious once you frame it that way. The classic mistake is using an EBS volume or EFS for something that should be S3 (like storing uploaded images on a server's disk instead of in a bucket), which makes your app stateful, harder to scale, and more expensive.

A cost note

Rough order, cheapest to most expensive per GB: S3 (cheap, and cheaper still with lifecycle rules moving old data to colder tiers), then EBS, then EFS (the shared-filesystem convenience costs more). This is another reason to default to S3 for anything you can: it is usually both the most scalable and the cheapest. And on EBS specifically, use gp3 volumes, they are cheaper and better than the older gp2.

The take

S3, EBS, and EFS are not competitors, they are three answers to three different questions. EBS is a disk for one instance, EFS is a shared file system for many, and S3 is API-accessed object storage for files at scale. Ask who needs the data and how they access it, and the choice makes itself. Default to S3 whenever your data is really just files, it is usually the cheapest, most scalable, and least painful option.

Which storage service did you misuse first? A lot of people start by saving uploads to an instance's EBS disk, then learn the hard way why that data belonged in S3 the first time they needed a second server.

A Model That Finds Zero-Days Now Exists. Here's the Cloud Exposure Audit to Run This Week.

Muskan Bandta — Thu, 24 Sep 2026 05:27:20 +0000

GPT-6 Astra shipped with the first Critical cybersecurity rating OpenAI has ever given a model, because it can autonomously find zero-days and build working exploits. The capability is gated for now, but the honest planning assumption is that some form of automated vulnerability discovery reaches adversaries sooner than anyone would like. I am not going to write a doom piece about that. I am going to give you the audit I actually ran on our own cloud this week, because the useful response to this news is not fear, it is a checklist you can finish in a few hours.

The thesis is simple: automated vulnerability discovery probes what is reachable, not what is important to you. So the single highest-value thing you can do is know and shrink what you expose. Here is how.

1. Inventory what is actually reachable from the internet

You cannot defend what you do not know is exposed, and every account exposes more than its owners think. Build the list:

Public IPs and the instances behind them.
Load balancers and what they route to.
S3 buckets with any public access, and buckets fronting a CDN.
Security groups allowing 0.0.0.0/0 on any port, and especially on anything that is not 443.
API endpoints, admin panels, and dashboards reachable without a VPN.

Most teams find something here they forgot existed. That forgotten thing is exactly what automated discovery finds first.

2. Kill the exposure you do not need

For everything on that list, ask "does this need to be reachable from the entire internet." Usually a surprising amount does not:

Dev and staging environments with public IPs that could sit behind a VPN.
Admin interfaces open to the world that should be IP-restricted.
Security groups with 0.0.0.0/0 that were "temporary" a year ago.
Old load balancers and endpoints from services that no longer exist.

Every item you remove is one fewer thing any scanner, human or automated, can probe. This overlaps almost perfectly with the orphaned-resource cleanup I usually frame as cost work: the forgotten public bucket and the idle exposed load balancer are both a bill and an attack surface.

3. Measure and shrink your patch latency

If exploit development speeds up, the window between a vulnerability going public and being weaponized shrinks toward zero. Your patch latency, how long from "CVE published" to "patched in prod", becomes your dominant risk. Two moves:

Actually measure it. Pick your last few notable patches and time them. Most teams are slower than they believe.
Shorten it for internet-facing systems specifically. You do not need to patch everything in an hour; you need to patch the reachable things fast, because those are what gets probed.

4. Tighten the identities attached to exposed things

For anything reachable, check the blast radius if it were compromised: what IAM role or permissions does it carry? An exposed instance with an over-broad role turns a foothold into a full incident. Simulate the permissions of your internet-facing workloads and cut anything they do not need. Least privilege is not new advice; it is the advice that limits how far a successful exploit gets.

5. Make sure something independent would notice

You will not prevent every novel exploit if they get cheap to produce. So the last layer is detection, and it has to be independent of the thing being attacked:

Anomaly alarms on API call velocity per identity (CloudTrail to metric filter to alarm is enough to start).
Alerts on unexpected state changes and on spend spikes (a compromised account often shows up as a cost anomaly first).
A watcher comparing real resource state to expected baselines, on separate credentials from your workloads, so a breach that changes something surfaces as drift within minutes. (That independent-verification pattern is one we built into ZopNight precisely because the system being attacked cannot be trusted to report its own compromise.)

The take

A model that autonomously finds and weaponizes zero-days now exists, and even gated, that resets the clock on defensive fundamentals. The response is not to panic, it is to spend an afternoon this week doing five boring things: inventory what you expose, remove what you do not need exposed, measure and shrink patch latency, tighten the identities on reachable systems, and confirm something independent would notice a breach. None of it is new. All of it just got more urgent, because the assumption underneath the old comfort, that finding novel exploits is slow and expensive, is the assumption that is expiring.

Run the exposure inventory in step one and I would bet you find at least one thing you forgot was public. What did you find? Mine was an old dev load balancer still routing to something, exactly the kind of forgotten reachable surface this whole exercise is about.

IAM Explained Simply: Users, Roles, Policies and Why It Confuses Everyone

Muskan Bandta — Fri, 18 Sep 2026 06:43:59 +0000

IAM is the thing every AWS beginner bounces off. It is also the thing you cannot avoid, because nothing in AWS works until IAM lets it. The confusion is not your fault: IAM has a few pieces that sound similar (users, roles, policies, groups) and the relationships between them are not obvious. Let me explain it the way I wish someone had explained it to me, with no jargon until it earns its place.

The one sentence version

IAM answers a single question for every request in your account: is this identity allowed to perform this action on this resource? Everything else is detail about how you express "this identity," "this action," and "this resource." Hold that sentence and the pieces fall into place.

The pieces, in plain terms

Identities (who is asking):

User: a person or a long-lived thing with its own credentials. You, logging in. A user is meant for a human or a fixed program.
Group: just a bucket of users so you can attach permissions to many people at once. "The Developers group." A group is a convenience, not an identity that acts.
Role: the one that confuses everyone, and the most important to understand. A role is a set of permissions that anything can temporarily assume. It has no permanent credentials. An EC2 instance, a Lambda function, or a user from another account can "put on" a role and get its permissions for a short time, then take it off. Think of a role as a costume anyone approved can wear, not a person.

Permissions (what they can do):

Policy: a JSON document that says Allow or Deny for specific actions on specific resources. Policies are where the actual permissions live. You attach policies to users, groups, or roles.

So the shape is: policies define permissions, and you attach them to identities (users, groups, roles).

Why roles are the part that clicks last

Beginners get users immediately and roles slowly, because "permissions nobody owns permanently, that things temporarily assume" is unusual. But roles are how AWS wants you to work, for a good reason: no long-lived credentials to leak.

Instead of giving your EC2 instance a stored access key (which can be stolen), you attach a role to the instance. The instance assumes the role and gets temporary credentials that rotate automatically. Same for Lambda, for cross-account access, for CI pipelines. If you find yourself creating a user and storing its keys somewhere for a machine to use, that is almost always a sign you should have used a role instead.

A tiny policy, decoded

Policies look scary and are actually simple once you see the structure:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

Read it as a sentence: Allow the action get an S3 object on the resource any object in my-bucket. That is it. Effect (Allow/Deny), Action (what), Resource (on what). Most policies are just longer lists of these.

The two rules that resolve most confusion

1. Explicit Deny always wins. If any policy that applies to you says Deny, you are denied, no matter how many Allows exist. This is why "I have admin but still get access denied" happens, some Deny higher up (an SCP, a boundary) overrode your Allow.

2. Deny by default. If nothing explicitly Allows an action, it is denied. You do not start with everything and remove; you start with nothing and grant. This is why a brand-new user can do almost nothing until you attach a policy.

How to not shoot yourself in the foot

Least privilege. Grant the specific actions needed, not *. It is annoying now and a relief forever. Broad permissions are how accounts become un-auditable.
Roles for machines, users for humans (and prefer SSO even for humans). Do not store access keys for services. Attach a role.
Use the policy simulator. Before you swear a permission is right, simulate it. AWS has a tool that tells you whether a given identity can do a given action, no guessing.
Groups for people, not roles. Put humans in groups and attach policies to the group, so onboarding is "add to group," not "copy someone's permissions."

The take

IAM is confusing because the words overlap, not because the idea is hard. It answers one question, is this identity allowed to do this action on this resource, using policies (the permissions) attached to identities (users for humans, roles for machines and temporary access, groups for convenience). Remember that explicit Deny wins and everything is denied by default, prefer roles over stored keys, and grant least privilege, and IAM stops being the wall you bounce off.

What part of IAM took longest to click for you? For most people it is roles, the "permissions nobody owns that things temporarily wear" idea that is unlike anything else until it suddenly makes sense.

Astra Solved 10 Decades-Old Problems on a Rounding Error of Compute. The Real Story Is the Cost Curve.

Muskan Bandta — Fri, 18 Sep 2026 06:43:47 +0000

Before GPT-6 Astra made headlines for finding zero-days, it did something quieter and, to me, more economically startling: it produced proofs for ten mathematics and theoretical computer science problems that had sat unsolved for decades, and it did it for a reported few thousand dollars of compute. Everyone focused on the math. I keep thinking about the invoice. Because the story that matters for anyone who budgets infrastructure is not "AI is smart now," it is what happens to planning when a unit of genuinely novel intellectual work drops to the price of a rounding error.

The number is the news

Decades-unsolved problems are, by definition, things that resisted a lot of expert human effort. The traditional cost of solving one is measured in careers, not dollars. Astra reportedly cleared ten for an amount of compute that would not survive a single line-item review on most cloud bills.

Set aside whether every proof holds up (that verification matters and is its own story). The direction is the point: the marginal cost of attempting hard, novel, high-value intellectual work is collapsing toward the cost of the compute to run the attempt. That is a different economic regime, and it breaks assumptions that FinOps and capacity planning are built on.

Why this is a cost-planning problem, not just an AI story

For years, expensive cognitive work was a fixed, scarce, human input you planned around. You could not "scale up" a research breakthrough by renting more of it. Now, increasingly, you can attempt to, by spending compute. That changes three things about how you budget:

Some work moves from headcount to a cloud line item. Tasks that used to be "hire an expert, wait a quarter" become "spend some compute, get an attempt back today." The cost does not disappear, it moves from payroll to your inference and GPU bill, where it behaves completely differently: usage-metered, spiky, and attributable only if you instrument it.
The temptation to over-attempt is real. When one attempt is cheap, teams run many. Cheap-per-attempt times a-lot-of-attempts is how a "rounding error" becomes a real number on the bill. This is Jevons paradox again: make something efficient and consumption rises to meet it.
The value per run is wildly variable. A $2,000 run that cracks a decades-old problem is the deal of the century. A $2,000 run that produces a plausible-looking wrong answer nobody verifies is $2,000 of waste dressed as progress. The cost is easy to see; the value is hard, and connecting them is the actual discipline.

The FinOps muscles this demands

None of this is exotic if you already do cloud cost work. It is the same muscles, pointed at a new kind of spend:

Attribute it. Which team, which project, which question generated this compute? Novel-work spend hides across invoices and shared keys exactly like early cloud spend did. If you cannot attribute it, you cannot manage it.
Cap the attempts. Budgets and rate limits per project, so "cheap per run" does not quietly become "expensive in aggregate" while everyone feels frugal.
Verify before you value. The run cost is the easy half. The hard half is checking whether the output is right and worth what it cost. A pile of unverified AI outputs is not an asset, it is a liability with a receipt.
Watch for runaway loops. An automated pipeline firing expensive runs on a loop is the new "forgot to turn off the GPU box," and it shows up as a spend anomaly before anyone notices. (Anomaly detection on this spend is the same instinct as anomaly detection on cloud cost, which is part of what ZopNight does, pointed at a new resource.)

The take

Astra solving ten decades-old problems cheaply is being read as a capability milestone, and it is one. But the more durable lesson for anyone who plans infrastructure spend is economic: the cost of attempting hard, novel work is collapsing toward compute, which means categories of work are migrating from headcount onto your cloud bill, where they behave like every other usage-metered cost, cheap per unit, dangerous in aggregate, and worthless unless you connect the spend to verified value. The teams that treat this like real FinOps, attribute, cap, verify, alert, will get the leverage. The teams that treat it as "it's only a few thousand dollars" will find out how fast a few thousand dollars, many times over, adds up.

Is your organization starting to spend real compute on open-ended, novel work yet? And if so, is that spend tracked as a real cost line with attribution, or is it still "it's just some API calls"? That gap is where I expect the next round of budget surprises.

How OpenAI Decided Astra Was Too Dangerous to Ship Open: Capability Thresholds, Explained

Muskan Bandta — Fri, 18 Sep 2026 06:43:37 +0000

When GPT-6 Astra shipped on September 3, the headline was that OpenAI rated it Critical for cybersecurity, the first time it has ever given a model that rating, and chose to gate the dangerous capability rather than release it openly. A lot of coverage treated "Critical" as a vibe. It is not. It is the output of a structured process for deciding when a model is too dangerous to ship as-is, and understanding that process is genuinely useful, because this kind of capability-gating is going to become normal and you will keep seeing these ratings. Here is how it actually works, in plain terms.

The core idea: capability thresholds, not just "is it safe"

The framework OpenAI and other labs use does not ask the vague question "is this model safe." It asks a sharper one: "does this model cross a defined capability threshold in a domain we consider dangerous." Cybersecurity is one such domain (others include things like bio and autonomy). Each domain has tiers, roughly escalating from low to high to critical, defined by what the model can do, not how it feels.

So "Critical for cybersecurity" is not a mood. It is a claim that the model crossed a specific, pre-defined capability line, in this case, the ability to autonomously find zero-day vulnerabilities in hardened systems and turn them into working exploits without human guidance. That is a bright-line capability, and the model reportedly cleared it.

Why the threshold triggers action, not just a label

The point of defining thresholds in advance is that crossing one is supposed to force a response, before the model ships, not after something goes wrong. That is exactly what played out with Astra:

An internal evaluation showed the model performing well enough at autonomous cyberattacks that OpenAI could not rule out having crossed its Critical threshold.
Crossing that line triggered a pause on parts of the work while the company strengthened isolation, internet controls, action monitoring, and alignment.
Development resumed after those mitigations, and the model shipped with the dangerous capability gated rather than open.

The sequence is the whole value of the framework: define the dangerous line ahead of time, evaluate against it honestly, and let crossing it mandate specific safeguards. Without pre-defined thresholds, "is it too dangerous" becomes a judgment call made under launch pressure, which is exactly when you do not want to be inventing the standard.

What "gated" means as a mitigation

Rating a capability Critical does not automatically mean "do not ship." It means "do not ship this capability openly." Astra's general intelligence is available; the zero-day capability ships behind split, controlled access. This is the framework working as intended: it separates the dangerous slice from the useful whole and applies controls proportional to the risk, rather than the blunt choice of ban-it-all or ship-it-all.

Why this matters even if you never touch model safety

You are not running these evaluations. So why care? Two reasons that are directly practical:

These ratings are becoming a signal you should read. When a model ships with a Critical cyber rating, that is public information about what capabilities now exist in the world, gated or not. It is an input to your own threat model. "A model that can autonomously find zero-days exists as of September 2026" is a planning fact, and the rating is how you learned it.
The pattern is coming to your own AI governance. The idea of defining capability thresholds in advance, evaluating against them, and gating what crosses the line is not just for frontier labs. Any organization deploying capable AI against real systems will eventually need its own version: what is this agent allowed to do, at what capability does it require human gating, what is the pre-defined line that changes the rules. The framework labs are using is a preview of the governance every AI-using company will need.

The take

"Critical for cybersecurity" is not a marketing adjective, it is the result of a defined process: name the dangerous capabilities in advance, set thresholds, evaluate honestly, and let crossing a line force specific safeguards, up to and including gating the capability away from open release. Astra is the first model to trip the cyber threshold, and watching how OpenAI handled it, pause, mitigate, resume, ship gated, is a preview of how capable-but-dangerous AI gets released from here. It is also a template for the governance your own organization will need the day it puts a capable model near anything that matters.

Does your organization have any pre-defined line for what an AI system is allowed to do before a human has to step in, or is it still decided case by case under pressure? That "we'll know it when we see it" gap is exactly what capability thresholds are meant to close.

AWS Compute Explained: EC2 vs ECS vs Fargate vs Lambda, and When to Use Which

Muskan Bandta — Thu, 17 Sep 2026 11:17:29 +0000

AWS has a confusing number of ways to run your code, and the names do not tell you how they relate. EC2, ECS, Fargate, Lambda, and more, all "compute," all overlapping. Beginners pick one semi-randomly and stick with it. Let me lay out what each actually is, how much of the work AWS does for you versus you, and a simple way to decide, so you choose on purpose instead of by habit.

The one axis that organizes all of them

Every compute option sits on a single spectrum: how much of the operational work do you do versus how much AWS does. More control means more responsibility; less responsibility means less control. That is the whole tradeoff.

From most-you-manage to least:

EC2: you get a virtual server

EC2 (Elastic Compute Cloud) gives you a virtual machine. You pick the size, the operating system, and you are responsible for the OS, patching, scaling, and what runs on it. It is the most flexible and the most work.

Use it when: you need full control of the environment, you are running something that expects a real server (legacy apps, specific OS tuning), or you want to manage the machine yourself.

The catch: you own the undifferentiated heavy lifting, patching, scaling, keeping it healthy. Powerful, but you are the sysadmin.

Containers: ECS and the Fargate question

Containers package your app with its dependencies so it runs the same everywhere. To run containers on AWS you need two decisions: an orchestrator (what schedules and manages your containers) and a launch type (what the containers actually run on).

ECS (Elastic Container Service) is the orchestrator. It decides where your containers run, restarts them if they die, and scales them. But ECS still needs something to run the containers on, and that is where the two launch types come in:

ECS on EC2: your containers run on EC2 instances that you manage. You still own the servers under the containers.
ECS on Fargate: you do not manage any servers at all. You hand AWS a container and say "run this," and Fargate provisions the compute invisibly. No instances to patch or scale.

So Fargate is not a separate orchestrator, it is a serverless way to run containers. ECS (or EKS, the Kubernetes version) is the brain; Fargate is the "no servers to manage" launch option under it.

Use containers when: you want portability and consistent deploys, and you are running services (APIs, workers) that stay up. Choose Fargate over EC2 launch type unless you have a specific reason to manage the underlying instances (cost tuning at scale, special hardware).

Lambda: you give AWS a function

Lambda is the far end of the spectrum: you upload a function, and AWS runs it in response to an event (an HTTP request, a file upload, a queue message). No servers, no containers to manage, no capacity to plan. You pay per invocation and per millisecond of run time, and when nothing calls it, you pay nothing.

Use it when: your workload is event-driven, bursty, or intermittent, individual tasks are short, and you do not want to run anything 24/7. Great for glue code, webhooks, scheduled jobs, and light APIs.

The catch: cold starts (the first call after idle waits for the function to spin up), execution time limits, and it is a poor fit for long-running or steady heavy workloads (where always-on compute is cheaper).

A decision shortcut

Ask these in order:

Is it event-driven, short, and intermittent? Lambda. Do not run a server for something that fires a few times an hour.
Is it a long-running service you want portable and easy to deploy? Containers on ECS/EKS, and use Fargate so you do not manage servers, unless you have a reason to.
Do you need full control of the machine, a specific OS, or are you running something that expects a real server? EC2.
Not sure and want the least operational burden? Start serverless (Lambda for functions, Fargate for containers) and move toward EC2 only if you hit a wall or a cost crossover.

The cost angle in one line

Roughly: Lambda is cheapest for spiky, low-volume work (you pay only when it runs); containers on Fargate are a sweet spot for steady services without server management; EC2 becomes cheapest per unit at large, steady scale if you manage it well (rightsizing, commitments). "Serverless is always cheaper" and "EC2 is always cheaper" are both wrong, it depends on the shape of the workload.

The take

AWS compute is one spectrum from "you manage the server" (EC2) to "you hand AWS a function" (Lambda), with containers (ECS/EKS, run on EC2 or serverless Fargate) in between. Pick based on the shape of your workload and how much operational work you want to own: event-driven and short means Lambda, steady portable services mean containers on Fargate, full control means EC2. Choose on purpose, and you get the right tradeoff instead of whatever you used last time.

Which compute option did you default to when you started, and did you later realize a different one fit better? A lot of people run everything on EC2 first, then discover half of it should have been Lambda or Fargate.

AI Assistants Can Now Drive Your Kubernetes Cluster. Here's the Ops Risk Nobody's Costing In

Muskan Bandta — Tue, 15 Sep 2026 12:10:09 +0000

Red Hat is building an open-source MCP server for Kubernetes and OpenShift, which lets AI assistants like VS Code, Copilot, and Cursor read and act on your clusters directly. This is genuinely useful, describing what you want in plain language and having the assistant translate it into cluster operations is a real productivity win. It also hands an AI assistant a path to your cluster's control plane, and most of the excitement I have seen skips straight past what that means operationally. As someone who worries about blast radius, let me lay out the risk and how to adopt this safely, because the tool is coming whether or not you plan for it.

What "AI can drive your cluster" actually means

An MCP server for Kubernetes exposes cluster operations as tools an AI assistant can call: list resources, read logs, describe deployments, and depending on how it is configured, create, scale, patch, and delete. The assistant reasons in natural language and calls those tools to get things done.

The productivity case is obvious: "why is this pod crashing" becomes a conversation instead of ten kubectl commands. The risk is the same door: an assistant that can kubectl apply and kubectl delete has the same power as an admin running those commands, and it is driven by a model interpreting fuzzy instructions and whatever text it reads along the way.

The three risks to actually plan for

1. Read versus write is everything. An assistant that can only read your cluster is low-risk and high-value: it triages, explains, and suggests, and a human executes. An assistant that can write to the cluster is a different risk class entirely, because now a misinterpreted instruction or a confidently wrong plan becomes a real change to production. The single most important decision is where you draw the read/write line, and the safe default is read-only until you have strong reasons and strong guardrails otherwise.

2. The cluster's own data is an injection surface. This is the part people miss. An assistant driving your cluster reads logs, resource names, annotations, and events to do its job, and all of that is text that people and workloads can write. A crafted log line or a malicious annotation is now input to a system that can call cluster operations. It is the same prompt-injection problem that turns any credentialed agent into a liability: the assistant does not distinguish "instruction from my operator" from "text I read in a pod log." If it can write to the cluster, that injection surface has teeth.

3. RBAC is your real control, and it is probably too broad. Whatever the assistant can do is bounded by the Kubernetes RBAC of the identity it uses. If you point it at a service account with cluster-admin "to make it work," you have handed a language model cluster-admin. The whole safety story rests on scoping that RBAC tightly: least privilege, namespaced where possible, and no destructive verbs unless you have deliberately decided to allow them.

How to adopt it without getting burned

You do not have to choose between the productivity and the safety. In order:

Start read-only. Give the assistant a role that can get, list, and watch, and nothing that mutates. This captures most of the value (triage, explanation, debugging help) with almost none of the risk.
Scope RBAC tightly, per namespace. Do not use cluster-admin. Grant the specific verbs on the specific resources in the specific namespaces the assistant genuinely needs. This is the actual control, treat it as seriously as you would any admin credential.
Require human approval for writes. If you enable mutations, gate them: the assistant proposes the change, a human reviews and applies it. Plan then approve then execute, the same pattern that keeps any credentialed agent safe.
Audit everything. Log every operation the assistant performs, on separate infrastructure. When something goes wrong you need to reconstruct what it did, and "the assistant's own logs" are not a trustworthy record if the assistant is what misbehaved.
Stage rollouts of write access. If you must give it write access, do it in dev and staging first, watch how it behaves against real cluster data, and only then consider production, narrowly.

The take

AI assistants driving Kubernetes is a real productivity leap and a real expansion of who (or what) can change your cluster. The tool is arriving; the responsible move is to plan the guardrails before you enable it, not after an incident. Start read-only, scope RBAC tightly, gate writes behind a human, and audit independently. Do that and you get the debugging-as-a-conversation upside without handing a language model the keys to production. Skip it, and "the assistant deleted the wrong deployment" becomes a postmortem you could have avoided.

If you have wired an AI assistant to your cluster, did you give it write access, and if so, what guardrails did you put around it first? I would keep mine read-only for a long while before I trusted it with delete.