Interview Insights · Cloud Engineer
What I Wish Every Cloud Engineer Candidate Knew Before Walking In
Quick summary — Cloud interview prep
Cloud interviews test the fundamentals underneath the services far more than the services themselves. Many candidates spend their preparation memorising service names and limits. Then the interview asks them to split a network into subnets, explain why an instance cannot reach the internet, or design a simple web app with clear trade-offs. These depend on networking, Linux and reasoning, which every cloud provider builds on. If you know what to expect, you can prepare for the hour you will actually have.
In this guide you will learn:
- Why fundamentals matter more than memorised service lists
- The CIDR and subnet maths you should be able to do on paper
- How a troubleshooting round works and a checklist that follows the packet
- How to approach a whiteboard design without drawing every service you know
- A night-before checklist and the questions worth asking at the end
SECTION 01The fundamentals sitting underneath every cloud
AWS, Azure and Google Cloud all rest on the same basics: Linux servers, IP networking, DNS, HTTP, storage and identity. Interviewers know that services change and that you will learn the exact console on the job. What they cannot easily teach is why traffic flows the way it does. So the first part of many cloud interviews quietly checks these basics.
The question I find most revealing is subnet maths. If you can split 10.0.0.0/16 into subnets on paper and say how many usable addresses each has, I know you understand what the VPC wizard is doing for you.
| Fundamental | Typical question | What a good answer includes | Quick practice |
|---|---|---|---|
| CIDR and subnets | How many addresses in a /24, and how many can you use in AWS? | 256 total; AWS reserves 5 per subnet, so 251 usable | Split a /16 into four /18s on paper |
| DNS | What happens when you type a domain in the browser? | Resolver, recursive lookup, record types such as A and CNAME | Run dig on a domain and read the answer |
| Linux | A disk is full on a server. What do you check? | df -h, du to find large folders, log rotation | Fill a test disk and find the culprit |
| Shared responsibility | Who patches the OS on an EC2 instance? | The customer; the provider secures the underlying host | Compare EC2, RDS and Lambda responsibilities |
VPC: 10.0.0.0/16 -> 65,536 addresses
Split into four /18 subnets (each 16,384 addresses):
10.0.0.0/18 10.0.0.0 - 10.0.63.255
10.0.64.0/18 10.0.64.0 - 10.0.127.255
10.0.128.0/18 10.0.128.0- 10.0.191.255
10.0.192.0/18 10.0.192.0- 10.0.255.255
A /24 has 256 addresses.
In AWS, 5 are reserved in every subnet:
network address, VPC router, DNS, future use, broadcast
So a /24 subnet gives 251 usable addresses.import ipaddress
vpc = ipaddress.ip_network('10.0.0.0/16')
for sub in vpc.subnets(new_prefix=18):
print(sub, sub.num_addresses)
# 10.0.0.0/18 16384
# 10.0.64.0/18 16384
# 10.0.128.0/18 16384
# 10.0.192.0/18 16384
subnet = ipaddress.ip_network('10.0.1.0/24')
print(subnet.num_addresses - 5, 'usable in AWS') # 251You do not need to be fast at this. You need to be able to do it without a calculator website. Practise a few splits a day for a week and it becomes easy.
SECTION 02How the troubleshooting round really works
Almost every cloud interview I run includes a broken scenario. The classic one is: 'An EC2 instance in a private subnet cannot reach the internet to install updates. What do you check?' I am not looking for the right answer in the first sentence. I am looking for an order. Strong candidates follow the path a packet takes and check each hop. Weak candidates jump between random ideas.
If you get stuck, say which layer you are checking and why. That alone keeps the interviewer with you, and they will often nudge you towards the next hop.
| Hop to check | What could be wrong | How to verify | Fix |
|---|---|---|---|
| Instance security group | Outbound rules removed | Check outbound rules in the console or CLI | Allow outbound HTTP/HTTPS |
| Subnet route table | No 0.0.0.0/0 route to a NAT gateway | aws ec2 describe-route-tables | Add a default route to the NAT gateway |
| NAT gateway | Placed in a private subnet, or deleted | Check its subnet has a route to the internet gateway | Create it in a public subnet |
| Network ACL | Ephemeral return ports blocked | Check inbound rules for 1024-65535 | Allow return traffic on ephemeral ports |
"I would follow the path of the packet.
First, on the instance: does curl to a public site time out
or fail on DNS? That tells me if it is name resolution or
connectivity.
Then the security group: outbound is usually open, but I
would confirm.
Then the subnet's route table: a private subnet needs a
default route to a NAT gateway.
Then the NAT gateway itself: it must sit in a public subnet
whose route table points to the internet gateway.
Finally the NACLs, especially return traffic on ephemeral
ports, because NACLs are stateless."# From the instance (via Session Manager)
curl -sS -m 5 -o /dev/null example.com && echo ok
dig +short example.com
# Route table for the instance's subnet
aws ec2 describe-route-tables \
--filters Name=association.subnet-id,Values=subnet-0abc123 \
--query 'RouteTables[].Routes[]'
# Where does the NAT gateway live?
aws ec2 describe-nat-gateways \
--query 'NatGateways[].{ID:NatGatewayId,Subnet:SubnetId,State:State}'The best candidates also say how they would reach the instance in the first place. Mentioning Session Manager instead of opening SSH to the internet shows the careful habits teams want.
SECTION 03Designing on the whiteboard without overbuilding
The design question is usually small: 'Design hosting for a company website with a contact form' or 'How would you run this app so it survives one server failing?' The most common mistake is drawing every service you have heard of. Fifteen boxes do not impress anyone. They make the interviewer wonder whether you understand what each one is for.
Start by asking a few requirement questions. Then draw the simplest design that meets them, and add pieces only when a requirement asks for them. Say the trade-off each time you add something.
| Requirement question | Why ask it | Design impact | Trade-off to mention |
|---|---|---|---|
| How much traffic, and does it spike? | Sizing and scaling | Auto Scaling group or serverless | Cost versus headroom |
| Can it be down for a few minutes? | Availability target | One AZ or multiple AZs | Multi-AZ costs more |
| Is any data sensitive? | Security and compliance | Encryption, private subnets, access logs | More setup and review |
| Is it mostly static content? | Simplest possible hosting | S3 plus CloudFront instead of servers | Less flexibility for server logic |
REQUIREMENTS (after asking):
- Company website, mostly static pages
- Contact form that emails the sales team
- Low traffic, short downtime acceptable
DESIGN:
User -> CloudFront (HTTPS via ACM)
-> S3 bucket with static site (not public;
CloudFront origin access only)
Contact form -> API Gateway -> Lambda -> SES email
WHY:
No servers to patch, low cost, HTTPS by default.
WHAT I WOULD ADD IF ASKED:
WAF on CloudFront for bot traffic,
CloudWatch alarm on Lambda errors.NEW REQUIREMENT: Dynamic app, must survive
one server failing.
User -> Route 53 -> ALB (two public subnets, two AZs)
-> Auto Scaling group, min 2 instances across AZs
(private subnets)
-> RDS Multi-AZ (private subnets)
TRADE-OFFS TO SAY ALOUD:
- Two AZs means paying for at least two instances.
- RDS Multi-AZ adds a standby you pay for but
cannot read from in the classic setup.
- NAT gateway per AZ for full HA, or one to save cost.Notice how the second design only appears when the requirement changes. That is how real teams design, and showing it in an interview tells the interviewer you will not overspend on day one.
SECTION 04Before you walk in: a cloud candidate's checklist
Use these tabs in the days before your interview. They cover the fundamentals to refresh, the stories to prepare and the questions worth asking at the end.
FUNDAMENTALS TO REFRESH (one evening each)
[ ] CIDR: split a /16 into /18s and /24s on paper
[ ] Public vs private subnet, IGW vs NAT gateway
[ ] Security group (stateful) vs NACL (stateless)
[ ] DNS: A, CNAME, alias records, TTL
[ ] IAM: user, group, role, policy, trust policy
[ ] Storage: block vs object vs file
[ ] Linux: df, du, top, systemctl, journalctl, ss
[ ] Shared responsibility for EC2, RDS, LambdaHAVE ONE SHORT STORY FOR EACH
1. A project you designed, with one trade-off.
2. Something you broke and how you fixed it.
3. A permission problem you debugged.
4. A time you reduced cost or cleaned up.
5. Something you learned on your own recently.
Format: situation in one line, what you did,
what you learned. Under a minute each.GOOD QUESTIONS FOR THE END
- How do changes reach production here?
- Is infrastructure managed as code? Which tool?
- How is access to production granted to new joiners?
- Is there an on-call rotation for this role?
- What would a good first three months look like?
Avoid asking only about leave policy or timings in
the technical round; save those for HR.SECTION 05Small things that change how the hour goes
These are the reminders I would give every candidate on the way into the room.
- It is fine to say which cloud you know — If you know AWS and the team uses Azure, say so and map the concepts. Interviewers respect honest translation more than guessing at names.
- Draw before you explain — A rough sketch of subnets and arrows makes your answer easier to follow and helps you spot gaps yourself.
- Ask before you design — Two or three requirement questions prevent a design that solves the wrong problem.
- Name the layer when stuck — Saying 'I am now checking the routing layer' keeps the interviewer following you even when you are unsure.
- Close with a real question — Ask how changes reach production. It shows interest and tells you a lot about the team you may join.
SECTION 06Interview Q&A — Cloud interview prep
Q1What is the difference between a public and a private subnet?
A public subnet has a route table entry sending 0.0.0.0/0 to an internet gateway, so resources with public IPs can be reached from the internet. A private subnet has no such route. Its resources can reach out through a NAT gateway placed in a public subnet, but cannot be reached directly from the internet.
Q2Explain the shared responsibility model with an example.
The provider secures the physical data centres, hardware and the virtualisation layer. The customer secures what they put on top. On EC2 that includes patching the operating system, configuring security groups and managing IAM. On a managed service such as RDS, the provider patches the database engine, but the customer still controls network access, users and encryption settings.
Q3How would you give an EC2 instance permission to read from S3?
Create an IAM role with a policy allowing s3:GetObject on the specific bucket and prefix, and attach it to the instance through an instance profile. The SDK on the instance picks up temporary credentials automatically. I would not put access keys on the instance.
Q4An application on EC2 suddenly returns 502 errors through the ALB. Where do you look?
Start with the target group health checks to see whether targets are unhealthy. Then check the application logs on the instance and whether the app is listening on the expected port. Also check whether the security group still allows traffic from the ALB's security group. A 502 usually means the load balancer got an invalid or no response from the target.
Q5How do you decide between EC2, containers and Lambda for a new service?
It depends on the workload. Lambda suits short, event-driven tasks with variable traffic and no server management. Containers suit long-running services that need consistent environments and more control. EC2 suits workloads needing full OS control or special software. I would ask about traffic pattern, run time and team skills before choosing.
SECTION 07Test yourself — Cloud interview prep quiz
Five questions. No sign-up.
0 / 5Pick an answer to see why it is right or wrong.
SECTION 08Frequently asked questions
What should I study before a cloud engineer interview?
Focus on networking basics such as CIDR, subnets, routing and DNS, then Linux commands, IAM, storage types and the shared responsibility model. Practise one troubleshooting scenario and one small design out loud. Review your own projects so you can explain every choice.
Are cloud engineer interviews hard for freshers?
They can feel hard if you only prepared service names. Most fresher interviews focus on fundamentals, one or two scenarios and your projects. Preparing those areas properly makes the interview far more manageable.
What are common cloud troubleshooting interview questions?
Typical ones are an instance that cannot reach the internet, a website returning 502 errors, an application that cannot read from S3 due to permissions, and a server whose disk is full. Answer by checking each layer in a clear order.
Do I need to know both AWS and Azure for interviews?
Usually one cloud in depth is enough for a fresher, plus an understanding that concepts carry across. If the company uses another cloud, show how your knowledge maps, such as VPC to virtual network and IAM roles to managed identities.
What questions should I ask at the end of a cloud interview?
Ask how changes reach production, whether infrastructure is managed as code, how new joiners get access, whether there is on-call and what success looks like in the first few months. These show genuine interest in the work.
How can I prepare for Cloud Engineer interview answers with a trainer?
Yes. Uncodemy's Cloud Computing Training Course in Noida (classroom and online) includes live projects, one-to-one mock interviews and resume reviews, so you practise Cloud Engineer interview answers with trainer feedback before the real interview. You can book a free demo class from this page to see how the sessions work.
SECTION 09Related reads
Classroom & online · Noida
Walk into your cloud interview prepared
Our Cloud Computing Training Course builds the networking, Linux and cloud design fundamentals interviewers test, with mock troubleshooting and design rounds before the real one.
Talk to a counsellor for current fees- Networking and Linux basics
- AWS and Azure hands-on labs
- Mock design and debug rounds
- Weekday & weekend batches