Cloud Engineer Top 100 Interview Questions

Commit to the capacity you are confident of using almost all the time, which is the steady baseline of your usage history, not the average or the peak. A commitment is paid whether or not you use it, so over-committing turns a discount into waste.

• break-even utilization = committed price / on-demand price

What it means: with a 40% discount you pay 60% of the on-demand price for every committed hour, used or not. A committed unit saves money only if it would otherwise have run more than 60% of the time.

How to size it:

1. Look at hourly usage over several months and find the level you never or rarely drop below.
2. Account for planned changes: migrations, right-sizing or architecture changes that could shrink usage during the term.
3. Prefer flexible commitments that apply across instance sizes, families or regions, which lowers the risk.
4. Commit in tranches, adding more every few months rather than all at once, so commitments track the business.
5. Monitor utilization and coverage of commitments monthly.

Leave variable and uncertain load on demand or spot capacity. The goal is not maximum coverage, but no wasted commitment.

Load the inventory, apply a small set of clear rules to each resource, and print every finding with its monthly cost, so the biggest savings are obvious and each finding can be sent to an owner.

Rules worth starting with:

• Missing mandatory tags: without an owner, nobody can be asked whether a resource is needed.
• Idle virtual machines: average CPU below a few percent over two weeks.
• Unattached volumes: disks left behind after servers were deleted.
• Unused public addresses: reserved addresses attached to nothing, which many providers charge for.

Key points:

• Report, then act: idle by CPU is a strong hint, not proof. A server can be idle on CPU and still serve a nightly job, so confirm with the owner first.
• Use the real cost of each resource, so the report is ranked by money rather than count.
• Keep the rules in data or simple functions, so adding a rule does not mean rewriting the script.
• Run it on a schedule and send findings to the owning team, using the owner tag where it exists.

Most cost tools offer these checks built in. A short script is still useful for custom rules and for inventories gathered from several accounts.

Set budgets per team or product, alert the owners directly with enough context to act, and tune alerts so they fire only for changes that matter. An alert sent to a shared inbox nobody reads is the same as no alert.

1. Budget by owner: one budget per account, product or team, built from tags and account structure.
2. Alert on forecasts, not only actuals: a forecast to exceed the budget at mid-month gives time to act; an actual overrun at month-end does not.
3. Use several thresholds, such as 50%, 80% and 100%, with only the higher ones going to people who must respond.
4. Turn on anomaly detection for daily spend per service and account, which catches sudden jumps that budgets miss, such as a runaway job on the third day of the month.
5. Set a minimum impact, so a 300% jump in a service costing 2 a day does not page anyone.
6. Route to the owning team's channel or ticket queue, with the account, service, top resources and the change since yesterday.
7. Define the expected response, such as acknowledging within a working day and explaining or fixing within a week.

Review alert outcomes monthly. Alerts that never lead to action should be retuned or removed.

Unit cost divides the cost of running a product by the business output it delivers, such as cost per order, per active customer or per gigabyte processed. It shows efficiency, while total spend mostly reflects growth.

• unit_cost = total cost of the product / units of business output

What each term means:

• Total cost of the product: its direct cloud costs from tags and accounts, plus a fair share of shared costs such as networking and security tools.
• Units of business output: a metric the business already tracks and cares about, such as orders completed or monthly active users.

Why it beats total spend:

• A rising bill can be good news if the business is growing faster than costs.
• It connects engineering work to business value: an optimization that cuts cost per order is easy to explain.
• It makes forecasts realistic: expected growth in orders times cost per order gives next year's budget.
• It allows fair comparisons between products of different sizes.

Choose the unit carefully and keep it stable. A metric that changes definition every quarter makes the trend meaningless.

Break the increase down until it points at specific resources, find the day it started, and match that to a change. Most jumps come from a small number of causes.

1. Slice the bill by service, account, region and usage type, and compare with last month. The increase usually concentrates in one or two lines.
2. Find the start date with daily cost data, then look for deployments, configuration changes or traffic events on that day.
3. Drill to resources using tags and resource-level cost data.
4. Check the usual suspects: data transfer and NAT processing, forgotten test environments, logging volume, autoscaling that never scales in, storage growth, expired commitment discounts, and unknown resources in unused regions, which may mean leaked credentials.
5. Fix it, confirm the daily cost returns to normal, and estimate the total impact.
6. Prevent a repeat with an anomaly alert or guardrail for that specific cause.

flowchart TD
  A["Bill up 40%"] --> B["Break down by service, account and usage type"]
  B --> C["Find the day the increase started"]
  C --> D["Match to deployments and changes"]
  D --> E{"Unknown resources or regions?"}
  E -->|yes| F["Treat as a possible security incident"]
  E -->|no| G["Fix the cause with the owning team"]
  G --> H["Add an alert or guardrail"]

Serverless charges per request and per unit of execution time, so it costs almost nothing at low traffic and grows linearly. An always-on server costs the same every hour, so it is expensive at low traffic but cheaper per request at high, steady traffic.

• serverless monthly cost = requests × price_per_request + requests × duration_s × memory_GB × price_per_GB_second
• break-even requests = server monthly cost / serverless cost per request

What each term means:

• duration_s and memory_GB: execution time and allocated memory, which together are billed in gigabyte-seconds.
• server monthly cost: the always-on instance, or the minimum fleet that gives the redundancy you need.

When to use it: to choose a compute model, and to know the traffic level at which to move a workload. Also count what the formula leaves out: servers need patching and scaling work, while serverless adds cold starts and execution limits.

Below break-even, serverless is cheaper and needs no capacity planning. Well above it, steady traffic usually belongs on servers or containers, possibly with committed pricing.

A queue hands each message to one consumer, which removes it when done. A topic in publish-subscribe pushes each message to every subscriber. An event stream keeps an ordered, retained log that many consumers read independently and can replay.

When to use which:

• Queue to spread work across a pool of workers, such as resizing uploaded images.
• Topic when one event must trigger several independent actions, such as "order placed" notifying email, billing and analytics. Often each subscriber gets its own queue for durability.
• Stream when consumers need history, replay or ordering, or when new consumers must read past events.

All three usually deliver at least once, so consumers must handle duplicates safely.

An API gateway is the managed front door for APIs: it receives client requests, applies common policies such as authentication and rate limits, and routes each request to the right backend service. Teams then do not have to reimplement those concerns in every service.

Typical responsibilities:

• Routing: map paths and methods to backend services, functions or other APIs.
• Authentication: validate tokens or API keys before requests reach backends.
• Rate limiting and quotas: per client, protecting backends from overload and abuse.
• Request validation: reject malformed requests early against a schema.
• TLS termination and custom domains.
• Transformation: small changes to headers or payloads, such as adding a request ID.
• Caching of safe, repeatable responses.
• Versioning and staged rollouts of API changes.
• Observability: access logs, metrics and tracing headers for every call.

What to keep out of it: business logic. A gateway full of complex transformations and conditions becomes a fragile, hard-to-test monolith that every team depends on.

The gateway is on every request path, so treat it as critical infrastructure: deploy it across zones, monitor its latency and errors, and manage its configuration as code.

Monitor what users experience and what the cloud platform can do to you: latency, errors and saturation of the service, plus quotas, throttling, managed-service health and cost. CPU and memory alone miss most real incidents.

Making monitoring useful:

• Alert on symptoms, such as error rate and latency against objectives, and use resource metrics for diagnosis rather than paging.
• Use synthetic checks from several regions to see outages before users report them.
• Watch provider status signals, such as health event notifications for your accounts, and correlate them with your own metrics.
• Tag metrics and alerts by owner and service, so they reach the right team.

The CAP theorem says that when a network partition splits a distributed database, it must choose between consistency, where every read sees the latest write, and availability, where every request gets an answer. Partitions cannot be ruled out in distributed systems, so the real choice is what happens during one.

How it shows up when choosing a database:

• Single-region relational databases with synchronous standbys favor consistency; during a failover, writes pause briefly.
• Globally distributed databases often offer a per-request choice between strong and eventual consistency, trading latency and availability for freshness.
• Multi-region active-active writes usually mean eventual consistency and a conflict-resolution rule, such as last write wins or merging.

Even without a partition, there is a constant trade-off between latency and consistency: strong consistency across regions means waiting for distant replicas. Choose per data type, not per system, since one application often needs both.

Copy the bulk of the data while the source keeps running, keep the copy continuously in sync with change data capture, and then cut over in a short, rehearsed window with a way back.

1. Assess: size, change rate, engine compatibility, dependencies and the acceptable downtime.
2. Prepare the target with the schema, users, parameters and network connectivity from the source.
3. Full load: copy existing data while the source stays live.
4. Continuous replication: stream ongoing changes from the source's transaction log until lag is near zero.
5. Validate: compare row counts and checksums, and run the application's test suite against the target.
6. Cut over: stop writes on the source, wait for replication to catch up, switch connection settings and start writes on the target.
7. Keep a rollback path: reverse replication from the target to the source for a period, or a tested plan to switch back.

flowchart LR
  A["Source database live"] --> B["Full load to target"]
  B --> C["Continuous change replication"]
  C --> D["Validate data"]
  D --> E["Stop writes and drain lag"]
  E --> F["Switch application to target"]
  F --> G["Reverse replication for rollback"]

Rehearse the cutover in staging with production-sized data. The rehearsal finds slow steps and surprises before they cost downtime.

Store the site's files in private object storage and serve them through a content delivery network with TLS, so users load pages from a nearby edge location and the storage is never exposed directly.

flowchart LR
  A["Users worldwide"] --> B["DNS with custom domain"]
  B --> C["Content delivery network with TLS"]
  C -->|cache miss| D["Private object storage origin"]
  E["Build pipeline"] -->|upload and invalidate| D

Key decisions:

• Private origin: only the content delivery network may read the bucket, through its own access identity or signed requests.
• Caching: file names with content hashes, such as app.3f9a1c.js, get long cache lifetimes, while HTML gets short ones so new releases appear quickly.
• Deployment: the pipeline uploads new assets first, then HTML, then invalidates cached HTML paths.
• TLS and headers: a managed certificate on the custom domain, plus security headers added at the edge.
• Edge logic: small edge functions handle redirects and clean URLs without any servers.
• Protection: a web firewall and rate limits at the edge if forms or APIs are involved.

This design has no servers to patch, scales automatically, and usually costs very little. Dynamic features go into separate APIs the page calls.

Multi-cloud can reduce dependence on one provider and give access to unique services, but it multiplies skills, tooling, security work and data transfer costs. It pays off when there is a specific, concrete reason, not as a general hedge.

When it makes sense:

• A clear need, such as a customer or regulator requiring a second provider, or a capability only one provider offers.
• Independent workloads placed on different providers, which is far simpler than one application spanning both.
• Portable layers, such as containers and infrastructure code, where they reduce real switching costs without blocking managed services.

Collect logs from every account into central, organization-level destinations: a locked archive for audit and security logs, and searchable platforms for security and operations, with consistent formats and clear access rules.

flowchart LR
  A["Workload accounts"] --> B["Organization-wide collection"]
  B --> C["Log archive account, write-once"]
  B --> D["Security analytics platform"]
  B --> E["Operations search platform"]
  C -->|long-term retention| F["Cold storage tiers"]

Design points:

1. Organization-wide audit logging that member accounts cannot disable, delivered to a dedicated archive account.
2. Write-once storage for audit logs, with access limited to a small security group.
3. Standard formats and fields: timestamps in one zone, request IDs, account, service and environment, so searches work across sources.
4. Separate destinations by purpose: the security team needs audit, network and identity logs, while operations teams need application and platform logs. Both can receive copies.
5. Control cost: filter debug noise at the source, sample high-volume logs where acceptable, and move old logs to cheap storage.
6. Retention by type, set by investigation needs and regulation.
7. Monitor the pipeline itself, alerting when an account or source stops sending.

Spread every tier across at least three zones, keep the web and application tiers stateless behind load balancers with autoscaling, and use a managed database with a synchronous standby, so the loss of any server or zone causes no outage.

flowchart TD
  A["Users"] --> B["DNS and content delivery with web firewall"]
  B --> C["Load balancer across 3 zones"]
  C --> D["Web and app servers, autoscaled, private subnets"]
  D --> E["Cache cluster"]
  D --> F["Managed database primary"]
  F -->|synchronous| G["Standby in another zone"]
  F -->|asynchronous| H["Read replica"]
  D --> I["Object storage for uploads"]

Key decisions:

• Edge: static content from a content delivery network; a web application firewall in front.
• Load balancing: health checks remove failed instances; TLS terminates at the load balancer.
• Compute: stateless instances in private subnets across zones, with capacity to survive losing one zone.
• State: sessions in the cache or signed tokens; files in object storage.
• Data: managed database with automatic failover to the standby, read replicas for heavy reads, and point-in-time backups copied to another account.
• Networking: one NAT gateway per zone and private endpoints for cloud services.
• Operations: infrastructure as code, rolling or blue-green deployments, dashboards and alerts on latency and errors.

Trade-offs: three zones and spare capacity raise cost, and a multi-region design would add further protection against a regional outage at much greater cost and complexity.

Let users upload directly to object storage, have each new file trigger an event onto a queue, and process files with scalable, idempotent workers that write results and notify the user, with failed files set aside for inspection.

flowchart LR
  A["Client"] -->|upload with signed URL| B["Upload bucket"]
  B -->|object created event| C["Queue"]
  C --> D["Workers or functions"]
  D --> E["Processed files bucket"]
  D --> F["Metadata database"]
  D --> G["Notify user"]
  C -->|after repeated failures| H["Dead-letter queue"]

1. Upload: the API issues a short-lived signed URL, so large files go straight to storage without passing through application servers.
2. Trigger: the storage service publishes an event per new object onto a queue, which buffers bursts.
3. Process: workers scan for malware, validate the file type, then transform it, such as creating thumbnails or extracting text.
4. Record: results go to a separate bucket, and status and metadata go to the database.
5. Handle failures: retries with backoff, then a dead-letter queue and an alert.

Design points:

• Idempotent workers: events can be delivered twice, so key outputs by the input file's identifier.
• Scale on queue depth, with limits that protect the database.
• Lifecycle rules to delete raw uploads after processing, and to expire abandoned uploads.

Move it first with minimal change, so the data center can be exited and the team learns the platform, then modernize step by step around a working system rather than in one big rewrite.

flowchart LR
  A["Assess and map dependencies"] --> B["Build landing zone"]
  B --> C["Rehost or replatform"]
  C --> D["Stabilize and optimize"]
  D --> E["Extract services one at a time"]
  E --> F["Retire monolith parts"]

1. Assess: map servers, dependencies, data flows, licensing and performance baselines.
2. Prepare: build the landing zone, network connectivity to the data center, and identity.
3. Move: rehost the application servers onto virtual machines, and replatform the database onto a managed service, which is often the biggest quick win.
4. Stabilize: monitoring, backups, autoscaling where possible and right-sizing based on real cloud metrics.
5. Modernize gradually: route specific functions to new services behind a facade, so new code replaces parts of the monolith over time while the old code keeps serving the rest.
6. Retire: remove each replaced part of the monolith and, finally, the data center contracts.

Each phase delivers value on its own and has a rollback plan. A big-bang rewrite delays all value until the end and carries the highest risk of failure.

Confirm the slowness with data from that country, break each page load into its stages to see which one is slow, then follow that stage to its cause: DNS, the network path, the content delivery edge or the origin.

1. Confirm and measure: use real-user monitoring or synthetic tests from that country, and compare with other regions.
2. Break down the timing: DNS lookup, connection, TLS handshake, time to first byte and download time.
3. Check edge routing: which edge location and which origin region serve those users. Misrouting to a distant region is common.
4. Check caching: a low cache hit ratio in that country sends every request back to the origin.
5. Check the network path: a specific internet provider or peering problem shows up as slowness on only some networks.
6. Check the origin: server time for requests from that country, such as region-specific data or personalization.

flowchart TD
  A["Slow loads reported in one country"] --> B["Confirm with real-user and synthetic data"]
  B --> C{"Which stage is slow?"}
  C -->|DNS or connect| D["Check DNS routing and network paths"]
  C -->|time to first byte| E["Check cache hit ratio and origin region"]
  C -->|download| F["Check asset sizes and edge location"]

Structure it as a short story: the situation, what you personally did and decided, the measurable result, and what you learned. Interviewers want to understand your judgment, not hear a list of services.

1. Situation: the business problem and its constraints, such as a data center contract ending, a cost target or reliability problems.
2. Your role: what you owned, distinct from what the team did.
3. Decisions: the options you considered and why you chose one, such as managed database versus self-managed, or which migration strategy.
4. Execution: the hardest problem you hit and how you solved it.
5. Results: numbers wherever possible, such as "monthly cost fell 35%", "deployment time went from two hours to ten minutes" or "no outages during cutover".
6. Reflection: what you would do differently and what you carried into later work.

What the interviewer is listening for:

• Trade-off thinking across cost, reliability, security and speed.
• Ownership and honesty, including mistakes and how you recovered.
• Whether you can explain technical choices to non-specialists.
• Awareness of operations after launch, not just the build.

Prepare two or three stories, such as a migration, an incident and a cost optimization, each about three minutes long.

Turn the disagreement into a shared comparison against agreed criteria, such as total cost, team effort, reliability, flexibility and lock-in, then decide, record the reasoning and set a point to revisit it.

1. Understand each position: what each person is optimizing for, such as control and lower fees, or speed and less operational work.
2. Agree on criteria and weights before comparing options, so the discussion is about the problem rather than preferences.
3. Estimate total cost of ownership: include engineering time to build, patch, scale, secure and run on call, not only the service fee.
4. Test the uncertain parts: a short proof of concept answers questions such as "can the managed service meet our latency" with data.
5. Decide and record it in an architecture decision record with the trade-offs accepted.
6. Set revisit triggers, such as a cost threshold or a missing feature, so the decision is not permanent by default.

What the interviewer is listening for:

• That you value data over opinion and can disagree respectfully.
• Awareness that self-managed systems carry hidden operational costs, and managed services carry limits and lock-in.
• That once a decision is made, you commit to it, even if it was not your preference.