I've recently accepted an Infrastructure Engineer role in a fully cloud-based environment and will be starting next month. I've spent about 10 years in second-line IT support, with some third-line investigation work, at the same organization. My current environment is hybrid and fairly siloed, so over time I've become more interested in cloud infrastructure, networking, identity, Intune, automation, and security rather than primarily supporting end-user devices.
I've been studying outside work, completed several Microsoft certification exams, built projects in Azure, and successfully interviewed for this infrastructure role. I understand that certifications and lab work are very different from managing production systems, and I expect there will be a lot I need to learn.
For people who have made a similar transition, or who currently work in infrastructure or cloud engineering, what should I realistically expect during my first three to six months? What does a new engineer usually do day to day, what should I already know, and what is normally learned on the job? I'm especially interested in advice about learning the existing environment, handling operational work, on-call expectations, and avoiding the mistake of trying to master Azure, networking, infrastructure as code, Linux, and security all at once.
4 Answers
Cloud platforms still rely on the same fundamentals. TCP/IP, routing, firewalls, virtual machines, identity, storage, and troubleshooting principles haven’t fundamentally changed; the difference is that they’re software-defined and managed through different interfaces. Learn each general technology alongside how your organization implements it. Your daily work could involve maintaining existing deployments, adjusting infrastructure-as-code, responding to alerts, supporting releases, or investigating incidents. Also make sure you understand the on-call arrangement and how much out-of-hours work is actually expected, rather than assuming every infrastructure role has the same schedule.
Your support background will probably help more than you expect. Troubleshooting is still troubleshooting; the systems are just larger and more interconnected. Spend the first few months reading runbooks and existing infrastructure-as-code, following incidents, learning how changes are approved, and understanding how systems are deployed, monitored, backed up, and recovered. Try to build a map of the environment and document what you learn before attempting major improvements.
Don’t rush to fix things just because they look unusual. First learn why they were designed that way, what constraints exist, and what past failures shaped the current setup. There may be undocumented dependencies or operational workarounds that aren’t obvious from the configuration. Once you understand the reasons behind the current design, you’ll be in a much better position to suggest improvements safely.
At first, expect to spend more time learning the environment than delivering major projects. You may handle routine operational work such as patching, monitoring alerts, performing morning checks, investigating recurring issues, and working through the business-as-usual queue. A good new engineer reviews a request, forms an opinion, and then asks whether they have the authority and context to make the change. Ask plenty of questions, but don’t be afraid to take action once you understand the process and risks.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures