Applying for an attachment at Safaricom was almost a side quest. I was so nervous going in, with imposter syndrome (I have it even more rn as I'm waiting for the next steps). I had been grinding arrays, trees, and dynamic programming for weeks. None of that came.

There were 2 tasks, and task 2 was about the "Elasticsearch Search API."

I paused. Then I smiled. Elasticsearch had been on my learning track for a while. Funny how that works.

All tests passed. 100%.

But this post isn't really about the test. It's about Elasticsearch. What it is, how it actually works, and why I think every developer building anything at scale should understand it.

What is Elasticsearch?

Elasticsearch is a distributed, open-source search and analytics engine built on top of Apache Lucene. It stores data as JSON documents and lets you search, analyze, and visualize it at scale — in near real-time.

It's the E in the ELK Stack (Elasticsearch, Logstash, Kibana).

Why Does Elasticsearch Even Exist?

Here's the problem it solves.

You have a blog. Thousands of posts. A user types "nairobi tech" in your search bar. The naive solution:

SELECT * FROM posts WHERE body LIKE '%nairobi%' OR body LIKE '%tech%';

That works. Until you have 10 million posts. Then it crawls. Then it times out. Then your users leave and never come back.

The issue isn't hardware. It's the approach. A relational database is optimised for retrieving exact records. It's not built for finding everything relevant to a phrase across millions of rows.

Elasticsearch solves this with an inverted index.

Think of the index at the back of a textbook. Instead of reading every page to find where "Nairobi" is mentioned, you flip to the index, and it tells you exactly which pages. Elasticsearch builds that index on your data automatically, keeps it updated in real time, and when you search, it doesn't scan. It looks up.

That's why it returns results in milliseconds even at massive scale.

The Inverted Index, Visualised

Here's what happens when you index three blog posts:

Search "nairobi tech" → hit the index → instantly know Post 1 and Post 2 are relevant. No scanning. No guessing. That's the entire trick.

Elasticsearch vs SQL

Before touching any code, lock this in:

The key difference: in SQL, you retrieve. In Elasticsearch, you search and rank. Results come back with a relevance score. Not just found or not found, but how well does this match?

Setting Up Locally

Fastest way to get running, one command:

curl -fsSL https://elastic.co/start-local | sh

This spins up Elasticsearch on port 9200 and Kibana on port 5601. Kibana is the UI that sits on top. Browse your data, build dashboards, and run queries visually. Start with raw HTTP requests first. Understanding what's happening underneath makes Kibana make sense.

Verify it's alive: (I used Postman)

GET http://localhost:9200

You'll get back cluster info. Remember to authenticate with your basic creds or API Key provided during set-up

Creating an Index (and Why Mappings Matter)

Creating an index is like defining a schema, except you're also telling Elasticsearch how to treat each field. This is the most important decision you'll make.

PUT /blog_posts
{
  "mappings": {
    "properties": {
      "title":        { "type": "text" },
      "body":         { "type": "text" },
      "author":       { "type": "keyword" },
      "tags":         { "type": "keyword" },
      "published_at": { "type": "date" },
      "views":        { "type": "integer" }
    }
  }
}

Two field types are doing completely different jobs:

text gets analysed before indexing. "Building Tech Communities in Nairobi" becomes ["building", "tech", "communities", "nairobi"]. This powers natural language search.

keyword is stored exactly as-is. No analysis. Used for exact matching, filtering, sorting, and aggregations.

If you map author as text when you meant keyword, filtering by exact author name won't work cleanly. And you can't change field types on an existing index without reindexing everything. Map it right the first time.

Now insert some documents to play with. Each POST to _doc creates one document with an auto-generated ID:

POST /blog_posts/_doc
{
  "title": "Building tech communities in Nairobi",
  "body": "The Nairobi tech ecosystem has grown significantly. Developer communities like GDG are driving this growth through events and mentorship.",
  "author": "Alex Nyambura",
  "tags": ["community", "nairobi", "devrel"],
  "published_at": "2025-03-01",
  "views": 340
}

POST /blog_posts/_doc
{
  "title": "Getting started with Kubernetes on GKE",
  "body": "Google Kubernetes Engine makes deploying containerized apps straightforward. This guide walks through setting up your first cluster.",
  "author": "Alex Nyambura",
  "tags": ["devops", "kubernetes", "gcp"],
  "published_at": "2025-04-15",
  "views": 820
}

POST /blog_posts/_doc
{
  "title": "ISP infrastructure in rural Kenya",
  "body": "Last-mile internet connectivity remains a challenge. Companies like Wakanet are bridging the gap in underserved regions.",
  "author": "Felix Jumason",
  "tags": ["infrastructure", "kenya", "internet"],
  "published_at": "2025-05-10",
  "views": 210
}

Confirm they're in:

GET /blog_posts/_count

You should see "count": 3. Now you have something real to search against.

Searching: The Three Patterns You'll Use Most

1. Full-text search with match:

GET /blog_posts/_search
{
  "query": {
    "match": {
      "body": "nairobi tech community"
    }
  }
}

match tokenizes your query the same way it tokenized the document at index time, then scores matches using BM25. Results come back ranked by relevance, highest first.

2. Search across multiple fields with multi_match:

GET /blog_posts/_search
{
  "query": {
    "multi_match": {
      "query": "kenya",
      "fields": ["title", "body", "tags"]
    }
  }
}

Real users don't know which field their keyword lives in. multi_match is what you actually want behind a search bar.

3. Combining conditions with bool:

GET /blog_posts/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "body": "kubernetes" } }
      ],
      "filter": [
        { "term": { "author": "Alex Nyambura" } },
        { "range": { "views": { "gte": 500 } } }
      ]
    }
  }
}

This is the pattern you'll use 80% of the time in production. must is for relevance and affects the score. filter is for hard conditions that don't affect scoring and is faster because Elasticsearch caches filters.

relevance goes in must, hard conditions go in filter.

Understanding Scores (BM25 in Plain English)

Every result has a _score. Three things push it up:

Term frequency: "Nairobi" appears 5 times in document A, once in document B. A wins.

Inverse document frequency: "Nairobi" only appears in 2 of 1000 documents, so it's a strong signal. "The" appears in all 1000, so searching for it tells you nothing. Common words carry low weight automatically.

Field length: "Primo Levi" in a 2-word author field is a stronger match than "Primo Levi" buried in a 500-word body.

Scores are only meaningful relative to each other within the same query. There's no fixed scale. A score of 1.9 in one query means nothing compared to 1.9 in a different query.

Pagination, Sorting, and Field Filtering

Return only the first 2 results:

{
  "size": 2,
  "from": 0,
  "query": { "match_all": {} }
}

size = how many to return. from = offset. Page 2 would be "from": 2. The total hit count always reflects the full match count, not just what's shown on the current page.

Sort by year descending:

{
  "sort": [{ "year": { "order": "desc" } }],
  "query": { "match_all": {} }
}

When you sort by a field, _score becomes null. There's no relevance calculation. You're ordering, not ranking.

Return only specific fields:

{
  "_source": ["author", "title"],
  "query": { "match_all": {} }
}

Never return entire documents when you only need two fields. Especially at scale.

What's Next From Here

If this sparked something:

• Fuzzy search: "fuzziness": "AUTO" and Elasticsearch handles typos automatically

• Aggregations: the analytics side. "Top 5 authors by post count", "views by month". SQL's GROUP BY but distributed and fast

• Analyzers: customise how text gets tokenized. Build autocomplete, handle edge cases

• Kibana: the UI that ships with Elasticsearch. Great for exploring data and visualising aggregations once you understand the raw query layer

One More Thing

I'm still in the middle of the Safaricom internship application process. There's more to that story and I'll write the full thing once it's wrapped up. The application process, what the assessment was actually like, what I'd tell someone going in cold.

For now, Elasticsearch isn't magic. It's a really smart index with a clean query API. Once that clicks, you'll start seeing use cases for it everywhere.

And if you're preparing for a technical assessment at any company that deals with large amounts of data, add it to your list. It came up for me. It might come up for you.

Let's connect on LinkedIn or check out more posts at blog.lxmwaniky.me. I write about cloud, Software, and building things in the Kenyan tech ecosystem.

If you missed the deep dives on the other two, check out my guides on How to Pass the Generative AI Leader Certification and the heavy-duty Professional Machine Learning Engineer (PMLE) audit.

Today, we go under the hood of the Associate Cloud Engineer (ACE).

The ACE is the "Mechanic’s Exam." It doesn't care about your high-level strategy or your AI vision. It cares if you know the exact gcloud command to resize a cluster or which specific role prevents a billing disaster. It is an audit of your operational intuition. Here is the detailed blueprint of how I cleared it.

1. The Core Pillar: Obsessing Over the "Hierarchy"

In the ACE exam, Google tests your ability to act as a gatekeeper. If you don't understand the Resource Hierarchy, you’ll get lost in the logic puzzles.

• The Blueprint: You have to visualize the cloud like a massive construction project.

  • Organization: The County Government (the domain).

  • Folders: The Estates (grouping projects by department or environment like Dev/Prod).

  • Projects: The specific Plot of Land. This is the base unit. Billing lives here.

  • Resources: The actual house (VMs, Buckets, GKE clusters).

• The Law of Inheritance: Policies flow down. You can never "deny" at a lower level what was "allowed" at a higher level. Google uses "Union" logic—if any level gives you access, you have it.

• Least Privilege is the Law: If a question asks how to give a developer access, and "Owner" is an option, it’s probably a distractor. Google wants you to pick a Predefined Role (like Compute Instance Admin). Avoid Primitive Roles at all costs.

2. The "Mechanic’s" Toolset: CLI vs. Console

You cannot pass this exam by just clicking buttons in the UI. You need to understand the Cloud SDK.

• The Syntax Trap: One of the easiest ways to spot a wrong answer is the command prefix.

  • gcloud is for almost everything (VMs, IAM, Projects).

  • gsutil is strictly for Cloud Storage (Buckets/Objects).

  • bq is strictly for BigQuery.

  • kubectl is for GKE.

• Scenario Logic: If an answer suggests using gsutil to create a VM, you can ignore it in one second. I spent my night shifts typing these out in the Cloud Shell to make the syntax second nature.

3. Networking: The "Final Boss" of the ACE

Networking is where most candidates fail. Google’s networking logic is unique, and the exam exploits that.

• VPC is Global: This is a major point of confusion for those coming from AWS. Your VPC spans the world.

• Subnets are Regional: You don't have global subnets. You have a subnet in us-central1 and another in europe-west1.

• Load Balancing Tiers:

  • Global (Layer 7): HTTP(S) Load Balancing. Use this if you need to route based on the URL path (e.g., /api goes to a different backend than /images).

  • Regional (Layer 4): Network Load Balancing. Use this for high-performance TCP/UDP traffic where you don't care about the application content.

4. The "Audit" Strategy: 200 Questions and Keyword Hunting

Consistency beats intensity. I ran through over 200 practice questions to train my brain to find the "Anchor Word" in every scenario.

• "Cost-Effective": Look for Spot/Preemptible VMs or Archive Storage.

• "Minimal Maintenance": Stop looking at GCE (VMs) and start looking at Cloud Run or App Engine.

• "Hybrid": This is a signal for Cloud VPN (cheap/internet) vs. Cloud Interconnect (expensive/direct fiber).

5. The AI Proctor: Using LLMs for Gap Analysis

I used Gemini and Claude as private tutors to find my "Logical Gaps." I didn't just ask them for answers; I asked them to simulate the pressure. Here is the exact prompt I used to turn an AI into a Google Interviewer:

The ACE Simulator Prompt:
"Act as a Google Cloud Associate Cloud Engineer (ACE) exam simulator. Generate a full-length mock exam with 50 multiple-choice questions matching the real ACE exam difficulty and syllabus. Each question must have 4 options and only one correct answer. Mix scenario-based questions (e.g., 'A company needs to...') with direct technical questions. Cover IAM, Compute, Storage, Networking, GKE, and Monitoring. After I submit, show my score and provide a 'Senior Engineer Review' explaining why the correct answer is Google's Best Practice and why the other three are 'Toil' or security risks."

6. The Essential Resource Stack

I cut the noise and stuck to these high-signal resources:

1. The Foundation: Antoni Tzavelas’ video on freeCodeCamp. It’s 20 hours of pure operational gold. It’s the only resource that actually explains the "Why" behind the commands.

1. The Manual: Official Google Cloud Skills Boost. I did every lab until I could do them without looking at the instructions.

2. The Validation: Google's Sample Exam. Google Sample Practice exams are notoriously harder than the real thing. If you can hit 85%, you will walk through the actual exam.

3. The Cheat Sheets: Learngood.com for quick domain summaries when I had 10 minutes between university errands.

🏁 Final Logic: Automate or Die

The ACE exam is Google’s way of asking: "Can we trust you with our hardware?"

Google's engineering culture is built on eliminating Toil (manual, repetitive work). Whenever you are stuck between two answers that both work, choose the one that requires the least human intervention.

You’ve got the roadmap. Now, go put in the night shifts. The view from the top of the 3x mountain is worth the climb.

Co-written with Google Gemini

We’ve all been there. You start a new project on Google Cloud or AWS. You’re excited. You log into the console, click "Create Instance," pick a region (probably europe-west1 because latency to Nairobi matters), open a few ports on the firewall, and your app is live. You feel like a genius.

But then, three months later, you need to replicate that environment for staging. Or worse, you accidentally delete a firewall rule and take down production. You try to remember what settings you clicked. Was it n1-standard-1 or e2-micro? Did I allow port 8080 or just 80?

Suddenly, you’re not a Cloud Engineer anymore. You’re just a guy trying to remember where he put the keys.

This is the "Jua Kali" approach to the cloud. It works until it doesn't.

In the professional world, we don't click buttons. We write code. We use Terraform. And today, I’m going to teach you exactly what that is using the universal language of Mjengo (Construction).

The Problem: The "Freestyling Fundi"

Imagine you bought a plot in Ruiru and you want to build a house. You hire a local Fundi. You go to the site, point at the ground, and say, "Weka ukuta hapa" (put a wall here).

The next day, you come back. The wall is there, but it’s crooked. The kitchen is where the bathroom should be. If you wanted to build an identical house next door, you couldn't. You’d have to stand there and shout instructions all over again. There is no documentation. There is no version control. It’s just vibes.

This is what happens when you manage cloud infrastructure manually via the Console. It’s prone to human error, it’s not reproducible, and it’s a nightmare to scale.

The Solution: The Architect’s Blueprint (IaC)

Now, imagine the professional way. You hire an Architect. They don't touch a single brick. Instead, they produce a Blueprint.

This blueprint defines everything. The dimensions, the materials, the plumbing, the electrical wiring. You can hand this blueprint to any construction crew, and they will build the exact same house. Whether it's in Ruiru, Mombasa, or Kisumu—if the blueprint is the same, the house is the same.

This is Infrastructure as Code (IaC). And Terraform is the tool we use to write the blueprint.

Core Concepts

Terraform might look intimidating with its .tf files and HashiCorp Configuration Language (HCL), but it maps perfectly to construction concepts. Let's break it down.

1. The Provider (The Contractor)

Before you break ground, you need to know who is doing the work. Are you hiring a crew that knows how to build on Google Cloud (GCP)? Or are you hiring a crew for AWS?

In Terraform, this is the Provider.

    # provider.tf
provider "google" {
  project = "my-awesome-project"
  region  = "us-central1"
}

This block tells Terraform: "Hey, we are hiring the Google Cloud crew. All instructions following this are for them."

2. Resources (The Building Blocks)

This is the meat of the project. A resource is a specific thing you want to build. In a mjengo, it's a wall, a window, or a water tank. In the cloud, it's a Virtual Machine, a Storage Bucket, or a Database.

For example, creating a bucket to store images:

    # main.tf
resource "google_storage_bucket" "image_store" {
  name     = "my-app-images-bucket"
  location = "US"
}

• resource: The keyword that screams "I want to build something!"

• google_storage_bucket: The type of material we are using.

• image_store: The internal nickname we give it (like calling a room "Master Bedroom").

3. Variables (Customizing the House)

Imagine you have a perfect blueprint for a 3-bedroom house. Client A wants the walls painted blue. Client B wants them white. You don't draw a whole new blueprint. You just change the "Paint Specification."

Variables allow you to make your code reusable.

    # variables.tf
variable "environment" {
  description = "Are we in dev or prod?"
  type        = string
}

# main.tf
resource "google_compute_instance" "server" {
  name         = "app-server-${var.environment}"
  machine_type = var.environment == "prod" ? "e2-standard-4" : "e2-micro"
}

4. State (The Site Logbook)

This is the most critical concept. When a construction crew builds a wall, they tick it off in the logbook. "Wall A is done."

Terraform keeps a file called terraform.tfstate. This is the brain. It remembers what has already been built in the cloud.

• If you run the code today, it builds a database.

• If you run the exact same code tomorrow, Terraform looks at the State File, sees the database exists, and does nothing.

It is smart enough to know the difference between "Build a new house" and "The house is already there." This prevents you from accidentally billing yourself for 50 duplicate servers.

The Workflow: Plan vs. Apply

So, how do you actually run this thing? It’s a two-step dance that saves you from disaster.

Step 1: terraform plan (The Site Visit)

You run this command in your terminal. Terraform reads your code, looks at your Google Cloud account, and compares them.

It then prints out a report: "Okay boss. Based on this blueprint, I need to add 2 servers, change 1 firewall rule, and destroy 1 old bucket."

It hasn't touched anything yet. It is asking for permission. This is your chance to catch mistakes before they happen.

Step 2: terraform apply (Groundbreaking)

If the plan looks good, you run terraform apply. The Google Cloud "crew" gets to work. APIs are called, resources are spun up, and within minutes, your infrastructure is live.

Why this actually matters

I'm currently rebuilding the infrastructure for my e-commerce platform, Merch-KE, entirely in Terraform. Why go through the effort?

1. Sleep: I sleep better knowing that if I accidentally deleted my entire project today, I could run terraform apply and have the entire platform back online in 15 minutes.

2. Audit Trails: Every change is a commit in GitHub. I can see exactly who changed the firewall rule and when.

3. Speed: I don't waste time clicking menus. I write code, I push, it deploys.

Stop treating your cloud infrastructure like a Jua Kali side hustle. Get a blueprint. Learn Terraform.

(If you want to see what a production-ready Terraform structure looks like, check out the merch-ke-infra repo on my GitHub. It’s a work in progress, but the architecture is there.)

If you’ve followed my journey or read my previous posts, you know I’m a Software and Cloud Engineer through and through. I like building systems that have clear logic, predictable integrations, and infrastructure that doesn’t require me to stare at loss curves until my eyes bleed. But here I am, a newly certified Google Cloud Professional Machine Learning Engineer. Honestly, it feels like a bit of a mistake, but it was a journey I needed to take.

It all started when I was watching "The Thinking Game," a documentary by Google DeepMind (an absolute banger). I’ve always done AI integrations—the "plug and play" stuff where you hit an API and magic happens—but that doc made me want to go deep into the rabbit hole. I wanted to understand the plumbing behind the curtain. I wanted to know how raw data actually transforms into "intelligence."

The Goal and the Hard Deadline

I have a Google Developer Premium subscription, which comes with a certification voucher. I’d set a personal goal to build a solid GCP foundation: I got the Gen AI Leader cert (Foundation), I’m currently prepping for the Associate Cloud Engineer (Associate), and I wanted a Professional cert to round it out.

Since I had zero Christmas or New Year plans—no parties, no travel, just me and my laptop—I decided to schedule the PMLE. The catch? My voucher was expiring on the 30th of December. I had exactly one month to prepare for one of the most notoriously difficult exams in the Google ecosystem. It was a one-month sprint or bust.

The Burnout and the "Upside Down"

I started off strong. I dove into the Google Skills course, learning about BigQueryML, Vertex AI Notebooks, and the basics of model training. But about three weeks out, I hit a wall. The content is massive. It’s not just about tools; it’s about a completely different dialect of engineering. My brain just checked out.

I literally gave up. I spent that entire week rewatching Stranger Things to prepare for the final season. (Side note: I’m still processing that Season 5 finale...). I was so far removed from ML that I didn't think I'd actually go back to it. I felt the burnout in my bones and was ready to let the voucher expire.

The Pivot: "Just Do It"

One week before the exam, I snapped back. I hate leaving things unfinished. I reached out to my accountability partner, Beth, to share my daily learnings. I told her basically every day, "Beth, I’m quitting. This isn't for me."

She was the realest. She didn't give me a motivational speech; she just said: "Just do it. The worst that can happen is a fail."

That’s when I locked in. I realised I didn't need to be a Keras or TensorFlow wizard to be a great Cloud Engineer. I decided to skip the deep coding and focus on AutoML and the Vertex AI ecosystem. On the 26th of December, Stranger Things 5 dropped. I binged the whole thing, felt that "main character energy," and decided to read some blogs from people who’d actually survived the PMLE.

I found Paul Kamau’s blog — it wasn't even a study guide, just a "what to do after" post, but it gave me the mental closure I needed to just finish the task before my birthday on the 31st. I even read his post on failing to make peace with the possibility of a "No Pass" result.

The 48-Hour Vertex AI Deep Dive

Two days before the exam, I found a post on the Google Developer Forums that was a total game-changer. It emphasized that 60-70% of the exam is Vertex AI. I stopped guessing and spent 48 hours straight reading the documentation for these specific pillars:

• Vertex AI AutoML: The "no-code" hero. It handles feature engineering and model selection for you, making it perfect for rapid prototyping.

• Vertex AI Pipelines & Orchestration: The factory line. This is how you use Kubeflow to automate the entire "Data -> Train -> Deploy" workflow.

• Vertex AI Experiments & Metadata: The forensics lab. Experiments track your scores (accuracy/loss), while Metadata tracks the lineage—proving exactly which dataset created which model version.

• Vertex AI Model Registry & Endpoints: The library and the URL. This is where you version your models and deploy them to an IP address so they can serve live traffic.

• Vertex AI Feature Store: The central hub. It allows different teams to share and reuse data features without recalculating them every time.

• Vertex AI Explainable AI (XAI): The "Why." Using Feature Attributions to explain exactly why a model made a certain decision.

• Vertex AI Model Monitoring: The watchdog. It checks for Drift (when the world changes) or Skew (when your training data doesn't match real-life data).

I used Gemini to generate scenario questions. The trick to Google exams is looking for keywords: if the prompt says "minimise cost for non-urgent tasks," the answer is Batch Prediction. If it says "fastest time to market," it’s AutoML.

Exam Day: 20 Minutes of Pure Chaos

I scheduled the exam for 10:00 AM. I woke up at 9:40 AM.

I was confused, panicked, and lowkey terrified. I took a fast shower and jumped into the portal with minutes to spare. For the first 30 minutes, I only managed to finish 10 questions. My brain hadn't fully woken up, and I was marking everything for review because I was so unsure of myself.

But then, the pattern clicked. I started seeing the "Google Way"—prioritising efficiency, cost-saving, and managed services. I finished the 50 questions with 30 minutes to spare and went back to review every single answer. I hit submit, expecting to see a failure screen.

"PASS."

I smiled, thanked God, and went straight back to sleep.

Final Thoughts

At times, I feel like a bit of an imposter because ML really isn't my primary focus and I don't plan on chasing ML-heavy roles. I’m a Software and Cloud Engineer, and that’s where I’m staying. However, I satisfied my curiosity. I went down the rabbit hole and came back with a professional certification that proves I understand the architecture of modern AI.

If you’re prepping for this and feel like it’s "not your thing," don't trip. Lock in on Vertex AI, find an accountability partner to keep you from quitting, and remember: the worst that can happen is a fail. And even then, you’ve still learned how the world works behind the scenes.

Now, back to the ACE prep. See ya in the cloud. ✌️

The Starting Point: "What Even Is This?"

I opened BigQuery with one goal: learn ML. I'd heard people throw around terms like "machine learning models" and "predictive analytics" for ages, and I always nodded along pretending I got it. Today, I decided to actually understand it.

The first thing I learnt? Machine learning isn't magic. It's pattern recognition. That's it. You show a computer loads of examples, and it figures out the patterns. Then when you give it new data, it uses those patterns to make predictions.

Think of it like this: If I showed you 1,000 photos of my campus and told you which ones were taken during exam season (empty library, stressed faces, Red Bull cans everywhere) versus holiday season (packed social spaces, smiling faces, general chaos), you'd eventually spot the patterns. You could then look at a new photo and guess when it was taken. That's basically what ML does, just with numbers instead of photos.

The Three Types of ML I Covered

1. Regression: Predicting Numbers

This is when you want to predict an actual number. How much will this house cost? How long will this taxi ride take? What will the temperature be tomorrow?

I practised with NYC taxi data, trying to predict trip duration. The model looked at things like:

• Distance of the trip

• Time of day

• Day of the week

• Pickup and dropoff locations

And from all that, it predicted: "This trip will probably take 847 seconds."

Where I messed up: At first, I didn't clean the data properly. I had trips that supposedly took 4 minutes but covered 0 miles. Rubbish data = rubbish predictions. Lesson learnt: Always check your data makes sense before training anything.

2. Classification: Putting Things in Boxes

This is when you want to categorise something. Will this customer buy again? (Yes/No) Is this email spam? (Yes/No) What type of product is this? (Electronics/Clothing/Food)

I worked with e-commerce data, trying to predict: "Will this visitor return and make a purchase?" The model looked at their first visit:

• Did they bounce immediately?

• How long did they stay?

• How many pages did they view?

• Where did they come from? (Google, Facebook, direct link)

• What device were they on?

Then it predicted: "This person has an 85% chance of buying when they come back."

Where I messed up: I initially trained and tested on the same data. It's like studying for an exam using the exact questions that'll be on the paper—of course you'll do well, but you haven't actually learnt anything. You need separate data for training and testing.

3. Clustering: Finding Hidden Groups

This is different. You're not predicting anything. You're asking: "What natural groups exist in my data?"

Imagine you have data on 10,000 customers but no labels. Clustering looks at their behaviour and says: "I've found 5 distinct groups":

• Budget shoppers who only buy during sales

• Premium customers who buy expensive items regularly

• Window shoppers who browse but rarely purchase

• Loyal mid-tier customers

• Brand new explorers still figuring things out

Nobody told the model these groups existed. It discovered them by finding similar patterns.

The SQL Parts That Confused Me

I thought I knew SQL. Turns out, I knew basic SQL. BigQuery ML threw some curveballs.

UNNEST: The Array Flattener

This one broke my brain initially. The Google Analytics data was nested—like a box inside a box inside another box. Each website session contained multiple "hits" (page views), and each hit contained multiple products.

FROM table,
UNNEST(hits) AS h,
UNNEST(h.product) AS p

What this does: It takes all those nested boxes and lays everything out flat so you can actually work with it. Session → hits → products becomes individual rows you can query.

Analogy: Imagine you have a filing cabinet (session) with folders (hits) that contain documents (products). UNNEST takes all the documents out and spreads them on your desk so you can see everything at once.

GROUP BY: The "You Must Include Everything" Rule

This rule annoyed me until I understood it. Here's the thing:

If you're using aggregate functions like SUM() or COUNT(), SQL needs to know: "Sum WHAT together?"

SELECT 
  product_name,           -- Not aggregated
  SUM(quantity)           -- Aggregated
FROM table

SQL says: "You're summing quantities into ONE number, but showing multiple product names? Which name goes with the total? I'm confused!"

You need GROUP BY:

SELECT 
  product_name,
  SUM(quantity)
FROM table
GROUP BY product_name    -- Now I know: sum quantities for EACH product

My mistake: I kept forgetting to include columns in GROUP BY and got errors like "expression references column which is neither grouped nor aggregated." Now I get it—every column that's not in a SUM/COUNT/AVG/etc. must be in GROUP BY.

IF and CASE: Making Decisions in SQL

These let you add logic to your queries.

IF is simple: "If this is true, do this, otherwise do that"

IF(count > 0, 1, 0)
-- If count is greater than 0, return 1, otherwise return 0

CASE is like multiple IF statements:

CASE
  WHEN score > 90 THEN 'Excellent'
  WHEN score > 70 THEN 'Good'
  WHEN score > 50 THEN 'Average'
  ELSE 'Needs work'
END

Where I got confused: In one query, I saw > 0, 1, 0 and thought there were three zeros doing the same thing. Took me ages to realise:

• First 0 is checking if something is greater than zero (part of the question)

• Second number 1 is what to return if true

• Third number 0 is what to return if false

Three different jobs, just unlucky they were all zeros!

The Complete Workflow: What Actually Happens

Here's what I learnt the ML process actually looks like:

Step 1: Explore Your Data

Look at what you've got. Check for weird values. Understand what each column means.

SELECT * FROM table LIMIT 10;

Simple, but essential.

Step 2: Clean Your Data

Remove the rubbish. Filter out impossible values.

My data had:

• Taxi trips with zero distance (how?)

• Negative durations (time travel?)

• Trips over 100 miles (from NYC to where??)

All had to go.

Step 3: Create Features

This is where you get creative. Take raw data and turn it into useful information.

Instead of just storing pickup_datetime, I extracted:

• Hour of day (rush hour vs quiet time)

• Day of week (weekday vs weekend)

These features help the model spot patterns.

Step 4: Split Your Data

This is crucial. Split into:

• Training data (60-80%): Model learns from this

• Test data (20-40%): Model has never seen this—used to check if it actually works

My dates:

• Training: August 2016 - April 2017

• Testing: May - June 2017

• Predictions: July 2017 onwards

No overlap! That's the key.

Step 5: Train the Model

CREATE OR REPLACE MODEL `project.dataset.model_name`
OPTIONS(
  model_type='logistic_reg',
  input_label_cols=['what_youre_predicting']
)
AS
SELECT * FROM training_data;

This is where the magic happens. BigQuery analyses all your training data and figures out the patterns.

Step 6: Evaluate the Model

SELECT * FROM ML.EVALUATE(MODEL model_name, (test_data));

This tells you: "How good is your model?"

For classification, you get a score called roc_auc:

• 0.9+ = Excellent

• 0.8-0.9 = Good

• 0.7-0.8 = Decent

• 0.6-0.7 = Poor

• 0.5 = Literally just guessing

My first model got 0.72 (decent). My improved model with more features got 0.91 (excellent!).

Step 7: Make Predictions

SELECT * FROM ML.PREDICT(MODEL model_name, (new_data));

Now you can predict on completely new data. This is where it becomes useful in the real world.

What Improved My Model

My first classification model only looked at two things:

• Did they bounce?

• How long did they stay?

Score: 0.72 (decent)

My second model added:

• Number of pages viewed

• How far they got in the shopping process (viewed products? Added to cart? Checked out?)

• Where they came from (Google? Facebook? Email?)

• What device they used (mobile? desktop?)

• What country they were from

Score: 0.91 (excellent!)

The lesson: More relevant features = better predictions. But only relevant ones—adding their visitor ID wouldn't help because it's just a random identifier that doesn't tell you anything about behaviour.

The Metrics That Matter

For Regression (predicting numbers):

Mean Absolute Error (MAE): On average, how far off are your predictions?

• My taxi model: 239 seconds (about 4 minutes)

• For a taxi ride, that's pretty good

R² Score: How much of the variation does your model explain? (0 to 1)

• My model: 0.72 (explains 72% of the variation)

• Not perfect, but solid

For Classification (predicting categories):

ROC AUC: Overall accuracy measure (0 to 1)

• Higher is better

• 0.91 = excellent

Precision vs Recall: Trade-offs in classification

• Precision: Of the ones you predicted "yes", how many were actually "yes"?

• Recall: Of all the actual "yes" cases, how many did you catch?

Where I Failed (And What I Learnt)

Failure 1: Training and Testing on the Same Data

I got amazing results! Model was perfect! Then I realised I'd basically given it the answers during the test. Rookie mistake. Always use separate time periods or random splits.

Failure 2: Not Checking Data Quality First

Garbage in, garbage out. I trained a model on data with impossible values and wondered why predictions were weird. Now I always clean first.

Failure 3: Forgetting to Handle Missing Values

SQL doesn't like NULLs. I kept getting errors until I learnt about IFNULL():

IFNULL(column_name, 0)  -- If it's NULL, use 0 instead

Failure 4: Not Understanding My Own SQL

I'd copy-paste queries without understanding them. Then when something broke, I had no idea why. Typing queries out line by line (even if slower) made me actually understand what was happening.

What Finally Clicked

The moment it all made sense was when I realised: ML is just finding patterns in examples.

That's it. You're not teaching it rules. You're showing it loads of examples and letting it figure out what matters.

• Lots of people who bounce don't come back? Pattern spotted.

• People who view 5+ pages tend to buy? Pattern spotted.

• Mobile users from social media behave differently to desktop users from Google? Pattern spotted.

The model just finds and remembers these patterns, then applies them to new data.

What's Next?

I want to try this with Kenyan data. Something relevant to home:

• Predicting crop yields based on rainfall and temperature?

• Classifying M-Pesa transactions as genuine or fraudulent?

• Clustering Nairobi neighbourhoods by economic activity?

The possibilities are endless once you understand the basics.

Key Takeaways (For Future Me)

1. Clean your data first. Always. No exceptions.

2. Split your data properly. Train on old data, test on new data, predict on future data. Never mix them up.

3. Start simple, then improve. My first model had 2 features and was decent. My second had 11 features and was excellent. Build iteratively.

4. Understand your SQL. Type it out, don't just copy-paste. The errors you make will teach you more than getting it right the first time.

5. More features ≠ are always better. They need to be relevant. Adding random IDs or useless columns just confuses the model.

6. Model scores don't mean much without context. 0.72 might be excellent for some problems and terrible for others. Understand what you're trying to achieve.

7. The workflow matters more than memorising syntax. Explore → Clean → Feature Engineering → Split → Train → Evaluate → Predict → Deploy. Master this process, and you can build anything.

Resources That Helped

• Google's public BigQuery datasets (perfect for practising)

• The NYC taxi data (messy real-world data)

• Google Analytics e-commerce data (nested data practice)

• Patience (lots of it)

• Trial and error (even more of it)

Final Thoughts

Machine learning felt like this huge, intimidating thing I'd never understand. Turns out, it's just SQL with some extra steps. If you can write queries, clean data, and think logically about patterns, you can do this.

Future me: When you're revising for exams and come back to this post, remember—you learnt all of this in one day. You got confused, you made mistakes, you fixed them. That's how learning works. Don't stress about not remembering everything. Just start building something, and it'll come back to you.

But first, let me explain what this certification actually means. A Generative AI Leader is someone who understands how generative AI can genuinely transform businesses. It's not about being a technical wizard who can code AI models from scratch. Instead, it's about having that business-level knowledge of Google Cloud's gen AI offerings and understanding Google's AI-first approach well enough to guide organisations towards innovative and responsible AI adoption. You're essentially someone who can spot opportunities across different business functions and industries, then influence gen AI-powered initiatives using Google Cloud's enterprise-ready offerings.

What makes this certification particularly valuable is that it's designed for anyone, regardless of their job role or technical background. Whether you're in marketing, operations, finance, or even a non-technical leadership position, this certification proves you can bridge the gap between AI technology and business strategy. In a world where every company is scrambling to figure out their AI strategy, being able to speak both languages is incredibly powerful.

Why I Decided to Take This Exam

Honestly, the decision came from watching how rapidly generative AI is reshaping entire industries. Every conversation I had, every article I read, and every business decision I observed seemed to circle back to gen AI. I realised that understanding this technology at a strategic level wasn't optional anymore. It was essential. I wanted to position myself as someone who could not only understand the hype but also cut through it and identify real, practical applications of generative AI in business contexts.

Plus, Google Cloud has been making significant moves in the AI space, and I was curious to understand their approach more deeply. The certification seemed like the perfect way to gain that structured knowledge whilst also having something tangible to show for it.

My One-Week Preparation Journey

Let me be upfront about this. One week is tight. Really tight. But it's doable if you're strategic about your time and resources. I treated it like a sprint, dedicating several hours each day to studying. Here's how I broke it down.

The first couple of days, I immersed myself in the fundamentals. I needed to ensure I had a solid grasp of what generative AI actually is, how it differs from traditional machine learning, and what makes it so transformative. I spent time understanding concepts like large language models, prompt engineering, and the various techniques used to improve model outputs.

By midweek, I shifted my focus to Google Cloud's specific offerings. This meant diving into Vertex AI, understanding the different AI tools and services Google provides, and learning how they fit together in real-world scenarios. I made sure I understood not just what each service does, but when and why you'd use one over another.

The final stretch was all about application and business strategy. I worked through scenario-based practice questions because I'd heard the exam was heavy on practical application. This turned out to be absolutely crucial preparation, as the actual exam was indeed focused on real-world business scenarios rather than abstract technical knowledge.

The Resources That Made the Difference

I relied heavily on Google's own materials, and I'm genuinely impressed by how comprehensive and well-structured they are. Here's what I used and how each resource helped me.

The Study Guide was my roadmap. Google provides a detailed study guide that outlines everything you need to know for the exam. I started here because it gave me a clear picture of the scope. I'd recommend printing it out or having it open on a second screen whilst you study, so you can tick off topics as you cover them. It helped me ensure I wasn't missing any critical areas.

The Generative AI Leader Learning Path on the Google Skills Platform(formerly Cloud Skills Boost) was essential. This is a free course that walks you through all the key concepts you need. I went through every module carefully, taking notes as I went. The course is structured brilliantly, starting with fundamentals and gradually building up to more complex business applications. What I particularly appreciated was how it connected technical concepts to real business outcomes. You're not just learning what a language model is; you're learning how it can solve actual business problems.

The Exam Guide complemented the study guide by showing me exactly what the exam would assess. It breaks down the knowledge areas into four main sections: fundamentals of gen AI, Google Cloud's gen AI offerings, techniques to improve gen AI model output, and business strategies for successful gen AI solutions. I used this to prioritise my study time, spending more hours on areas where I felt less confident.

The Sample Questions were a game changer. They helped me understand not just what topics would be covered, but how questions would be framed. The exam is all about scenarios and application, so practising with these sample questions helped me get into the right mindset. I didn't just answer them; I made sure I understood why each correct answer was right and why the wrong answers were wrong.

One thing I'll mention is that I also explored the Google Cloud community on Reddit. Whilst I didn't rely on it as a primary study resource, reading about other people's experiences gave me useful insights into what to expect and where to focus my attention.

What the Exam Was Actually Like

The exam was 90 minutes long with 45 multiple-choice questions. That might sound like plenty of time, but some of those questions require careful thought. You're given scenarios and asked to identify the best approach, the most appropriate Google Cloud service, or the right strategy for a particular business challenge.

Here's what really stood out to me: nearly every question was scenario-based. You won't find many questions asking you to simply define a term or list features. Instead, you'll see questions like, "A retail company wants to personalise customer recommendations whilst ensuring data privacy. What's the best approach?" or "Your organisation is concerned about bias in AI-generated content. Which technique should you prioritise?"

This means understanding how gen AI applies to real-world problems is absolutely key. You need to think about business context, not just technology. Questions touched on various industries like healthcare, finance, retail, and manufacturing, so having a broad understanding of how gen AI can be applied across different sectors is important.

I also noticed a strong emphasis on responsible AI. Google clearly wants Generative AI Leaders to understand not just what's possible with the technology, but what's ethical and responsible. Questions about managing bias, ensuring transparency, protecting privacy, and maintaining security came up regularly.

Key Topics to Focus On

The exam guide outlines four main knowledge areas, and I'd recommend giving each of them serious attention.

Fundamentals of Gen AI covers the basics. You need to understand what generative AI is, how it differs from traditional machine learning, and what makes it so powerful. This includes concepts like large language models, transformers, tokens, embeddings, and the various types of generative models (text, image, code, etc.). Don't just memorise definitions; make sure you understand the underlying concepts and how they relate to each other.

Google Cloud's Gen AI Offerings is where you learn about the specific tools and services. You'll need to know about Vertex AI and its various components, Model Garden, Generative AI Studio, and the different ways Google enables organisations to build with gen AI. Understand what each service does and, more importantly, when you'd use each one. Pay attention to the differences between pre-trained models, fine-tuned models, and building custom models.

Techniques to Improve Gen AI Model Output dives into how you make these models work better for your specific needs. This includes prompt engineering (probably one of the most practically important skills), retrieval-augmented generation (RAG), fine-tuning, grounding, and various optimisation techniques. You'll want to understand not just what each technique does, but when and why you'd use one approach over another. For instance, when is fine-tuning worth the effort versus just improving your prompts? When should you use RAG to ground your model in specific data?

Business Strategies for Successful Gen AI Solutions brings everything together from a strategic perspective. This covers how to identify opportunities for gen AI in your organisation, build business cases, manage change, address concerns about AI adoption, ensure responsible use, and measure success. This section is less about the technology itself and more about being an effective leader who can drive gen AI initiatives forward.

My Top Study Tips

Based on my experience, here are the things that made the biggest difference in my preparation.

Focus on application over memorisation. You won't succeed by just memorising definitions and features. Instead, practice thinking through scenarios. When you learn about a new concept or tool, immediately ask yourself: "Where would this be useful? What problems does it solve? When would I choose this over alternatives?" This mindset shift made everything click for me.

Pay attention to keywords in questions. The exam questions are carefully worded, and specific keywords often point you towards the right answer. Words like "immediately," "cost-effective," "scalable," "secure," or "responsible" aren't there by accident. They're guiding you towards understanding what the scenario is prioritising. I found it helpful to underline these keywords as I read through practice questions.

Understand the full spectrum of gen AI approaches. There's often a temptation to think that more sophisticated techniques are always better. But sometimes a simple prompt is all you need, and fine-tuning a model would be overkill. Understanding when to use lighter-touch approaches versus heavier investments in customisation is crucial. The exam tests your ability to match the right tool to the right job.

Don't skip the Google Skills course. It's free, it's comprehensive, and it's genuinely well done. I found that the course alone covered most of what I needed to know. The structure helps you build knowledge progressively, and the examples are practical and relevant.

Think about responsible AI from the start. This isn't just an add-on topic; it's woven throughout the entire exam. Google clearly wants Generative AI Leaders to champion responsible AI practices. Whenever you're thinking through a scenario, consider the ethical implications, potential biases, privacy concerns, and transparency requirements.

Practice explaining concepts in business terms. Since this is a leadership certification, you need to be comfortable translating technical concepts into business value. Practice explaining why something matters to a business leader who doesn't have a technical background. This skill will serve you well both in the exam and in actual leadership roles.

Use the official materials first. There are lots of study resources out there, but I found Google's official materials to be the most reliable and comprehensive. Start with those, and only branch out if you need additional perspectives on specific topics.

Final Thoughts and Resources

Looking back on this week-long journey, I'm genuinely grateful for how accessible Google has made this certification. The fact that the core learning path is completely free removes a major barrier, and the quality of the materials shows that Google is serious about building a community of AI-informed leaders.

The $99 exam fee is reasonable, and the certification is valid for three years, providing ample time to leverage it before renewal is required. For anyone considering this certification, I'd say go for it. Whether you're in a technical role looking to develop business acumen or a business professional wanting to understand AI strategy, this certification provides genuine value.

Here are all the official resources I used and would recommend:

Study Guide: https://services.google.com/fh/files/misc/generative_ai_leader_study_guide_english.pdf

Generative AI Leader Learning Path (Free): https://www.skills.google/paths/1951

Exam Guide: https://services.google.com/fh/files/misc/generative_ai_leader_exam_guide_english.pdf

Sample Exam Questions: https://forms.gle/soztS7Q74AXBncATA

Schedule Your Exam: https://cp.certmetrics.com/google/en/login

Certification Details: https://cloud.google.com/learn/certification/generative-ai-leader

The materials Google provides are genuinely excellent, and I found them more than sufficient for passing the exam. The learning path is structured thoughtfully, the study guide is comprehensive, and the sample questions give you a real feel for what to expect.

If you're on the fence about taking this certification, my advice is simple: if you work with technology, business strategy, or leadership in any capacity, this knowledge is becoming essential. The certification is achievable with focused preparation, and the knowledge you gain will serve you well beyond just passing an exam. Generative AI isn't going anywhere; it's only going to become more central to how businesses operate. Positioning yourself as someone who understands both the technology and its business applications is one of the smartest moves you can make right now.

Good luck with your preparation, and feel free to reach out if you have any questions about the exam or the journey

Two years ago, I was just another confused student at DevFest 2023, trying to figure out what the hell everyone was talking about. I didn't know what APIs were. I definitely didn't know what Kubernetes was. Hell, I was just there because someone said there'd be free food and maybe I'd meet people who could explain why my code kept breaking.

Fast forward to November 8th, 2025. Same event. Different role. This time, I wasn't just attending. I was organizing it. And speaking at it. About Google Kubernetes Engine. To 300+ people.

How the hell did we get here?

The Random Idea That Started It All

DevFest Mt. Kenya almost didn't happen this year. The usual leads weren't available, and for a hot minute, it looked like the Mt. Kenya region would just... skip it.

Eleanora and I were at the Google Offices when she broke the news, and we looked at each other like, "Nah. Hell no. We're doing this ourselves."

It was one of those stupid ideas that sound easy until you actually start planning. You know, the kind where you're like "how hard can it be?" and then reality hits you at 2 AM during your fifth planning meeting that week.

But we did it anyway. Because sometimes you just gotta be dumb enough to try.

Organizing DevFest: A Masterclass in Controlled Chaos

Organizing DevFest Mt. Kenya 2025 taught me more about event management than any course ever could.

We collaborated with campuses across the Mt. Kenya region. We had late-night meetings where we debated everything from sponsorship decks to whether we should order chicken or beef for lunch.

We dealt with budget constraints, last-minute speaker changes etc. That shit kept me up at night.

Seeing that crowd walk in? That was the moment I realized we actually pulled this off. All those sleepless nights, all those "are we sure this is gonna work?" conversations, they paid off.

And I couldn't have done it alone. Not even close. The organizing team, the volunteers, the partners who believed in this vision - they made it happen. This wasn't my event. It was ours.

Standing on Stage (And Trying Not to Pass Out)

Let's talk about my GKE talk.

I've given presentations before. In class. To maybe 30 people max. Always with the safety net of knowing everyone in the room.

This was different.

In a conference hall. With a microphone. And expectations.

Imposter syndrome hit me backstage. My brain was doing that thing where it replays every possible way you can mess up:

"What if the slides don't load?" "What if nobody understands what I'm saying?" "What if I forget everything mid-sentence?" "What if they realize I'm just a student who Googles half his problems?"

Stage fright is real, man. I don't care how confident you look on the outside - standing in front of hundreds of people who expect you to teach them something is scary as hell.

But then I started talking. About containers. About Kubernetes. About why orchestration matters in cloud-native applications. And somehow, people were nodding, taking notes. Actually engaged.

I realized something mid-talk: I've been teaching myself this shit for two years. I've broken production deployments. I've debugged at 3 AM. I've read the docs until my eyes hurt. I might not be an expert, but I know enough to help someone else get started.

And that's enough.

The Q&A after the talk? Even better. People asked real questions and also "gotcha" questions to test me, about how to deploy their own apps, how to choose between services, how to get started with cloud computing.

That's when I knew the talk worked. Not because I was perfect, but because I made something complicated feel approachable.

You can read more about my GKE talk here

After my talk, a few people came up to me. Some wanted clarifications on Kubernetes concepts. Others just wanted to correct me(I’m not always right).

But one conversation stuck with me.

A student from another campus asked, "How do you grow a tech community? We don't have one at our school, and I want to start something, but I don't know where to begin."

I swear, it felt like looking at myself two years ago.

I remember standing at DevFest 2023, asking the exact same question. Feeling like everyone else had it figured out except me. Wondering if I even had what it takes to lead anything.

And now here I was, on the other side of that conversation, giving advice. Telling them what worked for us. Encouraging them to just start, even if it feels small.

It's wild how life circles back like that.

The Uncomfortable Parts Nobody Talks About

Real talk for a second: MCing isn't my thing.

I'm cool with teaching. I can stand on a stage and explain Kubernetes for an hour. But walking around, making small talk with unfamiliar faces, keeping energy high between sessions? That drains me.

I'm somehow uncomfortable with strangers even though I'm literally organizing events for hundreds of people. Make it make sense.

Also, if you took a selfie with me during DevFest, please share those pics. I need proof this shit actually happened.

What DevFest Taught Me

Organizing DevFest Mt. Kenya 2025 wasn't just about pulling off a successful event. It taught me things I didn't expect to learn:

1. You don't need to be perfect to lead.

I'm not the smartest person in the room. I'm not the most experienced. But I showed up. I put in the work. I asked for help when I needed it. That's enough.

2. Communities are built by people who care, not by people who know everything.

Half the organizing team were students. We made mistakes. We improvised solutions on the fly. But we cared about creating something valuable for our region, and that mattered more than having all the answers.

3. Imposter syndrome doesn't go away. You just learn to do it scared.

I still feel like a fraud sometimes. Like someone's gonna tap me on the shoulder and say "You're not qualified for this." But you do the thing anyway. The fear doesn't stop you from showing up.

4. The people you meet make it worth it.

I met developers who are building amazing projects. Students who are hungry as hell to learn. Professionals who took time to mentor and guide. People who challenged me to keep growing.

That's what makes communities powerful - not the events, but the connections you build.

What's Next?

Honestly? I don't fully know.

I want to keep speaking. DevFest 2025 was my first physical talk at an event, and despite the nerves, I'm looking forward to more. There's something about teaching that feels right, you know? Like this is what I'm supposed to be doing.

I'm also working towards becoming a Google Developer Expert someday. Sounds ambitious as hell, but why not? Two years ago, I didn't think I'd be organizing DevFests or speaking about cloud infrastructure. If that can happen, anything can.

Maybe next time, we'll take the University of Embu community to DevFest Nairobi or DevFest Pwani. Experience the energy of bigger conferences. Learn from other communities. Bring that knowledge back home.

Because that's what it's all about - lifting as you climb. Learning and teaching at the same time. Building something bigger than yourself.

To Everyone Who Made This Possible

This event happened because of us.

To the organizing team, the volunteers, the partners who believed in this vision, the speakers who shared their knowledge, and the 300+ attendees who showed up - thank you.

You reminded me why I fell in love with tech communities in the first place.

It's not about the code. It's not even about the technology.

It's about the people. It always has been.

If you're reading this and you're thinking about starting something - a community, an event, a project - just do it. It'll be scary. You'll doubt yourself. You'll wonder if you're qualified.

But you don't need permission to start. You just need to show up.

And if a confused kid from Embu who Googled "what is an API" two years ago can organize a 300+ person developer conference and speak about Kubernetes, trust me - you can do whatever the hell you're dreaming about too.

Just start. Others will follow.

Test-Driven Development (TDD) is a coding approach where you write tests before writing the actual code. It sounds backward, but it transforms how you design and build software.

The cycle is simple:

1. RED - Write a failing test

2. GREEN - Write minimal code to pass

3. REFACTOR - Improve code without breaking tests

Why Bother with TDD?

You'll Write Code That Actually Works

How many times have you "finished" coding, only to find hidden bugs later? TDD ensures every piece of functionality is verified the moment it's written.

It Prevents Over-Engineering

When you write tests first, you only build what you actually need. No more "what if" features that complicate your code.

Your Tests Actually Test Something

Ever written tests that always pass? With TDD, you see tests fail first, proving they can catch real problems.

Let's Build Twitter's Vowel Remover

Twitter famously removed vowels to fit messages in 140 characters. "Twitter" becomes "twttr". Let's build this using TDD.

Step 1: RED - Write a Failing Test

# test_twttr.py
from twttr import shorten

def test_remove_vowels_from_twitter():
    result = shorten("twitter")
    assert result == "twttr"

Run this test (pytest test_twttr.py). It fails because shorten() it doesn't exist yet.

Why this matters: The failure proves our test works and can detect problems.

Step 2: GREEN - Write Minimal Code to Pass

# twttr.py
def shorten(word):
    return "twttr"  # The simplest thing that could work(Cheating)

Run the test again. It passes!

Why we "cheat": This keeps us focused on one requirement at a time.

Step 3: Add Another Test - Back to RED

def test_remove_vowels_from_hello():
    result = shorten("hello")
    assert result == "hll"

Run tests again. First test passes, second fails. Perfect progression.

Step 4: Write Real Logic - GREEN

def shorten(word):
    result = ""
    for char in word:
        if char.lower() not in "aeiou":
            result += char
    return result

Both tests pass! We now have working logic.

Step 5: Add Edge Cases

def test_empty_string():
    assert shorten("") == ""

def test_all_vowels():
    assert shorten("aeiou") == ""

def test_mixed_case():
    assert shorten("Hello World") == "Hll Wrld"

All tests pass with our current implementation.

Step 6: REFACTOR

def shorten(word):
    vowels = "aeiouAEIOU"
    return "".join(char for char in word if char not in vowels)

Run tests again - still green! We improved the code without breaking anything.

Common TDD Objections (And Why They're Wrong)

"It Slows Me Down"

Short-term: yes. Long-term: you save hours of debugging and rewriting.

"My Code Changes Too Much for Tests"

If your code changes frequently, tests are even more valuable. They catch breaks immediately.

"I Don't Know What to Test"

Start with the happy path, then add edge cases:

• Normal input

• Empty input

• Boundary cases

• Error conditions

When TDD Shines

• New features: Design through tests

• Bug fixes: Reproduce the bug with a test first

• Legacy code: Add tests before modifying

• Learning: Understand requirements before implementing

Your TDD Cheat Sheet

1. Think: What's the smallest behaviour I need?

2. Test: Write a test for that behaviour

3. Run: Watch it fail (RED)

4. Code: Write minimal code to pass (GREEN)

5. Clean: Improve code without breaking tests (REFACTOR)

6. Repeat: Choose the next smallest behaviour

Bottom Line

TDD isn't about religiously following rules. It's about building confidence in your code, one verified piece at a time.

The next time you start coding, try writing the test first. That red-to-green transition might just become your new addiction.

The Challenge of Starting

When I first stepped into the role of GDG on Campus Lead at the University of Embu, I thought I knew what I was getting into. Organise some tech talks, maybe a few workshops, and connect students with Google technologies. Simple enough, right?

I couldn't have been more wrong.

The reality hit me during our first event planning meeting. Staring at a room of eager students with diverse skill levels, different interests, and varying degrees of confidence, I realised that my job wasn't just about Google technologies—it was about people. It was about creating an environment where a first-year computer science student felt comfortable asking questions alongside a final-year developer building their capstone project.

The Growth in Complexity

What started as "let's do some Flutter workshops" evolved into something much richer. We found ourselves navigating questions that went beyond code:

• How do you make technical content accessible to students who are still finding their footing in programming?

• How do you balance structured learning with the organic curiosity that drives real innovation?

• How do you build confidence in students who see technology as intimidating rather than empowering?

Each event taught me that technical leadership is deeply human work. The best workshops weren't just about Firebase or Flutter—they were about creating moments where students realised they could build things that mattered.

The Unexpected Lessons

Leadership is listening. The most impactful changes we made came from really hearing what our community needed. Sometimes that meant pivoting from a planned AI workshop to a basic Git tutorial because that's where the real knowledge gap was.

Consistency beats intensity. The students who benefited most weren't necessarily those who attended our biggest events, but those who engaged regularly with our smaller, ongoing initiatives.

Your role is to make yourself unnecessary. By the end of the year, seeing other students step up to lead sessions and mentor their peers was more rewarding than any certificate.

The Technical and the Personal

This role taught me to bridge worlds—translating complex technical concepts into engaging learning experiences, connecting academic theory with practical application, and most importantly, helping students see themselves not just as consumers of technology, but as creators.

The Google Developer ecosystem provided incredible resources, but the real magic happened in the spaces between the official curriculum.

Looking Forward

As I transition from this role, I'm carrying forward a deeper understanding of what the developer community means. It's not just about the latest frameworks or trending technologies—it's about fostering environments where curiosity thrives, where failure is reframed as learning, and where everyone has the support they need to grow.

To future GDG on Campus Leads: embrace the complexity. Your role is part educator, part community builder, part mentor, and part student. The technical skills you'll develop are valuable, but the leadership skills you'll gain are transformative.

The developer community needs leaders who understand that our most important work happens not in the code we write, but in the opportunities we create for others to discover what they're capable of building.

Gratitude and Recognition

This journey wouldn't have been possible without an incredible support system:

My Core Team

Google Developer Experts (GDEs)

Regional Community Managers

University of Embu

Community Contributors

Leadership in tech communities is never a solo effort—it's the result of an ecosystem of support, mentorship, and collaboration.

Thank you to Google Developer Groups and the entire community that made this year of growth and impact possible.

Let me start from the beginning, because every good story needs context for you to understand just how far this journey has taken me.

The Day Reality Hit Me Hard

November 2023. I still get goosebumps thinking about that day when I organised transport for 10 students from my campus to DevFest Mt Kenya at DEKUT. It was literally the first thing I had ever organised in my life, and looking back, I had no business being there. I was this naive first-year student who genuinely believed I was destined to become some kind of elite hacker. Yeah, I know how that sounds now, but at 18, fresh out of high school, I thought I had the tech world figured out.

I held this title, "Cyber Security Lead" at our campus GDSC chapter, which sounds impressive until you realise I had never done a single thing related to cybersecurity. Not one workshop, not one session, nothing. I was living in this bubble where having a title meant I actually knew what I was doing. The reputation I had built at school felt solid, and other students would come to me with tech questions like I was some kind of expert.

Then DevFest happened.

Sitting in that auditorium at DEKUT, listening to developers casually throw around terms I couldn't even spell, let alone understand, was humbling in the worst possible way. These people were talking about APIs, cloud architecture, and machine learning models, and I'm sitting there wondering if "Postman" was actually a person who delivered mail. The presentations might as well have been in a foreign language. Every session made me realise how little I actually knew, how fake my confidence had been.

The ride back to Embu was probably the longest two hours of my life. While other students were excitedly discussing what they'd learned, I was having an internal crisis. All that reputation I'd built? It felt like a house of cards that had just collapsed. I felt like a fraud, and worse, I felt completely lost about what to do next.

The Postman Obsession That Changed Everything

But here's the thing about rock bottom - it gives you a solid foundation to build from. Throughout that entire DevFest event, one thing kept nagging at me. Everyone kept mentioning "Postman" as the event’s sponsor, and they talked about it like it was this amazing tool for API testing. I had no clue what APIs even were, but something about the way people talked about Postman made it sound accessible, even fun.

After the event, I couldn't get it out of my head. I kept thinking about this tool and wondering what I was missing. Then I remembered something - Brian Muchai, the Postman Student Leader at DEKUT, looked familiar. It took me a while to place him, but then it hit me - we went to the same high school! This felt like fate, or at least like the universe giving me a small break.

Reaching out to Brian was terrifying. Here I was, this guy who had just realised he knew nothing about tech, asking someone who seemed to have it all figured out for help. But Brian was incredible. Instead of making me feel stupid for not knowing basic concepts, he actually encouraged me to apply as a Postman Student Leader for my own campus. He told me about the API 101 course and how it could help me understand the fundamentals.

I signed up for that virtual course immediately, and for the first time in months, things started making sense. APIs weren't this mysterious, impossible concept - they were actually logical and useful. The course was structured in a way that assumed you knew nothing, which was perfect for someone like me who literally knew nothing. I spent hours going through the modules, taking notes, and practicing with the Postman interface.

When it came time to hold my first session as part of the application process, I was absolutely terrified. My hands were shaking so badly I could barely hold my laptop steady. I was about to teach API concepts to other students when I'd only learned them myself a few days earlier. But you know what happened? The session was amazing. Students were asking questions, getting excited about building their first API requests, and I could see that same spark of understanding in their eyes that I'd felt when things first clicked for me.

Writing that application report was nerve-wracking, but I poured everything into it - my newfound understanding of APIs, my vision for bringing practical tech skills to our campus, and my commitment to helping other students avoid the confusion I'd experienced. When the acceptance email came through, I literally jumped out of my chair. I was officially a Postman Student Leader, and it felt like my first real achievement in tech.

Watching GDSC Slowly Die (And Deciding to Save It)

By this time, I was juggling two roles - my new position as a Postman Student Leader and my existing spot on the GDSC core team as the Cyber Security lead (still not doing any actual cybersecurity work, but at least now I was contributing in other ways). Being part of both communities gave me a unique perspective on what was working and what wasn't.

The contrast was stark. Through Postman, I was learning practical skills that I could actually use and teach to others. The content was relevant, the community was supportive, and students were genuinely engaged. But GDSC on our campus was struggling. We weren't inactive exactly, but there was this sense that we were just going through the motions.

The problem became crystal clear as the academic year progressed - almost all of our GDSC leads were final year students. While I was getting excited about APIs and community building, they were focused on graduation, job applications, and moving on with their lives. I don't blame them - that's the natural progression. But as someone who was just finding his footing in tech, the thought of losing this community was devastating.

I started noticing things that other people missed. Leads would skip meetings because they had commitments. Events were getting smaller because there wasn't consistent promotion. New students weren't joining because the energy just wasn't there. We were slowly bleeding out, and nobody seemed to care because everyone was already mentally checked out.

That's when it hit me - someone needed to step up, and that someone might have to be me. The thought was terrifying. I was barely keeping up with my own learning, still figuring out basic concepts, and now I was considering taking responsibility for an entire community? But the alternative was watching GDSC die completely, and I couldn't let that happen. Not when I'd seen firsthand through Postman how powerful tech communities could be.

Building a Team Before I Was Even the Leader

March 2024 was when I made one of the boldest decisions of my life. Instead of waiting for the official GDSC lead selection process in September, I decided we needed to start building a new core team immediately. The math was simple - if we waited until September, the current leads would already be gone, and GDSC would be left in limbo for months. We couldn't afford that kind of gap.

I wasn't even officially the lead yet, but I was already thinking like one. The selection process was intense, but not in the way you might expect. I wasn't looking for the students with the highest GPAs or the most impressive GitHub profiles. I was looking for something much more valuable - passion. I wanted people who got excited when they talked about helping others learn, who asked thoughtful questions during our sessions, and who understood that building a community meant we'd all be learning together.

I remember interviewing potential team members and asking them why they wanted to be part of GDSC. Some gave these rehearsed answers about wanting to "enhance their technical skills" or "build their professional network." Those weren't necessarily wrong answers, but they weren't what I was looking for. The candidates who got selected were the ones who talked about wanting to create something meaningful, who shared stories about being confused by tech concepts and wanting to help others avoid that confusion, who understood that leadership in a student community meant being a facilitator, not a know-it-all.

The core team I built became the backbone of everything we accomplished. They became my support system, my sounding board, and the people who kept the community running when I was struggling with my own challenges. Working with this team taught me that the best communities are built by people who complement each other's strengths and cover for each other's weaknesses.

During this transition period, we started organizing Flutter Study Jams across campus, and these became our testing ground. We weren't just teaching Flutter - we were learning how to work as a team, how to coordinate logistics, how to keep students engaged week after week, and how to handle the inevitable technical difficulties that come with any live coding session.

I still remember the anxiety before our first Flutter Study Jam. We'd planned everything meticulously, but I kept wondering - what if nobody shows up? What if the Wi-Fi fails? What if I can't answer their questions? What if we're actually making things more confusing instead of helping? But students started trickling in, and then more came, and before we knew it, we had a room full of people genuinely excited to learn about mobile app development.

Watching students build their first Flutter apps, seeing them get excited when their code compiled successfully, answering their questions and realizing I actually knew the answers - these moments were addictive. Each session built our confidence as a team and proved that we could actually do this. By the time the official transition period came around in September, we weren't just hoping to keep GDSC alive - we had already proven we could make it thrive.

The Interview That Changed My Life

April 2024 brought the interview for the GDSC Lead position, and I've never been more nervous about anything in my life. This wasn't just a casual conversation - this was my chance to officially take responsibility for something I'd already been working toward for months.

I remember sitting in front of my laptop for that virtual interview, trying to balance confidence with humility, explaining my vision for what GDSC could become on our campus. I talked about the Flutter Study Jams we'd already organized, the team I'd been building, and my experience as a Postman Student Leader. I shared my frustrations with the disconnect between what we learned in class and what the industry actually needed, and my belief that student communities could bridge that gap.

The interviewer asked me about challenges I anticipated, and I was honest about them - the difficulty of maintaining engagement, the challenge of teaching concepts I was still learning myself, and the pressure of living up to expectations. But I also talked about why I was willing to take on those challenges, about seeing students get excited about tech concepts, about the potential I saw in our campus community.

The waiting period between April and September felt endless. Every day I wondered if I'd said the right things, if I'd come across as confident enough, if they could tell how much this meant to me. When that acceptance email finally arrived, I read it three times before it sank in. I was officially going to be the GDSC Lead, and suddenly all those months of preparation felt real.

The Recruitment Revolution

September 2024 marked the beginning of what I like to call our "recruitment revolution," though that probably sounds more dramatic than it actually was. We had a new academic year starting, which meant hundreds of fresh first-year students who were curious, eager, and hadn't been discouraged by our campus's previously weak tech culture.

Our recruitment strategy was aggressive but welcoming. We didn't just put up posters and hope people would show up - we went to where the students were. We set up booths during orientation week, we visited first-year classes to give brief presentations, we organized "Introduction to Tech" sessions that were specifically designed for complete beginners. We wanted students to know that GDG on Campus(Structure changed) wasn't just for people who already knew how to code.

The response was incredible, but it also created new challenges. Suddenly we had students with wildly different skill levels all wanting to learn together. Some had never written a line of code, while others had been programming since high school. Some wanted to learn web development, others were interested in mobile apps, and a growing number were curious about AI and machine learning.

We decided to embrace this diversity instead of trying to segment everyone into different skill levels. We introduced new tech stacks that we'd never covered before - AI and ML became regular topics in our sessions, which was both exciting and terrifying because I was learning these concepts alongside everyone else. We organized Cloud Study Jams that introduced students to Google Cloud Platform, hosted Career Tech Talks where industry professionals shared real insights about working in tech, and ran workshops covering everything from basic programming concepts to advanced development frameworks.

The energy was infectious. Students were staying after sessions to ask questions, forming study groups on their own, collaborating on personal projects, and actually building things together. We weren't just a club anymore - we were becoming a real community where learning happened both during formal sessions and in the spaces between them.

DevFest 2024: From 10 to Over 40

When DevFest 2024 was announced, I knew this would be the ultimate test of how far we'd come. The previous year, I'd struggled to convince 10 people to attend. This year, we were looking at taking over 40 students, and they weren't just coming for the experience - they were coming because they were genuinely excited about what they might learn.

The logistics were a complete nightmare. Coordinating transport for that many people, managing registrations, collecting payments, making sure everyone knew what to expect, handling last-minute cancellations and additions - it was like running a small travel agency. But seeing that bus (yes, we could finally afford to rent an entire bus!) filled with excited students from our campus was one of the most rewarding moments of my entire journey.

The difference in our students' experience compared to my first DevFest was night and day. They weren't sitting there confused and overwhelmed - they were engaged, asking intelligent questions, taking notes, networking with other attendees, and actually understanding the presentations. During the lunch breaks, I watched our community members confidently approaching speakers to ask follow-up questions, exchanging contacts with students from other universities, and discussing project ideas with each other.

When we got back to campus, the energy didn't die down. Students were sharing what they'd learned, starting new projects inspired by what they'd seen, and recruiting their friends to join our community. By this time, we had grown to over 500 members, a number that still amazes me when I think about where we started. We weren't just a student club anymore - we were a movement, a family, a platform where students could discover their potential and actually do something meaningful with their skills.

Making It Official: Registration and Real Impact

One of the most important victories we achieved was getting GDSC officially registered with the university by September 2024. This might sound like boring administrative work, but it was actually a game-changer for everything we wanted to accomplish.

Before registration, we were essentially operating in the shadows. We couldn't officially book large venues for events, we couldn't access funding opportunities that were available to registered student organisations, we couldn't rent transport for trips, and we missed out on partnerships with external organisations that only worked with officially recognised groups.

The registration process itself was a masterclass in bureaucracy and patience. There were forms to fill out, constitutions to draft, faculty advisors to recruit, and endless back-and-forth with the student affairs office. But when we finally got that official approval, it opened doors we didn't even know existed.

This official status allowed us to host what became the first-ever student-led tech events at our campus - something that still makes me incredibly proud. We organised the ICP Hubs Kenya Campus Tour, bringing blockchain and Web3 education directly to our students. This wasn't just a one-hour presentation - it was a full-day event with hands-on workshops, networking opportunities, and real industry professionals sharing their expertise.

We also partnered with Moringa School to host a comprehensive Data Science and Cyber Security Workshop. As a Moringa Campus Ambassador (yes, I had started accumulating these titles), I was able to leverage that relationship to bring industry-standard training right to our doorstep. These weren't small club meetings held in empty classrooms - these were legitimate events with proper venues, professional speakers, and students from across different departments attending.

The impact of these events went beyond just the immediate learning outcomes. They showed our entire campus that students could organize meaningful, professional-quality events. They proved that there was genuine interest in practical tech skills. And they established GDSC as a serious organization that other groups and institutions wanted to partner with.

The Hidden Battles Nobody Saw

But behind all these successes, I was fighting battles that nobody could see, and this is the part of the story that I think is most important to share, especially for other student leaders who might be going through similar struggles.

Being a leader meant that people looked up to me, expected me to have answers, and assumed I had everything figured out. The reality was completely different. I was juggling my community responsibilities with a demanding ALX Software Engineering course that required hours of study every day. I was trying to maintain my academic performance, manage my personal relationships, and deal with family issues that would have been challenging for anyone, let alone a student trying to build a tech community from scratch.

Depression started creeping in during the quiet moments between events, when the adrenaline of organising wore off and I was left alone with the weight of everyone's expectations. There were nights when I'd sit in front of my laptop, knowing I had sessions to plan, reports to write, and team members depending on me, but feeling empty inside. The motivation just wasn't there, and the guilt of not being productive made everything worse.

Burnout became my constant companion. I'd wake up exhausted, drag myself through classes, force enthusiasm during sessions, and then collapse at the end of the day, only to repeat the cycle the next day. There were weeks when I considered quitting everything - Community, ALX, sometimes even university itself. The pressure felt overwhelming, and I wasn't sure I was strong enough to handle it all.

Imposter syndrome whispered in my ear constantly. When I was teaching concepts I'd learned just days before, when I was networking with industry professionals who seemed infinitely more knowledgeable, when students asked me questions I couldn't answer immediately - all of these moments made me feel like a fraud who would eventually be exposed.

The hardest part was that I couldn't show this vulnerable side to anyone. My team needed me to be strong and decisive. The community looked to me for direction and inspiration. My family expected me to be succeeding. Admitting my struggles felt like admitting failure, so I learned to hide behind a mask of competence and enthusiasm.

There were moments when that mask almost slipped completely. During particularly stressful periods, I'd find myself snapping at team members, making poor decisions because I was too tired to think clearly, or cancelling important meetings because I just couldn't handle one more responsibility. The people closest to me probably noticed that something was off, but I was too proud to ask for help.

Learning to Build in Public

Through all of this struggle, I learned one of the most valuable lessons of my entire journey: never build in the dark. This lesson came from the tech community itself, and it was revolutionary for someone who used to hide projects until they were "perfect."

Before joining tech communities, I had this mindset that everything needed to be polished and professional before sharing it with others. I'd work on projects alone, never showing them to anyone until I thought they were ready for judgment. This meant that most projects never got shared at all, because they never felt ready enough.

The tech community taught me a completely different approach. People shared their ugly code, their half-finished projects, their failed experiments, and their learning processes. Instead of being judged for these imperfections, they received helpful feedback, encouragement, and collaboration opportunities.

I started applying this principle to our GDSC community. Instead of only promoting events after they were perfectly planned, I'd share our planning process, ask for input from community members, and be transparent about challenges we were facing. Instead of only showcasing successful projects, we created spaces for people to share their work in progress, their learning struggles, and their experimental ideas.

This transparency transformed our community culture. Students stopped being afraid to ask questions because they saw that everyone was learning together. People started collaborating more because they could see where others needed help. Our events became better because we incorporated feedback during the planning process instead of only after the fact.

On a personal level, this principle helped me deal with my imposter syndrome. Instead of pretending I had all the answers, I started being honest about what I was learning alongside everyone else. Instead of hiding my struggles, I began sharing appropriate parts of my journey, which helped other students realize they weren't alone in their challenges.

The Google Recognition

When I applied to be a GDG on Campus Organiser in early 2024, it felt like a long shot. Here I was, a first-year student who had only been seriously involved in tech communities for about a year, applying for a position that would make me an official representative of Google's developer community program at the campus.

The application process was thorough - they wanted to know about my experience leading communities, my vision for tech education on campus, my plans for collaboration with local GDGs, and my commitment to diversity and inclusion in tech. I spent weeks crafting my responses, trying to balance honesty about my relatively short experience with confidence about what I could accomplish.

The waiting period was agonising. Months passed without any communication, and I started assuming I hadn't been selected. I continued with my GDSC leadership, but in the back of my mind, I kept wondering what I could have done differently in my application.

When the acceptance email finally came in August 2025, I had to read it several times before it sank in. Google had selected me to be a GDG on Campus Organizer, which meant our transition from GDSC to GDGoC (Google Developer Groups on Campus). This wasn't just a name change or a bureaucratic shift - it represented recognition of the work we'd been doing and trust in our ability to continue growing the community.

This transition also meant we'd be working more closely with local GDGs, sharing resources and expertise across different types of developer communities. It opened up new opportunities for our students to attend events beyond campus, to connect with working professionals in the tech industry, and to contribute to larger projects that extended beyond our university.

Looking back, this Google recognition felt like validation of a journey that had started with me feeling completely lost at DevFest 2023. In less than two years, I had gone from someone who didn't understand basic tech concepts to someone Google trusted to lead and build communities that would work hand in hand with their broader developer ecosystem.

The Mentorship Gap That Shaped My Leadership

One area where my journey has been particularly difficult is mentorship - or rather, the complete lack of it. I've never had a proper mentor, and honestly, I've become somewhat resistant to the idea because of a painful experience that happened right after high school.

I had identified someone in the tech industry who I thought could guide me, and I reached out with genuine enthusiasm, asking for advice about getting started in technology. Instead of a polite decline or even constructive feedback, this person blocked me without explanation. That rejection left scars, making me hesitant to seek guidance from industry professionals even when I desperately needed it.

Instead of having someone to turn to for advice, I learned to be incredibly resourceful. I found answers through online communities, documentation, trial and error, and countless hours of self-directed learning. While this made me more independent and probably more creative in solving problems, I sometimes wonder how different my journey might have been with proper mentorship.

The lack of mentorship also meant that I made mistakes that could have been easily avoided, took longer paths to solutions that already existed, and struggled with decisions that an experienced mentor could have helped me navigate. There were times when I felt completely alone in my leadership role, unsure if the decisions I was making were right, with nobody to provide perspective or encouragement.

This experience has profoundly shaped how I approach mentorship within our community. Despite not having a mentor myself - or maybe because of it - I've tried to be the mentor figure I wish I'd had for the students in our community. I make myself available for questions, provide guidance and support, share my learning resources, and most importantly, I never make anyone feel stupid for asking basic questions or needing help with fundamental concepts.

I always tell aspiring leaders and students in our community to find mentors, but I also try to prepare them for the possibility of rejection. Don't let one bad experience close you off from the wisdom and guidance that could accelerate your growth, but also don't let the absence of formal mentorship stop you from pursuing your goals.

Creating a Platform for Real Learning

What I'm most proud of in this entire journey is the platform we created for students to learn skills that simply aren't taught in our regular classes. This wasn't just about adding more technical content to people's lives - it was about fundamentally changing how students on our campus thought about technology and their own potential.

When I first started at university, there was this massive gap between what we learned in lectures and what was actually happening in the tech industry. We'd study theoretical concepts in isolation, complete assignments that felt disconnected from real-world applications, and graduate without ever building anything meaningful or collaborative.

Through our community, we were able to bridge that gap. Students learned to work with APIs through our Postman sessions, built real mobile applications during Flutter Study Jams, deployed projects to the cloud through our Google Cloud workshops, and most importantly, learned to work together on projects that actually mattered to them.

But the learning went beyond just technical skills. Students learned to present their work confidently, to give and receive feedback constructively, to collaborate with people who had different skill levels and perspectives, and to persist through frustrating debugging sessions and failed experiments. These are the skills that actually matter in professional environments, and they're almost impossible to learn through traditional classroom instruction alone.

Our community also became a platform for students to showcase their work, connect with opportunities, and build genuine relationships. People found collaborators for hackathons, co-founders for startup ideas, mentors among older students, and friends who shared their interests and ambitions. The networking aspect happened naturally because it was built on shared learning experiences and mutual support rather than transactional exchanges.

We created an environment where it was safe to be a beginner, where asking questions was encouraged, where failure was treated as part of the learning process, and where everyone was expected to help others along the way. This community culture transformed not just individual students, but the entire tech ecosystem on our campus.

Looking around now, I see students who joined as complete beginners leading their own projects, organizing their own events, and mentoring newer members. I see projects that started in our workshops turning into viable products and even small businesses. I see alumni who credit their community experience with helping them land their first tech jobs or get accepted into competitive graduate programs.

Where This Journey Has Led Me

As I write this, reflecting on everything that's happened since that disappointing bus ride back from DevFest 2023, I'm amazed at how much can change in just two years. The confused first-year student who felt like he knew nothing about tech has become someone who leads communities, organizes large-scale events, partners with major organizations, and helps other students discover their own potential.

This journey has taken me into rooms I never thought I'd enter and connected me with people I never imagined I'd meet. I've presented at tech conferences, partnered with international organizations, been recognized by Google as a community leader, and most importantly, helped hundreds of students begin their own tech journeys with more support and direction than I had when I started.

But the real transformation isn't in the titles or recognitions - it's in how fundamentally my relationship with learning and leadership has changed. I no longer wait for permission to start building something meaningful. I no longer assume that someone else is better qualified to solve problems I care about. I no longer hide my work until it's perfect, and I no longer let fear of failure prevent me from trying new things.

The communities that once intimidated me have become the foundation of my growth, and now I have the opportunity to build communities that will hopefully do the same thing for other students who are where I was two years ago - confused, eager, and ready to learn if someone just shows them where to start.

The experience has taught me that leadership isn't about having all the answers - it's about being willing to ask the right questions and work toward solutions alongside other people who care about the same things. Community building isn't about creating perfect events and flawless programs - it's about creating spaces where people can learn, grow, and support each other through the messy, exciting process of discovering what they're capable of.

And perhaps most importantly, I've learned that the best way to overcome imposter syndrome isn't to become an expert at everything - it's to embrace the fact that we're all learning together, and that teaching others is one of the most effective ways to deepen your own understanding.

If you're reading this as someone who feels lost in tech, who doesn't think you belong in these communities, or who thinks you need to have everything figured out before you can contribute, I hope my story shows you that none of those things are true. Communities are built by people who care, not by people who already know everything. Your journey starts with showing up, asking questions, and being willing to learn alongside others who are on similar paths.

The tech world needs more people who are willing to build communities, support beginners, and create platforms for learning that go beyond what traditional education provides. It needs people who understand that the most valuable technical skills are often the ones we learn together, and that the most meaningful projects are the ones that help other people grow.

That's what communities have given me, and that's what I hope to give back through the communities I'm building now.

This post is a detailed log of my first time deploying a real application on GKE. I'm starting from scratch, explaining the core concepts, the commands I used, and, most importantly, the errors I hit and how I fixed them. If you're new to this, I hope my journey helps clarify yours a bit.

Before We Start: The Core Concepts

Before we even touch the cloud, we need to get a few key terms straight. I had to wrap my head around these before anything else made sense.

1. What is a Container? (And Docker?)

A container is a standard package that holds everything your application needs to run: the code, its libraries, and its settings. The best analogy is a musician's custom-built flight case. It has the instrument, the sheet music, the stand—everything. With this case, the musician can show up to any venue in the world, open it up, and perform perfectly without needing anything from the venue itself.

Docker is the tool you use to build these "flight cases." It’s a platform that lets you package your application into a portable container image.

2. What is Kubernetes? (often called K8s)

If one container is one musician, what happens when your application gets big and you need a whole orchestra of them? This is where Kubernetes comes in. Kubernetes is the conductor. It's an open-source system that manages all of your containers (the orchestra) for you. Its job is to:

• Schedule: Decide which musician plays on which part of the stage.

• Scale: If a song needs more violins, it brings on more violinists (adds more containers).

• Self-heal: If a trumpeter suddenly gets sick (a container crashes), it immediately brings in a replacement so the show goes on.

3. What is Google Kubernetes Engine (GKE)?
While Kubernetes is the conductor, it still needs a place to perform. GKE is a world-class concert hall managed by Google. You could build your concert hall (run Kubernetes on your servers), but that's a massive amount of work. GKE provides a ready-to-go, reliable environment. Google's team handles the difficult parts—like the building's electricity, security, and maintenance—so you can focus purely on being the conductor and making sure your application (the music) is great.

With that, let's get started.

Step 1: Setting Up the Concert Hall (The GKE Cluster)

The first step was to create a cluster. A cluster is the foundation of GKE—it's a set of computer resources (called "nodes") that will run our containers. This is the digital venue where our performance will take place.

I chose to create my cluster in Autopilot mode. In GKE, you have two choices:

• Standard Mode: You manually choose the size and number of machines (nodes) for your cluster. You have more control, but you're also responsible for managing them.

• Autopilot Mode: You just tell GKE to run your applications, and it figures out how much computing power is needed. It automatically adds or removes nodes as required.

For a beginner, Autopilot is perfect. You don't have to worry about managing the underlying servers, and you only pay for the resources your apps consume. After a few minutes of setup in the Google Cloud Console, my cluster was live.

Step 2: Getting the First Musician on Stage (Deploying an App)

Now that the venue was ready, it was time to deploy my first application. All interactions with a Kubernetes cluster happen through a command-line tool called kubectl. Think of it as the conductor's baton; it’s the tool we use to give instructions to our orchestra.

I started with a command to create a Deployment.

kubectl create deployment hello-server --image=us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

A Deployment is a Kubernetes object that acts as a manager for your app. You tell it, "I want one copy of my 'hello-server' app running at all times." The Deployment's job is to make that happen. If your app crashes, the Deployment will automatically start a new one. It’s like hiring a dedicated manager for your string section, whose only job is to ensure the right number of musicians are always on stage and ready to play.

I hit enter and immediately got an error.

error: failed to create deployment... connect: connection refused

This was my first real-world debugging moment. The error meant my kubectl tool wasn't authenticated to talk to my new GKE cluster. The fix was to run a gcloud command to fetch the credentials and configure kubectl for me. This command essentially connected my conductor's podium to the concert hall's sound system, so my instructions could finally be heard.

gcloud container clusters get-credentials musical-cluster --region us-central1

I ran the deployment command again, and this time it worked. My app was running.

However, it was only running inside the cluster. No one from the outside world could access it. To make it publicly available, I had to create a Service.

kubectl expose deployment hello-server --type=LoadBalancer --port 80 --target-port 8080

A Service provides a stable network endpoint (like an IP address) for your application. By setting type=LoadBalancer, I told GKE to provision a real, external cloud load balancer from Google's network, assign it a public IP, and automatically send any traffic to my running app. In our analogy, this is like setting up the main entrance and hiring ushers. The ushers (the Load Balancer) guide the audience to the musician who is ready to play.

After a minute, the external IP was ready. I pasted it into my browser, and there it was.

Step 3: Adding More Musicians (Scaling the Application)

My single app was running fine, but a real application needs to handle lots of users. This means I needed to scale out by adding more copies, or replicas.

This is where the power of the Deployment object shows. With a single wave of the conductor's baton, I told the orchestra manager to expand the section.

kubectl scale deployment hello-server --replicas=3

This command updated the Deployment object, changing its desired state from 1 replica to 3. Kubernetes immediately saw the difference and started two new, identical copies of my app to match the new state.

The Service I created in the previous step automatically detected these new copies and started distributing traffic between all three of them. I could prove this by going back to the browser and refreshing the page. The Hostname value at the bottom changed every few refreshes, showing my request was being handled by a different replica each time. It was a simple but powerful demonstration of scaling and load balancing.

Step 4: The Update That Almost Failed

The final test was to update the application to a new version, 2.0.0, without any downtime. Kubernetes is designed to do this with a rolling update strategy. It replaces old app containers with new ones gradually, one by one, ensuring the application is always available. The goal was to give all the musicians a new sheet of music without interrupting the concert for the audience.

I ran the command to tell my Deployment to use the new image:

kubectl set image deployment/hello-server hello-app=us-docker.pkg.dev/google-samples/containers/gke/hello-app:2.0

I watched the status and saw that GKE was trying to start a new container with the 2.0 image, but it got stuck in a Pending state. This meant the new musician, holding the new sheet music, was waiting backstage, but there was no empty chair for them on the stage. The good news was that my old 1.0 replicas were still running, so my website was still live. But the update was failing.

To find out why, I used the most important command for Kubernetes troubleshooting: kubectl describe pod. This gives you a detailed event log for a specific pod.

kubectl describe pod <name-of-the-pending-pod>

The answer was in the Events section at the bottom. The analogy clicked instantly. My stage crew (Autopilot) went to the lumberyard (Google's infrastructure) to get wood for a new chair, but the yard owner said, 'Sorry, your account has hit its safety limit for today. No more materials for you.'

This was a huge learning moment. All Google Cloud projects have quotas, which are safety limits on resource usage. A rolling update temporarily requires more resources than normal because, for a moment, both old and new app replicas need to exist. My project's quota was too low to allow for this temporary increase.

Here’s the workaround I followed:

1. First, I undid the failed update to get back to a stable state:

    kubectl rollout undo deployment/hello-server
   

2. Next, I made some room by scaling the old application down from 3 replicas to 2:

    kubectl scale deployment hello-server --replicas=2
   

3. With the resources freed up, I ran the set image update command again. This time it worked, replacing the two old replicas with two new ones.

4. Finally, I scaled the now-updated application back up to 3 replicas:

    kubectl scale deployment hello-server --replicas=3
   

It was a valuable lesson in how cloud resource limits affect application management. After that, I refreshed my browser and saw "Version: 2.0.0." The update was complete.

Final Thoughts

My first dive into GKE was a success. The most important takeaway for me was that the errors were the best part of the experience. Hitting the authentication and quota issues forced me to learn how to debug, which is a far more useful skill than just following a tutorial that works perfectly. I was also genuinely impressed with how GKE automates complex tasks like scaling and load balancing with just a few commands.

The concert is just getting started.

Have you ever connected your computer to a network and found that you can't access the internet, but you can somehow still see other computers nearby? You might have encountered APIPA without knowing it.

APIPA stands for "Automatic Private IP Addressing." Think of it as your computer's emergency backup plan when things go wrong with your network connection.

How Networks Usually Work

Normally, when you connect your computer to a network, it asks a special server called a DHCP server: "Hey, can I get an IP address so I can join this network?" The DHCP server then gives your computer all the information it needs:

• An IP address (like 192.168.1.100)

• A gateway (the door to the internet)

• DNS servers (phone books for the internet)

This is like checking into a hotel - the front desk gives you a room number and tells you how to find the elevator and restaurant.

When Things Go Wrong

But what happens when the DHCP server is broken, unreachable, or simply doesn't exist? Your computer doesn't just give up. Instead, it says, "Fine, I'll make my IP address!"

This is where APIPA kicks in.

What APIPA Does

When your computer can't get an IP address from a DHCP server, APIPA automatically assigns itself an address that starts with 169.254. You'll see something like:

• 169.254.23.45

• 169.254.156.78

• 169.254.1.200

Think of this as your computer creating a temporary name tag for itself when there's no official host to give it one.

The Good and Bad of APIPA

The Good:

• Computers with APIPA addresses can talk to each other on the same network

• You can share files between nearby computers

• It's better than having no network connection at all

The Bad:

• No internet access (no gateway to the outside world)

• Can't reach devices outside your immediate network

• Usually means something is broken

How to Spot APIPA

On Windows, open Command Prompt and type:

ipconfig

If you see an IP address starting with 169.254, you've got APIPA.

On the surface, your computer might look "connected" to the network, but you'll notice:

• Websites won't load

• Email won't work

• You can't reach anything outside your local area

What APIPA Means

When you see a 169.254 address, your computer is essentially saying: "I tried to join the network properly, but something went wrong. I'm doing the best I can with what I have."

It's like showing up to a conference where the registration desk is closed - you can still talk to other people who showed up, but you can't get into the main event.

Real-World Examples of APIPA

Example 1: The Home Router Power Outage

Your home internet was working fine yesterday. Today, your computer shows it's connected to your WiFi, but you can't browse anything. After a power outage last night, your router came back online, but the DHCP service inside it didn't start properly. Your computer connects to the WiFi signal but gets an APIPA address like 169.254.78.234 instead of your usual 192.168.1.something.

Example 2: The New Ethernet Cable

You just moved your desk and bought a new 50-foot Ethernet cable from the store. Everything plugs in fine, but you keep getting 169.254 addresses. Turns out, the cheap cable you bought has a broken wire inside - your computer can partially communicate with the network but can't reach the DHCP server reliably.

Example 3: The Overpacked Office Network

It's Monday morning in a busy office. The DHCP server is configured to hand out only 50 IP addresses, but 60 people are trying to connect their laptops after the weekend. The first 50 people get normal addresses like 192.168.1.25, but employees 51-60 end up with APIPA addresses and can't access company resources.

Example 4: The Wrong Network Jack

You plug your laptop into a wall jack in a conference room. The port seems to work (link lights are on), but you get 169.254.156.89. Later, you discover this wall jack connects to an isolated network segment used for security cameras, not the main office network with internet access.

Common Scenarios Where APIPA Appears

1. Cable Problems: The Network cable is unplugged, damaged, or of poor quality

2. Switch Issues: The network switch is down, misconfigured, or the port is disabled

3. DHCP Server Problems: The server that hands out IP addresses is broken or overwhelmed

4. Wrong Network: You're connected to a network segment that doesn't have DHCP

5. Network Congestion: Too many devices are trying to get addresses from a limited pool

6. VLAN Misconfiguration: Your computer is on the wrong VLAN and can't reach the DHCP server

7. Router/Modem Issues: Home router's DHCP service crashed after a power outage

Troubleshooting APIPA: Step-by-Step

Level 1: Quick Fixes (Try These First)

Scenario: You just noticed your computer has a 169.254 address and no internet.

1. The Unplug-Replug Test

   • Unplug your Ethernet cable, wait 10 seconds, plug it back in

   • For WiFi: Disconnect and reconnect to the network

   • Wait 30 seconds and check your IP address again

2. The Network Restart

   • Right-click your network icon in the system tray

   • Select "Disable" then "Enable" your network adapter

   • Or open Command Prompt as administrator and type:

       ipconfig /release
       ipconfig /renew
     

3. The Computer Restart

   • Sometimes Windows gets confused - a restart clears everything

   • This fixes about 30% of APIPA issues

Level 2: Physical Investigation

Scenario: Quick fixes didn't work, time to check the hardware.

1. Cable Detective Work

   • Try a different Ethernet cable if you have one

   • Look for visible damage: bent connectors, crushed cable

   • Test the same cable on a different computer

   • Wiggle the cable at both ends - does the connection drop?

2. Port Testing

   • Try a different wall jack or switch port

   • Check if the port lights up when you plug in

   • Ask a colleague if their computer works in the same location

3. WiFi Signal Check

   • Move closer to the WiFi router

   • Try connecting a different device (phone, tablet)

   • Check if you can see other WiFi networks from the same location

Level 3: Network Infrastructure

Scenario: Your connection is physically fine, but APIPA persists.

1. DHCP Server Health Check

   • Ask IT or check if others are having the same problem

   • For home networks: restart your router (unplug for 30 seconds)

   • Check the router admin panel for DHCP settings

2. Address Pool Investigation

   • In busy environments, DHCP might be out of addresses

   • Try connecting at different times of day

   • Ask the administrator to check the DHCP lease table

Level 4: Advanced Troubleshooting

Scenario: Everything seems fine, but APIPA won't go away.

1. VLAN and Network Segmentation

   • You might be on the wrong network segment

   • Check with the network administrator about the proper VLAN assignment

   • Some wall jacks connect to isolated networks

2. Network Adapter Issues

   • Update network card drivers

   • Check Device Manager for yellow warning signs

   • Try a different network adapter if available

Why Understanding APIPA Helps

Recognising APIPA saves you time and frustration. Instead of wondering "Why is my internet so slow?" or "Why can't I reach anything?", you'll immediately know to look at the network infrastructure rather than your computer settings.

Key Takeaway

APIPA isn't the problem - it's a symptom that tells a story. When you see those 169.254 addresses, your computer is essentially saying, "I tried my best to join the network, but something in the infrastructure isn't working properly."

Think of APIPA as your network's equivalent of a car's "check engine" light. The light itself isn't broken - it's warning you that something else needs attention.

Remember:

• APIPA = 169.254.x.x addresses

• It means DHCP failed, not that your computer is broken

• You can still communicate locally, but no internet access

• It's always fixable once you find the root cause

Remember: Every network problem is solvable. The key is understanding what your computer is trying to tell you.

When I set up NGINX, the first thing I encountered was its default page. It was clean and simple, but not what I needed. My goal was to display my website instead, so I began exploring how everything works. That’s when I realised that NGINX is built around configuration files. It has a default setup that works well for testing, but if you want to serve your site, you need to configure it yourself.

I created a new config file for my site and linked it to NGINX, expecting everything to work immediately. However, my website was still missing, and I kept landing on the default page. After some digging, I learned that the default config was still active, so I had to disable it and properly enable mine. It seems simple now, but at the time, I struggled to understand what details I was missing.

While working through this, I stumbled upon the concept of a reverse proxy. At first, it felt complicated, but after reading and experimenting, I realised how useful it is. A reverse proxy sits in the middle, taking user requests and forwarding them to another server. This not only protects your backend but also helps manage traffic more effectively.

I also explored the idea of load balancing. Although I’m not using multiple servers yet, I found it fascinating how NGINX can distribute traffic across several servers to prevent any single server from becoming overwhelmed. For now, it’s just the knowledge I’m storing for when I eventually scale my projects.

I’m eager to dive deeper into NGINX, especially as my projects grow and I take on more challenging setups.

If you’ve worked with NGINX, I’d love to hear about your first experience. Let’s exchange ideas and keep learning!

Time to go big! Module 7 was about scaling from a simple guest network to a full enterprise architecture. My mission: design a complete four-department network for Tech Innovators Kenya Ltd with proper security policies that won't kill the router's CPU.

The Enterprise Challenge

The Goal: Scale from simple guest WiFi to complete enterprise network segmentation
The Departments: Management, Development, Sales, plus Guests (4 VLANs total)
The Challenge: Create security policies that are both effective and CPU-efficient
The Reality: Small router hardware handling enterprise-level complexity

Building the Complete VLAN Infrastructure

I took initiative and built out the Development and Sales VLANs independently, applying the patterns I'd learned from the Guest network.

The Complete Network Design

Management VLAN 10: 192.168.10.1/24 (executives, high security)
Development VLAN 20: 192.168.20.1/24 (engineers, development resources)
Sales VLAN 30: 192.168.30.1/24 (marketing, sales operations)
Guest VLAN 40: 192.168.40.1/24 (visitors, internet-only access)
Main LAN: 192.168.88.1/24 (original infrastructure)

Each department gets:

• Its IP address range

• Dedicated DHCP server

• Automatic DNS configuration

• Gateway services through the router

The "That's Too Basic" Moment

After setting up all the VLANs, I had a realisation: "Management department being so secure... it seems so basic"

The Problem: Just separating networks into VLANs doesn't provide security - it's just organization.

The Reality Check: Network separation without security policies is like having separate rooms in a house with no locks on the doors.

This led to understanding the difference between network organization and security implementation.

The Scalability Question

Looking at my growing list of VLANs, I asked the critical question: "If I have 20 departments, won't managing individual firewall rules become impossible?"

This is where enterprise networking gets real. You need scalable security architectures, not individual rules for every department.

Three Approaches to Enterprise Security

Method 1: Individual Rules (Doesn't Scale)

# This approach becomes unmanageable quickly
/ip firewall filter add chain=forward src-address=192.168.10.0/24 dst-address=192.168.20.0/24 action=drop
/ip firewall filter add chain=forward src-address=192.168.10.0/24 dst-address=192.168.30.0/24 action=drop
# ... (multiply this by every department pair)

Method 2: Address Lists (Medium Enterprise)

# Group networks into logical security zones
/ip firewall address-list add list=Internal-Networks address=192.168.10.0/24
/ip firewall address-list add list=Internal-Networks address=192.168.20.0/24
/ip firewall address-list add list=Internal-Networks address=192.168.30.0/24

Method 3: VLAN-Based Firewall (True Enterprise)

This is what major ISPs and enterprises use - firewall rules that operate at the VLAN level rather than the IP level.

My Choice: Method 2 for practical learning, with recognition that Method 3 is the enterprise standard.

Building Production-Grade Security Architecture

Creating Security Zones

Instead of thinking about individual departments, I organised networks into security zones:

# Department-specific lists
/ip firewall address-list add list=Management address=192.168.10.0/24 comment="Management Department"
/ip firewall address-list add list=Development address=192.168.20.0/24 comment="Development Department"  
/ip firewall address-list add list=Sales address=192.168.30.0/24 comment="Sales Department"
/ip firewall address-list add list=Guests address=192.168.40.0/24 comment="Guest Network"

# Security zone groupings
/ip firewall address-list add list=Internal-Networks address=192.168.10.0/24 comment="Management"
/ip firewall address-list add list=Internal-Networks address=192.168.20.0/24 comment="Development"  
/ip firewall address-list add list=Internal-Networks address=192.168.30.0/24 comment="Sales"
/ip firewall address-list add list=Privileged-Networks address=192.168.10.0/24 comment="Management - Full Access"
/ip firewall address-list add list=Restricted-Networks address=192.168.40.0/24 comment="Guests - Internet Only"

The Four-Rule Security Policy

Instead of potentially 20+ individual rules, I created just 4 strategic rules:

# Rule 1: Management gets access to everything (executive oversight)
/ip firewall filter add chain=forward src-address-list=Privileged-Networks action=accept comment="Management full access"

# Rule 2: Guests can't reach company resources (security boundary)  
/ip firewall filter add chain=forward src-address-list=Restricted-Networks dst-address-list=Internal-Networks action=drop comment="Guest isolation"

# Rule 3: All internal departments get internet access (business operations)
/ip firewall filter add chain=forward src-address-list=Internal-Networks action=accept comment="Internal internet access"

# Rule 4: Departments can't talk to each other (security segmentation)
/ip firewall filter add chain=forward src-address-list=Internal-Networks dst-address-list=Internal-Networks action=drop comment="Department isolation"

This elegant solution:

• ✅ Gives Management full network access

• ✅ Blocks guests from company resources

• ✅ Allows all departments internet access

• ✅ Prevents inter-department communication

• ✅ Scales to unlimited departments without adding rules

Router-on-a-Stick Magic

The Concept: One router providing routing services for multiple VLANs.

How It Works: The router automatically provides layer 3 routing between VLANs without additional configuration.

The Result: Each department can reach its gateway (192.168.x.1) and the internet, but department-to-department traffic is controlled by firewall rules.

RouterOS handles this automatically - no complex routing protocols needed for basic inter-VLAN routing.

The Performance Reality Check

Hardware Limitations Discovered

My HAP Lite router started showing strain:

• High CPU usage during complex operations

• Multiple DHCP servers (5 total) are consuming resources

• Complex firewall processing with address list evaluations

• Bridge learning overhead, managing MAC addresses across VLANs

ISP Professional Advice

A friend working at an ISP warned me, "MikroTik routers can struggle with high rule counts. Keep it efficient."

The Trade-off: Functionality vs. performance on limited hardware.

My Decision: Continue with the current setup for learning, but understand the scaling limitations.

Enterprise Routing in Action

The final routing table showed the router handling multiple network segments:

# /ip route print
0 A S  0.0.0.0/0           192.168.100.1    (default internet route)
1 ADC  192.168.10.0/24     Management-VLAN  (Management gateway)
2 ADC  192.168.20.0/24     Development-VLAN (Development gateway)  
3 ADC  192.168.30.0/24     Sales-VLAN       (Sales gateway)
4 ADC  192.168.40.0/24     Guest-VLAN       (Guest gateway)
5 ADC  192.168.88.0/24     LAN-Bridge       (Original LAN)

The router was simultaneously acting as:

• Gateway for 5 different networks

• DHCP server for 5 different networks

• Firewall enforcing inter-network policies

• NAT provider for internet access

Key Technical Skills Demonstrated

Scalable Architecture Design

# Address list management (scales to unlimited departments)
/ip firewall address-list add list=Security-Zone address=network-range comment="description"

# Strategic firewall rules (minimal count, maximum coverage)
/ip firewall filter add chain=forward src-address-list=source dst-address-list=destination action=policy comment="purpose"

# VLAN interface creation pattern
/interface vlan add name="Department-VLAN" vlan-id=XX interface=LAN-Bridge
/ip address add address=192.168.XX.1/24 interface=Department-VLAN

Performance-Conscious Implementation

• Rule efficiency: Address lists instead of individual IP rules

• Processing optimisation: Strategic rule placement for minimal CPU impact

• Scalable design: Architecture supporting growth without linear complexity increase

What I Achieved

Complete Enterprise Network Infrastructure:

• ✅ 4-department VLAN segmentation with proper IP addressing

• ✅ Scalable security framework supporting unlimited department growth

• ✅ CPU-optimised firewall rules (4 rules instead of 20+)

• ✅ Professional inter-VLAN routing with centralised internet access

• ✅ Department-specific DHCP services with automatic configuration

Security Policy Implementation:

• ✅ Management privilege elevation (executive access to all resources)

• ✅ Guest network isolation (internet-only access)

• ✅ Department segmentation (preventing lateral movement)

• ✅ Centralised internet access (controlled outbound connectivity)

From Small Office to Enterprise Scale

Module 7 was where I stopped thinking like a home user and started thinking like a network architect.

The key insights:

1. Network organization ≠ Network security - VLANs need security policies

2. Scalability matters from day one - Architecture decisions affect long-term maintainability

3. Performance is always a constraint - Enterprise features require enterprise hardware

4. Address lists are powerful - They enable policy-based networking at scale

The Real-World Connection

The security architecture I built mirrors what you'd find in:

• Corporate offices (department-based network segmentation)

• Hotels (guest isolation with different service levels)

• Schools (student/faculty/admin network separation)

• Hospitals (patient/medical/administrative network isolation)

The scale changes, but the fundamental concepts remain the same.

Understanding these patterns prepared me for the next phase of the challenge - where network complexity would increase even further with load balancing, VPNs, and advanced traffic management.

This is part of my MikroTik Zero to Hero challenge. Enterprise networking: where architecture decisions made early determine how far you can scale.

Time to tackle wireless networking! My mission: create a professional WiFi setup for "Tech Innovators Kenya Ltd" - a software development company needing secure employee WiFi plus isolated guest access. This is where networking gets real.

The Business Problem

The Company: Tech Innovators Kenya Ltd (25 employees + daily visitors)
The Challenge: Provide WiFi for employees while keeping guest traffic completely separated
The Risk: Guests accessing company servers, client data, or internal resources
The Solution: Dual-SSID setup with VLAN isolation

Starting Fresh (And Why I Had To)

I hit a roadblock right away. My router was controlled by something called "CAPsMAN" from previous configuration attempts, and I couldn't control the wireless interface.

Decision: Complete router reset and rebuild everything from scratch.

Challenge accepted! I rebuilt Modules 1-5 from memory in just 10 minutes. This proved I'd learned the fundamentals, not just copied commands.

Within minutes, I had:

• System identity and time sync ✓

• WAN/LAN separation ✓

• DHCP server and IP pools ✓

• Firewall rules and NAT ✓

• Internet connectivity is working ✓

Designing the Network Architecture

Main Network (Employees):

• SSID: TechInnovators-Main

• Network: 192.168.88.0/24 (existing LAN)

• Access: Full company resources + internet

Guest Network (Visitors):

• SSID: TechInnovators-Guest

• Network: 192.168.40.0/24 (new VLAN 40)

• Access: Internet only, no company resources

Building the Guest Network Infrastructure

Step 1: Create the Guest VLAN

/interface vlan add name="Guest-VLAN" vlan-id=40 interface=LAN-Bridge
/ip address add address=192.168.40.1/24 interface=Guest-VLAN

This creates a completely separate network segment for guests.

Step 2: Set Up Guest DHCP Service

/ip pool add name=Guest-Pool ranges=192.168.40.100-192.168.40.150
/ip dhcp-server add name=Guest-DHCP interface=Guest-VLAN address-pool=Guest-Pool
/ip dhcp-server network add address=192.168.40.0/24 gateway=192.168.40.1 dns-server=8.8.8.8,1.1.1.1

Important discovery: The DHCP server was created disabled! Had to enable it:

/ip dhcp-server enable Guest-DHCP

RouterOS always creates DHCP servers in a disabled state for safety.

Step 3: Create Guest WiFi Security

/interface wireless security-profiles add name="TechInnovators-Guest-Security" mode=dynamic-keys authentication-types=wpa2-psk unicast-ciphers=aes-ccm group-ciphers=aes-ccm wpa2-pre-shared-key="Guest2024!"

Professional but visitor-friendly password that's easy to share.

Step 4: Create the Guest Virtual Interface

/interface wireless add name="wlan-guest" master-interface=wlan1 ssid="TechInnovators-Guest" security-profile="TechInnovators-Guest-Security" vlan-mode=use-tag vlan-id=40

This creates a virtual WiFi interface that tags all traffic with VLAN 40.

Step 5: Connect Guest WiFi to Guest VLAN

/interface bridge port add interface=wlan-guest bridge=LAN-Bridge pvid=40

The pvid=40 ensures all traffic from this interface gets VLAN 40 tags.

Securing the Main Employee Network

Security Problem Discovered: The main WiFi was created with no encryption - completely open!

Professional Response: Immediate security implementation.

/interface wireless security-profiles add name="TechInnovators-Main-Security" mode=dynamic-keys authentication-types=wpa2-psk unicast-ciphers=aes-ccm group-ciphers=aes-ccm wpa2-pre-shared-key="TechStaff2024!"

/interface wireless set wlan1 mode=ap-bridge ssid="TechInnovators-Main" security-profile="TechInnovators-Main-Security" disabled=no

The Critical Service Disruption (And Recovery)

Disaster: While configuring VLANs, I accidentally deleted the main LAN DHCP server!

Symptom: My laptop suddenly got 169.254.x.x address and lost network access.

Emergency Recovery:

/ip dhcp-server add name=LAN-DHCP interface=LAN-Bridge address-pool=LAN-Pool
/ip dhcp-server enable LAN-DHCP

Lesson learned: Always verify core services remain intact after making changes.

Solving Guest Internet Access

Guests could connect to WiFi, but couldn't browse the internet. The problem was in two places:

Missing NAT Rule

/ip firewall nat add chain=srcnat src-address=192.168.40.0/24 out-interface="ISP Router" action=masquerade comment="Guest internet access"

Missing Firewall Rule

/ip firewall filter add chain=forward src-address=192.168.40.0/24 action=accept comment="Allow guest to internet"

Success! Guests could now browse the internet while being completely isolated from the company network.

Adding Professional Security Features

MAC Address Filtering for Employee Network

/interface wireless access-list add interface=wlan1 mac-address=F4:30:B9:13:C1:55 authentication=yes comment="Alex Laptop"
/interface wireless set wlan1 default-authentication=no

This creates a whitelist - only authorized devices can connect to the main network.

Channel Optimization

I set the wireless channel to 6 (2437 MHz) after analyzing the local spectrum for minimal interference.

Network Isolation Verification

Employee Network Test:

• ✅ Can access company resources (192.168.88.x)

• ✅ Can access the internet

• ✅ Can ping and manage the router

Guest Network Test:

• ✅ Can access the internet

• ❌ Cannot reach company resources (192.168.88.x)

• ❌ Cannot ping the router management interface

Perfect isolation achieved!

The Complete Architecture

Traffic Flow - Employees:

Employee Device → wlan1 → LAN-Bridge → Company Resources + Internet

Traffic Flow - Guests:

Guest Device → wlan-guest → VLAN 40 → Internet Only

Security Boundary: VLAN-based isolation prevents any guest access to the company infrastructure.

Professional Skills Demonstrated

Security-First Mindset

• Immediate identification of open network vulnerability

• Implementation of WPA2 encryption and MAC filtering

• Multiple layers of defence (VLAN isolation + firewall rules)

Troubleshooting Under Pressure

• Rapid diagnosis of DHCP server deletion

• Systematic approach to connectivity issues

• Layer-by-layer verification (DHCP → NAT → Firewall)

Enterprise Architecture Understanding

• Recognition that a single router setup has scaling limitations

• Understanding of how dedicated APs work in real businesses

• Foundation concepts applicable to enterprise equipment

Key Commands for Wireless Networks

# VLAN Creation
/interface vlan add name="Guest-VLAN" vlan-id=40 interface=LAN-Bridge
/ip address add address=192.168.40.1/24 interface=Guest-VLAN

# Wireless Security Profiles
/interface wireless security-profiles add name="Profile-Name" mode=dynamic-keys authentication-types=wpa2-psk unicast-ciphers=aes-ccm group-ciphers=aes-ccm wpa2-pre-shared-key="Password"

# Virtual Wireless Interface
/interface wireless add name="wlan-guest" master-interface=wlan1 ssid="Network-Name" security-profile="Security-Profile" vlan-mode=use-tag vlan-id=40

# Bridge Integration with VLAN
/interface bridge port add interface=wlan-guest bridge=LAN-Bridge pvid=40

# MAC Address Filtering
/interface wireless access-list add interface=wlan1 mac-address=MAC-ADDRESS authentication=yes
/interface wireless set wlan1 default-authentication=no

What I Achieved

Final Network Architecture:

• Main SSID: TechInnovators-Main (WPA2, MAC filtering, full access)

• Guest SSID: TechInnovators-Guest (WPA2, internet only, isolated)

• Security: Complete separation between employee and visitor traffic

• Automation: Both networks provide automatic IP assignment

• Compliance: Network isolation supporting data protection requirements

From Basic Connectivity to Professional Infrastructure

Module 6 was a huge leap forward. I went from understanding basic wireless concepts to implementing enterprise-grade network segmentation.

The accidental DHCP server deletion was valuable - it proved I could diagnose and recover from service disruptions under pressure. That's a critical skill for any network administrator.

Most importantly, I learned that professional networking isn't just about making things work - it's about making them work securely, reliably, and with proper isolation between different user groups.

The guest network isolation I built here is the same concept used in hotels, coffee shops, and corporate offices worldwide. The scale changes, but the fundamental principles remain the same.

This is part of my MikroTik Zero to Hero challenge. Professional wireless networking: harder than it looks, more rewarding than expected.

Next up: Module 7 - VLANs & Advanced Switching (Scaling to full enterprise department segmentation)

I started Module 5 thinking I'd learn some simple NAT rules and set up port forwarding. What I discovered instead was that most home networks don't work the way networking tutorials assume. Welcome to the world of double NAT!

The Assumption vs Reality

What I Thought My Network Looked Like:

Internet (Public IP) → MikroTik → LAN devices

What It Looked Like:

Internet → ISP Router → MikroTik → LAN devices
         Public IP    Private IP   Private IP

This changes everything about how NAT and port forwarding work.

Discovering My Real Network Topology

When I investigated my actual setup, here's what I found:

• Public IP: 102.219.209.38 (shared among ISP customers)

• ISP Router: Giving my MikroTik 192.168.100.40

• MikroTik WAN: 192.168.100.40 (private address!)

• MikroTik LAN: 192.168.88.0/24 (my controlled network)

Big revelation: My MikroTik doesn't have a real public IP address. It's getting a private IP from my ISP's router.

Understanding NAT in Simple Terms

Before diving into the complexity, let me explain what NAT does:

The Problem: Private IP addresses (like 192.168.x.x) can't talk to the internet directly.

The Solution: NAT translates private addresses to public addresses when packets leave your network, then translates back when replies come in.

Two Types of NAT

Source NAT (SRCNAT/Masquerade):

• Changes the source IP of outgoing packets

• Enables internal devices to access the internet

• Example: My laptop (192.168.88.200) appears as 192.168.100.40 to the ISP

Destination NAT (DSTNAT):

• Changes the destination IP of incoming packets

• Enables external access to internal services

• Example: Traffic to 192.168.100.40:22 gets redirected to 192.168.88.200:22

Setting Up Internet Access (The Easy Part)

Getting my LAN devices online was straightforward:

/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 out-interface=ISP action=masquerade comment="LAN to Internet"

This rule says: "When any device from my LAN (192.168.88.x) sends traffic out through the ISP interface, change the source IP to match the interface IP (192.168.100.40)."

Result: All my devices could browse the internet perfectly!

The Port Forwarding Reality Check

Here's where my dreams got crushed. I wanted to set up SSH access from the internet to my internal server.

I configured the DSTNAT rule:

/ip firewall nat add chain=dstnat dst-address=192.168.100.40 dst-port=22 protocol=tcp action=dst-nat to-addresses=192.168.88.200 comment="SSH port forwarding"

The Problem: This only works for traffic that reaches my MikroTik's WAN IP. But internet traffic hits my ISP router first, not my MikroTik!

Why True Port Forwarding Failed

The traffic flow for external access looks like this:

Internet User → ISP Router (192.168.100.1) → [STOPS HERE]

The ISP router doesn't know how to forward port 22 traffic to my MikroTik at 192.168.100.40. I'd need to configure port forwarding on the ISP router too, but I don't have access to it.

Hairpin NAT: A Clever Workaround

Even though real port forwarding didn't work, I could test the concept using "hairpin NAT" - accessing my external IP from inside my network.

From my laptop, I could SSH to 192.168.100.40:22 and get connected to 192.168.88.200:22. The NAT rule worked perfectly for internal testing!

Understanding Double NAT Impact

Most home internet connections work this way:

Your ISP does NAT: Your public IP is shared among many customers
Your router does NAT: Your devices share your router's private IP
Result: Two layers of address translation

Why This Matters

✅ What Works:

• Internet browsing and streaming

• Most apps and services

• Internal network communication

❌ What Doesn't Work:

• Hosting public services (web servers, game servers)

• Some peer-to-peer applications

• Direct external access to internal devices

The Difference Between Consumer and Business Internet

Consumer/Residential Internet:

• Shared public IP addresses (CGNAT)

• Limited or no port forwarding capability

• Designed for consuming content, not hosting

Business Internet:

• Dedicated public IP addresses

• Full control over port forwarding

• Designed for hosting services and servers

The Upgrade Path: Business internet plans if you need to host public services.

What I Accomplished

Even with double NAT limitations, I achieved:

✅ Perfect internet access - All LAN devices are browsing normally
✅ Clean NAT configuration - Proper masquerade rules
✅ Internal port forwarding - Working for local testing
✅ Network architecture understanding - Real-world vs textbook differences

Key Commands for NAT

# View current NAT rules
/ip firewall nat print

# Remove all NAT rules (clean slate)
/ip firewall nat remove [find]

# Source NAT for internet access  
/ip firewall nat add chain=srcnat src-address=192.168.88.0/24 out-interface=ISP action=masquerade

# Destination NAT for port forwarding
/ip firewall nat add chain=dstnat dst-address=WAN-IP dst-port=PORT protocol=tcp action=dst-nat to-addresses=INTERNAL-IP

# Monitor active connections
/ip firewall connection print

The Reality of Home Networking

Module 5 taught me that textbook networking and real-world networking are often different.

Most networking tutorials assume you have:

• A direct internet connection

• A real public IP address

• Full control over port forwarding

But most home users have:

• Connection through ISP equipment

• Shared/private IP addresses from ISPs

• Limited hosting capabilities

This isn't a failure - it's just reality. Understanding these constraints helps you work within them instead of fighting against them.

What NAT Doesn't Do

Important clarification: NAT only handles IP address translation. It doesn't:

• Block websites or content (that's firewall filtering)

• Control application access (that's layer 7 filtering)

• Manage bandwidth (that's Quality of Service)

• Provide security (that's firewall rules)

Each network function has its tools and rules.

From Frustration to Understanding

Initially, I was frustrated that "simple" port forwarding didn't work. But learning about double NAT, CGNAT, and ISP network architecture gave me a much deeper understanding of how the internet really works.

This knowledge is valuable whether you're troubleshooting home networks, planning business infrastructure, or just understanding why some applications work better than others.

The journey was teaching me that good networking isn't about memorising commands - it's about understanding how traffic flows through complex, real-world infrastructures.

This is part of my MikroTik Zero to Hero challenge. Sometimes the most valuable lessons come from discovering what doesn't work and why.

Next up: Module 6 - Wireless Configuration (Building secure WiFi networks with proper isolation)

After three modules of getting basic connectivity working, I had a sobering realisation: my router was completely naked on the internet. No firewall rules. Management interfaces are accessible from anywhere. Time for a serious security wake-up call.

The Scary Reality Check

Picture this: Your router is humming along nicely, DHCP is working, the internet is flowing smoothly, and then you realise anyone on the internet can try to access your router's management interface.

That's exactly where I was after Module 3. My network worked great, but it was about as secure as leaving your front door wide open with a "Welcome Hackers" sign.

Understanding How Traffic Flows

Before jumping into firewall rules, I had to understand where traffic goes in my network. This was the key to everything.

The Three Traffic Paths

1. INPUT Chain - "Who can talk TO the router?"

• When I use Winbox to manage the router

• When someone tries to access the router from the internet (bad!)

• When the router receives replies from internet services

2. FORWARD Chain - "Who can pass THROUGH the router?"

• When my laptop browses the internet

• When someone from the internet tries to reach my laptop (also bad!)

• Most of your normal internet traffic

3. OUTPUT Chain - "What can the router send OUT?"

• When the router updates its time via NTP

• When the router checks for software updates

• Usually not configured in basic setups

Here's how it looks:

Laptop → Internet: Goes through FORWARD chain
Managing router: Goes through INPUT chain  
Router getting updates: Goes through OUTPUT chain

The Magic of Connection States

This blew my mind. Instead of looking at every packet individually, MikroTik's firewall remembers connection states:

• NEW: Someone is trying to start a new connection

• ESTABLISHED: Packets from connections we already started

• RELATED: Traffic related to connections we have (like FTP data)

• INVALID: Weird, suspicious, or broken packets

The security superpower: Allow replies to connections we started, but block strangers trying to start new connections to us.

Building My First Real Security

Securing the Router Itself (INPUT Chain)

I started with the most critical part - protecting the router from internet attacks:

# Rule 1: Allow replies to connections the router started
/ip firewall filter add chain=input connection-state=established,related action=accept comment="Allow replies to my connections"

# Rule 2: Drop suspicious/broken traffic
/ip firewall filter add chain=input connection-state=invalid action=drop comment="Drop invalid packets"

# Rule 3: Allow ping from my local network only
/ip firewall filter add chain=input protocol=icmp src-address=192.168.88.0/24 action=accept comment="Allow ping from LAN"

# Rule 4: Allow management from my local network only  
/ip firewall filter add chain=input src-address=192.168.88.0/24 dst-port=8291 protocol=tcp action=accept comment="Winbox from LAN"

# Rule 5: Block everything else
/ip firewall filter add chain=input action=drop comment="Drop all other input"

Controlling Internet Access (FORWARD Chain)

Next, I controlled what could pass through the router:

# Rule 1: Allow replies to connections my devices started
/ip firewall filter add chain=forward connection-state=established,related action=accept comment="Allow reply traffic"

# Rule 2: Allow my local network to access the internet
/ip firewall filter add chain=forward src-address=192.168.88.0/24 action=accept comment="Allow LAN to internet"

# Rule 3: Drop suspicious forwarded traffic  
/ip firewall filter add chain=forward connection-state=invalid action=drop comment="Drop invalid forward"

# Rule 4: Block everything else from getting to my network
/ip firewall filter add chain=forward action=drop comment="Drop all other forward"

The Moment I Locked Myself Out

Here's where things got interesting. I was connected to my router through my home WiFi (not the lab network) when I enabled the firewall.

Suddenly, no more access!

The firewall was working perfectly - it was blocking my WiFi connection because it wasn't from the trusted LAN network (192.168.88.0/24).

Creative Problem Solving

I had to add a special rule to allow my wireless connection:

/ip firewall filter add chain=input src-address=MY-WIRELESS-IP dst-port=8291 protocol=tcp action=accept comment="Winbox from wireless" place-before=4

The place-before=4 was crucial - it had to go before the "drop everything else" rule.

Testing My Security

I did proper security testing:

✅ Positive Test: My laptop from the LAN could still manage the router
✅ Negative Test: A different device couldn't access management
✅ Functionality Test: Internet access still worked perfectly

All tests passed! The firewall was doing exactly what it should.

Understanding Rule Order (Super Important!)

MikroTik processes firewall rules from top to bottom and stops at the first match. This means order matters a lot.

I made the mistake of adding duplicate rules by running commands multiple times. Had to clean up:

/ip firewall filter remove 0,1,2,3,4

Lesson learned: Always check existing rules before adding new ones.

What My Security Policy Does

For Management Access:

• ✅ Allow from my local network (192.168.88.0/24)

• ✅ Allow from my specific wireless IP

• ❌ Block everyone else on the internet

For Internet Access:

• ✅ My devices can browse the internet freely

• ✅ Replies to my requests come back fine

• ❌ Random internet users can't reach my devices

For Network Diagnostics:

• ✅ I can ping the router from my network

• ❌ Internet users can't ping my router

The Commands That Matter

# View all firewall rules
/ip firewall filter print

# Add a rule at a specific position
/ip firewall filter add chain=input src-address=192.168.88.0/24 dst-port=8291 protocol=tcp action=accept place-before=5

# Remove rules (be careful!)
/ip firewall filter remove 0,1,2

# Test connectivity
/ping 8.8.8.8
/ip firewall connection print

What I Achieved

By the end of Module 4:

✅ Router is secure - Management only from trusted networks
✅ Internet access maintained - Users can browse normally
✅ Attack resistance - Invalid and suspicious traffic blocked
✅ Diagnostic capability - Network troubleshooting still works
✅ Professional security model - Default deny with explicit allows

The Big Learning

Module 4 taught me that good security is about controlling traffic flows, not just blocking bad stuff.

The connection state tracking was the real game-changer. Instead of trying to guess what's good or bad, I let the firewall remember what connections my network started, and only allow replies to those.

This is how enterprise networks work - not by trying to identify every possible threat, but by having a clear policy about what's allowed and blocking everything else.

From Open Door to Fort Knox

My network went from being completely open to having enterprise-grade security. But this was just the foundation. I still had no NAT rules for internet access, no VLANs for network segmentation, and no Quality of Service controls.

The journey was getting more complex, but also more powerful. I was starting to understand why network professionals choose MikroTik - it gives you complete control to build exactly what you need.

This is part of my MikroTik Zero to Hero challenge. Security first, everything else follows.

Next up: Module 5 - NAT & Port Forwarding (Making internal services accessible while staying secure)

I started Day 2 with the internet working perfectly - but only if I manually set IP addresses on my devices. Time to fix this and make the network usable for normal people who just want to plug in and go online.

The Starting Problem

My laptop was still showing 169.254.86.20 - that annoying self-assigned IP address Windows gives itself when it can't find a DHCP server.

The Issue: My router could get online, but it wasn't helping other devices get IP addresses automatically.

The Goal: Make it work like a normal home router where devices just connect and everything works.

Understanding DHCP Components

Before diving in, I had to learn what pieces make DHCP work:

• IP Pool: The range of addresses available to give out (like 192.168.88.100 to 192.168.88.200)

• DHCP Server: The service that hands out IP addresses

• DHCP Network: The configuration tells clients what gateway and DNS servers to use

• DHCP Lease: The record of who has which IP address

Think of it like a hotel check-in system - you need rooms available (pool), a front desk person (server), information about hotel services (network config), and a guest registry (leases).

Setting Up My First DHCP Server

Step 1: Create the IP Pool

/ip pool add name=LAN-Pool ranges=192.168.88.100-192.168.88.200

This gives me 101 IP addresses to hand out (100-200), while keeping 1-99 free for servers and network equipment.

Step 2: Create the DHCP Server

/ip dhcp-server add name=LAN-DHCP interface=Bridge-LAN address-pool=LAN-Pool

Simple enough! Or so I thought...

Step 3: Configure Network Settings

/ip dhcp-server network add address=192.168.88.0/24 gateway=192.168.88.1 dns-server=8.8.8.8,1.1.1.1

This tells DHCP clients:

• Your network is 192.168.88.0/24

• Your gateway (router) is 192.168.88.1

• Use Google (8.8.8.8) and Cloudflare (1.1.1.1) for DNS

The Hidden Problem I Discovered

After setting everything up, my laptop was STILL getting 169.254.x.x!

I checked the DHCP server status:

/ip dhcp-server print

And there was the problem - it showed an X flag, meaning the server was disabled!

Big Learning: MikroTik creates DHCP servers in a disabled state for safety. You have to manually enable them.

/ip dhcp-server enable LAN-DHCP

SUCCESS! My laptop immediately got 192.168.88.200!

Making Sure My Laptop Always Gets the Same IP

For my lab work, I wanted my laptop to always get the same IP address. This is called a DHCP reservation.

First, I found my laptop's lease:

/ip dhcp-server lease print
# Showed: 192.168.88.200, MAC F4:30:B9:13:C1:55, status: bound

Then I made it permanent:

/ip dhcp-server lease make-static [find mac-address=F4:30:B9:13:C1:55]

I got an error saying "already have static lease with this IP address," - but this meant it worked! Sometimes MikroTik error messages are confusing like that.

Setting Up Time Synchronisation (NTP)

Networks need accurate time for logging, certificates, and troubleshooting. Time to set up NTP (Network Time Protocol).

My First Attempt (Failed)

/system ntp client servers add address=pool.ntp.org

Error: "bad command name servers"

Turns out my RouterOS version uses a different syntax.

Second Attempt (Also Failed)

/system ntp client set primary-ntp=pool.ntp.org

Error: "invalid value for argument ip-address"

Learning: NTP needs actual IP addresses, not domain names like "pool.ntp.org".

What Worked

/system ntp client set primary-ntp=129.6.15.28
/system ntp client set secondary-ntp=132.163.97.1

I looked up the IP addresses for reliable NTP servers and used those directly.

Checking if it worked:

/system ntp client print
# Results:
# active-server: 129.6.15.28
# last-update-before: 7s450ms  
# last-adjustment: 15ms384us

Perfect! The router was now keeping accurate time.

Watching the System in Action

MikroTik has great logging. I could watch DHCP in action:

/log print where topics~"dhcp"

This showed me every time a device requested an IP address, got one, or renewed its lease. Helpful for troubleshooting!

What I Accomplished in Module 3

By the end of Module 3, I had a fully functional network:

✅ DHCP server working - Devices automatically get IP addresses
✅ IP pool configured - 192.168.88.100-200 range for automatic assignment
✅ Static reservation - My laptop always gets 192.168.88.200
✅ DNS servers configured - Clients get Google and Cloudflare DNS automatically
✅ Time synchronisation - Router keeps accurate time via NTP
✅ Network monitoring - Can watch DHCP activity in real-time

The Complete Picture

Now, when someone plugs into my network, they automatically get:

• An IP address (192.168.88.100-200)

• Subnet mask (255.255.255.0)

• Gateway address (192.168.88.1)

• DNS servers (8.8.8.8 and 1.1.1.1)

No manual configuration needed - just like a professional network!

Key Commands I Learned

# DHCP Server Setup
/ip pool add name=LAN-Pool ranges=192.168.88.100-192.168.88.200
/ip dhcp-server add name=LAN-DHCP interface=Bridge-LAN address-pool=LAN-Pool  
/ip dhcp-server network add address=192.168.88.0/24 gateway=192.168.88.1 dns-server=8.8.8.8,1.1.1.1
/ip dhcp-server enable LAN-DHCP

# DHCP Management  
/ip dhcp-server print
/ip dhcp-server lease print
/ip dhcp-server lease make-static [find mac-address=MAC-ADDRESS]

# NTP Time Sync
/system ntp client set enabled=yes
/system ntp client set primary-ntp=129.6.15.28
/system ntp client print

# Monitoring
/log print where topics~"dhcp"

What I Learned About RouterOS

1. Services start disabled - Always check if you need to enable things

2. Error messages can be confusing - Sometimes they mean success!

3. Domain names don't always work - Some services need IP addresses

4. Logging is your friend - Use it to see what's happening

5. MikroTik doesn't guess - You have to be explicit about everything

From Frustration to Understanding

Module 3 was where things started feeling "normal." Instead of fighting the system, I was beginning to understand its logic.

The network was finally behaving like people expect - plug in a device, and it just works. But I knew this was still just the beginning. So far, my network has had zero security. Anyone could connect and do anything.

Time to fix that...

This is part of my MikroTik Zero to Hero challenge. We're building toward a secure, professional network step by step.

Next up: Module 4 - Firewall Fundamentals (Time to lock things down!)

After getting familiar with MikroTik in the morning, I thought the afternoon would be easy - just set up some IP addresses and get online. I was so wrong.

The Big Problem I Discovered

Remember that bridgeLocal from Module 1? Well, it was causing a huge mess:

• All 4 Ethernet ports were acting like one big switch

• My internet connection (WAN) was mixed with my local network (LAN)

• My laptop was getting a weird IP address: 169.254.86.20

That 169.254.x.x address is what Windows gives itself when it can't find a DHCP server. Not good!

Separating WAN and LAN (The Right Way)

First thing I had to do was separate the internet connection from my local network:

The Problem: Everything was on one bridge
The Solution: Create proper separation

Here's what I did:

# Delete the messy bridge
/interface bridge remove bridgeLocal

# Create a new bridge for LAN only
/interface bridge add name=Bridge-LAN

# Put only the local ports in the LAN bridge
/interface bridge port add interface=ether2 bridge=Bridge-LAN
/interface bridge port add interface=ether3 bridge=Bridge-LAN
/interface bridge port add interface=ether4 bridge=Bridge-LAN

# Leave ether1 separate for internet connection
# Rename interfaces to make sense
/interface set ether1 name=ISP
/interface set ether2 name=Laptop

Now I had a clean separation:

• ISP (ether1) = Internet connection

• Bridge-LAN (ether2-4) = Local network

Setting Up IP Addresses

Time to give everything proper IP addresses:

WAN Side (Internet): Use DHCP to get an IP from my ISP router

/ip dhcp-client add interface=ISP

LAN Side (Local Network): Use static IP

/ip address add address=192.168.88.1/24 interface=Bridge-LAN

The /24 means the first 24 bits are the network part. So 192.168.88.1/24 means:

• Router IP: 192.168.88.1

• Network: 192.168.88.0 to 192.168.88.255

The Big Mistake That Taught Me Everything

After setting up IP addresses, I tried to ping Google:

/ping 8.8.8.8

FAILED!

I could ping my ISP router (192.168.100.1), but not the internet. What was wrong?

I checked my routing table:

/ip route print

And there it was - the problem:

0 A S  0.0.0.0/24     192.168.100.1

Do you see it? 0.0.0.0/24 instead of 0.0.0.0/0

The /24 vs /0 Lesson

This was my biggest learning moment:

• 0.0.0.0/24 = Only route traffic for 0.0.0.1 to 0.0.0.255 (useless!)

• 0.0.0.0/0 = Route ALL unknown traffic to this gateway (what we want!)

The fix:

# Remove the wrong route
/ip route remove [find dst-address=0.0.0.0/24]

# Add the correct default route
/ip route add dst-address=0.0.0.0/0 gateway=192.168.100.1

SUCCESS! Now I could ping 8.8.8.8!

Another Mistake I Made

I accidentally added a DHCP client to my LAN bridge:

/ip dhcp-client add interface=Bridge-LAN  # WRONG!

This made no sense because:

• WAN interfaces should GET IP addresses (be DHCP clients)

• LAN interfaces should GIVE IP addresses (be DHCP servers)

I was asking my LAN to search for a DHCP server that didn't exist!

Understanding My Network Layout

By the end of Module 2, my network looked like this:

Internet → ISP Router → ether1(ISP) → MikroTik → Bridge-LAN → ether2-4
           192.168.100.1  192.168.100.40  192.168.88.1

Clean and logical!

What I Learned About Routing

The routing table shows how traffic gets around:

/ip route print
# Results:
# 0 A S  0.0.0.0/0       192.168.100.1  (send everything unknown here)
# 1 ADC  192.168.88.0/24 Bridge-LAN     (local network is directly connected)  
# 2 ADC  192.168.100.0/24 ISP           (ISP network is directly connected)

The flags mean:

• A = Active (route is working)

• D = Dynamic (created automatically)

• C = Connected (directly attached network)

• S = Static (I created this manually)

My Troubleshooting Method

When things don't work, I learned to check in this order:

1. Symptoms: Can't reach 8.8.8.8

2. Check routing: /ip route print

3. Check interfaces: /ip address print

4. Test step by step: Local → Gateway → Internet

5. Fix the root cause: Correct the subnet mask

What I Accomplished

By the end of Module 2:

✅ Proper WAN/LAN separation - No more mixed networks
✅ Internet connectivity working - Can ping 8.8.8.8
✅ Clean routing table - Correct default route
✅ Logical interface naming - ISP and Laptop instead of ether1/ether2
✅ Understanding traffic flow - Know how packets move around

The One Thing Still Not Working

My laptop was still getting that 169.254.x.x address. I could manually set a static IP and everything worked, but automatic assignment wasn't happening yet.

Next challenge: Set up a DHCP server so devices get IP addresses automatically.

Key Commands I Mastered

# IP address management
/ip address add address=192.168.88.1/24 interface=Bridge-LAN
/ip address print

# DHCP client management  
/ip dhcp-client add interface=ISP
/ip dhcp-client print

# Routing
/ip route print
/ip route add dst-address=0.0.0.0/0 gateway=192.168.100.1

# Testing connectivity
/ping 8.8.8.8 count=3
/ping 192.168.100.1

The Real Learning

Module 2 taught me that networking is all about logical separation. Just because ports are physically next to each other doesn't mean they should be on the same network.

The /24 vs /0 mistake was embarrassing but incredibly valuable. Now I'll never forget that subnet masks completely change how routing works.

This is part of my MikroTik Zero to Hero challenge. The journey from confusion to clarity continues!

Next up: Module 3 - DHCP Server & Basic Services (Finally getting automatic IP addresses working!)

I decided to learn MikroTik networking from scratch. This is my story of Day 1 - the very first time I touched a MikroTik router.

What is MikroTik Anyway?

Before starting, I had no idea what MikroTik was. Here's what I learned:

• MikroTik makes networking equipment (routers, switches, wireless devices)

• RouterOS is their operating system that runs on the hardware

• It's like Linux, but specially made for networking

• You can buy their hardware, OR run it on regular computers

Think of it like this: RouterOS is the brain, and MikroTik hardware is the body.

My First Connection Problem

I plugged in the router and tried to connect. Big mistake #1 - I assumed the login was blank username and blank password.

ERROR: "Wrong credentials"

After some googling, I found out newer RouterOS versions need:

• Username: admin

• Password: (leave blank)

Then it immediately asks you to create a new password. Smart security feature!

Three Ways to Control Your Router

MikroTik gives you three ways to control your router:

1. Winbox - A Windows program (easiest for beginners)

2. WebFig - Use your web browser

3. CLI/SSH - Command line (for advanced users)

I started with Winbox because it looked the friendliest, but quickly discovered the command line was easier to understand.

The Interface Confusion

When I first looked at the interfaces, I was confused. The router showed 7 interfaces, but I could only see 4 physical ports:

• ether1-4: The actual physical ports you can touch

• wlan1: The WiFi interface

• bridgeLocal: A virtual interface grouping ports together

• pwr-line1: Just another name for an Ethernet port

Key Learning: Not all interfaces are physical ports you can see and touch.

My First Commands

Here are the basic commands I learned on Day 1:

# Check the router name
/system identity print

# Change the router name
/system identity set name="Alex-Lab1"

# See all network interfaces
/interface print

# Make a backup of settings
/system backup save name=factory-backup

# Set the correct time
/system clock print

What I Discovered About Network Setup

The biggest surprise: Everything was connected to one big bridge called bridgeLocal. This meant:

• All 4 Ethernet ports acted like a switch

• The WAN (internet) and LAN (local network) were mixed

• My laptop couldn't get a proper IP address

This explained why things weren't working as expected!

CLI vs GUI - My Preference

I thought I'd use the GUI (graphical interface) for everything. But I quickly found the command line more logical:

• Commands follow a tree structure: /system/identity, /interface

• You can stay in sections and navigate around

• Shortcuts work: /int pr instead of /interface print

• It just made more sense to me

What I Accomplished on Day 1

By the end of Day 1, I had:

✅ Successfully connected to my MikroTik router
✅ Changed the system name from "MikroTik" to "Alex-Lab1"
✅ Created a backup of the original settings
✅ Set the system clock and timezone
✅ Mapped out all the physical and virtual interfaces
✅ Learned the basic navigation in both GUI and CLI

The Real Learning

The most important thing I learned wasn't technical - it was that MikroTik is different from consumer routers. It doesn't try to guess what you want. It gives you complete control, but you need to understand what you're doing.

This is both powerful and intimidating for a beginner.

What's Next?

Day 1 was just about getting familiar with the system. Tomorrow (Module 2), I need to:

• Fix the network setup so that WAN and LAN are properly separated

• Configure IP addresses correctly

• Get my laptop to connect to the internet through the router

The journey has just begun, but I'm already seeing why network professionals love MikroTik - it's incredibly powerful once you understand the basics.

This is part of my MikroTik Zero to Hero challenge. Follow along as I document my learning journey from complete beginner to confident network administrator.

Next up: Module 2 - IP Addressing & Basic Connectivity