Cloud Interview Cheatsheet: Last-Minute Prep and Key Topics
Cloud interviews test three things at once: what you know technically, how you solve problems you have not seen before, and whether you can explain your thinking clearly. Memorising facts is the least important of the three. Interviewers want to understand how your brain works when something is unfamiliar, not whether you can recite a definition.
This cheatsheet covers the topics most likely to come up, the question types you will face, and how to frame your answers so they land well.
Topics That Come Up Most#
| Topic | Why it matters | Prep priority |
|---|---|---|
| Networking (VPCs, subnets, load balancers, DNS) | Almost every cloud problem involves networking at some level | High |
| IAM and security (roles, least privilege, policies) | Security hygiene is expected at all levels | High |
| Compute and scaling (auto-scaling, containers, serverless) | Core infrastructure knowledge | High |
| Storage (object/block/file, lifecycle policies) | Choosing the right storage type is a common scenario question | Medium |
| CI/CD and IaC (pipeline stages, Terraform, GitOps) | DevOps-adjacent roles will dig deep here | Medium–High |
| Observability (metrics, logs, traces, alerting) | SRE and platform roles test this heavily | Medium |
| Architecture patterns (stateless, high availability, DR) | Senior and design-heavy roles lean on this | Medium |
| Cost and billing (reserved instances, spot, cost optimisation) | Any production role will touch this eventually | Low–Medium |
Prioritise networking, IAM, compute, and storage as your core review areas. The rest depends on the specific role.
Question Types You Will Face#
Scenario questions — “How would you design a highly available web application on AWS?”
These test architecture thinking and trade-off awareness. There is no single correct answer. Interviewers want to see your reasoning, not just a solution.
Concept questions — “What is the difference between SQS and SNS?”
These test knowledge breadth. Give a concise explanation and a concrete use case for each. Do not just define the acronym.
Troubleshooting questions — “A service is responding slowly, how do you investigate?”
These test methodical thinking. Start broad (where is the bottleneck?) and narrow down systematically. Explain each step and why you are taking it.
Behavioural questions — “Tell me about a time you dealt with a production incident.”
These test communication, ownership, and learning. Use structured answers and be specific. Vague answers (“I worked with the team to resolve it”) tell the interviewer nothing.
Scenario Answer Framework#
Adapt the STAR method for cloud scenarios:
- Situation — What was the context? What was running, what was at stake?
- Technical context — What was the architecture, tooling, or constraint you were working within?
- Action taken — What did you specifically do? What commands, configs, changes, decisions?
- Result and learning — What was the outcome? What would you do differently or the same next time?
This works for both behavioural questions (past experience) and design scenarios (hypothetical problem-solving).
10 Questions That Come Up Frequently#
1. What is the difference between SQS and SNS?
SQS is a queue — one consumer pulls a message and processes it. SNS is a pub/sub system — one message is pushed to multiple subscribers simultaneously. Use SQS for task queues and decoupled processing. Use SNS when you need to fan out a notification to multiple endpoints (email, Lambda, SQS, HTTP).
2. How would you design a highly available web application on AWS/GCP/Azure?
Run application servers across multiple availability zones. Use a load balancer to distribute traffic. Store session state externally (Redis or database) so any instance can serve any request. Use a managed database with a read replica or multi-AZ setup. Store static assets in object storage with a CDN in front.
3. What is the difference between authentication and authorisation?
Authentication confirms who you are — logging in with credentials, verifying a token. Authorisation determines what you are allowed to do once your identity is confirmed. A user can be authenticated but unauthorised to access a specific resource.
4. How do you secure secrets in a cloud environment?
Never hardcode secrets in code or config files. Use a managed secrets service (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault). Inject secrets into applications at runtime via environment variables or a mounted secret volume. Rotate secrets regularly and audit access.
5. What is a VPC and why does it matter?
A Virtual Private Cloud is a logically isolated network within a cloud provider. It lets you define your own IP ranges, subnets, route tables, and firewall rules. Without a VPC, your resources would be on a shared public network. A VPC gives you control over who can reach what.
6. What is a load balancer and when would you use L4 vs L7?
A load balancer distributes traffic across multiple servers. Layer 4 (network/transport) routes based on IP and port — fast, simple, no knowledge of the content. Layer 7 (application) routes based on HTTP data like URL paths, headers, or cookies — useful for routing /api traffic to one service and /static to another.
7. How does auto-scaling work?
Auto-scaling monitors a metric (CPU, request count, queue depth) and adds or removes instances when it crosses a threshold. You define a minimum and maximum instance count, and the scaling policy. Scale-out adds capacity; scale-in removes it. The challenge is setting sensible thresholds and handling stateful applications cleanly.
8. What is the difference between IaaS, PaaS, and SaaS?
IaaS gives you raw infrastructure — VMs, networking, storage. You manage everything above the OS. PaaS provides a platform to run your code without managing servers — Cloud Run, Heroku, App Engine. SaaS is a fully managed application you consume as a user — Gmail, Salesforce, Slack.
9. How would you investigate a performance issue in a cloud application?
Start at the symptom: which service is slow? Check metrics first — CPU, memory, latency, error rate. Check logs for errors or unusual patterns. Use distributed tracing if available to find which service in a chain is the bottleneck. Check database query performance. Verify network latency between services. Check if a recent deployment coincides with the issue.
10. What is idempotency and why does it matter?
An idempotent operation produces the same result whether you run it once or ten times. It matters because in distributed systems, retries are common — network failures, timeouts, and crashes all trigger retries. If your operation is not idempotent, retries cause duplicate data or unintended side effects.
Day-Before Checklist#
- Re-read the job description and note every technology mentioned
- Confirm which cloud provider they use (check the job spec, company blog, LinkedIn)
- Review 2-3 projects from your own work that you can speak to in detail
- Read through your CV and be ready to explain every item on it
- Prepare 3 thoughtful questions to ask the interviewer (not salary, not “what does the company do”)
- Get the interview logistics sorted: time zone, link, ID if on-site
- Get a decent sleep — tiredness kills performance in technical interviews
Red Flags to Avoid#
Vague answers. “I worked on cloud infrastructure” tells the interviewer nothing. Be specific about what you did, what technology you used, and what the outcome was.
Claiming to know tools you do not know. If you say you know Terraform and they ask you to explain state backends, you need an answer. Only list things you can actually discuss.
Not asking clarifying questions on scenarios. If asked “how would you design a web application?”, ask clarifying questions first: expected traffic? Latency requirements? Geographic distribution? Real engineers clarify before designing.
No real examples. “In theory I would…” is weaker than “I did this on a project and here is what happened.” Even personal or study projects count if you can speak to them in detail.
Shutting down under uncertainty. It is fine to say “I have not worked with that specific service, but here is how I would approach learning it / how it compares to something I have used.” Interviewers are testing problem-solving, not encyclopaedic knowledge.