Cloud Engineer Top 100 Interview Questions

Choose by how much control you need against how much platform work you want to own. Managed orchestration gives the most control over many services, serverless containers remove server management entirely, and plain virtual machines suit a few simple or legacy deployments.

Questions that decide it:

• How many services, and is there a team to own a platform?
• Does the workload need special hardware, long-running processes or fine-grained networking?
• Does traffic drop to zero often, making pay-per-use attractive?

Starting with serverless containers and moving to orchestration only when its flexibility is clearly needed avoids running a complex platform too early.

The instance metadata service is a local endpoint, reachable only from inside a virtual machine at a link-local address, that tells the machine about itself and hands out temporary credentials for its role. Any process, or any request an attacker tricks the server into making, can query it, so it is a prime target for server-side request forgery.

sequenceDiagram
  participant A as Application
  participant M as Metadata service
  participant X as Attacker via forged request
  A->>M: Request a session token with a special header
  M->>A: Short-lived session token
  A->>M: Ask for credentials with the token
  M->>A: Temporary role credentials
  X->>M: Plain request with no token
  M-->>X: Rejected

How to protect it:

1. Require session tokens: use the metadata version that needs a token obtained with a special request and header. Most forged requests cannot add that header.
2. Limit network hops, so containers on the host cannot reach the metadata service unless they need it.
3. Disable the service on machines that do not need it.
4. Give the role minimal permissions, so stolen credentials are worth little.
5. Detect misuse: alert when instance credentials are used from addresses outside your own networks.

Placement strategies control which physical hardware a group of virtual machines lands on. Cluster placement packs them close together for speed, spread placement puts each on separate hardware for resilience, and partition placement separates groups of machines from each other.

When to use which:

• Cluster for tightly coupled high-performance computing and distributed training, where node-to-node latency dominates.
• Spread for a handful of critical instances, such as a database primary and its replicas or cluster leader nodes.
• Partition for large distributed databases and storage systems that already replicate data across failure domains.

Placement works within a zone. Resilience against a full zone failure still needs instances in several zones.

Run batch work on capacity that exists only while jobs run, use the cheapest capacity the job can tolerate, and keep compute close to its data.

1. Use a job scheduler or managed batch service that queues jobs and scales the cluster from zero to the size needed and back.
2. Use spot capacity for fault-tolerant tasks, with checkpointing so interrupted work resumes.
3. Match instance types to each job: memory-heavy jobs on memory-optimized machines, and graphics processors only for jobs that use them.
4. Keep data local: run compute in the region where the data lives, and stage hot data on fast scratch storage near the nodes.
5. Package jobs as containers, so they start quickly and run the same everywhere.
6. For tightly coupled jobs, use cluster placement and low-latency networking, since slow node-to-node communication wastes every node's time.
7. Measure cost per job, and stop jobs that exceed expected runtime.

Most savings come from never paying for an idle cluster. A cluster left running overnight after the queue empties can cost more than the jobs themselves.

Patch in small, health-checked batches behind a load balancer, or better, replace servers with new ones built from a patched image, so capacity never drops below what users need.

flowchart TD
  A["Build and test patched image"] --> B["Replace a small canary batch"]
  B --> C{"Health checks and metrics good?"}
  C -->|no| D["Stop and roll back to previous image"]
  C -->|yes| E["Replace next batch"]
  E --> F{"Fleet complete?"}
  F -->|no| C
  F -->|yes| G["Retire old image"]

1. Prefer immutable replacement: bake patches into a new image, launch new servers, drain and terminate old ones.
2. Keep capacity: add new servers before removing old ones, or patch at most a small percentage at a time.
3. Drain connections from each server at the load balancer before it is replaced or rebooted.
4. Start with a canary batch and compare error rates and latency with the rest of the fleet.
5. Automate rollback: stop the rollout when health checks fail, and relaunch from the previous image.
6. Patch on a schedule with deadlines by severity, and track fleet compliance continuously.

For servers that cannot be replaced, such as some legacy systems, use in-place patching in maintenance windows, one redundant member at a time.

Block storage presents a raw disk to one server, file storage presents a shared file system to many servers over the network, and object storage keeps whole objects with metadata in a flat namespace reached through an HTTP API.

When to use which:

• Use block storage for databases and anything needing low-latency random reads and writes from one server.
• Use file storage when several servers must read and write the same files using normal file operations.
• Use object storage for large volumes of unstructured data, archives and anything shared over the web. It is usually the cheapest per gigabyte.

Objects are replaced whole rather than edited in place, so object storage is a poor fit for workloads that update small parts of large files.

Durability is the probability that stored data is not lost; availability is the probability that you can reach it at a given moment. Eleven nines, 99.999999999%, of annual durability means each object has about a one in 100 billion chance of being lost in a year.

• expected objects lost per year = number_of_objects × (1 − durability)
• maximum yearly downtime = (1 − availability) × 8,760 hours

What each term means:

• Durability comes from storing redundant copies or erasure-coded fragments across several devices and facilities, and repairing lost copies automatically.
• Availability covers temporary unreachability, such as a service disruption, during which the data still exists.

When it matters: high durability does not protect you from yourself. Deleting an object, overwriting it with bad data, or ransomware using valid credentials all succeed perfectly durably. Versioning, object locking and copies in a separate account handle those risks.

Storage classes can share the same durability but offer lower availability at a lower price. That is a sensible trade for data that is rarely read.

Storage classes trade price per gigabyte against access cost and speed. Lifecycle rules move objects to cheaper classes automatically as they age, and delete them when they are no longer needed.

How to apply lifecycle rules well:

1. Learn the access pattern from access logs or storage analytics before choosing transition ages.
2. Respect minimum storage durations: cold classes often charge for a minimum number of days, so moving short-lived data there costs more.
3. Account for retrieval fees: archived data that turns out to be read often can cost more than keeping it hot.
4. Expire what you do not need, including old object versions and incomplete multipart uploads, which are easy to forget.
5. Consider automatic tiering classes when the access pattern is unknown or changes.

Versioning keeps every previous version of an object, so an overwrite or delete can be undone. Object locking makes versions impossible to delete or change until a retention date passes, even for someone with administrator credentials.

How versioning behaves:

• An overwrite creates a new current version and keeps the old one.
• A delete adds a delete marker, so the object looks gone but older versions remain recoverable.
• Old versions cost storage, so add lifecycle rules that expire non-current versions after a set period.

How object locking behaves:

• Each locked version has a retain-until date.
• A governance-style mode lets specially authorized users remove the lock in emergencies.
• A compliance-style mode cannot be shortened or removed by anyone until the date passes, including the account's root user.
• A legal hold blocks deletion indefinitely until it is removed.

Why it matters for ransomware: attackers with stolen credentials try to delete or encrypt backups. Versioning alone does not stop someone who can delete versions; compliance-mode locking does.

Combine locking with replication to a separate account that production credentials cannot reach. A mistaken compliance lock cannot be undone either, so test retention settings on non-critical data first.

A snapshot is a point-in-time copy of a volume or database, usually stored incrementally by the same service. A backup is a managed, independent copy with its own retention, catalog and restore process, ideally stored away from the original account and region.

When to use which:

• Snapshots for quick rollback before a risky change, and as the building block that backup tools automate.
• Backups for real recovery: scheduled, retained, copied off-site and locked.
• For databases, take application-consistent copies, using the database's own backup feature or by flushing writes first, so a restore does not need lengthy repair.

A snapshot in the same account as the data it protects is not a disaster recovery plan. Copy it somewhere an attacker or a bad script cannot reach.

Choose a relational database when data has relationships, needs flexible queries and must stay consistent across tables. Choose a NoSQL store when access patterns are simple and known in advance, and scale or latency matters more than query flexibility.

NoSQL families:

• Key-value: sessions, carts, feature flags.
• Document: product catalogs and user profiles with nested data.
• Wide-column: time series and very high write volumes.
• Graph: relationships such as recommendations and fraud rings.

When to use which: start relational unless there is a clear reason not to, since most business data is relational and requirements change. Pick NoSQL for a specific, well-understood access pattern at a scale where relational partitioning would be painful.

A read replica serves read traffic to scale reads, and is usually updated asynchronously. A standby replica sits in another zone purely for high availability, is updated synchronously, and takes over automatically if the primary fails.

When to use which:

• Use a standby for every production database where downtime matters. It is the baseline for availability.
• Add read replicas when reads overload the primary, and accept that replicas may return slightly stale data.
• Use a cross-region read replica as a disaster recovery copy that can be promoted if the whole region fails.

Applications must tolerate replica lag. Reading your own write from a lagging replica, such as showing an order list right after checkout, needs to go to the primary.

Point-in-time recovery combines regular full snapshots with a continuous archive of the database's transaction log. To recover, the service restores the most recent snapshot before the chosen moment, then replays the logged changes up to that moment.

flowchart LR
  A["Daily snapshots"] --> C["Restore latest snapshot before target time"]
  B["Continuous transaction log archive"] --> D["Replay changes up to target time"]
  C --> D
  D --> E["New database instance"]
  E --> F["Validate data"]
  F --> G["Copy back data or switch application"]

1. Choose the target time, just before the mistake or corruption.
2. The service creates a new instance; it does not overwrite the original.
3. Validate that the restored data looks right at that point.
4. Recover: either copy the affected rows back into production, or point the application to the restored instance.

Points to know:

• The recovery point can be within minutes of the target, depending on how often logs are archived.
• Restore time grows with database size and the amount of log to replay, so measure it against your recovery time objective.
• The recovery window is limited by the retention period you configure.

Add a cache when the same data is read far more often than it changes, when database queries are expensive, and when slightly stale data is acceptable. The most common pattern is cache-aside: the application checks the cache first and fills it from the database on a miss.

sequenceDiagram
  participant A as Application
  participant C as Cache
  participant D as Database
  A->>C: Get product 42
  C-->>A: Miss
  A->>D: Query product 42
  D-->>A: Row
  A->>C: Store with time to live
  A->>D: Update product 42
  A->>C: Delete product 42 key

Keeping it consistent:

• Time to live on every entry, so stale data expires even if an invalidation is missed.
• Delete the key after a database write, rather than updating it, to avoid racing writes leaving old data behind.
• Write-through caching updates the cache in the same path as the database, at the cost of slower writes.
• Versioned keys let a deploy change data shapes without reading old cached formats.

Pitfalls:

• Stampedes: a popular key expires and thousands of requests hit the database at once. Use request coalescing or slightly randomized expiry times.
• Cache as a hidden dependency: if the cache fails, can the database handle the full load?

Most cloud storage is encrypted at rest by default with keys the provider manages. With customer-managed keys, you create and control the key in the provider's key management service, and the storage service uses it through envelope encryption, asking your key to wrap and unwrap the data keys.

What customer-managed keys give you:

• Access control on the key itself: even a user with storage permissions cannot read data unless the key policy allows them to use the key.
• Separation of duties: key administrators cannot read data, and data users cannot change the key.
• An audit trail of every use of the key.
• Crypto-shredding: disabling or deleting the key makes all data under it unreadable.

Risks: a disabled or deleted key is an outage, and possibly permanent data loss. Protect keys with deletion waiting periods and alerts, and include key access in disaster recovery tests.

Data transfer is billed per gigabyte on paths that architecture diagrams rarely label, such as between zones, between regions and out to the internet. It grows with traffic, so a design that was cheap at launch can become expensive at scale.

How to reduce it:

1. Make it visible: break the bill down by usage type, and use flow logs to find the biggest talkers.
2. Avoid NAT for cloud services: reach storage and other managed services through private endpoints.
3. Cache at the edge: a content delivery network cuts internet egress from the origin.
4. Compress responses and replication streams.
5. Keep chatty services together, in the same zone where resilience allows.
6. Question cross-region replication of data that does not need it.

Start from how the data is accessed, which is by key, by query, as files or as a disk, then narrow by latency, sharing, durability and cost. Most real workloads combine several storage types.

flowchart TD
  A["New data to store"] --> B{"Queried by fields and relationships?"}
  B -->|yes| C["Relational or NoSQL database"]
  B -->|no| D{"Whole files over the web, large or many?"}
  D -->|yes| E["Object storage"]
  D -->|no| F{"Shared by many servers as a file system?"}
  F -->|yes| G["Managed file storage"]
  F -->|no| H["Block volume or fast local disk"]

Criteria to check:

1. Access pattern: reads and writes per second, read-to-write ratio, and random or sequential access.
2. Latency: milliseconds for user requests, or hours for archive retrieval.
3. Sharing: one server, many servers or the whole internet.
4. Durability and recovery: can the data be rebuilt, or is it the only copy?
5. Size and growth, which affect both cost and scaling limits.
6. Retention and compliance: how long it must be kept, and whether it must be locked.

Choose managed services by default. Running your own storage cluster on virtual machines adds operational work that is rarely worth it.

Plan address ranges centrally and early: give each network a private range that never overlaps with on-premises networks, other cloud networks or partners, and size it for years of growth.

1. Use private ranges such as 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16.
2. Avoid overlaps with every network you might ever connect to, because overlapping ranges cannot be routed between.
3. Allocate generously: often a /16 per environment per region, since re-addressing a live network is painful.
4. Split into subnets per zone and tier, such as public, application and data, so routing and security rules follow the design.
5. Remember reserved addresses: providers keep a few addresses in each subnet, and container platforms can use many addresses per node.
6. Keep spare blocks for new tiers, zones or services.
7. Track allocations in an IP address management tool, not a spreadsheet that drifts.

A useful formula: a prefix of length p holds 2^(32 − p) IPv4 addresses. Each step down in prefix length doubles the size.

Parse the range with a real IP address library, generate subnets of the requested size, check there are enough for every zone and tier, and assign them in a predictable order so the plan is reproducible.

Key points:

• Validate the input range strictly: a range with host bits set, such as 10.40.1.0/16, usually means a typo and should be rejected.
• Fail clearly when the range is too small, naming what was available and what was needed, rather than handing out partial plans.
• Assign deterministically, such as tier by tier and zone by zone, so running the plan again gives the same answer.
• Report usable addresses, subtracting what the provider reserves per subnet.
• Return the spare blocks, so future growth is planned rather than improvised.

In practice, tiers rarely need equal sizes: public subnets holding only load balancers can be much smaller than application subnets. The same approach works by splitting the range into differently sized blocks, largest first.

A server in a private subnet has only a private address, so it reaches the internet through a NAT gateway in a public subnet. The NAT gateway replaces the server's private source address with its own public address, and the public subnet routes to the internet through an internet gateway.

flowchart LR
  A["Server in private subnet"] -->|default route| B["NAT gateway in public subnet"]
  B -->|default route| C["Internet gateway"]
  C --> D["Internet"]
  D -->|replies| C
  C --> B
  B -->|translated back| A

1. The private subnet's route table sends 0.0.0.0/0 to the NAT gateway.
2. The NAT gateway translates the source address and tracks the connection.
3. The public subnet's route table sends 0.0.0.0/0 to the internet gateway.
4. Replies come back to the NAT gateway, which forwards them to the original server.

Design points:

• NAT allows outbound-only connections; nothing on the internet can start a connection to the private server.
• Put one NAT gateway per zone and route each zone to its own, so a zone failure does not cut every zone off and cross-zone charges are avoided.
• NAT gateways charge per gigabyte processed, so reach cloud services through private endpoints instead.
• For IPv6, an egress-only gateway plays the same outbound-only role, since IPv6 addresses need no translation.