I've worked in QA for about two years, and over the past year I've gained hands-on experience with Azure and Azure DevOps. I've learned mainly by working with our team's environment and occasionally getting guidance from a technical architect.
So far, I've centralized dashboards and cut daily monitoring time roughly in half, automated an Azure Runbook that produces a data report instantly instead of requiring about an hour of manual work, and worked with managed identities, Azure Policy, role assignments, storage monitoring, IoT Hub, alerts, and other Azure metrics.
I've passed a fundamentals certification and have started applying for junior Azure and DevOps roles. However, many listings ask for three to five years of Azure experience, plus Docker, Kubernetes, Terraform, CI/CD, and related tools. Since I work full-time, have a part-time job, and study Azure as well, I have limited time for personal projects. I also can't show most of my company work because of confidentiality restrictions.
Is Azure administration or cloud/DevOps still a realistic direction for someone with my background? Should I focus on Azure administration, SRE, or DevOps, and what would be the most practical skills to learn next?
5 Answers
Your QA background can be an advantage instead of something you need to abandon. Automation, test design, scripting, CI/CD, and release quality all overlap with modern engineering teams. You could strengthen that path with Playwright or another automation framework, pipeline integration, test reporting, and performance testing, while continuing to learn Azure.
A QA engineer who understands deployments, infrastructure, observability, and automated testing can be valuable even without immediately becoming a full-time DevOps engineer. An internal move may also be more realistic than trying to compete directly for an external role asking for several years of infrastructure experience.
Azure is still worth learning, but the challenge isn’t unique to Azure. Employers are generally cautious about putting inexperienced people in charge of production infrastructure, regardless of whether the platform is Azure, AWS, or Google Cloud.
Based on your examples, you may currently be closer to cloud administration, monitoring, or the observability side of SRE than to a traditional DevOps role. That’s still useful experience, but DevOps positions often expect you to build and maintain delivery systems, infrastructure as code, containers, deployment pipelines, and production operations.
That distinction helped me understand my position better. I was mainly targeting Azure Administrator roles, so I’ll keep studying for the administrator certification while gradually adding Docker, Terraform, Kubernetes, and CI/CD.
There’s no need to pivot simply because the first applications didn’t work out. Cloud is a long-term career path, but certification alone won’t make you marketable. Keep gaining experience where you are, learn from the infrastructure and release teams whenever possible, and look for opportunities to contribute to deployments, monitoring, scripting, or incident reviews.
If you can’t publish company projects, create small sanitized examples at home and document the architecture, decisions, and tradeoffs. More importantly, try to move internally or find a role that combines QA with automation and cloud responsibilities. That is likely a more achievable next step than jumping straight into a mid-level DevOps position.
If your immediate goal is Azure administration, you don’t have to force yourself into a pure DevOps role right away. Build on the experience you already have: identity and access management, governance, networking, monitoring, storage, backup, troubleshooting, and cost awareness.
At the same time, remember that mature Azure environments usually aren’t managed only through the graphical portal. Administrators often use scripting, Azure CLI or PowerShell, templates, Terraform, version control, and change pipelines. Those skills will make you much more competitive for administrator and cloud engineering positions.
The tools listed in those job descriptions are a good indication of what you need to learn next. Working with Azure services through the portal is not the same as designing repeatable infrastructure and delivery processes.
Focus on Terraform or Bicep, Git, CI/CD pipelines, Docker, networking, identity, logging, and basic Kubernetes. Try to connect them in a small project rather than studying each tool in isolation. For example, deploy a simple application with infrastructure as code, build it into a container, and use a pipeline to test and deploy it. Even a modest project can demonstrate how the pieces fit together.
Your current automation work is a good foundation. Just describe it accurately on your résumé: explain the problem, what you automated, which Azure services you used, and the measurable result. You don’t need to reveal confidential company details.
There is definitely a frustrating chicken-and-egg problem because many tools are easier to learn through real work. An internal transfer, a small nonprofit, or a junior systems role that includes cloud responsibilities can be a practical way to gain that first serious experience.
I’ve already started automating parts of our application testing, so combining that with Azure and CI/CD may be a practical way to build experience without starting over in a completely different field.