I recently graduated with a systems science degree, which covered theory, organizations, business, and how IT fits together, but involved less programming than a traditional computer science degree. A few months ago, I started as a systems administrator trainee. I was told there would be a structured onboarding plan and a mentor, but it has become clear that the company is figuring out the trainee role as they go.
Most days, I teach myself and occasionally ask coworkers for help. They are supportive, but they are also busy with their own responsibilities, and I have not been given many small tasks that I can own and learn from. I am also the youngest person and only woman on the IT team, while many of my coworkers have decades of experience. They sometimes explain things as though I should already understand them, which has made me hesitant to ask questions and caused me to underestimate myself.
I have a basic understanding of Azure and have worked through some AZ-900 material, but I am struggling to turn concepts such as virtual networks, subnets, virtual machines, and network security groups into practical skills. I have access to a development environment where I can experiment safely, so I would like to build and troubleshoot useful projects rather than only read documentation.
If you were starting over as a junior systems administrator, what would you learn first? What small Azure projects or exercises would help connect the theory to real administration work? I would also appreciate advice on understanding the company's infrastructure, identity, networking, security, server, subscription, and cost-management practices without becoming overwhelmed.
4 Answers
Azure is far too broad to approach as one subject. Break it into foundations: identity and access, networking, compute, storage, monitoring, security, and automation. Learn enough about each area to understand how they connect, then go deeper where your team spends most of its time.
The cloud administrator label can hide several different jobs. Find out whether your team mainly handles infrastructure, servers, identity, networking, security, or all of them. A structured learning path or course platform can help, but pair every topic with a small lab or a real example from your workplace. Watching regular Azure update content can also help you become familiar with terminology and recognize topics that are worth studying in more depth.
Ask your manager for a lightweight training plan rather than waiting for a perfect onboarding program to appear. It could contain three parts: topics to learn, a person to shadow, and a small task to complete each week. Even a recurring thirty-minute check-in would give you a place to ask questions and confirm priorities.
When you get stuck, write down what you already know, what you expected to happen, what actually happened, and the specific question you need answered. That makes it easier for busy coworkers to help and shows that you are taking ownership. You do not need to prove that you already know everything; your job as a trainee is to build understanding safely and progressively.
Try to understand how Azure is actually used in your organization instead of attempting to learn the entire platform at once. Map out the subscriptions, resource groups, identity model, networking, on-premises connections, security controls, monitoring, deployment tools, and cost-management process. Ask coworkers to explain one area at a time, and turn each conversation into a simple diagram or set of notes.
Once you understand the environment, look for a small improvement you can own, such as documenting resources, reviewing unused assets, improving tags, creating a basic cost report, or checking whether common resources follow the team’s security standards. Those tasks create useful results while helping you learn what the company actually depends on.
First, don’t mistake the experience gap for a knowledge gap. People with decades in IT often forget how much background knowledge they’ve accumulated, so needing things explained does not mean you are failing.
For hands-on practice, use your development environment to build a small lab. Create a virtual network with separate subnets, deploy two virtual machines, configure one as a domain controller, and join the other to the domain. Then deliberately change an NSG rule and observe how connectivity breaks. Troubleshooting the problem will teach you much more than memorizing definitions. Keep notes on what you changed, what failed, and how you fixed it. That record can become your own practical reference guide.
That’s reassuring to hear. I do have a safe development environment, so I’m going to start with a small lab like this and document each change and troubleshooting step.
Our small Azure team handles a mixture of infrastructure, security, identities, networking, and servers, which is part of what made the platform feel so overwhelming. I’ll try organizing my learning around those areas and identifying which ones are most important in our environment.