Cloud Interview Study Plan: A 4-Week Prep Schedule
This plan is for candidates who have an interview confirmed or likely within four weeks. It is not an open-ended learning plan — it is a focused prep schedule designed to get you as ready as possible in the time you have.
Four weeks is enough time to refresh your technical knowledge, practise answering questions out loud, prepare your behavioural stories, and research the company. It is not enough time to learn cloud from scratch. If you are still at the foundations stage, the cloud engineer roadmap is the better starting point.
Before You Start: What This Plan Assumes#
- You have some existing cloud experience (hands-on, not just reading)
- You have a specific role or role type in mind
- You can commit 45-90 minutes per day, most days of the week
- You know which cloud platform the role uses (AWS, GCP, or Azure)
If you are interviewing at multiple companies simultaneously, this plan still applies — you will adapt the technical focus areas for each company, but the structure stays the same.
Week 1: Audit and Foundations#
Goal: Know your gaps before you start filling them randomly.
The most common prep mistake is reviewing what you already know and feeling confident, when what you actually needed was to find the areas you have not touched in a while. Week 1 is about honest assessment.
Day 1-2: Audit Your Knowledge#
Go through the job description line by line and list every technical skill mentioned. Then honestly rate yourself on each: strong, patchy, or unfamiliar.
Also list the services you have not used in the last six months. You may have set up VPC peering two years ago and forgotten the specifics. That gap will show up in an interview.
Create two lists:
- Things to refresh (you know them but need to re-examine the details)
- Things to build up (you have weak or no experience and they appear in the job description)
Day 3-4: Refresh Core Cloud Concepts#
Regardless of platform or role, there are fundamentals every cloud engineer interview will test:
- IAM: policies, roles, service accounts, least privilege
- Networking: VPCs, subnets, routing, security groups, NAT, DNS
- Compute: VMs, auto-scaling, load balancing
- Storage: object storage, block storage, file storage — when each applies
- Managed vs self-managed services: the trade-offs
Do not read passively. For each concept, write two or three sentences explaining it as if you were answering an interview question. If you can’t, that’s the gap.
Day 5-7: Make a Question Bank#
Build a personal question bank from three sources:
- Questions from the job description itself (if it says “experience with Kubernetes”, write down the questions you would expect to get asked about Kubernetes)
- Questions from the cloud engineer interview questions guide
- Questions from your audit — the areas you flagged as patchy are where question banks are most useful
You do not need to answer all of them yet. The purpose of building the bank this week is to make the next three weeks more targeted.
Daily time commitment this week: 60-75 minutes.
Week 2: Technical Depth#
Goal: Fill your identified gaps and practise explaining things out loud.
Day 8-10: Focus on Platform-Specific Services#
Go deep on the services most relevant to the role. Do not try to cover everything — focus on what the job description mentions and what commonly comes up for this type of role.
For a DevOps-focused role on AWS, that means ECS or EKS, CodePipeline or GitHub Actions integration, CloudFormation or Terraform, and IAM roles for CI/CD pipelines.
For a data engineering-focused role on GCP, that means BigQuery, Pub/Sub, Dataflow, Cloud Storage, and IAM at the project and dataset level.
Use the official documentation for specifics (limits, default behaviours, service quotas) because these details come up in interviews and most third-party resources do not cover them. Rebuild something you have built before from scratch — the act of doing it again surfaces the gaps that reading alone does not.
Day 11-12: Infrastructure as Code#
Most cloud engineering interviews expect some familiarity with Terraform, CloudFormation, or a platform-native IaC tool. Review:
- How state works in Terraform and why it matters
- Module structure and when to use modules
- How to handle secrets and variables
- Common commands you use day to day (
plan,apply,import,state mv)
If you are weak on IaC, write a simple Terraform configuration this week — even a basic VPC with two subnets and a compute instance. The act of writing it cements more than reading about it.
Day 13-14: Explain Things Out Loud#
Reading and understanding are different from being able to explain something clearly under mild pressure. This week, pick five concepts from your question bank and explain each one out loud, as if answering an interview question.
Time yourself. A good answer to a foundational question should take 60-90 seconds. If you are running over two minutes, you are over-explaining. If you are done in 20 seconds, you have not gone deep enough.
Record yourself on at least one of these. The discomfort of listening to yourself is useful data.
Daily time commitment this week: 75-90 minutes.
Week 3: Practice and Scenarios#
Goal: Move from reviewing knowledge to applying it under interview conditions.
Day 15-17: Work Through Technical Questions#
Take your question bank from Week 1 and start answering the questions — out loud, as if in an interview. Do not write the answers first. Speak them.
For each answer, check yourself:
- Did you define key terms clearly?
- Did you give a concrete example or use case?
- Did you explain a trade-off or limitation?
- Did you take longer than two minutes without adding proportional value?
Focus on the questions where your answers felt thin or uncertain. Those are the ones that will show up in the interview and catch you out.
Day 18-19: System Design and Scenarios#
Practise working through a system design prompt from scratch. Use the process of speaking through assumptions, constraints, and trade-offs. Pick one scenario from the scenario-based interview guide and work through it fully — not just “here’s what I would do” but the entire diagnostic reasoning process.
If you have a friend or colleague who can mock-interview you, this week is the time to ask. Even one 30-minute mock with feedback is worth several hours of solo review.
Day 20-21: Architecture Concepts#
If the role is at a senior or mid-senior level, make sure you can discuss:
- High availability vs fault tolerance (they are related but not the same)
- RTO and RPO and how architectural choices affect them
- When microservices make sense and what problems they introduce
- Multi-region trade-offs: when is multi-AZ enough?
You do not need to know every architectural pattern in detail — you need to be able to reason about trade-offs in a conversation. See the cloud architecture interview questions guide for the specific concepts that come up most.
Daily time commitment this week: 60-90 minutes.
Week 4: Refinement and Prep#
Goal: Get everything to interview-ready state, practise the non-technical elements, and build confidence.
Day 22-24: Behavioural Stories#
Spend dedicated time on your STAR stories. Most candidates leave this until the day before and then stumble through unpolished answers about vague situations.
Pick 6-8 experiences from your work history that you can draw from in the interview. Make sure they cover:
- Handling an incident or production issue
- Making a technical decision or recommendation
- Dealing with disagreement or conflict
- Learning something new quickly
- Delivering under constraints
Practise telling two or three of these out loud. They should be two to three minutes each — specific, concrete, and ending with a clear result or lesson. See the behavioural interview guide for the full STAR framework and common mistakes.
Day 25-26: Company Research#
Read the company’s engineering blog if they have one. Many cloud-heavy companies publish how they think about infrastructure, what tools they use, and what problems they are solving. This is interview gold — references to their actual tech choices in your answers demonstrate real interest and preparation.
Review their job description one more time. Flag any terms or technologies that appeared in the description but that you did not properly address in Weeks 2-3. Spend a focused hour on each.
Prepare 3-5 questions to ask them. Good questions are specific to the team’s work, not questions answered on their website. “What does your CI/CD pipeline look like?” is reasonable. “What is your biggest infrastructure challenge this year?” is better.
Day 27-28: Final Review and Logistics#
Do a final pass through your question bank — just the questions, without looking at your notes, to see which ones you can answer confidently and which ones still feel shaky. Spend your remaining time on the shaky ones.
Confirm practical details: the interview format (phone, video, in-person), how many rounds, whether there is a live coding or infrastructure task. Ask the recruiter if you are unsure — it is a legitimate question.
Daily time commitment this week: 45-60 minutes.
What to Do the Day Before#
Do not cram. The day before an interview is not the time to learn new material — it is too late for it to stick and attempting it increases anxiety.
- Re-read the job description once
- Review your two or three strongest STAR stories out loud
- Confirm the interview time, link or address, and interviewer names if you have them
- Get a reasonable amount of sleep
Preparation that happens the day before an interview is almost always wasted. The preparation that matters happened in the previous four weeks.
If You Only Have 2 Weeks#
Cut Week 3 in half and merge it with Week 4. Prioritise:
- Audit your gaps (Day 1-2, still essential)
- Refresh the highest-priority technical topics from the job description (Days 3-6)
- Practise explaining five to eight technical questions out loud (Days 7-9)
- Prepare your STAR stories (Days 10-11)
- Company research and final review (Days 12-14)
Drop the deep-dive architecture content unless the role is explicitly senior. Focus on what the job description says the team actually does.
Adapting the Plan for Different Role Types#
DevOps engineer: Weight Week 2 toward CI/CD pipelines, IaC, and container orchestration. In Week 3, practise deployment scenarios and incident-handling questions specifically.
Cloud engineer (generalist): Keep the plan as written, but make sure networking fundamentals get dedicated time in Week 2. VPC configuration and subnet design questions come up consistently in cloud engineer interviews.
SRE: Add reliability engineering concepts to Week 2: SLOs, error budgets, on-call processes, and observability tooling. Week 3 scenario practice should include incident scenarios specifically, not just system design.