Cloud Engineer Study Path for Your First 90 Days in the Job

Why a new hire needs a different study path

Before the job, you studied one provider in a clean sandbox. At work, you meet an environment built over years by other people. It has naming rules nobody wrote down, old resources nobody owns, and pipelines that only one person fully understands.

So the question changes. You no longer ask "what should I learn about the cloud?" You ask "what do I need to understand about this cloud to be safe and useful?" A good onboarding study path answers that question in order.

• Access and safety first. Know what you can touch, and how to avoid breaking production.
• The map second. Know how accounts, networks and services connect.
• The delivery path third. Know how a change goes from a pull request to production.
• Ownership last. Run something on your own, including when it fails.

Days 1 to 30: study the estate, not the console

The goal of the first month is to understand what exists and who owns it. Do not try to improve anything yet.

Read the existing documentation, then check it against reality. Docs and real environments drift apart. Ask for 30 minute sessions with the people who built each part. Bring a draft diagram and let them correct it. People explain more when they correct a drawing than when they answer an open question.

Milestone for day 30: a one-page diagram of the environment, reviewed by a senior engineer. Add a short list of open questions: resources with no owner, docs that do not match what you saw, and risks you noticed. That list is worth a lot to your manager, because new eyes see what the team stopped seeing.

• Account or project structure: how many accounts, subscriptions or projects exist, and why. Which ones are production.
• Identity and access: how you log in, which roles you have, how access is requested and approved. Find out what single sign-on and break-glass access look like.
• Network layout: main networks, how they connect to each other and to the office or data center, and where traffic enters from the internet.
• Naming and tagging rules: these tell you who owns a resource and what it costs. If the rules are not written down, write them down.

Days 31 to 60: study how changes reach production

The second month is about the delivery path. In most teams, nobody should change production by clicking in a console. Changes go through code and pipelines, so that is what you study now.

Then pick one small, real infrastructure change. Good first changes include adding a missing tag, fixing an alert threshold, or turning a resource that was created by hand into code. Ship it through the normal process, with review.

Milestone for day 60: a merged infrastructure change, deployed by the normal pipeline, with no manual step. Write a short note on anything confusing you met along the way. That note often becomes better onboarding docs for the next hire.

• Infrastructure as code: read the repos the team uses (Terraform, CloudFormation, Bicep, Pulumi or other). Learn how modules are organized, where state is stored and how drift is handled.
• CI/CD pipelines: follow one real change from pull request to deployment. Note every check, approval and environment it passes through.
• Environments: understand what is different between dev, staging and production, and why.
• Secrets and configuration: learn where secrets live, how they are rotated and how apps read them.

Days 61 to 90: study how the platform is run

The last month turns you from a contributor into an owner. You study what happens after deployment: monitoring, incidents and cost.

Ask to be the named owner of one service or component. Join on-call as a shadow first, then take a shift with a senior engineer as backup.

Milestone for day 90: a runbook you wrote or fixed, a first on-call shift, and a short review with your manager: what you own now, what you learned, and what you want to improve next quarter.

• Monitoring and alerts: what is measured, which alerts wake people up, and which ones everyone ignores.
• Runbooks: read the runbooks for the services you will own. Test one in a safe environment if you can.
• Incident history: read the last few incident reviews. They show the real weak points of the platform faster than any diagram.
• Cost reports: learn where the cloud bill comes from, and which teams or services drive it.

Where certifications fit in a new job

Many new cloud engineers feel they should study for the next certification right away. In the first 90 days, that usually competes with learning the job itself.

A simple rule works well: study for a certification only when it matches the platform you now run. If your company uses a provider you did not certify on, an associate level exam on that provider can make sense around the end of month two. By then you will have real context, so the study goes faster. If you already hold the matching certification, wait until after day 90 and pick a topic your incidents and tickets show you need, such as networking, security or Kubernetes.

Check exam details, prices and renewal rules on the official certification pages of AWS, Microsoft Learn or Google Cloud before you book. They change over time.

How to present this plan to your manager

Managers like a plan they can track. Turn the three phases above into a one-page roadmap with the milestones and a date for each. Share it in your first week and ask what they would change. Then review it together at day 30, 60 and 90.

This turns onboarding into a shared plan, not a guess. It also gives you a clear record of what you delivered when your first performance review comes. For the general method behind these plans, see our 30-60-90 day plan template guide. If you came from software development, the 30-60-90 day plan for software engineers covers the code side in more depth.