First Cloud Job Cheatsheet: What to Do in Your First 90 Days

Starting a cloud job is different from passing a certification. The skills that get you hired are not the same as the skills that make you effective once you are there. In a certification, you are tested on what you know. In a job, you are operating in someone else’s environment, following conventions you did not design, and working within constraints you do not fully understand yet.

The first 90 days are about learning the environment, earning trust, and making one or two small contributions. Not about rewriting, improving, or suggesting a better way to do things before you understand why things are the way they are.

Week 1: Listen, Observe, Ask the Right Questions#

The single most important thing in Week 1 is restraint. You are absorbing information, not contributing code or infrastructure changes.

What to do:

• Do not touch production without explicit guidance from your manager or a senior engineer
• Read existing documentation: runbooks, architecture diagrams, README files, wiki pages. Even outdated documentation tells you something about what the team intended.
• Understand the deployment process before you run anything in the pipeline. Ask someone to walk you through it.
• Observe how work is tracked: tickets, sprints, Slack channels, on-call rotations. Get a feel for the rhythm before you jump in.

Questions worth asking in Week 1:

• “What does done look like for my role in the first 30 days?”
• “What should I avoid doing in the first month without checking with someone first?”
• “Where do incidents get logged and how are they communicated?”
• “Is there documentation I should read before I start touching anything?”
• “Who is the right person to ask about X?” — understand who owns what before you start pinging people randomly

What not to do:

Do not suggest improvements, point out inefficiencies, or propose new tools in Week 1. You do not have the context to make those judgements yet. A process that looks unnecessary from the outside often exists for a specific reason that took the team months to learn.

Month 1: Get Productive in the Existing Environment#

The goal of Month 1 is to be able to operate in the environment independently for routine tasks, without requiring someone to hold your hand or check your work constantly.

Understand the incident process:

• How are alerts routed? Where do they land (PagerDuty, Slack, email)?
• What is the escalation path when something is broken?
• When should you page someone and when should you just handle it?
• Where is the incident log or post-mortem repository?

You may not be on-call in Month 1, but you need to understand this process before you are.

Understand the production environment:

Draw a rough diagram of the production architecture from what you can find: documentation, the cloud console, Terraform state, monitoring dashboards. You will probably get it wrong in places. That is fine — it will surface the gaps in your knowledge and give you specific things to ask about.

Set up your local environment properly:

• Cloud CLI tools configured with the right credentials and profiles
• VPN access working (if required)
• SSH keys added and tested
• Access to monitoring dashboards and log systems
• Local development environment that mirrors how the team works

Do not skip this or leave it half-done. A poorly configured local environment is a friction tax you pay every single day.

Make one small contribution:

A documentation fix. A minor pipeline improvement. An alerting rule that was missing. A runbook update. Something that is genuinely useful, small enough to be reviewed quickly, and demonstrates you understand how the team works. This is more valuable than waiting to make a “big” contribution.

Common mistake: Spending Month 1 trying to understand everything before doing anything. You will never understand everything. Start contributing small things while you are still learning.

Months 2–3: Start Contributing Meaningfully#

By Month 2 you should have enough context to take on work that requires real changes to infrastructure or deployments.

Take on a real ticket:

Pick up a ticket that requires you to change infrastructure, update a deployment, or fix a real problem. Not just documentation. Understand the change fully before you make it. Write your plan down. Ask for a review before you apply anything to production.

Ask for feedback before assuming your work is right:

The temptation is to open a PR and assume it is good. Instead, describe your approach to a senior engineer before you write the code or configuration. “I am planning to do X by doing Y — does that make sense given how the team works?” catches misalignments early.

Pair on work you do not fully understand:

If there is a task involving a service or pattern you have not worked with before, ask to pair with someone who has. You will learn more in one pairing session than in a week of reading documentation alone.

Learn the cost and compliance constraints:

Every production environment has things that are off-limits without approvals: certain data handling practices, specific regions, large instance types, public-facing services without a security review. Learn what these are before you accidentally create something that needs to be torn down.

Start developing evidence-based opinions:

After two months in the environment, you will start forming views on what works and what does not. That is healthy. The important thing is to base those opinions on what you have observed in this specific environment — not on a blog post you read, a certification you passed, or how your last job did things. Each environment has its own constraints and history.

Things That Matter More Than Technical Skills in the First 90 Days#

Asking good questions. A good question is specific, shows you have already tried to find the answer, and is directed at the right person. “I tried to deploy the service following the runbook, got this error on step 4, and Googled it without finding anything that matched — is this expected or did I miss something?” is a good question. “How does the deployment work?” is not.

Communicating blockers early. If you are stuck, say so within a few hours, not after a day of spinning. “I have been looking at this for 3 hours and I am not making progress — can I get 10 minutes with someone?” is a sign of good judgement. Sitting on a problem silently for two days is not.

Following team conventions even when you disagree. If the team uses a different naming convention, branching strategy, or tool than you would choose, follow their way. Earn trust first. There is a time to propose changes — it is not Month 1.

Reading code and configuration before writing it. Before you add a new resource in Terraform, read the existing module to understand the patterns being used. Before you open a PR, read similar PRs that were recently merged. The codebase is documentation.

Not breaking production. This sounds obvious. It is less obvious at 5pm on a Friday when a change looked fine in staging and you want to merge before the weekend. If you are unsure, wait.

Am I Set Up Properly? Checklist#

Common Early Mistakes and How to Avoid Them#

Running terraform apply without a terraform plan first.

Always run plan first and read the output before applying. Understand every resource it intends to create, modify, or destroy. If you do not recognise a change, investigate before applying.

Hardcoding credentials in a script or configuration file.

Credentials in code end up in version control. Even in private repositories, this is a serious security issue. Use environment variables, secrets managers, or IAM roles. If you see hardcoded credentials in existing code, raise it — do not copy the pattern.

Deploying to the wrong environment.

In most setups there is a dev/staging/production separation. Check your context (Kubernetes namespace, Terraform workspace, AWS profile, GCP project) before running anything. A deployment to production that was meant for staging can be expensive to fix.

Not reading PR review comments carefully.

Review comments are not just criticism. They contain context, constraints, and team conventions you need to know. Read every comment. Understand why the change was requested before making it. Ask if it is not clear.

Pushing directly to main in a repo with a protected branch.

Most teams protect the main branch. Pushing directly is either blocked or a serious process violation. Use a branch, open a PR, get a review. Even for a one-line change.

What to Aim for by Month 3#

By the end of Month 3, you should have:

• Made a genuine contribution to the team’s infrastructure, tooling, or reliability — something that improved things in a measurable way
• A clear enough understanding of the production environment that you could describe it to a new starter
• The trust of at least one senior engineer who has seen your work and thinks you are reliable

These three things will set the tone for the rest of your time at the company and give you the foundation to grow quickly from there.