Cloud Engineer interview questions and answers

A region is a separate geographic area with its own set of data centres, such as Mumbai (ap-south-1) or Hyderabad (ap-south-2) on AWS. Each region has several availability zones: one or more data centres with their own power, cooling and networking, close enough for low-latency links but far enough apart that one fire or power cut doesn't take down another.

For high availability you run at least two copies of every tier in different zones: servers in an Auto Scaling group spread over two or three zones behind a load balancer, and a database with a standby in another zone. If one zone fails, traffic goes to the others. Running in a second region protects against a whole-region outage, at a much higher cost.

Auto scaling adds servers when load rises and removes them when it falls, so you pay for what you need and survive spikes. An Auto Scaling group has a launch template (which image and instance type to start) and a minimum, desired and maximum number of instances.

Scaling policies change the desired count. Target tracking is the simplest: keep average CPU at, say, 50%, and the group adds or removes instances to hold it there. Step scaling reacts to CloudWatch alarm thresholds, scheduled scaling handles known peaks like office hours, and predictive scaling learns daily patterns. The group also replaces instances that fail health checks. Mention that the application must be stateless, with sessions kept in a shared store, so any instance can be removed safely.

Start with two numbers from the business. RTO, recovery time objective, is how long the application may be down. RPO, recovery point objective, is how much data, measured in time, you can afford to lose. Lower numbers cost more.

The common strategies, cheapest first: backup and restore, where you rebuild from backups in another region, with an RTO of hours; pilot light, where data is replicated continuously but servers are off until needed; warm standby, a smaller full copy running all the time and scaled up on failover; and multi-site active-active, both regions serving users, for near-zero RTO. Keep the infrastructure in code so it can be rebuilt quickly, and test failover regularly. A plan nobody has tested usually fails.

There are six: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. The framework is a set of questions for reviewing a workload against each pillar, and AWS offers a free Well-Architected Tool to record a review.

Then give one real example. For cost optimisation: "In my last project, a review showed our development servers ran all night and our production instances averaged 10% CPU. We scheduled dev to stop outside working hours, moved production to a smaller instance family after a week of load testing, and bought a Savings Plan for the steady baseline. The monthly bill fell by about a third with no effect on performance." Interviewers care more about the example than the list.

They differ in how much the provider manages for you. With IaaS, infrastructure as a service, you rent virtual machines, disks and networks, and manage the operating system and everything above it: Amazon EC2, Azure Virtual Machines. With PaaS, platform as a service, you deploy your code and the provider runs the servers, operating system and runtime: Azure App Service, Google App Engine, AWS Elastic Beanstalk. With SaaS, software as a service, you just use a finished application: Gmail, Microsoft 365, Salesforce.

Connect it to the shared responsibility model: the further you go from IaaS to SaaS, the less you patch and maintain, but the less control you have. Containers and serverless functions sit between IaaS and PaaS.

Block storage is a virtual disk attached to a server, like Amazon EBS or Azure Managed Disks. It is fast and low-latency, and suits an operating system disk or a database, but usually attaches to one server at a time. File storage is a shared file system that many servers mount over NFS or SMB, like Amazon EFS or Azure Files; use it when several servers need the same files. Object storage, like Amazon S3 or Azure Blob Storage, keeps files as objects in buckets, accessed over HTTP APIs. It is cheap, scales almost without limit and is very durable.

Use object storage for backups, logs, images and static websites, block for databases, file for shared content.

For most applications, managed. The provider handles patching, automated backups with point-in-time restore, standby replicas with automatic failover, read replicas and monitoring, which would otherwise take a lot of a team's time and are easy to get wrong.

You still own a lot: schema design, indexes and slow queries, users and permissions, network access, parameter settings and choosing the right size. Running it yourself on a VM makes sense when you need things the service doesn't allow, such as operating-system access, an unsupported extension or version, special licensing, or very fine tuning, and when you have people who can run it. Mention cost honestly: managed costs more per hour but usually less once you count the engineering time.

It depends on the application, so I'd ask how it is built and how traffic varies. For an API with bursts and quiet periods, serverless fits well: AWS Lambda or Azure Functions scale automatically, cost nothing when idle and need no servers, but Lambda runs at most 15 minutes per call and has cold starts. If it's already a container, a serverless container service like AWS Fargate or Google Cloud Run gives similar scaling without rewriting it.

VMs in an Auto Scaling group suit steady traffic, long-running processes or software that needs the full operating system, and can be cheapest at constant high load with reserved pricing. Interviewers want to hear you compare running cost, operations effort and limits, not name a favourite.

What makes a subnet public is its route table: it has a route for 0.0.0.0/0 to an internet gateway, and instances there need a public or Elastic IP to be reached from the internet. A private subnet has no route to the internet gateway, so nothing on the internet can start a connection to its servers. Put load balancers in public subnets and application servers and databases in private ones.

For outbound access, such as downloading updates, a private subnet's default route points to a NAT gateway placed in a public subnet. It lets traffic out and replies back in, but no new connections in. Mention that a NAT gateway lives in one zone, so use one per zone for resilience, and it charges per hour and per GB processed.

An Application Load Balancer works at layer 7, on HTTP and HTTPS. It reads the request, so it can route by path (/api to one target group, /images to another) or by host name, terminate TLS, and send traffic to instances, containers by IP, or Lambda functions. It's the usual choice for web applications and microservices.

A Network Load Balancer works at layer 4, on TCP, UDP and TLS. It doesn't look inside requests, handles very high traffic with low latency, can have a fixed Elastic IP per zone and keeps the client's source IP. Use it for non-HTTP protocols, when clients need fixed IPs to allow in their firewall, or for extreme throughput. Both do health checks and spread targets across zones.

Two main ones. A Site-to-Site VPN is an encrypted IPsec connection over the internet between the office firewall (the customer gateway) and a virtual private gateway or Transit Gateway on AWS. Each connection has two tunnels for redundancy, it can be set up in an hour, and it's cheap, but speed and latency depend on the internet. AWS Direct Connect is a dedicated private line from the office or data centre to AWS through a partner, with steady latency and higher bandwidth, but it takes weeks to arrange and isn't encrypted by default.

Many companies use Direct Connect with a VPN as backup. Whatever you choose, plan non-overlapping IP ranges first: if the office and VPC both use 10.0.0.0/16, routing between them breaks.

A provider is the plugin that talks to a platform's API, such as aws or azurerm, configured with a region or subscription. A resource is one piece of infrastructure the provider manages, written like resource "aws_instance" "web" with its arguments. Variables are inputs, so the same code can create different sizes or names, and outputs print values or pass them to other configurations, like a load balancer's DNS name. Data sources read things that already exist, such as the latest AMI.

To refer to another resource you use its address and attribute, for example vpc_security_group_ids = [aws_security_group.web.id]. That reference also tells Terraform the order: it creates the security group first.

Terraform works with many providers, so one tool and one language, HCL, covers AWS, Azure, Google Cloud and services like Cloudflare or GitHub. It keeps its own state file, and plan shows exactly what will change before anything happens. CloudFormation is AWS-only, but AWS stores the state for you in stacks and it needs no extra tool; teams fully on AWS often choose it. Ansible is mainly for configuring servers, installing packages and editing files, in ordered tasks; it can create cloud resources but doesn't track them in state the way Terraform does.

Many teams use Terraform to create the infrastructure and Ansible to configure what runs on it. You can also mention OpenTofu, an open-source fork of Terraform.

For the changed resource, terraform plan shows the difference and proposes setting it back to what the code says, because the code is the source of truth. If the manual change was right, update the code to match it so the plan comes back clean; if it was wrong, apply. terraform plan -refresh-only shows drift without proposing changes.

For the manual bucket, write a matching resource block and import it: terraform import aws_s3_bucket.logs my-logs-bucket, or an import block in the code, which plan can use to generate the configuration. To prevent this, give people read-only console access in production and run a scheduled terraform plan -detailed-exitcode, which exits with code 2 when there are changes, and alert on it.

A user is an identity for one person or application, with long-term credentials such as a password or access keys. A group is a set of users you attach permissions to, like Developers. A role has permissions but no long-term credentials; it is assumed for a while and gives temporary credentials, which is how EC2 instances, Lambda functions, other accounts and single sign-on users get access. A policy is the JSON document that states what is allowed or denied: Effect, Action, Resource and optional Conditions.

Least privilege means giving only the actions and resources a job needs, nothing more: s3:GetObject on one bucket, not s3:* on everything. Also mention locking away the root user with MFA and no access keys.

Use AWS CloudTrail, which records API calls in the account. In the console's Event history, which keeps 90 days of management events, filter by the event name DeleteBucket. The event shows who made the call (the user or the assumed role and its session name), the time, the source IP address and whether it came from the console, the CLI or an SDK. If it was an assumed role, look for the matching AssumeRole event to trace the person or system behind it.

For longer history, the account should have a trail delivering logs to a protected S3 bucket, queried with Athena or CloudTrail Lake. Mention that object-level actions, like deleting single files, are data events and are logged only if you turn them on.

Bring them into AWS Organizations, grouped into organisational units such as Production, Development and Security. Use service control policies to set guardrails that no one in an account can get around: for example, deny disabling CloudTrail, deny leaving the organisation, or allow only the Mumbai and Hyderabad regions. SCPs set the maximum permissions; they don't grant any, and they don't apply to the management account.

For people, use IAM Identity Center with the company directory, so each person signs in once and gets permission sets per account, instead of IAM users in every account. Send CloudTrail logs from all accounts to a separate logging account, and run GuardDuty and Security Hub from a security account. AWS Control Tower can set much of this up.

Each file has an owner, a group and permissions for three classes: the owner, the group and everyone else. Each class gets read (4), write (2) and execute (1), added together. So 640 means the owner can read and write (6), the group can only read (4), and others have no access (0). ls -l shows it as -rw-r-----. On a directory, execute means permission to enter it.

So only the owner and members of the file's group can read config.yml. Set those with chown appuser:appgroup config.yml. Mention adding a user to a group with usermod -aG appgroup alice, and that admin rights come through sudo, configured with visudo or the sudo or wheel group, never by sharing the root password.

Create a unit file, /etc/systemd/system/myapp.service. Under [Unit], a Description and After=network.target. Under [Service], ExecStart with the full path to the program, User=myapp so it doesn't run as root, Restart=on-failure and RestartSec=5. Under [Install], WantedBy=multi-user.target.

Then run sudo systemctl daemon-reload so systemd reads the new file, and sudo systemctl enable --now myapp to start it and enable it at boot. Check it with systemctl status myapp and read its logs with journalctl -u myapp -f. Interviewers often ask how you install the application's dependencies first: apt on Ubuntu or Debian, dnf on Red Hat and Amazon Linux.

Run top (press P to sort by CPU) or ps aux --sort=-%cpu | head to find the process ID and its command. Look at the load average and the wa value in top too: high load with high I/O wait means a disk problem, not CPU. Before stopping anything, capture evidence for the root cause: the application's logs and, for Java, a thread dump with jstack.

Then stop it gently: kill PID sends SIGTERM (15), which lets the program finish work and clean up. Only if it ignores that, kill -9 PID sends SIGKILL, which can't be caught and gives no clean-up. If it's a systemd service, use systemctl restart instead, so systemd keeps track of it. Then fix the cause, not just the symptom.

Connect a real interest with what you've done about it. Structure: what draws you, the proof, and what you want to do next. For example: "I like that in the cloud a whole system, from network to servers, can be built from code in minutes. While preparing for [certification or course], I built [project], a web app on [AWS or Azure] with a load balancer, auto scaling and a managed database, all in Terraform. I'd like to grow in designing and running systems like that for real customers."

Avoid saying you chose cloud only because it pays well or is in demand; interviewers want curiosity they can see.

Be honest about what you have and what it proves. A certification shows you know the services; interviewers want to hear that you also used them. For example: "I passed [certification] in [month]. Preparing taught me the main services and how to choose between them, but what helped most was the labs: I broke a VPC's routing on purpose and fixed it, and learned more from that than from the videos."

If you don't have one: "Not yet; I'm preparing for [certification] and have built [project] meanwhile." Never claim a certification you haven't passed, as they're easy to verify.

Pick a real, modest mistake and spend most of the answer on how you fixed it and what you changed. Use STAR: "In a test account I created a large GPU instance for an experiment and forgot it (situation). A week later the budget alert fired at three times the normal spend (task). I terminated it, checked for anything else left running, and told my lead straight away with the cost (action). Then I set up budget alerts per project and a tag rule so untagged test resources are stopped every night; it hasn't happened again (result)."

Interviewers value quick ownership and a lasting fix more than a perfect record.

Talk in business terms: money, speed and risk, not services. For example: "We'd stop buying servers up front and pay monthly for what we use, and new environments would take hours, not weeks. The risks are that costs grow if nobody watches them, and that staff need training. I'd suggest we move one application first, set a monthly budget with alerts, and compare cost and uptime after three months before moving more."

Give both sides honestly; a manager trusts someone who mentions the risks. Use one simple comparison instead of jargon, and end with a small, low-risk first step.

Many cloud support and operations roles in India serve clients abroad, so expect this. Answer honestly and show you understand why: "Yes, I understand cloud systems run around the clock and clients in [region] work during our night. I'm comfortable with a rotation, and I'd plan my routine around it. I'd also like to know how the handovers between shifts work, since good handover notes prevent most mistakes."

If you have a real constraint, state it politely and ask about options. Saying yes now and refusing shifts later hurts you more than being honest in the interview.