DEV Community: Mrutyunjay

My AWS Certification Journey: From Serverless Projects to 12 Active Certifications

Mrutyunjay — Thu, 17 Sep 2026 14:19:55 +0000

How client work, structured learning, hands-on practice, and a few uncomfortable challenges helped me earn all 12 active AWS certifications, along with the now-retired Database Specialty.

In early 2016, I started working with AWS through Lambda, API Gateway, DynamoDB, serverless architectures, and CI/CD pipelines. I learned primarily by building solutions for clients and customers across different domains and use cases.

AWS was not something I opened only while studying. It became part of my everyday working life: designing an API, deciding where a workload should run, investigating a deployment problem, thinking about permissions, or explaining a cloud trade-off to a customer. That daily exposure gave the services context that no list of flashcards could provide.

Over time, I added structure to that experience through AWS certifications, focused reading, courses, and hands-on practice. The result is 12 currently active AWS certifications, plus the AWS Certified Database - Specialty, which has since been retired.

This is the timeline of that journey.

The Timeline

2020: Finally taking the first step

AWS Certified Solutions Architect - Associate

SAA-C02 | June 2020

I had already been working with AWS for four or five years, but I kept postponing the exam because I felt I was not ready. Eventually, I decided to take it anyway and passed.

There was a slightly uncomfortable gap between how much AWS I used at work and how ready I felt for an exam. I could discuss architectures and solve day-to-day problems, but the exam still felt like an official judgement of whether I knew enough. Passing it showed me that the experience was already there; I mainly needed to organise it and trust it.

That first certification was an important lesson: practical experience matters, but waiting until you feel completely ready can become its own form of procrastination.

2021: Building the foundation

AWS Certified Cloud Practitioner

CLF-C01 | June 2021

This was the only certification in the journey that I took after the Solutions Architect - Associate. By then, I had more AWS project experience and a clearer understanding of how the different parts of the platform fit together.

2022: Stretching beyond architecture

I wanted to test myself across the full lifecycle of building and operating cloud applications. I took two Associate exams on the same day, back to back.

AWS Certified Developer - Associate

DVA-C01 | February 2022

AWS Certified SysOps Administrator - Associate

SOA-C02 | February 2022

The SysOps exam was especially memorable because it included a live lab exercise. Instead of answering only multiple-choice questions, I had to work directly in an AWS environment and complete practical tasks. It was a unique and enjoyable experience, and the only exam in this journey that included a similar hands-on lab assessment.

Later that year, I made my first move into the Professional-level exams.

AWS Certified DevOps Engineer - Professional

DOP-C01 | May 2022

Working with AWS CI/CD pipelines and delivering software for customers gave me a strong practical foundation for this exam. The certification also pushed me to think beyond individual services and focus on delivery, reliability, automation, and operations as a complete system.

In real projects, a pipeline is never just a pipeline. It is also about permissions, artifact handling, deployment strategy, rollback, observability, and the point at which a change should be allowed into production. Seeing those concerns repeatedly in customer work made the exam scenarios feel less like isolated questions and more like familiar engineering decisions.

2023: Specialisation and deeper architecture

AWS Certified Database - Specialty

DBS-C01 | January 2023

I have always been fascinated by databases. Before AWS, I had worked with Oracle, IBM Db2, and MySQL. On AWS, I worked with RDS and Aurora from the early days, including experimenting with the first version of Aurora Serverless, which was not yet production-ready.

This was my first AWS Specialty certification. The certification has since been retired, but the knowledge remains useful.

AWS Certified Security - Specialty

SCS-C02 | October 2023

AWS Certified Solutions Architect - Professional

SAP-C02 | November 2023

I completed the Solutions Architect - Professional exam on a day when I was travelling internationally for a vacation. I received the result while on the flight, which made for a memorable end to that part of the journey.

It is not the most conventional place to receive an exam result, but it captured how this journey fitted around life and work. The certification was important, but it was not pursued in a vacuum. It sat alongside projects, deadlines, travel, and the ordinary interruptions that make long-term learning real.

2024: Data, machine learning, and AI

AWS Certified Machine Learning Engineer - Associate (Beta)

MLA-C01 | October 2024

AWS Certified AI Practitioner

AIF-C01 | October 2024

My interest in data and machine learning naturally led me towards these certifications. Taking a beta exam also meant learning from a new blueprint and being comfortable with some uncertainty in the exam experience.

2025: Connecting data engineering to the cloud

AWS Certified Data Engineer - Associate

DEA-C01 | March 2025

This certification brought together several areas I had been working towards: data stores, data processing, governance, security, monitoring, and designing reliable data pipelines on AWS.

2026: Generative AI, renewal, and a networking challenge

AWS Certified Generative AI Developer - Professional (Beta)

AIP-C01 | March 2026

This was almost three and a half hours of intense concentration. My experience with Amazon Bedrock and Retrieval-Augmented Generation helped me relate many of the exam scenarios to real use cases. Those practical connections made the exam challenging, but approachable.

AWS Certified Solutions Architect - Associate

SAA-C03 | April 2026

In the meantime, my original Solutions Architect - Associate certification had expired, so I took the current version again. Renewal was a useful reminder that certifications are not only milestones; they are also a reason to revisit fundamentals and keep them current.

AWS Certified Advanced Networking - Specialty

ANS-C01 | May 2026

Networking was the area I had consciously avoided because I had not had as many opportunities to work deeply in it. Eventually, I decided to challenge myself.

I did not clear my first attempt, possibly missing by only one question or one option. Then work became busy, and I saw the announcement that the exam was scheduled to be retired on 25 August. I took it again the day before the announced deadline and passed. AWS later extended the exam availability until December 2026, but by then my result was already in.

That experience was a useful counterweight to the successful first attempts. A failed exam does not always mean that the whole approach is wrong. Sometimes it points to a narrow gap, a weak area, or the need to become more comfortable with the way questions are framed. The second attempt was less about starting over and more about closing that specific gap.

What Actually Helped

The early certifications were based heavily on experience gained through project work across customers, industries, and use cases. That experience gave me context for the services and architecture patterns that appeared in the exams.

Working on AWS day in and day out creates a library of mental examples. A question about an asynchronous integration can connect to a real Lambda workflow. A question about deployment safety can bring back a pipeline decision. A question about database scaling can connect to a production conversation about read replicas, caching, or Aurora. The details vary, but the underlying decision patterns repeat.

Structured learning helped me organise that experience. I used AWS documentation, Stephen Marek's courses, and other Udemy courses depending on the topic and the exam.

For the later certifications, especially data engineering, machine learning, and generative AI, I relied more on a combination of structured reading, scenario-based learning, and hands-on work. When a concept was unclear, I used Google Search and Google Chat to gather explanations and related scenarios instead of trying to navigate the enormous AWS documentation landscape for every question.

That approach supplemented, rather than replaced, the official material. I still validated concepts by using the services and tools directly. Reading about a feature helped me recognise it; building with it helped me understand it.

The correlation between study and real work also made recall faster. Instead of memorising that a service had a particular feature, I could attach the concept to a scenario: a customer constraint, a design trade-off, a deployment failure, or a small experiment I had run myself. Those associations gave the information somewhere to live.

Hands-on work was especially useful when a topic felt abstract. Creating a small proof of concept, checking how a service behaved, or tracing a request through several AWS components often answered a question more clearly than another hour of passive reading. The goal was not to reproduce an entire customer system at home. It was to isolate one idea and make it observable.

The most effective loop for me was:

Project experience -> Structured study -> Scenario-based questions -> Hands-on practice -> Exam

Each part strengthened the others. Client work made the material concrete. Study exposed gaps in my understanding. Practice questions showed me how concepts were tested. Hands-on work made the answers easier to remember.

That is why I do not see work experience and certification preparation as separate tracks. Work gives the concepts texture; study gives them structure. When the two are connected, learning becomes quicker, recall becomes more reliable, and the exam preparation feels much closer to the engineering problems I actually enjoy solving.

The Bigger Lesson

I did not earn these certifications by following a perfect plan. I postponed the first exam, took two exams back to back, attempted a difficult Specialty twice, and kept learning as my work changed from serverless applications to databases, security, data engineering, machine learning, and generative AI.

The certifications gave structure to a decade of learning. The project work gave that structure meaning.

My advice to anyone considering an AWS certification is simple: use your real work as the foundation, add enough structure to expose what you do not know, and take the exam before waiting for perfect confidence.

What has helped you most when preparing for cloud certifications: project experience, structured study, or hands-on practice?

Building a Local-First Agent Platform with Strands, Ollama, and an MCP Gateway

Mrutyunjay — Mon, 14 Sep 2026 08:22:36 +0000

Most agent demos start with one model, one prompt, and a handful of functions in the same process. That is a useful place to start, but it becomes difficult to evolve once the application needs multiple domains, multiple agent behaviors, and tools that should be owned independently.

I wanted to build something closer to a small platform than a single chatbot: a local-first application where an agent can use travel, finance, and entertainment capabilities without knowing how those capabilities are implemented or where they run.

The result is a Python application built with:

Strands Agents for agent orchestration
Ollama for a local language model
Model Context Protocol (MCP) for the tool contract
FastMCP for the gateway and domain servers
FastAPI for the backend API
Streamlit for a lightweight chat interface
mise and uv for reproducible local setup

The important design choice is the MCP gateway. The agent talks to one MCP endpoint, while the gateway composes several focused domain servers behind it.

The Problem

A first version of an agent application often looks like this:

User -> Chat UI -> Agent -> Every tool in the application

That shape has a few problems:

The agent client becomes coupled to every tool server. Adding a new domain means changing the client configuration or orchestration code.
Tool ownership becomes unclear. Travel, finance, and entertainment concerns end up mixed together.
Independent deployment is harder. A failure or restart in one domain can affect the whole tool surface.
The system is difficult to inspect. There is no single place to ask which downstream services are healthy.
Agent behavior and domain capabilities get tangled. Changing an agent's tone or workflow should not require changing the tool implementation.

The underlying problem was not simply "how do I call an LLM?" It was how to create clean boundaries around an agent that needs to use capabilities from several domains.

The Design Goal

I set three constraints for the design:

The model should run locally during development.
The agent should have one stable tool endpoint.
Each domain should expose a small, independently owned MCP server.

That led to this architecture:

flowchart LR
    UI[Streamlit UI] --> API[FastAPI backend]
    API --> A[Strands agent]
    A --> G[MCP gateway]
    G --> T[Travel MCP server]
    G --> F[Finance MCP server]
    G --> E[Entertainment MCP server]
    T --> TT[Travel tools]
    F --> FT[Finance tools]
    E --> ET[Entertainment tools]

The UI and backend have a straightforward responsibility: accept a conversation and return an answer. The agent decides whether tools are needed. The gateway hides the topology of the domain servers from the agent runtime.

What I Built

1. A registry of agent behaviors

Agent definitions live as flat modules under src/agents/. Each definition describes an agent identity, system prompt, and skills. The registry is the single source of truth:

_AGENT_REGISTRY: dict[str, AgentDefinition] = {
    DEFAULT_AGENT.agent_id: DEFAULT_AGENT,
    RESEARCH_AGENT.agent_id: RESEARCH_AGENT,
    SUPPORT_AGENT.agent_id: SUPPORT_AGENT,
    TRAVEL_ITINERARY_AGENT.agent_id: TRAVEL_ITINERARY_AGENT,
    FINANCE_TRACKER_AGENT.agent_id: FINANCE_TRACKER_AGENT,
    ENTERTAINMENT_SCOUT_AGENT.agent_id: ENTERTAINMENT_SCOUT_AGENT,
}

This separates how the agent should behave from which tools exist.

The backend exposes the available profiles through GET /api/agents, and the chat endpoint accepts an agent_id. That makes it possible to add a research-focused agent or a travel-planning agent without duplicating the MCP connection logic.

2. One MCP client surface for the agent

The orchestrator connects to the configured MCP endpoint, discovers its tools, and gives the discovered tool list to Strands:

with create_mcp_client() as mcp_client:
    tools = mcp_client.list_tools_sync()
    agent = build_agent(tools, agent_id=agent_id)
    result = agent(prompt)

The orchestrator does not need to know whether a tool belongs to travel or finance. It only needs the MCP contract.

The MCP URL is normalized before connecting so streamable HTTP endpoints do not introduce avoidable redirect failures. This is a small detail, but transport details like this matter when local services are composed together.

3. A config-driven MCP gateway

The gateway loads its downstream routes from src/mcp/gateway/routes.json:

{
  "routes": [
    {
      "name": "travel",
      "url": "http://127.0.0.1:8001/mcp",
      "envVar": "TRAVEL_MCP_SERVER_URL"
    }
  ]
}

At startup, each route is mounted as a proxy namespace. A new downstream server can therefore be introduced by adding route configuration and implementing its own MCP server, without rewriting the agent client.

The route loader also supports environment-variable overrides and a complete configuration-path override through MCP_GATEWAY_ROUTES_CONFIG. That keeps local defaults convenient while leaving room for another environment to provide different service locations.

4. Focused domain servers

Each domain server owns only its own tools:

Travel: geocoding, weather, place search, route distance, and Wikipedia summaries
Finance: foreign exchange rates, historical rates, stock quotes, and crypto markets
Entertainment: local events and movie search

The gateway composes these servers, but it does not absorb their domain logic. This keeps the boundaries useful: domain changes stay in the domain server, while gateway changes stay focused on composition and operations.

5. Health visibility through the gateway

The gateway exposes a gateway_health tool and the backend exposes GET /api/mcp-health. The health response includes the overall gateway status and the status of each downstream server.

That gives the application an operational view like this:

{
  "gateway": "MCP Gateway",
  "overall_status": "ok",
  "downstream": {
    "travel": {"status": "ok"},
    "finance": {"status": "ok"},
    "entertainment": {"status": "ok"}
  }
}

A tool gateway should not be treated as a black box. If the agent cannot use a tool, the first question should be whether the downstream server is available and advertising the expected tools.

A Request Through the System

A chat request travels through the application like this:

sequenceDiagram
    participant U as User
    participant UI as Streamlit UI
    participant API as FastAPI
    participant A as Agent orchestrator
    participant G as MCP gateway
    participant D as Domain MCP server

    U->>UI: Ask a question
    UI->>API: POST /api/chat
    API->>A: Build conversation prompt
    A->>G: Discover and call tools
    G->>D: Proxy the domain tool call
    D-->>G: Return structured result
    G-->>A: Return tool result
    A-->>API: Generate final answer
    API-->>UI: Return response JSON

For example, a question such as:

What is the weather in Sydney, and how far is it from the airport?

can be handled by the travel tool group without the UI knowing which server provides geocoding, weather, or route calculations.

Why Keep the Model Local?

The project uses Ollama during development, with the model and host configured through environment variables:

OLLAMA_MODEL=qwen3.5:4b
OLLAMA_HOST=http://127.0.0.1:11434
MCP_SERVER_URL=http://127.0.0.1:8000/mcp

A local model makes experimentation cheaper and keeps the basic development loop independent of a hosted inference provider. It also makes the architecture easier to test: the agent, gateway, and domain servers can be run on one machine with explicit local boundaries.

This does not mean a local model is always the right production choice. The orchestration layer is intentionally separate from the model implementation, so the model can change without changing the MCP architecture.

Running It Locally

The project uses mise to manage the toolchain and uv for dependencies.

mise install
mise run sync
cp .env.example .env

Start the domain servers first, then the integrated API and UI:

mise run mcp-travel
mise run mcp-finance
mise run mcp-entertainment
mise run api
mise run ui

The main endpoints are:

Streamlit UI: the local Streamlit URL printed by mise run ui
Chat API: POST /api/chat
Agent catalog: GET /api/agents
API health: GET /api/health
MCP health: GET /api/mcp-health
MCP gateway: /mcp

The repository also includes tests for conversation prompt construction, agent skill composition, and invalid agent selection.

Design Tradeoffs

Why a gateway instead of connecting to every server directly?

A direct multi-client design can be simpler at very small scale. The gateway becomes valuable when the number of domain servers grows or when the agent runtime should have one stable connection point.

The tradeoff is an additional network hop and another component to operate. In this project, the gateway earns its place by providing composition, namespaces, route configuration, and downstream health checks in one location.

Why flat agent modules instead of a large class hierarchy?

The agent profiles are mostly configuration and prompt behavior. Flat modules make each profile easy to locate and review. The registry provides explicit discovery without adding inheritance or lifecycle complexity.

Why Streamlit for the UI?

The goal was to validate the architecture and interaction loop, not to build a full product frontend. Streamlit provides a usable chat surface quickly while keeping the backend contract visible and testable.

What I Learned

The most useful lesson was that agent architecture is largely about boundaries.

The model is only one part of the system. The more durable decisions were:

giving agents a stable capability surface
separating agent behavior from domain tools
keeping each MCP server focused
making service locations configurable
exposing health information where composition happens

MCP is useful here not because it makes every tool intelligent, but because it gives tools a common interface that the agent runtime can discover and use.

What I Would Build Next

The current implementation is a foundation. The next improvements would be:

streaming agent responses through the API and UI
richer tool metadata and request tracing
authentication and authorization at the gateway
contract tests for every downstream MCP server
retries and timeouts per route
persistent conversation storage
production model adapters alongside the local Ollama adapter

The core shape would stay the same: specialized agents, focused domain servers, and one observable MCP gateway between them.

Closing Thoughts

The project started as a question about building a useful local agent. It became a question about how to let an agent grow without turning the entire application into one tightly coupled tool registry.

The answer was to put the boundary in the right place:

User experience -> API -> Agent -> MCP gateway -> Domain servers

That structure keeps the system understandable today and gives it a path to evolve tomorrow.

The complete project is available on GitHub, including the setup commands, route configuration, agent registry, MCP servers, and tests.