Cloud engineer interview questions, with worked answers

How to use these questions

Answer in the terms of the provider the ad names, then add a case of your own: what you built, for how many teams, what went wrong and what it cost. If you know another provider better, say so and map the idea across; interviewers value the idea more than the product name.

What a cloud engineer is expected to know

• Foundations: accounts or subscriptions, identity and roles, policies and the shared responsibility between provider and customer.
• Networks: address ranges, subnets, routing, firewalls, private endpoints, DNS and the link to the company's own sites.
• Code and change: infrastructure as codeAsked in 40% of cloud engineer ads (as of 5 Nov 2026).Write and review modules, keep state safe, plan before apply, and find drift between the code and the cloud., state, reviews and pipelines in CI/CDAsked in 66% of cloud engineer ads (as of 5 Nov 2026).Pipelines that test and roll out infrastructure changes the same way every time, with a review before apply..
• Reliability: availability zones and regions, backups, disaster recovery and monitoringAsked in 9% of cloud engineer ads (as of 5 Nov 2026).Collect metrics and alert on what users feel; often next to the providers' own monitoring tools..
• Workloads and money: virtual machines, containersAsked in 60% of cloud engineer ads (as of 5 Nov 2026).Run workloads on a managed cluster: deployments, scaling, networking, secrets and upgrades of the cluster., serverless functions, managed databases, and what each costs on AWSAsked in 52% of cloud engineer ads (as of 5 Nov 2026).Accounts and organisations, identity and roles, networks, compute, storage and managed databases, and the bill. depends on the provider, AzureAsked in 47% of cloud engineer ads (as of 5 Nov 2026).Subscriptions and management groups, Entra ID for identity, virtual networks, policies and the cost reports. depends on the provider or Google CloudAsked in 25% of cloud engineer ads (as of 5 Nov 2026).Projects and folders, identity and access, networks, compute and the managed services teams build on. depends on the provider.

Foundations: responsibility, landing zones, identity and networks

What does the shared responsibility model mean for your daily work?

What they check: that you know where the provider's duty ends and yours begins.

Short answer: "The shared responsibility model splits the work: the provider secures the buildings, hardware and the services it runs; we secure what we put on top, such as identities, network rules, data, the settings of each service and our own servers. The more managed the service, the less is ours, but access and data are always ours."

The full answer: Most cloud breaches come from the customer's side of the line: a storage bucket left public, a key in a repository, an account with far too many rights. So the daily work is guard rails that stop those mistakes, logging that shows who did what, and reviews of changes. For a virtual machine you patch the operating system yourself; for a managed database the provider patches it and you still decide who can connect.

A weak answer: "The provider handles security, that is why we moved." Follow-up: "Who patches a container image we built?" We do: the provider runs the platform, the image is ours.

A company is starting in the cloud. How would you set up the landing zone?

What they check: that you start with structure and guard rails, not with the first workload.

Short answer: "A landing zone is the prepared ground every team builds on: a structure of accounts or subscriptions by environment and team, central identity with single sign-on, central logging that teams cannot switch off, a network design with shared links, policies that block risky settings, and a budget and tags on every account. I build it as code, so a new team gets the same setup in an hour."

The full answer: Each provider has a starting kit for it, and many companies adapt one rather than start from nothing. Separate production from the rest, keep a break-glass account for emergencies, and decide early how teams ask for a new account. Write down the few rules that are not negotiable, such as no public storage and no keys for people, and let teams decide the rest.

A weak answer: "Everyone works in one shared account, we can split it later." Follow-up: "A team needs an exception to a policy." Explain how exceptions are asked for, approved, limited in time and recorded.

How do you manage identity and access, and keep least privilege in practice?

What they check: that identity is your first control, and that you can keep it tidy over time.

Short answer: "People sign in through the company's identity provider with multi-factor authentication and get roles, not personal keys. Workloads get their own identities with only the rights they need, least privilege, and no long-lived secrets. I review rights regularly and remove what was not used."

The full answer: Start from groups and roles mapped to jobs, grant admin rights only for a limited time and with a reason, and alert on use of the root or owner accounts. The providers can report which permissions a role never used; that is the easiest place to trim. Least privilege is never finished, so make the review a routine, not a project.

A weak answer: "The developers have admin so they are not blocked." Follow-up: "A developer's laptop is stolen." Explain what their access could reach and how you would cut it.

Design the network for an application that must reach the company's offices but not the internet.

What they check: subnets, routing and private connections, without a public path by accident.

Short answer: "I put the application in private subnets with no route to the internet, reach the provider's services through private endpoints, and connect the offices through a VPN or a dedicated line into a central hub network. Firewall rules allow only the ports needed, and DNS resolves the private names on both sides."

The full answer: Plan address ranges that do not overlap with the offices or with other networks you may connect later; fixing overlaps is painful. A hub-and-spoke design keeps shared links and inspection in one place. Updates for servers still need a way in, through a proxy or a private mirror. Log the network flows, so you can show an auditor nothing left by another path.

A weak answer: "I open the security group to everything and restrict it later." Follow-up: "Two networks need to talk but their address ranges overlap." Discuss translation or re-addressing, and why planning ranges early avoids it.

Infrastructure as code, pipelines and secrets

Why infrastructure as code, and how do you handle state and drift?

What they check: that you use code for repeatability and review, and know its weak points.

Short answer: "Infrastructure as code means the setup is written in files, reviewed like software and applied by a pipeline, so environments match and every change has a history. With TerraformAsked in 40% of cloud engineer ads (as of 5 Nov 2026).Write and review modules, keep state safe, plan before apply, and find drift between the code and the cloud. the state file records what exists, so I keep it in a locked, encrypted remote store. Drift, a change made outside the code, I find with a regular plan and either bring into the code or undo."

The full answer: The tools differ: Terraform and Pulumi work across providers, CloudFormation belongs to AWS and Bicep to Azure, and each provider has its own native option. The habits are the same: small modules with clear inputs, versions pinned, a plan read by a second person before apply, and no one with rights to change production by hand except in an emergency, which is then written back into the code.

A weak answer: "I fix things in the console and update the code when I have time." Follow-up: "Two pipelines changed the same state at once." Explain locking and why each state should have one owner.

How do you roll out an infrastructure change safely?

What they check: a release habit for infrastructure that limits the blast radius.

Short answer: "The change goes through a merge request with the plan attached, automatic checks for policy and security, a review, then development, test and production in that order. Risky changes go out in a quiet hour with a rollback written down, and I watch the dashboards afterwards."

The full answer: Read the plan for anything that will be destroyed and recreated, because a small change in code can replace a database. Split large changes, and protect important resources from deletion. Policy checks in the pipeline catch public access or missing encryption before a person has to. Write down who approves production changes and when changes are frozen, for example over a sales peak.

A weak answer: "If the plan runs, it is safe." Follow-up: "The plan shows the load balancer will be replaced." Explain why that matters and how you would avoid downtime.

How do you store and rotate secrets and keys, and keep data secure with encryption?

What they check: no secrets in code, and encryption you can explain.

Short answer: "Secrets live in the provider's secret store or a vault, read at run time by identities that need them, and rotated on a schedule or after anyone leaves. Wherever possible workloads use their own identity instead of a secret at all. Data is encrypted at rest and in transit, with keys in the key service and access to the keys logged."

The full answer: Scan repositories and images for secrets, because one leaked key can cost more than a year of the cloud bill. Decide who controls the keys: the provider's default keys or keys the company manages, which some regulated companies require. Plan what happens when a key is deleted, because encrypted data without its key is gone.

A weak answer: "The password is in an environment file in the repository, it is private." Follow-up: "A key was pushed to a public repository an hour ago." Revoke it first, then look for use in the logs, then fix the habit.

Availability, recovery, monitoring and incidents

How do you design for high availability across availability zones and regions?

What they check: that you match the design to what the business needs and pays for.

Short answer: "An availability zone is a separate data centre within one region, so I spread servers and managed services across at least two zones behind a load balancer; that covers most failures. A second region protects against a regional outage but costs more and is harder, so I use it only when the business needs it."

The full answer: Start from the agreed targets: how long the service may be down and how much data it may lose. Many managed services offer a zone-redundant option with a switch. Watch for the parts that are not spread, such as one NAT gateway or a single database instance. A second region needs data copied across, names that move, and a tested switch-over; without the test it is a hope.

A weak answer: "We are in the cloud, so it is always available." Follow-up: "The provider's region has an outage for four hours." Say what your design does and what it would cost to do more.

Plan backup and disaster recovery for a critical system.

What they check: recovery targets, copies outside the blast radius, and tested restores.

Short answer: "I agree two figures with the owners: the recovery point objective, how much data may be lost, and the recovery time objective, how long recovery may take. Then I set backups to match, keep copies in another account and region that ordinary admins cannot delete, and run a restore on a schedule to prove it works."

The full answer: Ransomware and a stolen admin account are the cases to design for, so immutable or locked backups matter. Disaster recovery also needs the infrastructure itself, which is where infrastructure as code pays: you can rebuild the environment from code and restore the data into it. Write the runbook, practise it once a year at least, and time it.

A weak answer: "The provider keeps three copies of everything." Follow-up: "Someone deleted the production account." Explain where your copies are and who could still reach them.

What do you monitor in the cloud, and what should wake someone at night?

What they check: alerts that point to user impact and real risk, not noise.

Short answer: "I watch what users feel, such as errors and response times, plus the platform signs that come before trouble: full disks, failing health checks, quota limits, expiring certificates, and the security signs such as a root login or a policy turned off. Only what needs action now pages someone; the rest goes to a daily review."

The full answer: Use the provider's monitoring and logging, often with PrometheusAsked in 9% of cloud engineer ads (as of 5 Nov 2026).Collect metrics and alert on what users feel; often next to the providers' own monitoring tools. and Grafana or another tool across providers, and keep logs central so one search covers every account. Each alert needs an owner and a runbook. Cost is a signal too: an alert on an unusual daily spend catches leaked keys and runaway jobs.

A weak answer: "We alert on CPU above eighty." Follow-up: "The on-call engineer got forty alerts last night and none mattered." Sort them by action needed and remove or tune the rest.

A production service is down after a change to the cloud setup. Walk us through the incident.

What they check: calm order: restore service, communicate, then find the cause without blame.

Short answer: "I confirm the impact, open an incident and say who leads. The fastest safe way back is usually to roll back the change through the pipeline. I keep a timeline and post updates. Once the service is back, we hold a blameless review and fix the gap that let the change through, such as a missing check or test."

The full answer: Look at what changed first: the pipeline history, the audit log of the provider, and the provider's own status page in case the fault is theirs. Do not make several changes at once while under pressure. The review asks why the change seemed safe, and the actions make the next one safer, not someone more careful.

A weak answer: "I fix it quickly in the console and tell nobody." Follow-up: "The rollback fails." Explain how you would restore from code or backups and who you would call in.

Cost, workloads, migration and more than one cloud

The cloud cost rose sharply this month. How do you find out why and bring it down?

What they check: that you can read the bill and treat cost as a design property.

Short answer: "I break the bill down by service, account and tag to find what grew, then ask the owner why. Common causes are forgotten test resources, oversized servers, data moving between regions or out to the internet, and logs kept forever. I fix the cause, set budgets and alerts, and make tagging mandatory so the next bill can be read."

The full answer: Cost work, often called FinOps, is shared with finance and the teams. Steady load can use commitments or reserved capacity for a lower rate; short jobs can use spare capacity that the provider may take back. Switch off development environments at night. Show each team its own spend every month, because people manage what they can see.

A weak answer: "The cloud is expensive, there is nothing we can do." Follow-up: "Finance wants a forecast for next year." Explain how you would build it from the current spend, growth and planned projects.

Virtual machines, containers or serverless: how do you choose for a new service?

What they check: a choice made from the workload and the team, not from fashion.

Short answer: "Serverless functions suit short, event-driven work that runs now and then: no servers to patch, cost only when they run, but limits on run time. Containers suit services that run all the time and need control, on a managed platform or KubernetesAsked in 60% of cloud engineer ads (as of 5 Nov 2026).Run workloads on a managed cluster: deployments, scaling, networking, secrets and upgrades of the cluster. if the company already runs one. Virtual machines are for software that needs a whole server."

The full answer: Ask who will run it at night. Kubernetes is powerful and needs people who know it; a managed container service may be enough. Serverless moves work to the provider and ties you closer to it. Containers built with DockerAsked in 33% of cloud engineer ads (as of 5 Nov 2026).Build small, safe container images and know what runs inside them before they reach production. carry over between providers more easily than functions. Write the decision down with its reasons, so it can be reviewed later.

A weak answer: "Kubernetes for everything, it is the standard." Follow-up: "The function runs for twenty minutes." Explain the time limits and what you would use instead.

How would you migrate an application from the company's data centre to the cloud?

What they check: a plan by stages with low risk, and honest choices about how much to change.

Short answer: "First I map what the application needs: servers, data, network links, licences and who uses it. Then we choose with the owners whether to move it as it is, adapt it to managed services, or rebuild it. Data moves with continuous copying, we test in the cloud, and the cut-over is short with a way back."

The full answer: Move simple applications first to learn, and leave the most tangled for later. Licences can decide the route, because some do not carry over. Check network latency to systems that stay behind. After the move, shut the old servers down on a date, or the company pays twice. Each provider has migration tools; the plan matters more than the tool.

A weak answer: "We copy all servers over in one weekend." Follow-up: "The application talks to a mainframe that stays." Discuss the network link, latency and what to test.

Should a company use more than one cloud? How do you answer the multi-cloud question?

What they check: a balanced view of cost, skills and risk, with no favourite provider.

Short answer: "Many companies use more than one provider because of history, a purchase or one service they need, and that is fine. Running the same system on two clouds at once is costly and rarely worth it. I keep the common parts common, such as identity, Terraform and logging, and let each workload use its provider well."

The full answer: AWS, Azure and Google Cloud all cover the common needs; the choice rests on existing contracts, the skills of the team, data rules and the services a product needs. Plan an exit for the most critical systems: know where the data is, how it would be moved and roughly what it would cost, which some regulators ask for. Keep the decision with the architects and finance, written down.

A weak answer: "Always two clouds, so we are never locked in." Follow-up: "The board asks what happens if our provider fails us." Show the exit plan and its cost.

As a senior cloud engineer or cloud architect, how would you set standards for many teams?

What they check: that you can lead without blocking, through a platform and clear rules.

Short answer: "I offer a paved road: modules, templates and pipelines that make the safe way the easy way, with a few rules enforced by policy and the rest as guidance. I write decisions down, review designs early with the teams, and measure adoption, incidents and cost, not the number of tickets closed."

The full answer: At principal cloud architect and head of cloud level the questions turn to people and money: the platform roadmap, contracts with providers, security and compliance evidence for audits, and how many engineers the platform needs. Expect a case such as "three teams built three different landing zones" and explain how you would bring them together without stopping their work.

A weak answer: "Teams must ask the cloud team for every resource." Follow-up: "A team says your module slows them down." Listen, measure, and change the module or the rule.

Your CV for these questions

Each cloud project on your CV invites the questions above: which provider, how many accounts, what it cost, what failed and what you changed. Put each story in one line under the job where it happened, so the interviewer asks for it:

Run the free check against a cloud job you want: every skill it finds missing is a question you can expect, so prepare those stories before the others.