DEV Community: Munagala Karthik

OCI Service Limits, What You Need to Know Before You Start Building

Munagala Karthik — Sun, 26 Apr 2026 16:25:55 +0000

Have you ever been surprised by cloud limits in the middle of a deployment?
One thing I didn't expect when working on OCI was how limit-aware you need to be.
Coming from AWS where most things just work within generous defaults, OCI taught me to plan differently.
Need more than 2 identity domains? You'll need to upgrade your account and submit a request. Need more VM capacity? Same process; submit and wait for approval.
It's not a bad thing honestly. It just means you need to think ahead.
In AWS I never thought about limits until I hit them. In OCI I learned to check limits before I even start building.
Every resource has a ceiling. And raising that ceiling requires a conversation with Oracle first.
Once I changed my mindset from "just deploy and figure it out" to "plan your limits before you start", working in OCI became much smoother.
OCI is powerful. But it rewards engineers who plan ahead, not those who move fast and fix later.
Know your limits before your deployment does.

Why Your AI Prompts Are Getting Generic Answers (And How to Fix It)

Munagala Karthik — Thu, 23 Apr 2026 13:23:19 +0000

Most engineers treat AI like a search engine.
Type a question; hope for a good answer; get frustrated when it's generic.
That's not how it works.
AI responds to context. The more specific you are, the better the output. Think of it like briefing a new team member who knows everything, but has no idea about your environment.
Here is what changed my results completely.
Give it a role; "You are a cloud security engineer working on AWS" instantly shifts the tone and depth of the response.
Give it context; mention the service, the environment, the constraint. "Write an IAM policy for a Lambda function that only reads from one S3 bucket" beats "write an IAM policy" every single time.
Give it a format; tell it exactly what you want back, a policy document, a checklist, a Terraform block. Be specific.
Tell it what to avoid; "no broad permissions, no wildcards, follow least privilege" saves you from cleaning up a messy output.
I now use this for IAM policies, security checklists, Terraform reviews, incident response drafts and boto3 scripts.
Same AI, better prompts, completely different results.
Prompt engineering is not a skill for AI people. It is a skill for anyone who wants to stop wasting time.

I Gave a Service Account Full Admin Access, Here's What Happened Next

Munagala Karthik — Sun, 19 Apr 2026 15:54:53 +0000

I gave a service account full admin access once.
Just to get things working quickly. I told myself I'd restrict it later.
Later never came.
Three months passed. That service account was still sitting there with more permissions than it needed. Quietly. Invisibly. A ticking time box nobody was watching.
This is how most cloud environments get messy. Not from big mistakes. From small shortcuts that never get cleaned up.
The "I'll fix it later" culture in cloud security is more dangerous than any misconfiguration.
Because later feels responsible in the moment. You acknowledged the problem. You just didn't solve it.
What actually helped me was treating every temporary fix like a bug. Log it. Track it. Set a deadline.
If it doesn't have a deadline it doesn't exist.
Don't let your shortcuts outlive your memory of why you made them.

CloudTrail Is Not Just a Log, It's Your AWS Security Camera

Munagala Karthik — Wed, 15 Apr 2026 03:26:45 +0000

Nobody told me AWS CloudTrail was this important until something went wrong.
An unexpected API call showed up in our environment. No one on the team claimed it.
That one moment changed how I think about cloud monitoring forever.
Before that I treated CloudTrail like a checkbox. Enabled it because best practices said so. Never actually looked at the logs.
After that I started treating it like a security camera. Always on. Always watching. And you better know how to read what it's recording.
The fix wasn't complicated. Set up proper log filtering. Created alerts for suspicious API calls. Made it a habit to review weekly.
But the lesson hit hard.
Enabling a security tool is not the same as using it. Most breaches don't happen because the tool wasn't there. They happen because nobody was watching.
Turn it on. Then actually look at it.

Vibe Coders

Munagala Karthik — Sun, 12 Apr 2026 06:45:59 +0000

Vibe coding is fun until it isn't.
You're flying through features. AI is writing everything. It feels like a superpower.
Then you hit the context limit.
The model forgets what it built. Starts contradicting itself. Code breaks in ways that make no sense. And suddenly you're spending more time fixing AI mistakes than you would have spent just writing it yourself.
I've been there.
The problem isn't vibe coding itself. The problem is depending on it completely.
If you don't understand what the code is doing you can't fix it when the AI loses the plot. And it will lose the plot.
Use it as a tool. Not a replacement for thinking.
Let AI handle the boilerplate. You handle the logic. You review every line. You stay in control.
The engineers who will win with AI are not the ones who prompt the best. They're the ones who know enough to catch when the AI is wrong.
Don't outsource your understanding. That's the one thing AI can't give back to you.

DevOps #CloudSecurity

Things kept breaking in my OCI lab… until I fixed IAM

Munagala Karthik — Wed, 08 Apr 2026 12:35:03 +0000

Things kept breaking, and it wasn’t because I wrote bad code.

It was IAM.
I was setting up a cloud lab in OCI and everything looked fine on the surface, instances, networking, policies.
But every time I tried to launch or manage resources, something failed.

Not loudly. Just enough to slow everything down.
At first, I assumed it was a config issue.

So I kept switching between tasks, checking networking, then compute, then scripts.

That made it worse.
I wasn’t losing time… I was losing context.

What finally worked was slowing down and tracing the failure properly.
I started reading the exact error messages and mapping them back to IAM policies.
That’s when I finally saw it.

A small missing permission:
Allow group to read instance-images in tenancy
Once I added it, everything started working instantly.
No changes to code. No changes to architecture.
Just IAM.
Nothing else changed.

The biggest lesson?
Most cloud failures aren’t about what you built, they’re about what you forgot to allow.

If something feels randomly broken in the cloud, start with IAM first.