# Cloud Engineer Roadmap in 2026. Don't Become a Cloud Engineer Until You Watch This **Channel:** Cloud DevOps with Ana **Source:** https://www.youtube.com/watch?v=IstrvX6Co5U **Transcript page:** https://www.withtranscript.ai/video/IstrvX6Co5U ## Chapters - 0:00 — Why Cloud Learning Needs Focus - 2:19 — System Design and Choosing One Cloud - 4:09 — Building Infrastructure with Code - 5:55 — Kubernetes Security and Observability - 7:49 — AI Projects, Job Readiness, and Mistakes ## Transcript **[0:00] Speaker A:** If you want to become a cloud engineer in 2026, stop trying to learn everything. AWS has hundreds of services. Azure has hundreds more. Then there's Linux, networking, Terraform, Docker, Kubernetes, CI/CD, security, Python, and now AI. If you try to master all of that before applying for your first job, you could spend the next 2 years studying and still feel like you are not ready. So, in this video, I'm going to simplify everything. I'm giving you the cloud engineer roadmap I would follow if I had to start again from zero in 2026. I will show you what to learn, in which order, what projects to build, what you can ignore initially, and how to actually turn those skills into a job. And there's one rule I want you to remember throughout this entire video: build more than you study. So, let's start. Phase one, master the fundamentals. **[0:51] Speaker A:** Before AWS, before Kubernetes, before Terraform, learn what is happening underneath the cloud. Start with Linux. You don't need to become a Linux administrator, but you should understand files, permissions, processes, services, SSH, environment variables, logs, and basic bash. And please, don't spend 3 weeks watching Linux tutorials. Launch a Linux server, SSH into it, install Nginx, break something, find the logs, fix it. That experience will teach you much more than memorizing commands. Next is networking, and this might be one of the most underrated cloud engineering skills you should learn. IP addresses, CIDR, subnets, DNS, routing, ports, HTTPS, firewalls, NAT, and load balancing. Because when your application cannot communicate with your database or your Kubernetes service isn't reachable, you need to understand what's happening underneath. A surprising number of cloud problems are actually networking problems. Then, learn Git. Your Terraform, Kubernetes manifests, pipelines, scripts, and configurations should all live in your version control. **[2:00] Speaker A:** And finally, learn enough Python to automate things. You don't need to become a software engineer, but you should be able to write scripts, call APIs, process JSON, and automate repetitive tasks because a cloud engineer who can automate is much more valuable than someone who can only click buttons in a console. **[2:19] Speaker A:** Phase two, learn system design. This is where many cloud roadmaps go wrong. They tell you, "Learn EC2, learn S3, learn Lambda, learn RDS." But they don't teach you why you would use them. Imagine you have an application running on one server with one database. It works perfectly for 100 users. But now imagine you suddenly have 1 million users. What happens? You might need multiple servers, a load balancer, caching, database replication, queues, auto scaling, redundancy. That's system design. You need to understand concepts like high availability, scalability, fault tolerance, load balancing, caching, and disaster recovery. And remember this, everything fails. Servers fail, networks fail, deployments fail. Cloud regions can have problems, and humans definitely make mistakes. So good cloud engineers don't design systems assuming nothing will fail. They design systems assuming something eventually will. Phase three, pick one cloud. Now you can finally choose AWS, Azure, or Google Cloud. **[3:27] Speaker A:** And please, don't try to learn all three at the beginning. Instead, look at the job market. Open 30 to 50 cloud engineer and DevOps positions where you want to work. Which cloud appears most frequently? Start there. If Azure dominates your local market, don't blindly choose AWS because someone on YouTube told you to. For whichever cloud you choose, focus on five areas: compute, storage, networking, identity, databases. For AWS, that could mean EC2, S3, VPC, IAM, RDS, and DynamoDB. But, don't try to memorize every configuration option. For every service, ask, "What problem does this solve?" That's much more important. **[4:09] Speaker A:** Phase four, build your first real architecture. Now, stop watching tutorials. Build something. Deploy a web application, but don't stop after launching one virtual machine. Create something close to a real architecture. Maybe users hit a load balancer. Behind it, you have multiple application servers. Those connect to a managed database. Everything sits inside a VPC with public and private subnets. Then, ask yourself, "What happens if one server dies? What happens if traffic increases **[4:38] Speaker B:** 10 times? Can someone access my database directly from the internet? Where are my secrets stored? What happens if one availability zone fails?" Those questions are where you start thinking like an engineer. Phase five, Terraform, Docker, and CICD. Now, take that infrastructure and stop creating it manually. Learn Terraform. Understand providers, resources, variables, outputs, state, remote state, and modules. Then, rebuild your architecture with code. Your network, subnets, security groups, compute, load balancer, database, everything. **[5:11] Speaker A:** Then, destroy it and rebuild it. When your entire infrastructure comes back automatically, infrastructure as code starts to click. And next, Docker. Learn images, containers, Docker files, registries, networking, volumes, and environment variables. Take your application and containerize it. Then, automate everything with CICD. And again, you don't need Jenkins, GitHub Actions, GitLab CI, and Azure DevOps simultaneously. Pick one. For example, GitHub Actions. Build a pipeline, code push, build, test, security scan, Docker image, registry, deployment. Now, every time you push code, the deployment happens automatically. At this point, you are no longer just having individual tools. You are building an actual engineering workflow. **[5:55] Speaker A:** Phase six, Kubernetes. **[5:57] Speaker B:** Now, we can finally talk about Kubernetes. And notice how late Kubernetes appears in this road map. And this is intentional. You don't start your cloud journey with Kubernetes because Kubernetes becomes dramatically easier when you already understand Linux, networking, cloud, Docker, and deployments. And you should start with pods, deployments, services, config maps, secrets, ingress, storage, air back, and then helm. After you understand Kubernetes locally, move to a managed service, EKS, AKS, or GKE. Deploy the application you already built. Connect your CI/CD pipeline. Now, imagine what happens. You push code, your pipeline runs tests, it scans for vulnerabilities, it builds a Docker image, pushes it to a registry, and deploys the new version to Kubernetes. That is a portfolio project worth talking about in an interview. Then, phase seven, security and observability. But, there's a problem. Your application is running. How do you know it's healthy? This is where observability comes in. **[6:58] Speaker B:** Learn metrics, logs, traces, and alerts. Start with cloud provider's monitoring tools. Then, explore tools like Prometheus and Grafana. Monitor CPU, memory, errors, latency, traffic, container health. Then, deliberately break your application. Yes, break it. Stop a service. Generate high CPU. Break connectivity. Deploy a bad version. Then, use your monitoring and logs to figure out what happened. Troubleshooting is one of the most valuable cloud engineering skills you can develop. And security should exist throughout everything you are building. You should learn IAM, least privilege, encryption, secrets management, private networking, audit logs, vulnerability scanning, and never hard code credentials. And please don't expose your database publicly because you couldn't get the networking to work. **[7:49] Speaker B:** Phase eight, add AI. And because this is 2026, there's one more layer I would add, AI. You don't need to become an AI engineer, but cloud engineers need to understand how AI workloads are deployed and operated. You should learn the basics of LLMs, AI APIs, rack, vector databases, AI agents, GPU workloads, and AI observability. Then explore platforms like AWS Bedrock, Microsoft Foundry, or Google Vertex AI. You could take the application you have already built and add **[8:20] Speaker A:** an AI support assistant, a rack system, or even an AI incident analyzer. And now you have combined cloud, infrastructure as code, containers, Kubernetes, CCD, security, observability, and AI. And that's a very different portfolio from someone who simply lists 25 technologies on their resume. The one project I would build. In fact, if I had to build only one serious portfolio project in 2026, I would build this, a production-style cloud-native application. You should use Terraform for the infrastructure, Docker for containerization, Kubernetes for orchestration, GitHub Actions for CCD, Trivy for vulnerability scanning, Prometheus and Grafana for observability, IAM and secrets management for security, auto scaling for scalability, and optionally add an AI feature. Then intentionally create failures. Break the networking, deploy a bad container, remove a permission, generate high CPU, and troubleshoot every problem. And finally, document everything. Create a GitHub repo, an architecture diagram, a professional readme, deployment instructions, your design decisions, your security decisions, and most importantly, add a section called problems I encountered and how I solved them. **[9:32] Speaker A:** That section can become incredibly powerful during interviews because companies don't only want to know what you built. They want to know can you figure things out when they break. And this is your 90-day plan. If you want to structure this into roughly 90 days, I would do it like this. Month one, foundations. Linux, networking, Git, Python, system design, and one cloud platform. Build small projects while you are learning. Month two, cloud and DevOps. Terraform, Docker, CI/CD, Kubernetes, security, observability. Start combining everything into end-to-end projects. And then, month three, become job ready. This is where I would stop spending 100% of my time studying. Build your flagship project. Fix your resume. Prepare for technical interviews. Prepare five strong behavioral stories using the STAR method. And most importantly, start applying before you feel ready. Don't wait until you have completed every technology in this video. You don't need Kubernetes expertise before submitting your first application. **[10:33] Speaker A:** You don't need three certifications. You don't need to know every AWS service. Start looking at jobs from day one. Let the job market tell you what skills you should prioritize. And finally, here are the mistakes I would avoid. Don't collect certifications without building projects. Certifications can prove knowledge, and some are useful, but projects prove you can apply it. Don't learn three clouds simultaneously. Master one first, and then if you want, expand with others. Don't learn five CI/CD tools. Just learn one properly. Don't start with Kubernetes before understanding containers and networking. And here's a new one for 2026. Don't blindly copy infrastructure code from AI. ChatGPT can generate Terraform. AI can generate Kubernetes YAMLs. AI can generate an entire CI/CD pipeline. And that's useful, but you still need to understand what that code is going to do before you deploy it to production. So, if I had to start again, my road map would look like this. **[11:27] Speaker A:** Linux and networking. Git and Python. System design. One cloud. Build an architecture. Terraform. Docker. CI/CD. then Kubernetes, security, observability, and finally AI infrastructure. And throughout the entire journey, build projects. Don't try to become an encyclopedia of AWS services because AI can already retrieve documentation faster than you. AI can write Terraform, AI can generate Kubernetes YAMLs, AI can build pipelines, but someone still needs to understand what should we build, how should we secure it, how should it scale, what happens when things fail. **[12:00] Speaker B:** And maybe most importantly in 2026, should we deploy this AI-generated code to production at all? That's the cloud engineer I would aim to become, not someone who memorizes cloud services, but someone who knows how to build, automate, secure, monitor, and troubleshoot real systems. If you want the complete step-by-step roadmap, I have a linked it in the description. And if you're preparing for interviews, you will find also a PDF with 150 interview questions and answers to help you practice. Both links are below in the description. And if you like this video, please like and subscribe, and see you in the next one.