I recently graduated with a systems science degree and started working as a system administrator trainee a few months ago. My background is more focused on systems, business, and how IT fits into organizations than on hands-on programming or infrastructure.
The company originally described a structured onboarding plan and a mentor, but since this is their first trainee in this kind of role, the process has been less organized than expected. My coworkers are helpful, but they are very busy, and I have not been given many small tasks that I can take ownership of. Most of my time has gone toward teaching myself.
I am also the youngest person and only woman on the IT team, while many of my coworkers have decades of experience. That gap sometimes makes me feel as though I should already understand things, so I hesitate to ask questions. My manager tells me not to put so much pressure on myself, but I still feel like I am not progressing or contributing enough.
I have worked through some AZ-900 material and understand the basic ideas behind services such as VNets, subnets, virtual machines, and network security groups. What I am missing is practical experience: what do administrators actually do with these concepts, and how do they troubleshoot real problems?
If you were starting over as a junior Azure administrator, what would you learn first? What small projects or exercises would help turn the theory into useful hands-on skills? I have access to a development environment where I can experiment safely, so I would especially appreciate ideas involving infrastructure, identity, networking, security, servers, or cost management.
4 Answers
First, do not mistake an experience gap for a competence gap. People with decades in IT often forget how much background knowledge they have accumulated, so it is completely normal for their explanations to feel incomplete. Ask them to slow down or explain the assumed context; that is part of training, not an inconvenience.
For a practical lab, create a small virtual network with two VMs. Configure one as a domain controller, join the other to the domain, and document each step. Then deliberately change an NSG rule, break remote access, investigate the logs and connectivity, and restore it. Repeat the same idea with DNS, identity permissions, routing, backups, and monitoring. Breaking and repairing systems teaches much more than reading definitions.
Certifications and structured courses are useful for vocabulary, but they should support hands-on work rather than replace it. Follow a curated Azure learning path and keep up with reliable technical demonstrations, then immediately reproduce the relevant examples in your lab.
Also try to schedule a short recurring session with one teammate, even if it is only 20 minutes. Come prepared with a specific question, a diagram, or something you tried and could not explain. Busy engineers are much more likely to help with a focused question than with a broad request to teach Azure. Keep a list of unfamiliar terms from meetings and research a few each week.
Use the company environment as your learning map. Find out how subscriptions, resource groups, networks, identities, security controls, monitoring, backups, and costs are organized. Ask whether there is documentation or an architecture diagram, then make your own version as you learn.
A useful early project would be to review resource utilization and spending in a nonjudgmental way. Identify unused resources, oversized VMs, missing tags, inconsistent backup settings, or places where monitoring could be improved. Present your findings as questions and possible improvements rather than criticism. This will teach you how the organization actually uses Azure and give the team something concrete to discuss.
Azure is too broad to learn all at once, so choose a foundation path instead of trying to cover every service. I would start with identity and access management, networking, compute, storage, monitoring, and basic security. Learn how those pieces connect in your company’s setup, including any on-premises systems.
Keep a simple lab journal with the goal, architecture, commands or portal changes, expected result, actual result, and what fixed the problem. Build a small application environment with a network, separate subnets, a VM or app service, managed identity, key storage, logging, alerts, and a backup. Then tear it down and rebuild it with infrastructure-as-code if that is relevant to your team. That turns isolated terms into an end-to-end system.
That is reassuring to hear. I have access to a development environment where I can experiment, so I am going to start with the two-VM lab and deliberately test what happens when I change the network rules.