There is a version of Week 0 that would have felt completely foreign to me.
IP addresses, DNS, HTTP, TCP/IP, application architecture. For someone starting from zero, these concepts are a lot to absorb in one week. I remember what that felt like.
But I am not starting from zero.
I graduated from DMI Cohort 2 in May 2026. I was the App/Docker Lead for an 11-person team that deployed Spring PetClinic Microservices — 8 services, full CI/CD on AWS EKS, Prometheus scraping metrics every 15 seconds, Zipkin tracing requests across 4 services, alerts firing within 30 seconds of a service failure.
I have deployed on AWS. I have deployed on Azure. I have written Terraform modules, Ansible playbooks, GitHub Actions pipelines, and Kubernetes manifests. I know what a private subnet is because I put a MySQL database in one. I know what an A record is because I used one to point a domain to a VM's public IP.
So why am I doing Week 0 of Cohort 3 self-paced?
Because knowing something and documenting it clearly are two different skills. And the second one matters more for your career.
What Week 0 Actually Taught Me
Prompt Engineering is a Real Skill
Task 1 was writing a structured ChatGPT prompt to explain networking protocols. The key ingredients: context, specific question, format requirements, length constraints, and relevant background.
I have been doing this with AI tools — Claude Code and KIMCHI — since Cohort 2. But having a formal framework for it made me realise I was doing it intuitively without being able to explain why it worked. Now I can.
The discipline of a good AI prompt is identical to the discipline of a good Terraform variable definition. Be explicit. Constrain the output. Define expectations upfront. Garbage in, garbage out, whether you are talking to an LLM or provisioning cloud infrastructure.
Explaining Things Simply is Harder Than Doing Them
**Task 2 **asked me to explain packet switching, IP addresses, TCP/IP, and HTTPS in 100 to 150 words using the EpicReads bookstore scenario — a friend in Finland, customers in Nigeria.
I know all four concepts from production deployments. But fitting them into 150 words that a non-technical person could understand? That took four drafts. Every word had to earn its place.
Here is the version I ended up with:
When your friend's EpicReads website goes live in Finland, every device on the internet has a unique IP address — like a postal address. When a Nigerian user types the URL, DNS translates it to that Finnish IP address. The request does not travel in one piece. Packet switching breaks it into small chunks called packets. Each packet finds its own fastest route across the internet and they reassemble at the destination. TCP/IP manages this journey — TCP ensures every packet arrives, IP handles the routing between countries. HTTPS encrypts the conversation so no one between Nigeria and Finland can read the customer's payment details. That is how a click in Lagos reaches a server in Helsinki in under 200 milliseconds.
Architecture Diagrams Force Clarity
Two-tier versus three-tier. I have built both in production:
EpicBook on Azure: React frontend + Node.js backend + MySQL RDS in private subnet
Spring PetClinic: 8-service microservices with API Gateway, Config Server, Eureka, and 5 business services
The two-tier diagram is simple — frontend connects directly to database. The three-tier adds a backend layer that handles business logic between the two. The diagram does not capture the complexity of what I built. But it forces you to articulate the layers clearly — which is the foundation for understanding why microservices exist.
DNS in Production vs DNS in Theory
Task 4: connect epicreads.com to 52.172.142.222:3000 using the correct DNS record.
The answer is an A record. CNAME maps domain to domain — you cannot use it to point directly to an IP address. The port does not go in DNS at all. Nginx handles the port — accepting traffic on 80 or 443 and forwarding it internally to 3000. I did exactly this for EpicBook on Azure.
The theory confirms what I already knew from practice. That is the best kind of learning.
Why Public Documentation Matters
Every assignment gets pushed to GitHub. Every week adds a commit to my public portfolio. By the end of the self-paced programme alongside Cohort 3, I will have a documented, versioned record of everything I know, not just what I can do.
That is the difference between a developer who has done the work and one who can prove it, explain it, and teach it to someone else.
The work I did in Cohort 2 already proved I can build. This is me proving I can articulate.
If you are just starting DevOps, Cohort 3 is live now. What feels like fundamentals in Week 0 is what makes everything in Weeks 6 through 14 make sense.
**P.S. **This post is part of the DevOps Micro Internship (DMI) with Agentic AI — Cohort 3 — by Pravin Mishra. My graded progress is public: https://dmi.pravinmishra.com/s/Lucycloud2024.html · Start your DevOps journey: https://dmi.pravinmishra.com/?utm_source=student&utm_medium=ps-linkedin&utm_campaign=cohort3
Top comments (0)