Beyond the Cloud ,From a Linux Terminal to Enterprise Cloud Architecture — and Finding Purpose Along the Way.

# Beyond the Cloud

From a Linux Terminal to Enterprise Cloud Architecture — and a Purpose I Never Planned.

---

I didn't become a Cloud Architect because I had a plan. I became one because I kept following my curiosity.

More than a decade ago, I was a graduate without a campus placement, trying to understand why a Linux command worked. Today, I design cloud platforms for large enterprises, mentor engineers around the world, and still find myself asking the question that started everything: how do things actually work?

The notifications arrive quietly, on ordinary evenings.

A comment under a post I wrote about Kubernetes: your explanation made this so much clearer. A note from an engineer several time zones away who read one of my articles. A review after a mentoring session: I finally have a roadmap.

None of these are dramatic. But I've come to treasure them, because each one means the same small, remarkable thing: something that once took me weeks of struggle to understand now costs a stranger a ten-minute read. Confusion I lived through, someone else gets to skip.

I'm Pooja Daga, a Cloud Architect specializing in AWS, Kubernetes, and platform engineering. My official work is designing enterprise AWS platforms — the accounts, networks, clusters, and guardrails that let large organizations build safely at scale. It is intricate, demanding work, and I love it. But those quiet notifications come from somewhere else entirely: a passion I never planned, sharing knowledge with engineers I may never meet. It began as a hobby, quietly became a habit, and somewhere along the way turned into a purpose.

People sometimes ask how the two fit together. The honest answer is that neither one followed a roadmap.

## The Machinery Underneath

In India, the campus placement arrives before graduation and functions as a public verdict on your worth. In 2012, my classmates had offers. I had a question with no answer: what now?

They were mostly headed toward application development — Java, PHP, .NET — the safe path. What pulled at me was harder to explain. I wanted to understand the machinery underneath the applications: what a server was actually doing, how an operating system made decisions, how a packet found its way across a network.

That pulled me to Red Hat Linux training in Jaipur, my hometown in northern India. There were weeks when I attended those Linux classes more faithfully than my college lectures. Where most people saw an intimidating black terminal, I saw a magic trick being explained, one command at a time.

There was no strategy in any of it. Cloud computing wasn't yet part of my world. But Linux taught me how systems think — processes, memory, networking, permissions — and that layer beneath the tools changes very slowly. Understand it, and you are never truly starting from zero again.

## Riding the Waves

My career has really been a sequence of waves: virtualization, cloud, DevOps, containers, Kubernetes, platform engineering — and now AI, larger than any of them. A career in infrastructure is a decision, made over and over, about what to do when the next wave appears.

The first threat to that career wasn't fear. It was comfort. A few years into my work as a Linux administrator, I had become good at my job, and my job had become quiet. I wasn't struggling anymore, and because I wasn't struggling, I wasn't growing. Comfort is deceptive that way: it wears the costume of achievement, and nobody warns you that the reward for mastering your environment is that it stops teaching you.

After months of rejected interviews elsewhere, I made the bigger choice: I left the familiar behind and moved to Bengaluru, India's technology capital, where I knew almost no one. The move gave me more than opportunities — it gave me proof that I could land somewhere unfamiliar and figure it out.

The defining wave came later. I was working on automation and traditional data centers when talk of a new AWS initiative began moving through the organization — and with it, noise: debates, politics, predictions of failure. I heard a door opening. While the debate continued, I studied, prepared, put my hand up, and interviewed for the AWS team. I got in.

That decision became the hinge of my career. Looking back, I've noticed the same pattern with every major technology shift: the engineers who benefit most are rarely the ones who predict the future perfectly. They're the ones willing to become beginners again while everyone else is still debating whether the change is real.

Inside AWS, I didn't try to learn everything at once. I learned fundamentals and delivered what was in front of me, slightly better each day. Basic Terraform provisioning grew into reusable modules, then multi-environment architectures, then standards. There was no breakthrough moment. Consistency matters far more than intensity: we overestimate what we can learn in three weeks and underestimate what we can build in three years.

## What Architecture Actually Is

From the outside, architecture looks like drawing diagrams. From the inside, it is the discipline of trade-offs.

I learned this the way many architects do — through failure. One incident began with a routing change so small and carefully planned it barely seemed worth discussing. Within minutes, applications across the platform went dark. Alerts flooded in, a call filled with teams that had never needed to speak to each other before, and hours disappeared into tracing a blast radius wildly out of proportion to the change that caused it. That day rewired how I thought about architecture: no technical decision exists in isolation. Every change has dependencies, and every dependency has consequences. Validation, impact analysis, and rollback planning stopped being checklist items and became habits.

It also taught me where real confidence comes from. Not from systems that work — from being part of the calm group at 2 a.m. when they don't. Architecture, I came to understand, isn't only designing systems for the day everything works. It is deeply understanding what happens on the day everything doesn't.

Over time, the questions I was asked changed. They were no longer just about how to build or automate something, but why one design was better than another. The conversations shifted toward balancing security with speed, cost with resilience, and technical elegance with operational reality. I realized architecture isn't about finding perfect answers; it's about making informed trade-offs.

When a senior architect moved on, I took on a significant share of our AWS responsibility. It would be easy to call that luck, but responsibility is rarely handed over overnight. Every production incident, migration, proof-of-concept, and design review had built trust long before that opportunity arrived.

Today I help lead enterprise AWS initiatives — from multi-account platforms and Amazon EKS environments to large-scale modernization programs. My work spans architecture, proof-of-concepts, implementation, troubleshooting, and technical decision-making. On one day I might be evaluating a new AWS capability. On another, designing infrastructure with Terraform, debugging a production issue, or helping the team balance scalability, security, reliability, and cost. I enjoy that balance because it keeps me close to both the technology and the people building it.

And I can trace every part of that work back through a single unbroken chain: architecture rests on cloud engineering, cloud engineering rests on automation, and automation rests on the Linux fundamentals I learned years ago in a classroom in Jaipur, when I was simply a graduate nobody had hired yet. Nothing was wasted. It just wasn't clear what anything was for until much later.

Even today, there are production incidents that humble me and technologies that remind me how much I don't know. Experience hasn't removed uncertainty from my career. It has simply taught me not to fear it.

## The Purpose I Never Planned

It began with one LinkedIn post.

I wasn't building a brand. I remembered my early years of searching blogs, documentation, and forums late into the night, trying to connect dots that nobody had connected for me, and I wanted to write the article I wished I had found back then. So I did. Then I wrote another. Along the way I discovered I enjoyed translating complex cloud and Kubernetes concepts into explanations that felt practical rather than intimidating. One post became many.

Then strangers started arriving — questions about AWS, confusion about Kubernetes, engineers wondering whether it was too late to move into cloud. The posts grew into Medium articles, the questions into mentoring sessions on Topmate, and the occasional technical notes into a community of cloud and DevOps engineers learning alongside me — a community I never set out to create. Somewhere in all those conversations, I learned the most important thing I know about my industry. The biggest barrier for most engineers isn't technical. It's belief.

People assume the gap between where they are and where they want to be is made of knowledge. Far more often, it's made of doubt — the quiet belief that they don't belong. I recognize that feeling immediately, because I carried it myself.

A mentor doesn't just answer technical questions. They help people believe they're capable of answering them on their own.

Teaching returns the favor: knowledge is the only asset I know of that multiplies when you give it away. I have spent years designing cloud platforms for enterprise environments, and none of that work has made me prouder than those small notes — because they are not evidence of my success. They are evidence of someone else's progress.

## The Wave Arriving Now

Every decade has its defining technology shift. For me, today, it's AI. It reminds me of cloud computing a decade ago: excitement, skepticism, endless predictions, and a lot of noise. What interests me isn't the hype. It's the chance to be a student again — the same pull I felt in front of a blinking Linux cursor in 2012.

Engineers often ask whether AI will replace them. I think it does the opposite of what many fear: it raises the value of fundamentals. When code and infrastructure can be generated in seconds, the scarce skill becomes judgment — knowing whether what was generated is secure, scalable, reliable, and appropriate for production. That judgment is built on Linux, networking, security, distributed systems, and cloud architecture. The foundations I started building back then haven't become less valuable. They've become more valuable.

That's why I still spend part of almost every week learning something new — an AWS capability, an EKS feature, a Terraform pattern I want to test before writing about it, and lately, AI tools. I get excited every time I discover something I didn't know the day before. All these years later, curiosity remains my favorite skill.

## The Room and the Table

Early in my career, I questioned myself more harshly than anyone else ever did — was I experienced enough, ready enough, deep enough to belong in the rooms where architecture decisions are made? What settled those questions was not reassurance. It was accumulation: incidents resolved, migrations delivered, designs defended, trust earned decision by decision. The technical ownership I hold today was not granted. It was built, the same way everything else was.

I don't measure my career by who else is at the table; I measure it by what I contribute once I'm there. But visibility travels farther than we think. Somewhere, there is a woman working in infrastructure, cloud, or software engineering, wondering whether cloud architecture, platform engineering, or AI are careers she can pursue. I hope my journey reminds her that every expert starts somewhere — I certainly did. And I hope more women claim these fields, not as exceptions but as a matter of course, because the technology that will power everyone's future should be shaped by every kind of mind that has to live in it.

## What Remains

Twelve years in, I know exactly what will not last. Every platform I have built will one day be rebuilt by someone else — redesigned, migrated, eventually decommissioned. Titles change. Certifications expire. Technologies keep dissolving into whatever comes next.

What remains is harder to see — fittingly, since I have spent my career on the invisible side of technology. It is a way of moving through a changing field: staying curious, staying consistent, giving knowledge away. And it is the engineers, some of them women who once doubted they belonged near an architecture diagram, who now design systems, mentor others, and pass their understanding along.

I set out to build cloud platforms, and I did. But the work I'll be remembered for wasn't in any job description: platforms carry applications, and people carry each other.

Whatever you're building right now — don't stop with the systems. Build yourself. Then build someone else.

---

Pooja Daga is a Cloud & DevOps Architect specializing in AWS, Kubernetes, and platform engineering. She writes about cloud and DevOps on LinkedIn and Medium, and mentors engineers through Topmate.