1-Week Cloud Interview Prep Cheatsheet: 7-Day Sprint Plan

Seven days is enough time to meaningfully improve your position if you focus on the right things. This is not “study everything you might ever be asked.” It is “cover the most likely ground efficiently, so you walk in knowing your material and your own examples cold.”

The plan assumes you already have some cloud knowledge. If you are starting from nothing, the 30-day plan is a better fit.

Day 1: Know the Company and Role#

Before you review a single technical topic, understand what you are walking into.

Read the job specification carefully:

Go through every line. Note every technology mentioned — cloud provider, specific services, tools (Terraform, Kubernetes, Datadog, etc.), and any methodology terms (GitOps, SRE, agile). These are the topics the team cares about. Prioritise them in your review.

Research the company:

• What cloud provider do they use? Check the job spec, LinkedIn, engineering blog, and job postings for other roles on the team.
• What industry are they in? Finance and healthcare have specific compliance requirements. Startups and scale-ups have different infrastructure patterns from large enterprises.
• Is there a public engineering blog? If so, read a few posts — it shows you what the team cares about and gives you things to ask about.

Understand the role level:

Review your own CV:

Read every item on your CV and be ready to talk about it. If you listed “Terraform” in your skills, expect to be asked about state backends, modules, or remote state. If you listed a project, know it inside out: what the architecture was, why you made the decisions you made, what you would do differently now.

Day 2: Networking and Security Concepts#

These are the highest-frequency topics across all cloud engineering interviews.

Networking concepts to know:

• VPCs: what they are, why they exist, the difference between public and private subnets
• Subnets: CIDR notation, how subnets relate to availability zones
• Security groups and network ACLs (or NSGs on Azure): stateful vs stateless, when to use each
• Route tables: how traffic is directed within and out of a VPC
• NAT gateway: how private instances reach the internet without being publicly accessible
• Load balancers: L4 vs L7, when each is appropriate
• DNS: how it works, what a CNAME and A record are, what Route 53 / Cloud DNS / Azure DNS does

IAM and security concepts:

• Roles vs users vs service accounts — the difference and when to use each
• Least privilege: what it means in practice (only grant what is actually needed for the task)
• Policies: how resource-based and identity-based policies interact
• How to secure secrets: Secrets Manager, Key Vault, Secret Manager — not hardcoded, not in version control, rotated regularly
• MFA and federation: basic understanding of how identity federation works

Practice: Explain each of these concepts out loud, as if talking to someone who knows a bit about tech but is not a cloud expert. If you cannot explain it out loud, you do not know it well enough yet.

Day 3: Compute, Containers, and Scaling#

Compute:

• EC2 / Compute Engine / Azure VMs: instance types, what drives the choice between them
• Auto-scaling: how it works, what metrics trigger it, what happens to in-flight requests during scale-in
• Launch templates and instance groups: how they are used in auto-scaling configurations
• Spot / preemptible / spot VMs: cheaper but interruptible, when this is acceptable

Containers:

• Docker: what a container is vs a VM, what a Dockerfile does, what a container registry is for
• Container orchestration: why Kubernetes exists (scheduling, scaling, self-healing)
• Kubernetes basics: pods, deployments, services, namespaces, what happens when a pod crashes

Serverless:

• Lambda / Cloud Functions / Azure Functions: event-driven, no server management, cold starts
• When to use serverless: short-lived tasks, event processing, irregular traffic. When not to: long-running jobs, persistent connections, cost at high volume.

Be ready for: “How does auto-scaling work and what can go wrong?” This is a common follow-up that separates candidates who have read about auto-scaling from those who have used it.

Day 4: Storage, Databases, and CI/CD#

Storage:

• Object storage (S3, GCS, Azure Blob): for files, images, backups, static websites. Not a file system. Eventually consistent in some configurations.
• Block storage (EBS, Persistent Disk, Azure Disk): attached to a VM like a hard drive. Used for databases, OS volumes.
• File storage (EFS, Filestore, Azure Files): shared file system, multiple VMs can mount it. Used when multiple services need to read/write the same files.
• Lifecycle policies: automatically move or delete objects based on age or access patterns

Databases:

• Managed relational: RDS, Cloud SQL, Azure Database — you manage the schema, they manage the server
• NoSQL options: DynamoDB, Firestore, Cosmos DB — key-value or document store, scales horizontally, no fixed schema
• When to use which: relational for structured data with relationships, NoSQL for flexible schemas, high throughput, or large scale reads

CI/CD:

• Pipeline stages: source → build → test → deploy
• Tools: GitHub Actions, GitLab CI, Jenkins, Cloud Build, Azure Pipelines
• IaC in pipelines: terraform plan in CI, terraform apply on merge to main
• GitOps: the Git repo is the source of truth for infrastructure state. Changes are made via PRs, not directly.

Terraform specifically: Know init, plan, apply, destroy. Know what state is. Know that you should not edit state files manually. Know what a module is.

Day 5: Architecture and Troubleshooting Scenarios#

Practise answering these scenarios out loud using the STAR structure (Situation, Technical context, Action, Result):

“How would you design a highly available web application?”

Cover: load balancer across AZs, stateless application tier, external session store (Redis), managed database with multi-AZ or replica, health checks, auto-scaling, CDN for static assets. Ask clarifying questions before designing: expected traffic, latency requirements, budget constraints.

“How would you investigate a service that is responding slowly?”

Cover: check metrics (CPU, memory, latency, error rate), check logs for errors or unusual patterns, check if a recent deployment coincides with the issue, check database query times, check network latency between services, use distributed tracing if available to isolate the bottleneck.

“How would you reduce costs on an over-provisioned system?”

Cover: right-size instances using metrics data, switch idle workloads to reserved or committed-use pricing, move appropriate workloads to spot or preemptible, use lifecycle policies on storage, identify and terminate unused resources, set up billing alerts.

The point of these practice runs is not to produce a perfect answer. It is to get comfortable structuring an answer out loud and asking clarifying questions before diving in.

Day 6: Behavioural Questions and Project Prep#

Prepare 3–5 STAR stories from your experience or projects:

For each story, prepare: what the situation was, the specific technical context, what you personally did (not the team — you), and what the outcome or learning was.

If you have limited work experience, frame personal projects as you would frame a work challenge. “I was building a cloud-hosted application and ran into X. I investigated by doing Y. The solution was Z. I learned that…”

Common behavioural questions:

• “Tell me about a time you solved a problem under pressure.”
• “Tell me about a time a project did not go as planned.”
• “How do you prioritise when you have competing work?”
• “Tell me about a time you disagreed with a technical decision.”
• “How do you keep your skills up to date?”

Prepare 3 questions to ask the interviewer. Good questions include:

• “What does the deployment process look like today, and are there any improvements planned?”
• “What does a typical incident response look like on the team?”
• “What are the main infrastructure challenges the team is working through right now?”

Avoid: “What is the salary?” (save for offer stage), “How many days off?” (not the impression you want at interview), “What does the company do?” (research this beforehand).

Day 7: Review and Rest#

Morning: Do a final pass through your notes from Days 2–5. Review your STAR stories. Check the company one more time.

Afternoon: Light review only. No cramming new topics. If you do not know it by Day 7, you are not going to learn it today.

Evening: Stop studying. Get a decent sleep. Tiredness is one of the most common reasons for poor interview performance and it is entirely preventable.

Morning of the Interview#

Do: Review your own projects and the two or three examples you are most likely to use. Skim the job spec one more time.

Do not: Open a new tutorial. Read a new topic. Try to memorise something new. Cramming the morning of an interview does more harm than good — it adds noise and increases anxiety.