Career Dashboard
Current Target Role: Cloud / DevOps Engineer (primary), Platform / MLOps Engineer (secondary)
Original Time-to-Hire Estimate: 3–6 months
Current Time-to-Hire Estimate: 3–5 months
Confidence Level: Medium
Skills Acquired: Terraform Modules (Refactoring IaC), Dockerized Service (Production‑like Packaging), Local Kubernetes Deployment (kind), Prometheus Metrics Exporter (Observability), CI Pipeline Enhancements (GitHub Actions)
Remaining Skill Gaps:
- Managed Kubernetes (EKS/GKE) and Terraform integration
- Cloud networking (VPC, subnets, routing, security groups)
- IAM best practices and least‑privilege design
- Deeper observability (Grafana dashboards, alerting, SLOs)
- Interview readiness for system design and incident troubleshooting
Today’s Objective
Today’s objective was to pause the “just keep learning” instinct and run a proper weekly review. I wanted to answer three questions honestly: what did I actually accomplish since Day 7, is the plan still aligned with the job market, and is the pace sustainable for a 41‑year‑old parent with limited daily energy? I also wanted to check whether the skills I’m investing in—Terraform, Docker, Kubernetes, observability, CI/CD—are still the highest‑leverage bets for employability, not just the most interesting technologies.
What I Worked On
I split the day into two parts: review and refinement.
In the review block, I went through my Terraform repo, Docker setup, GitHub Actions workflow, and Kubernetes manifests. I compared what I planned to do last week with what actually happened. I also re‑read several job postings I had bookmarked to see if my portfolio still maps cleanly to the requirements.
In the refinement block, I focused on stabilizing my local Kubernetes deployment. I fixed a crash‑loop issue caused by a missing environment variable, learned to use kubectl logs and kubectl describe more effectively, and updated my Deployment to use ConfigMaps for configuration. I also improved my README with a new architecture diagram that shows the flow from Terraform‑provisioned infrastructure to Docker image to Kubernetes deployment to Prometheus metrics.
What I Learned
I learned that Kubernetes is not a “weekend skill.” Even with prior production experience, there’s a conceptual shift from “run this container” to “declare desired state and let the control plane reconcile it.” That shift takes repetition. I also learned that my original plan was slightly optimistic about how quickly I could move from local Kubernetes to managed EKS/GKE while also job searching and parenting.
Another important learning: the job market is consistent. Terraform, Kubernetes, CI/CD, and cloud fundamentals are still the core stack for DevOps roles. AI‑adjacent work (like MLOps) sits on top of these, not instead of them. That reinforces the decision to treat AI as an add‑on, not the main path.
Finally, I learned that emotional fatigue is creeping in. The initial excitement of “new tools, new repo, new plan” has faded into the slower grind of deep learning. That’s not a sign the plan is wrong—it’s a sign I need to manage energy and expectations.
Skills Acquired (with definitions and why they matter):
- Terraform Modules (Refactoring IaC): Terraform is an Infrastructure as Code tool that lets you define cloud resources (compute, storage, networking) in declarative configuration files. I refactored my Terraform into modules so that VPCs, subnets, and application infrastructure are reusable and easier to reason about. This matters because real teams don’t keep everything in one file—modular IaC is a strong signal of production‑grade thinking.
Reference: Terraform tutorials - Dockerized Service (Production‑like Packaging): Docker lets me package my Python service and its dependencies into a container image that runs consistently across environments. I now have a repeatable
Dockerfileand can build, run, and push images to a registry. This is essential because most DevOps and platform roles assume you can work with containers as the basic deployment unit. - Local Kubernetes Deployment (kind): Kubernetes orchestrates containers across nodes, handling scheduling, restarts, and scaling. I used
kindto run a local cluster and deployed my Dockerized service using Deployment and Service YAMLs. This is important because Kubernetes appears in almost every mid‑level DevOps job description, and even basic familiarity with pods, services, and crash‑loop debugging is a differentiator. - Prometheus Metrics Exporter (Observability): I added a
/metricsendpoint to my service and configured Prometheus to scrape it, then started wiring up a simple Grafana dashboard. This matters because observability—metrics, logs, and traces—is now a first‑class requirement in many roles, not a nice‑to‑have. - CI Pipeline Enhancements (GitHub Actions): My GitHub Actions workflow now builds the Docker image, runs tests, and performs basic security checks (like
banditfor Python). This shows I understand how to automate quality gates and not just “run tests locally.”
Reference: DevOps labs example repo
Market Observations
I scanned around 20 new postings across LinkedIn, Indeed, and a few remote‑friendly boards. The patterns are almost boringly consistent:
- Core requirements:
- Kubernetes (often EKS or GKE)
- Terraform or other IaC
- CI/CD (GitHub Actions, GitLab CI, Jenkins)
- One major cloud (AWS or GCP)
- Nice‑to‑haves:
- Observability (Prometheus, Grafana, ELK)
- SRE practices (SLIs, SLOs, incident response)
- Platform engineering concepts (internal developer platforms, GitOps, ArgoCD, Backstage)
- AI‑adjacent mentions: A few roles mention “supporting ML workloads” or “MLOps,” but they still anchor on strong infra skills first.
This tells me the market hasn’t shifted under my feet in the last two weeks. The skills I’m building are still directly aligned with what hiring managers are asking for. That’s reassuring.
Resources Reviewed
Today I leaned on a few focused resources rather than binging random content:
- Kubernetes CrashLoopBackOff Debugging – TechWorld with Nana
Why I chose it: Nana explains Kubernetes concepts visually and walks through real error scenarios, which matches what I’m seeing in my local cluster.
What I learned: How to systematically debug CrashLoopBackOff issues using logs, events, and manifests.
Was it worth it? Yes—this directly improved my ability to debug my own deployment. - Terraform Modules and Best Practices – HashiCorp Tutorials
Why I chose it: I needed a clearer mental model for when and how to split Terraform into modules.
What I learned: How to structure modules, pass variables, and avoid tightly coupling everything into one configuration.
Was it worth it? Yes—my repo is cleaner and closer to what real teams expect. - DevOps Labs Example Repo (CI/CD + Terraform + Monitoring)
Why I chose it: I wanted to see how others structure a full DevOps learning environment with Terraform, Docker, CI, and monitoring.
What I learned: How to organize directories for infra, apps, monitoring, and workflows in a way that scales.
Was it worth it? Yes—it gave me concrete ideas for improving my own repo layout.
Progress Against Plan
If I compare the last week to my original expectations:
- Ahead on:
- Terraform quality (modules, structure, clarity)
- CI pipeline robustness (linting, security checks)
- Observability basics (Prometheus metrics wired in)
- On track for:
- Local Kubernetes deployment and basic debugging
- Portfolio documentation and diagrams
- Behind on:
- Managed Kubernetes (EKS/GKE)
- Cloud networking deep dive
- Volume of job applications
Overall, I’d call it “slightly behind schedule but in the right direction.” The delay is mostly due to underestimating Kubernetes complexity and the mental load of starting job search activities. That’s a realistic tradeoff, not a failure.
Weekly Review
This week’s plan was to:
- Solidify Terraform and Docker
- Get a basic Kubernetes deployment running
- Add observability
- Start or continue job applications
Was it worthwhile? Yes. Every hour invested went into skills that show up repeatedly in job postings. The plan was ambitious, and I didn’t finish everything, but the direction is clearly correct. The main adjustment I need is pacing: Kubernetes and managed cloud services require more time than I gave them on paper.
Should I continue with the plan? Yes, with a small modification: instead of rushing into EKS/GKE next week, I’ll spend more time deepening local Kubernetes understanding and only then move to managed clusters. The weekly review confirms that the strategy—Cloud/DevOps first, AI‑adjacent second—is still supported by market evidence and my own progress.
Strategy Changes
I’m not pivoting away from Cloud/DevOps or toward pure AI. Instead, I’m:
- Extending the Kubernetes learning window
- Pushing managed Kubernetes (EKS/GKE) to the next week or two
- Keeping the AI‑adjacent RAG demo as a “nice to have” once core infra skills feel solid
No dramatic changes—just a more honest timeline.
Next Steps
Over the next few days, I plan to:
- Deepen Kubernetes knowledge:
- Explore Services, Ingress, and ConfigMaps in more detail
- Practice rolling updates and scaling
- Start a gentle cloud networking deep dive:
- VPCs, subnets, routing, security groups
- Prepare for upcoming screening calls:
- Review common DevOps interview questions
- Write 3–5 STAR stories based on real incidents
- Apply to at least 5 more roles, prioritizing those that match my current stack (Terraform, Docker, Kubernetes, AWS, GitHub Actions).
Reflection
Two weeks in, the honeymoon phase is over and the real work has begun. I’m no longer riding the high of “new tools!”—I’m in the slower, more meaningful phase of building depth. That feels harder, but also more honest. I’m still convinced that Cloud/DevOps is the fastest realistic path back into tech for my background, and the market data keeps reinforcing that. The key now is to protect my energy, keep the scope realistic, and let the compounding effect of daily practice do its work.
