I'm in my final year of university and originally started learning backend development. I've always been interested in moving toward DevOps, but first wanted to understand the foundations—databases, networking, system design, and software architecture. After studying those areas, I began learning commonly used tools such as Docker, Kubernetes, AWS, and Terraform.
Now I want to build projects that teach practical, job-related skills rather than just creating an attractive cloud architecture diagram. I'd like to practice deployments, troubleshooting failed systems, observability, incident recovery, backups, and cost optimization. What projects, labs, or learning approaches helped you develop these skills?
4 Answers
A home lab is a great low-cost way to experiment. A few used mini PCs, old laptops, or inexpensive virtual machines can host Linux, a small Kubernetes cluster, a web application, and a CI/CD system. You can also self-host a blog or a small application and keep it available over time. Track resource usage and expenses, automate the setup with Terraform or configuration management, and review what you actually need. Just remember that you don’t have to master every tool before graduating—build solid fundamentals, stay curious, and learn from real projects or internships as you gain experience.
A useful project is to take an existing multi-service application, deploy it locally with Kubernetes, and then move it to one or more cloud providers. Add infrastructure as code, a pipeline, monitoring, tracing, and sensible security controls. You can also use a deliberately vulnerable application to practice hardening and incident investigation. The important part is not simply getting it running—it’s diagnosing why it stops working and improving the setup afterward.
Take a small application and run it like a real service. Start with a simple deployment, then add CI/CD, logging, metrics, dashboards, backups, and alerts. Once it works, deliberately create incidents in a test environment: break a deployment, fill the disk, expire a certificate, rotate a secret, or restore from backup. Keep notes about what happened, where you looked first, which signals helped, and how you recovered. That kind of troubleshooting and rollback practice is much closer to the job than building another polished architecture diagram.
This is exactly the kind of practice I was looking for. I’ll make sure to document each failure and recovery instead of just fixing it and moving on.
Set up observability before breaking anything. Prometheus and Grafana are good options for metrics, while a centralized logging stack can help you investigate failures. Even a basic home lab or inexpensive virtual machine is enough. Write short post-incident reviews for yourself: what failed, what you checked, what information was missing, and what you would automate next time. Learning to find the right evidence quickly is one of the most valuable DevOps skills.
Purposely breaking the cluster after it is working teaches a lot. Try troubleshooting with basic logs and metrics before relying on more advanced tools.