Cloud Engineer Top 100 Interview Questions

Security groups are stateful firewalls attached to individual instances or network interfaces. Network access control lists are stateless filters attached to whole subnets. Most designs rely mainly on security groups and use access lists for broad, subnet-wide rules.

When to use which:

• Use security groups for nearly everything, and reference other groups rather than addresses. "App servers accept traffic from the load balancer group" stays correct as instances change.
• Use access lists to enforce coarse boundaries, such as stopping a data subnet from ever talking to the internet, or to deny a specific address range quickly.

Because access lists are stateless, outbound rules must allow return traffic on ephemeral ports, typically 1024 to 65535. Forgetting this is a classic cause of mysterious timeouts. Default behaviors differ between providers, so check them for yours.

Peering connects two networks directly, and it is not transitive: if A peers with B and B with C, A still cannot reach C. A hub-and-spoke design connects every network to a central transit hub that routes between them, which scales far better as the number of networks grows.

When to use which:

• Use peering for a few networks that need high-volume, low-latency links between them.
• Use hub-and-spoke once there are more than a handful of networks, when traffic must pass central inspection, or when many networks share hybrid connectivity.

A full mesh of n networks needs n × (n − 1) / 2 peerings, which is why peering stops scaling quickly.

A private endpoint puts a network interface with a private IP address inside your subnet, connected over the provider's internal network to a managed service or to another organization's service. Private DNS makes the service's normal name resolve to that private address, so applications need no code changes.

flowchart LR
  A["App in private subnet"] -->|service name| B["Private DNS zone"]
  B -->|private address| A
  A --> C["Private endpoint in subnet"]
  C -->|provider internal network| D["Managed storage or database service"]

Benefits:

• No internet path: traffic never leaves the provider's network and needs no NAT gateway or public address.
• Lower cost: avoids NAT processing fees for heavy traffic to cloud services.
• Exfiltration control: endpoint policies can restrict access to your own resources only, so stolen credentials cannot copy data to an attacker's storage through the endpoint.
• Service exposure: you can publish your own service to other networks or customers privately, even when their address ranges overlap with yours.

Things to manage: endpoints usually cost per hour and per gigabyte, DNS must be configured for every network that uses them, and on-premises clients need DNS forwarding to resolve the private names.

A site-to-site VPN runs encrypted tunnels over the internet, so it is quick and cheap to set up. A dedicated private connection is a physical circuit from your network to the provider's edge, giving higher, steadier bandwidth and latency at higher cost and lead time.

When to use which:

• VPN for quick starts, small offices, low bandwidth and as a backup path.
• Dedicated connections for large data volumes, latency-sensitive hybrid applications and predictable performance.
• A common design uses dedicated connections as the primary path, with a VPN as automatic failover.

For high availability, use at least two connections terminating in different locations. A single circuit is a single point of failure, however fast it is.

Managed DNS services can answer the same name differently depending on a policy, which lets DNS act as a coarse, global traffic manager. Health checks let it stop returning unhealthy endpoints.

Limits to keep in mind:

• Caching: resolvers and clients keep answers until the time to live expires, and some ignore it, so DNS failover takes minutes rather than seconds.
• Resolver location: latency and geolocation decisions are based on the user's DNS resolver, which may be far from the user, unless the resolver passes on client subnet information.
• Health checks must test what users need, not just whether a port is open.

For fast, precise failover, combine DNS with global load balancing that uses a single anycast address.

A global load balancer gives the application one public address, often an anycast address announced from many edge locations worldwide. Users connect to the nearest edge, and the load balancer forwards each request over the provider's network to the closest region with healthy capacity.

flowchart LR
  A["User"] --> B["Nearest edge location"]
  B --> C{"Closest region healthy with capacity?"}
  C -->|yes| D["Region A backends"]
  C -->|no| E["Region B backends"]

How it decides:

1. Proximity: network routing brings the user to the nearest edge automatically.
2. Health: backends that fail health checks are removed within seconds.
3. Capacity: when a region reaches its configured capacity, overflow goes to the next closest region.
4. Policy: rules can pin users to regions for data residency or send a percentage of traffic elsewhere.

Compared with DNS-based routing:

• Failover does not wait for DNS caches to expire, because the address never changes.
• TLS can terminate at the edge, which shortens connection setup for distant users.

Design considerations: each region needs enough spare capacity to absorb another region's traffic, and user data must be available in whichever region serves the request.

Two networks with overlapping address ranges cannot be routed to each other directly, because a router cannot tell which network an address belongs to. Overlaps usually come from teams all using a default range, from acquisitions, or from partners with their own plans.

Problems they cause:

• Peering and transit attachments fail or are refused when ranges overlap.
• Hybrid connectivity breaks: cloud networks that overlap with on-premises ranges cannot reach those systems.
• Mergers stall: connecting two companies' networks needs a fix first.

Workarounds, from best long-term to quickest:

1. Re-address one of the networks. It is the only clean fix, and is easiest while the network is young.
2. Expose services through private endpoints, which work across overlapping ranges because consumers see a local address.
3. Translate addresses with NAT between the networks, accepting complexity and harder troubleshooting.
4. Use IPv6 for new connectivity, where the address space makes conflicts unlikely.

Prevention is far cheaper than any workaround: allocate ranges centrally from day one, and reserve space for future networks.

Follow the packet's path hop by hop and check each control that could drop it: routing, the NAT gateway, firewall rules in both directions, DNS and the operating system itself.

flowchart TD
  A["No internet from private server"] --> B{"Name resolves?"}
  B -->|no| C["Check DNS settings and resolver rules"]
  B -->|yes| D{"Subnet default route to NAT?"}
  D -->|no| E["Fix the private route table"]
  D -->|yes| F{"NAT healthy with route to internet gateway?"}
  F -->|no| G["Fix NAT or public route table"]
  F -->|yes| H{"Security group and access list allow traffic both ways?"}
  H -->|no| I["Fix rules, including ephemeral return ports"]
  H -->|yes| J["Check host firewall and proxy settings"]

1. Test precisely: resolve a name, then connect to a known address on a specific port, to separate DNS problems from connectivity problems.
2. Check routing: the server's subnet route table must send 0.0.0.0/0 to a NAT gateway.
3. Check the NAT: it must sit in a public subnet whose route table points to the internet gateway.
4. Check filters: outbound security group rules, and access list rules in both directions, remembering that access lists are stateless.
5. Check the host: its own firewall, proxy variables and routes.
6. Use flow logs and path analysis tools to see exactly where packets are accepted or rejected.

Divide the data size in bits by the usable bandwidth. If the result runs into weeks, or the transfer would saturate a link the business needs, a physical transfer device is usually faster.

• transfer_time = data_size_bits / (bandwidth_bits_per_second × efficiency)

What each term means:

• data_size_bits: terabytes × 8 × 10^12, since storage is quoted in bytes and links in bits.
• bandwidth: the link speed you can actually dedicate to the transfer, not the line's full rating if other traffic shares it.
• efficiency: typically 0.7 to 0.8, to allow for protocol overhead, retransmissions and contention.

When to use it: to plan migrations and backups, and to decide between network transfer and an offline device. Physical devices typically take around a week from order to data landing, so they win when the network transfer would take longer than that.

Whichever method you use, plan the delta: data keeps changing during the bulk copy, so finish with an online sync of the changes before cutover.

Stop as much bad traffic as possible before it reaches your servers, by layering denial-of-service protection, a web application firewall, bot and rate controls, and TLS at the provider's edge, then make sure the origin accepts traffic only from that edge.

How to operate it:

1. Start rules in count mode, review what they would block, then switch to blocking.
2. Log every decision to the central logging platform.
3. Tune for your application, since generic rules cause false positives on unusual but legitimate requests.
4. Lock down the origin; an origin reachable directly bypasses every edge control.
5. Plan for attacks: know your provider's escalation path and have emergency rules ready.

The edge is a filter, not a fix. Application vulnerabilities still need fixing in the code.

Send outbound traffic through a central, controlled exit where it can be filtered and logged, and give cloud services a private path so it never needs to leave at all.

1. Centralize egress: spoke networks route internet-bound traffic through a firewall and NAT in a shared hub network.
2. Filter by domain name: allow only the domains each workload needs, such as package mirrors and partner APIs, using a firewall or proxy that supports name-based rules.
3. Control DNS: use a DNS firewall to block known-malicious domains and catch lookups for unexpected ones.
4. Use private endpoints for storage, databases and other cloud services, which shrinks the internet allowlist.
5. Log flows and denials, and alert on blocked attempts, which often point to compromised hosts or misconfigured software.
6. Separate rules by environment, so development can be looser than production.

Trade-offs:

• Central inspection adds per-gigabyte processing costs and an extra hop, so size it for production volumes.
• The hub becomes critical infrastructure: deploy it across zones with automatic failover.
• Allowlists need an easy request process, or teams find workarounds.

IPv6 removes address scarcity and the need for NAT, but that also means every address is publicly routable, so security must come from firewall rules rather than from private addressing. Plan addressing, security and tooling before turning it on.

• Address plan: networks typically get a /56 prefix and each subnet a /64, which is far more addresses than needed. Plan prefixes per region and environment like IPv4 ranges.
• Inbound exposure: without NAT, a server with an IPv6 address can be reachable from the internet if rules allow it. Use an egress-only gateway for outbound-only subnets, and review security groups carefully.
• Dual stack: most networks run IPv4 and IPv6 side by side for years, so every rule, route and test must cover both.
• Rules and access lists: copy IPv4 intent into IPv6 rules; a missing IPv6 deny is a common gap.
• DNS: publish AAAA records only when the service actually works over IPv6.
• Tooling: check that logging, monitoring, allowlists and security tools parse and store IPv6 addresses correctly.
• Service support: some managed services and older appliances do not yet support IPv6.

A rising price for public IPv4 addresses is a common reason to adopt IPv6 for internet-facing traffic first.

Cloud identity and access management decides which principal may perform which action on which resource, under which conditions. Permissions are written as policies and attached to identities or resources, and every API call is checked against them.

Good practice:

• Humans sign in through single sign-on and assume roles; they do not get long-lived personal keys.
• Workloads use roles attached to the server, container or function, which supply rotating temporary credentials.
• Grant to groups and roles, never directly to individuals, so access follows job function.
• Start from nothing and add permissions, reviewing them with real usage data.

Everything is denied unless a policy allows it, and an explicit deny always wins.

Cloud platforms start from an implicit deny, then check every applicable policy: an explicit deny anywhere ends the evaluation, and the request succeeds only if some policy allows it and no guardrail blocks it. The exact layers differ by provider, but the principle is the same.

flowchart TD
  A["Request arrives"] --> B{"Explicit deny in any policy?"}
  B -->|yes| C["Denied"]
  B -->|no| D{"Organization guardrails permit it?"}
  D -->|no| C
  D -->|yes| E{"Identity or resource policy allows it?"}
  E -->|no| F["Denied by default"]
  E -->|yes| G{"Permission boundary or session limit permits it?"}
  G -->|no| F
  G -->|yes| H["Allowed"]

1. Default deny: with no matching allow, the answer is no.
2. Explicit deny wins: a deny in any layer overrides every allow.
3. Guardrails cap permissions: organization policies and permission boundaries never grant anything; they only limit what other policies can grant.
4. Allows can come from the identity or the resource: for access across accounts, usually both sides must allow it.

Why it matters in practice: when access unexpectedly fails, check every layer, not just the user's own policy. When access unexpectedly succeeds, look for an allow you forgot, such as a resource policy that grants access to a whole account.

Collect every policy statement whose action and resource patterns match the request, then apply the standard rule: any matching deny refuses the request, otherwise any matching allow permits it, and if nothing matches the answer is an implicit deny.

Key points:

• Match patterns case-sensitively with wildcard support, so storage:Get* covers storage:GetObject but not storage:getobject.
• Evaluate deny first, independent of the order the statements were written in.
• Distinguish explicit and implicit deny in the result, which makes debugging access problems much easier.
• Keep it pure: the function takes the request and the policies and returns a decision, so it is easy to test.

A real policy engine also evaluates conditions such as source network, time or tags, and combines several policy layers. The core deny-overrides logic stays the same, and writing it out is a good way to understand why a request was refused.

Long-lived access keys work until someone revokes them, so a leaked key stays useful to an attacker for months. Roles give workloads short-lived credentials that the platform issues and rotates automatically, so there is nothing permanent to leak.

How to apply it:

• Servers, containers and functions get a role attached by the platform, and software development kits pick up its credentials automatically.
• Pipelines and external systems use identity federation to exchange their own signed identity tokens for temporary credentials.
• People sign in through single sign-on and assume roles.
• Detect any remaining keys, alert on keys older than a set age and on unused keys, and plan to remove them.

Access keys remain only for rare cases that cannot federate, and those keys should be scoped narrowly and rotated on a schedule.

Use workload identity federation: the pipeline platform issues each job a short-lived, signed identity token, and the cloud exchanges that token for temporary credentials, but only if the token's claims match a trust policy you wrote, such as a specific repository and branch.

sequenceDiagram
  participant J as Pipeline job
  participant P as Pipeline identity issuer
  participant T as Cloud token service
  participant C as Cloud APIs
  J->>P: Request identity token for this job
  P->>J: Signed token with repository, branch and environment
  J->>T: Exchange token for a role session
  T->>T: Verify signature and match claims to trust policy
  T->>J: Credentials valid for one hour
  J->>C: Deploy using temporary credentials

1. Register the pipeline platform as a trusted identity issuer in the cloud account.
2. Create a deployment role whose trust policy accepts tokens only with specific claims, such as the main branch of one repository and the production environment.
3. The job requests a token, exchanges it for temporary credentials and deploys.
4. Credentials expire shortly after the job ends.

Why it is better: no secret is stored in the pipeline settings, so there is nothing to leak or rotate.

The main risk is a loose trust policy. A condition that accepts any branch, or any repository in the organization, lets a pull request deploy to production. Keep conditions as specific as possible.

Guardrail policies are applied at the organization or account-group level to set the maximum permissions anyone in those accounts can ever have. They never grant access themselves. Identity policies grant specific permissions to specific principals, within whatever the guardrails allow.

Good guardrail candidates:

• Block regions outside the approved list.
• Prevent disabling or deleting audit logs, security tooling and guardrails themselves.
• Require encryption on new storage and block public access settings.
• Stop accounts from leaving the organization.

Cautions: test guardrails in a sandbox group first, because a bad deny can break every account at once. Keep a documented, monitored emergency exception path for genuine break-glass needs.

Compare the permissions each identity has with what it has actually used, using the audit trail, then shrink the policy to match real usage, adding margin for rare but legitimate actions.

1. Gather usage data: platforms report when each service or action was last used per identity, and audit logs show every call.
2. Remove unused identities first: roles, users and keys with no activity in, say, 90 days are the easiest wins.
3. Generate a tighter policy from the actions actually used over a representative period, including month-end and quarterly jobs.
4. Test in staging, then deploy and watch for access-denied errors.
5. Keep a fast path to add back a missing permission, so teams trust the process.
6. Repeat on a schedule, because permissions creep back as systems change.

Preventing the problem:

• Start new roles with minimal permissions instead of broad managed policies.
• Use permission boundaries so teams can create roles without exceeding a ceiling.
• Review high-risk permissions, such as changing policies or reading secrets, more often than the rest.

An audit log must record every change and every sensitive access: who did what, to which resource, from where, when, and whether it worked. Attackers try to disable or delete it first, so protect it as carefully as the systems it records.

What to capture:

• Identity: the user or role, the session and how they authenticated.
• Action and resource: the API call and the exact resource it targeted.
• Context: source address, user agent and request parameters.
• Result: success or failure, including access-denied errors, which often reveal probing.
• Data access events for sensitive stores, such as object reads, in addition to management changes. They cost more, so enable them where they matter.

How to protect it:

1. Enable it organization-wide, so member accounts cannot turn it off.
2. Deliver it to a separate log archive account that workload administrators cannot access.
3. Lock it: write-once storage with retention locking.
4. Validate integrity: use signed digest files that prove no log file was changed or removed.
5. Alert on changes to logging configuration, and on gaps in delivery.
6. Retain it long enough for investigations and regulation, often a year or more, moving older logs to cheaper storage.