Cloud Engineer Top 100 Interview Questions

Cloud computing delivers computing resources as a metered service over the network, which you provision yourself in minutes and release when you no longer need them. Five characteristics separate it from simply renting servers in a data center.

Why these matter to an engineer:

• Self-service and elasticity make automation the normal way to work, because infrastructure is just API calls.
• Measured service turns architecture decisions into cost decisions: an idle resource keeps costing money.
• Resource pooling is why the provider and the customer share responsibility for security.

These characteristics apply whether the service is raw infrastructure, a managed platform or finished software. The service models differ in how much of the stack you manage.

The models differ in who owns the infrastructure and how many environments a workload spans. Public cloud is shared provider infrastructure, private cloud is dedicated to one organization, hybrid connects private and public environments, and multi-cloud uses more than one public provider.

When to use which:

• Public for most new workloads, especially variable or fast-growing ones.
• Private for steady, predictable loads with strict control needs, when the organization can run the platform well.
• Hybrid during migrations, or when some systems must stay on premises.
• Multi-cloud when there is a concrete reason, such as a regulatory requirement or a unique service, not as a default.

On premises, you buy hardware up front as a capital expense and own its capacity for years, whether you use it or not. In the cloud, you pay for usage as an operating expense, so cost follows demand, but every idle resource is billed continuously.

What it means in practice:

• The cloud saves most for variable workloads; steady loads save through commitment discounts rather than elasticity.
• Spending decisions move from a yearly procurement cycle to every engineer who launches a resource, so cost governance becomes an engineering task.
• Total cost comparisons must include power, space, staff, hardware refreshes and the cost of slow provisioning, not only the server price.

Scalability is the ability to handle more load by adding resources. Elasticity is doing that automatically in both directions as demand changes. High availability is staying up when components fail.

A system can have any one of these without the others, so each needs its own design decisions.

How they relate:

• A system that scales only vertically, with a bigger single server, is scalable up to a limit but not highly available.
• Elasticity needs a scalable design first: stateless servers, shared data stores and fast startup.
• High availability needs redundancy across failure domains, which elastic scaling across zones also provides.

Interview tip: give one example where a system is scalable but not highly available; it shows you see these as separate design goals.

Cloud architecture reviews commonly use six pillars, each a lens with its own questions. Applying all six exposes trade-offs that a review focused only on features would miss.

How to use them:

• Run a review at design time and again after major changes, recording risks per pillar with owners.
• Expect trade-offs: a second region improves reliability but raises cost and complexity, so decide deliberately.
• Prioritize by impact: fix high-risk reliability and security gaps before cost optimization.

The pillars are a checklist for thinking, not a scoring contest. A design can be right with deliberate weaknesses in one pillar, as long as they are understood and accepted.

Migration strategies range from moving an application unchanged to rebuilding it, and each application in a portfolio gets the strategy that fits its value, age and urgency. They are often called the "seven Rs".

How to choose:

1. Inventory every application with its owner, dependencies, usage and business value.
2. Retire what nobody uses; portfolios often contain a surprising share of it.
3. Rehost or replatform most of the rest to meet deadlines, and refactor only where the business case is clear.
4. Migrate in waves grouped by dependencies, so tightly coupled systems move together.

Rehosting first and modernizing later is common. Without a plan for the second step, though, it can simply move today's inefficiencies into a more expensive bill.

Choose the region by first applying hard constraints, such as where data may legally live, then optimizing for user latency, service availability and cost.

1. Data residency and regulation: some data must stay in a country or economic area. This narrows the choice before anything else.
2. Latency to users: pick the region closest to most users, measured with real latency tests rather than map distance.
3. Service availability: newer services and instance types often reach only some regions first. Confirm that every service you need exists there.
4. Price: the same resource can cost noticeably more in one region than another, as can data transfer out of it.
5. Disaster recovery pairing: if you need a second region, choose one far enough away to avoid shared disasters but close enough for acceptable replication lag.
6. Quotas and capacity: check limits and the availability of specialized hardware such as accelerators.
7. Sustainability: regions differ in the carbon intensity of their power supply.

Record the decision and its reasons. Region choice is expensive to reverse once data, networking and integrations are in place.

A landing zone is a prepared, multi-account cloud environment with security, networking, identity and governance already in place, so teams can deploy workloads into a secure, consistent foundation instead of building one each time.

What a landing zone sets up:

• Account structure: separate accounts for security tooling, log archives, shared networking and each workload environment, grouped under organizational units.
• Identity: single sign-on federated from the corporate identity provider, with role-based access and no long-lived user keys.
• Guardrails: organization-level policies, such as allowed regions, mandatory encryption and a ban on disabling audit logs.
• Central logging: audit and network logs from every account flowing into a locked-down archive account.
• Networking: a hub for shared connectivity to on-premises networks and the internet, with IP ranges allocated centrally.
• Security baseline: threat detection, configuration scanning and alerts switched on in every account by default.
• Cost controls: required tags, budgets and alerts per account.
• Account vending: an automated way for teams to request a new account that arrives with all of the above.

Build the landing zone as code, so every account is created identically and changes to the baseline roll out everywhere at once.

An account is the strongest boundary a cloud provider offers, separating permissions, quotas, billing and blast radius. Splitting workloads across accounts limits how far a mistake or a breach can spread.

flowchart TD
  A["Organization root"] --> B["Security unit"]
  A --> C["Infrastructure unit"]
  A --> D["Workloads unit"]
  A --> E["Sandbox unit"]
  B --> F["Log archive and security tooling accounts"]
  C --> G["Shared network account"]
  D --> H["Production accounts"]
  D --> I["Non-production accounts"]

Reasons to split:

• Blast radius: a compromised credential or a bad script in a test account cannot touch production.
• Security boundaries: permissions do not cross accounts unless explicitly granted, and guardrails can differ per group.
• Quota isolation: one team's load test cannot use up limits that production needs.
• Cost clarity: each account's bill maps directly to a team or product.
• Compliance scope: regulated workloads sit in accounts with stricter controls, keeping audits small.

Costs of splitting: cross-account networking, identity and logging need central design, which is exactly what a landing zone provides. Without that automation, many accounts become hard to govern.

Define a small set of mandatory tags that answer who owns a resource, what it is for and what it costs, then enforce them automatically at creation time, since tags added later are always incomplete.

Enforcement:

1. Block untagged resources with organization policies that reject creation when mandatory tags are missing.
2. Tag through infrastructure code: shared modules apply standard tags by default, so engineers rarely type them.
3. Validate values against allowed lists, so "prod", "Prod" and "production" do not split reports three ways.
4. Report and remediate: a weekly report of untagged spend per account, assigned to the account owner.
5. Use tags in automation: schedules that stop non-production resources at night, and alerts routed by owner, give teams a reason to tag correctly.

Keep the mandatory list short. Every extra required tag lowers compliance with all of them.

A cloud-native application is designed to use the cloud's strengths, which are elasticity, managed services and automation, and to expect failure as normal. It is about design choices, not about running in the cloud.

• Stateless services: instances keep no session data locally, so any instance can serve any request and can be replaced at any time.
• Managed services: databases, queues and storage are consumed as services rather than run on servers you maintain.
• Designed for failure: timeouts, retries with backoff, circuit breakers and redundancy across zones are built in.
• Elastic scaling: capacity follows load automatically, which needs fast startup and graceful shutdown.
• Automation everywhere: infrastructure as code, automated pipelines and repeatable environments.
• Configuration from the environment: the same build runs in every environment with settings injected at deploy time.
• Built-in observability: metrics, structured logs and traces from day one.
• Small, independently deployable units, such as containers or functions, where the team size and domain justify them.

A monolith can be cloud-native if it follows these principles. A microservice system running on hand-built servers is not.

Service quotas are limits a cloud provider sets per account and region on how much of a resource you can use, such as virtual CPUs, IP addresses or API calls per second. They protect the provider and you from runaway usage, but hitting one unexpectedly fails requests just like an outage.

How quotas cause incidents:

• Scaling hits a ceiling: autoscaling tries to add servers during a traffic spike and fails because the account reached its CPU quota.
• Address exhaustion: a subnet runs out of IP addresses, so new instances or containers cannot start.
• API throttling: deployment tools or monitoring agents exceed request rate limits and fail partway through.
• Disaster recovery surprises: the recovery region has default quotas far lower than the primary region.

How to prevent them:

1. Monitor usage against quotas and alert at about 80%.
2. Include quotas in capacity planning, and request increases well before launches and seasonal peaks.
3. Test failover at full scale in the recovery region, which reveals quota gaps.
4. Use backoff and retries for API calls, so throttling slows work instead of breaking it.

Match the instance family to the resource the workload uses most, size it from measured data rather than guesses, and benchmark before committing.

How to choose:

1. Profile the workload: CPU, memory, disk and network use, at average and peak.
2. Start general purpose if the profile is unknown, then move to a specialized family once measurements show a clear bottleneck.
3. Consider processor options: newer generations and alternative processor architectures often give better price-performance, if the software supports them.
4. Benchmark the real application on two or three candidates.
5. Revisit after a few weeks in production and right-size.

Burstable instances are cheap until they run out of credits. A busy service on them slows sharply under sustained load, which looks like a mysterious performance bug.

On-demand pricing charges full price with no commitment. Committed-use pricing gives a large discount in exchange for promising to use or pay for capacity for one to three years. Spot pricing sells spare capacity at the deepest discount, but the provider can reclaim it at short notice.

How to combine them:

• Cover the always-on baseline with commitments, sized to the minimum you are confident of using.
• Run variable load on demand, so you pay only while it exists.
• Move interruptible work to spot capacity, with fallbacks to on-demand.

Discount levels vary by provider, region and term, so check current pricing. Commitments that apply flexibly across instance families and regions carry less risk than those tied to one specific instance type.

Design every spot workload to expect interruption: make it stateless or checkpointed, spread it across many capacity pools, react to the interruption notice, and keep an on-demand fallback for work that must finish.

1. Choose suitable work: batch jobs, rendering, CI runners, stateless web workers and anything that can be retried.
2. Diversify: allow several instance types and all zones, so a shortage in one pool does not remove all capacity at once.
3. Handle the notice: providers warn shortly before reclaiming, often about two minutes ahead depending on the provider. Stop taking new work, finish or checkpoint the current task, and deregister from the load balancer.
4. Checkpoint long jobs to durable storage, so a restarted task resumes instead of starting over.
5. Mix capacity: keep a baseline on on-demand or committed capacity, and add spot capacity on top.
6. Fall back automatically to on-demand capacity when spot capacity is unavailable.

Never run a stateful primary database or a single irreplaceable server on spot capacity. Losing it is a guaranteed outage, just at an unpredictable time.

They differ in what triggers a change in capacity. Target tracking keeps a metric near a set value, step scaling adds or removes fixed amounts when thresholds are crossed, scheduled scaling changes capacity at set times, and predictive scaling forecasts demand from history.

Practical guidance:

• Prefer a metric close to user load, such as requests per instance or queue depth per worker, over raw CPU.
• Set warm-up time so new instances are not counted before they serve traffic, which prevents over-scaling.
• Scale out fast and scale in slowly, so short dips do not remove capacity needed seconds later.
• Combine policies: scheduled or predictive scaling sets a sensible floor, and target tracking handles the rest.

A golden image is a pre-built machine image that already contains the operating system, patches, agents and often the application. Configuring at boot starts from a base image and installs and configures everything when the server launches.

When to use which:

• Use golden images for autoscaled fleets, where fast and reliable startup matters most during a traffic spike.
• Use boot-time configuration for rarely launched servers or early-stage projects.
• A common hybrid bakes everything slow or risky into the image, and injects only environment-specific settings and secrets at boot.

Treat images like code: build them in a pipeline, scan them, version them, and retire old versions so nothing launches with stale patches.

Measure what the machine actually uses over a representative period, pick the smallest size that covers its peaks with headroom, then change it carefully and keep watching.

1. Collect at least two to four weeks of data, covering month-end or other cycles: CPU, memory, disk and network.
2. Install a memory agent if needed, since many platforms do not report guest memory by default, and memory is often the true constraint.
3. Use percentiles, not averages: size for the 95th or 99th percentile, and check the maximum for rare spikes.
4. Keep headroom: aim for peak use of about 60% to 70% of the new size, leaving room for growth and failover load.
5. Consider newer generations, which often give more performance per unit of cost at the same size.
6. Change through your normal deployment process, ideally one environment or one instance at a time, and watch latency and errors.

Right-sizing is not a one-off project. Schedule a monthly review of the biggest underused resources, since workloads drift as code and traffic change.

A cold start is the extra delay when a serverless platform has to create a new execution environment for a function: it allocates resources, loads the runtime and your code, and runs initialization before handling the request. Later requests that reuse that environment are "warm" and much faster.

What makes cold starts slower:

• Large deployment packages and many dependencies.
• Heavy runtimes and frameworks with slow startup.
• Expensive initialization, such as loading big models or opening many connections.
• On some platforms, attaching the function to a private network adds delay.

How to reduce them:

1. Trim the package: remove unused dependencies, and load rarely used ones lazily.
2. Initialize once: create clients and connections outside the handler so warm invocations reuse them.
3. Choose a lighter runtime for latency-sensitive functions.
4. Allocate more memory where the platform scales CPU with memory, since initialization then runs faster.
5. Use pre-warmed or provisioned capacity for steady, latency-critical traffic, accepting that you pay for it while idle.

Measure first: cold starts often affect only a small share of requests. They matter for user-facing, latency-sensitive paths, much less for background processing.

Each concurrent request to a function runs in its own execution environment, so the number of environments running at once is set by the request rate and how long each request takes.

• concurrency = requests_per_second × average_duration_seconds

What each term means:

• requests_per_second: the arrival rate of invocations.
• average_duration_seconds: how long each invocation runs, including time spent waiting on the database.

Why it threatens databases: functions scale out in seconds, and each environment usually opens its own database connection. A traffic spike, or a slowdown that makes each call take longer, can multiply concurrency and exhaust the database's connection limit, which makes everything slower still.

How to protect the database:

1. Cap the function's maximum concurrency below what the database can serve.
2. Use a connection pooling proxy between functions and the database.
3. Put a queue in front of non-urgent writes so they are processed at a steady rate.
4. Set short timeouts and back off on retries, so a slow database does not trigger a retry storm.

Watch duration as closely as traffic. A database slowdown raises concurrency even when traffic stays flat.