Cloud Engineer interview questions and answers

These are service models that differ in how much the provider manages. IaaS, Infrastructure as a Service, gives you virtual machines, disks and networks, like Amazon EC2 or Azure Virtual Machines. You manage the operating system, patches, runtime and application. PaaS, Platform as a Service, also manages the OS and runtime, so you just deploy code, for example AWS Elastic Beanstalk, Google App Engine or Azure App Service. SaaS, Software as a Service, is a finished application you simply use, such as Gmail, Microsoft 365 or Salesforce. As you move from IaaS to SaaS you get less control but also less operational work, and the shared responsibility line moves toward the provider. In practice, many teams mix them, for example running containers on a managed Kubernetes service, which sits between IaaS and PaaS.

A VPC, or Virtual Private Cloud, is a logically isolated network inside a cloud provider where you launch your resources. You give it an IP range in CIDR notation, such as 10.0.0.0/16, and split that into subnets, each living in one availability zone. Route tables decide where traffic goes. A public subnet has a route to an internet gateway, while a private subnet usually sends outbound traffic through a NAT gateway so instances can download updates without being reachable from outside. Security groups act as stateful firewalls on each network interface, and network ACLs are stateless filters at the subnet level. You can also add VPC endpoints for private access to services like S3, and connect VPCs using peering or a transit gateway. A common pattern is load balancers in public subnets and apps and databases in private subnets across at least two AZs.

IAM controls who can do what in a cloud account. A user is a long-term identity with a password or access keys. A group is a collection of users so you can attach permissions once, for example a Developers group. A policy is a JSON document listing allowed or denied actions on specific resources, with optional conditions. A role is an identity with permissions but no permanent credentials; a trusted principal assumes it and receives temporary credentials. I use roles almost everywhere: for EC2 instances and Lambda functions, for CI pipelines using OIDC federation, for cross-account access, and for engineers who log in through SSO with IAM Identity Center. Temporary credentials expire automatically, so there are no long-lived keys to leak. In all cases I follow least privilege and review unused permissions regularly.

The goal is to remove single points of failure. I would run the web tier on at least two instances, or containers, spread across two or three availability zones. An Application Load Balancer sits in front, does health checks and only sends traffic to healthy targets. An Auto Scaling group keeps the desired count and replaces any instance that fails. The app servers must be stateless, so sessions go into something like Redis or DynamoDB and uploaded files go to S3. For the database I would use a managed service like RDS or Aurora with Multi-AZ, so a standby takes over automatically if the primary fails. DNS with Route 53 health checks can add another layer. Finally, I would add monitoring and alarms so the team knows when something degrades, and test failover regularly.

The main compute pricing models are on-demand, commitment discounts, spot and serverless. On-demand means paying per second or hour with no commitment; it is the most flexible but the most expensive, so it suits new projects, short tests and unpredictable spikes. Savings Plans and Reserved Instances give large discounts, often 30 to 70 percent, in exchange for a one or three year commitment, so I use them for the steady baseline that always runs. Spot or preemptible VMs are spare capacity at up to 90 percent off, but they can be taken back, so they fit batch jobs, CI runners and stateless workers. Serverless services like Lambda or Cloud Run charge only when requests run, which is great for low or spiky traffic. A good strategy combines them: commitments for the baseline, on-demand for peaks and spot for fault-tolerant work.

A virtual machine runs a complete guest operating system on a hypervisor, so each VM has its own kernel, drivers and boot process. A container is just an isolated process on the host: it shares the host kernel and uses namespaces for isolation and cgroups for resource limits. Because of that, containers start in seconds, use less memory and pack more densely, and the same image runs the same way on a laptop and in production. VMs give stronger isolation, which matters for untrusted multi-tenant workloads, and they can run a different OS such as Windows next to Linux. In practice in the cloud we use both: Kubernetes nodes are VMs, and our services run as containers on them. I choose plain VMs for legacy apps, special kernels or licensed software, and containers for most modern stateless services.

Infrastructure as Code means describing networks, servers, databases and permissions in text files, then letting a tool such as Terraform, OpenTofu or CloudFormation create and update them. The files live in version control, so every change has an author, a review and a history. Teams use it because it makes environments repeatable: dev, staging and prod come from the same modules with different variables, so they do not drift apart. A plan step shows exactly what will change before anything happens, which makes reviews safer than clicking in a console. It also speeds up recovery, because you can rebuild an environment from code after a disaster. Declarative tools keep state and compare it with the real world, so they can detect drift when someone does make a manual change.

Metrics are numbers measured over time, like request rate, error rate, latency and CPU. They are cheap to store and query, so I use them for dashboards and alerts, for example in Prometheus with Grafana or in CloudWatch. Logs are detailed records of individual events, such as an error with a stack trace and request ID; they answer what exactly happened. Traces follow a single request as it moves through load balancers, services and databases, and show how long each step took, which is the fastest way to find a slow dependency in a microservice system. They work best together: a metric alert tells me the error rate jumped, a trace shows which service is failing, and that service logs explain why. I usually instrument with OpenTelemetry so all three share the same request context.

A CDN has many edge locations around the world. When a user requests a file, DNS sends them to a nearby edge. If the edge has a cached copy, it returns it at once, which is a cache hit; if not, it fetches from the origin, such as an S3 bucket or load balancer, stores it and returns it. This lowers latency and takes load off the origin. The main things I think about are TTLs and Cache-Control headers, which decide how long content is kept, and the cache key, because including unnecessary headers or cookies kills the hit ratio. For updates I prefer versioned file names like app.3f2a.js over frequent invalidations. Finally, I make sure personalized or private responses are marked no-store or private so the CDN never serves one user data to another.

Block storage gives a server a raw disk volume, such as EBS on AWS or Managed Disks on Azure. It has low latency and is formatted with a file system by the OS, so it suits databases and boot volumes, but usually only one instance uses it. Object storage, such as S3 or Google Cloud Storage, stores whole objects under keys and is accessed over an HTTP API. It is extremely durable, scales without limits and is cheap, so it is ideal for backups, logs, data lakes, images and static websites, but you cannot edit part of a file in place. File storage, such as EFS or Azure Files, gives a shared file system over NFS or SMB that many servers can mount at once, which fits shared content, home directories or legacy apps that expect file paths. I choose based on access pattern, performance and cost.

I would build a VPC across three availability zones with three subnet layers. Public subnets hold only the Application Load Balancer and NAT gateways. CloudFront with AWS WAF sits in front for caching, TLS and protection against common attacks. Private app subnets run the application on ECS Fargate or an EC2 Auto Scaling group, scaling on CPU or request count. Isolated data subnets host Aurora or RDS with Multi-AZ, encryption with KMS and automated backups. Security groups chain together: the ALB accepts 443 from the internet, the app accepts traffic only from the ALB security group, and the database only from the app security group. The app uses an IAM role and reads credentials from Secrets Manager. I add VPC endpoints for S3 and other services, CloudWatch logs and alarms, CloudTrail, and define everything in Terraform with CI review.

I always use a remote backend, for example an S3 bucket with versioning, encryption and native state locking, or Azure Blob or GCS. Each environment gets its own state, and often its own cloud account, so a mistake in dev cannot touch prod. I also split large systems into smaller states such as network, data and app, which keeps plans fast and limits the blast radius. Shared logic lives in versioned modules, and each environment has a thin root configuration with its own variables. Some teams use workspaces, but I prefer separate directories or a tool like Terragrunt for clearer separation. Changes go through pull requests where CI runs plan and posts the output, and apply runs only after approval, ideally from the pipeline using OIDC credentials. State can contain secrets, so access is tightly restricted. I also run scheduled plans to detect drift.

First I turn on S3 Block Public Access at both account and bucket level and keep Object Ownership set to bucket owner enforced, so ACLs are disabled. Access is granted through IAM roles and a bucket policy with least privilege, plus a condition that denies requests not using TLS. Data is encrypted with SSE-KMS using a customer managed key, so key policy adds a second layer of control and every use is logged. I enable versioning, and for compliance data Object Lock, to protect against deletion or ransomware. Applications reach the bucket through a VPC gateway endpoint, and the bucket policy can require that endpoint. Users download files through short-lived pre-signed URLs instead of public links. For visibility I enable CloudTrail data events, use Amazon Macie to find sensitive data, GuardDuty for threats, and lifecycle rules to delete data we no longer need.

I would follow the packet path step by step. First, the private subnet route table must send 0.0.0.0/0 to a NAT gateway. Second, that NAT gateway must sit in a public subnet whose route table points 0.0.0.0/0 to an internet gateway attached to the VPC, and the NAT must be in the available state with an Elastic IP. Third, I check the instance security group allows outbound traffic on 80 and 443, and that the network ACLs on both subnets allow outbound traffic and the inbound return traffic on ephemeral ports 1024 to 65535, since NACLs are stateless. Fourth, I check DNS: the VPC needs DNS resolution enabled, and I test with nslookup or curl to an IP. Finally, VPC Reachability Analyzer and Flow Logs quickly show where traffic is rejected. If the instance only needs AWS services, VPC endpoints may be a better answer.

I start with discovery: list servers, dependencies, data volumes, performance needs, compliance rules and current costs, often with a discovery tool. Then for each application I pick one of the 7 Rs, such as rehost (lift and shift), replatform (for example moving the database to RDS), refactor, repurchase as SaaS, retire or retain. Before moving anything, I set up a landing zone with accounts, networking, VPN or Direct Connect to the data center, identity and logging. For data, I use continuous replication such as AWS DMS or native database replication, so the final cutover is short. I run the app in parallel, do performance and failover tests, and plan a cutover window with a clear rollback plan, like switching DNS back. After go-live I monitor closely, rightsize resources, and gradually modernize, because the first move is rarely the most cost efficient design.

On every pull request the pipeline runs terraform fmt -check, validate, tflint and a security scanner such as Checkov or Trivy, then runs plan for each affected environment and posts the plan to the pull request. Reviewers approve the code and the plan together. After merge, the pipeline applies to dev automatically, then staging, and production waits for a manual approval through a protected GitHub environment. I save the plan file and apply exactly that plan so nothing changes between review and apply. State lives in a remote backend with locking, separate per environment. The pipeline authenticates to the cloud with OIDC, assuming a different least-privilege role per environment, so there are no long-lived keys. Finally, a nightly job runs plan against each environment and alerts if it finds drift.

First I check resources: every container needs CPU and memory requests based on real usage, and a memory limit, so scheduling and autoscaling work. Next, probes: a readiness probe that reflects whether the pod can serve traffic, a simple liveness probe that only checks the process, and graceful shutdown that handles SIGTERM and drains connections. For availability I want at least two or three replicas spread across zones with topology spread constraints, plus a PodDisruptionBudget that still allows node drains. I add an HPA on CPU or a custom metric. On security, the image should be scanned and run as non-root, secrets should come from a secret manager, and the pod should use its own service account with workload identity scoped to least privilege. Finally, I confirm dashboards, alerts tied to SLOs, logs with request IDs, and a tested rollback path.

I acknowledge the page, check how many users are affected, and open an incident channel so others know I am on it. The first question is what changed: a deploy, a config flag, a scaling event, or a provider issue on the status page. Then I narrow the scope using dashboards and traces: is it all endpoints or one, all AZs or one, and which dependency is slow, such as the database, a cache or an external API. I look at saturation signals like CPU, memory, connection pools, database load, throttling errors and queue depth. My priority is to mitigate before fully understanding, so if a deploy lines up with the spike I roll it back, or I scale out or fail over if capacity is the issue. Once stable, I find the root cause and run a blameless postmortem with concrete follow-up actions.

I keep secrets in a managed store such as AWS Secrets Manager, Azure Key Vault or Google Secret Manager, encrypted with KMS keys. Applications get access through their cloud identity, an IAM role, a managed identity or Kubernetes workload identity, so there is no bootstrap secret to protect. Access is least privilege per service and every read is logged in CloudTrail or the equivalent. I turn on automatic rotation for database credentials, and where possible use short-lived credentials instead, such as IAM database authentication or dynamic secrets. Secrets must never be committed to Git, baked into images or put in plain environment files, so I run secret scanning in repositories and CI. In Kubernetes I sync secrets with the External Secrets Operator or the CSI driver. I also avoid putting secrets into Terraform state where possible.

I start with accounts, because separate AWS accounts per team and environment are the cleanest cost boundary and need no tagging discipline. Inside accounts I define a short mandatory tag set, such as team, application, environment and cost-center, with fixed allowed values. I enforce it in several places: Terraform default_tags in the provider so every resource gets them, AWS Organizations tag policies for consistent values, and Config rules or CI policy checks to flag untagged resources. Those tags are activated as cost allocation tags so Cost Explorer and the Cost and Usage Report can break spend down. Each team gets budgets and anomaly alerts on its own spend. Shared costs like networking or support are split by an agreed formula in a showback report, and we track the percentage of untagged spend as a metric to drive it down.

An RPO under a minute rules out periodic backups, and an RTO of 15 minutes rules out building a region from scratch, so I would use warm standby. The primary region runs the full stack. The secondary runs a smaller copy deployed from the same Terraform and pipeline. Data uses Aurora Global Database or DynamoDB global tables, which replicate asynchronously with typical lag around a second, meeting the RPO. Secrets, KMS keys, container images and config are replicated too. Route 53 failover records or a global load balancer shift traffic, but I prefer a human-approved or well-tested automated failover to avoid flapping. Key trade-offs: async replication means a few seconds of transactions can be lost, so payments need idempotency keys and reconciliation; split brain must be prevented by fencing the old primary. Standby costs money, and the plan only works if we run regular game days.

I would use AWS Organizations, often with Control Tower, and treat the account as the main security and billing boundary. The structure has OUs such as Security, Infrastructure, Workloads split into Prod and Non-Prod, and Sandbox. Core accounts include a log archive account receiving organization-wide CloudTrail and Config, a security tooling account for GuardDuty and Security Hub as delegated admin, and a network account owning the transit gateway, egress and DNS. Each product team gets separate dev, staging and prod accounts, created by an automated account vending pipeline with baseline Terraform, budgets and tags. People log in through IAM Identity Center connected to the corporate IdP, using permission sets instead of IAM users. SCPs act as guardrails, for example denying unused regions, disabling CloudTrail changes and root usage. The trade-off is more accounts to manage, but blast radius, cost tracking and autonomy are much better.

I would start with data, not guesses. Using Cost Explorer or the cost and usage report with good tagging, I find the top services, accounts and teams driving spend, since usually a few items make up most of the bill. Quick wins come from waste: idle instances, unattached volumes, old snapshots, oversized dev environments running all night, and forgotten load balancers. Next is rightsizing with Compute Optimizer data, moving to newer or ARM-based Graviton instances, tuning autoscaling, and moving storage to Intelligent-Tiering or cheaper classes with lifecycle rules. After usage is lean, I buy Savings Plans for the steady baseline and move fault-tolerant work to Spot. I also review data transfer: NAT gateway traffic, cross-AZ chatter and egress, often fixed with VPC endpoints and caching. To keep reliability, changes go through normal testing and monitoring. Finally, I set budgets, anomaly alerts and team-level showback so savings last.

The key idea is to keep the old and new databases in sync while the application is still live. First I check compatibility, such as engine versions, extensions and character sets, and create the target schema. Then I do a full load using native tools like pg_dump or a snapshot, or AWS DMS, followed by change data capture through native logical replication or DMS so ongoing writes keep flowing to the target. I validate row counts and checksums and run load tests against the new database. For cutover, I rehearse in staging first. In production, I briefly stop writes or put the app in read-only mode, wait until replication lag is zero, run final validation, and switch the connection string through config or a DNS name. Before switching, I set up reverse replication if possible, so rollback is fast. Total write downtime can be a few minutes or less.

A site-to-site VPN creates IPsec tunnels over the public internet. It can be set up in hours and is cheap, but latency and throughput vary, and each tunnel has bandwidth limits, around 1.25 Gbps on AWS. Direct Connect, ExpressRoute on Azure or Cloud Interconnect on GCP, is a private dedicated link through a colocation partner. It gives stable latency, high bandwidth and lower data transfer prices, but takes weeks to provision and is not encrypted by default, so I would add MACsec or run a VPN over it for sensitive traffic. For resilience I would use two Direct Connect connections at two different locations, landing on a Direct Connect gateway attached to a transit gateway, with BGP handling failover. A cheaper option is one Direct Connect plus a VPN backup. I also plan non-overlapping IP ranges and monitor BGP sessions and link health.

I would run separate clusters for production and non-production, and give highly sensitive tenants their own cluster, because namespaces are a soft boundary. Inside a cluster, each team gets namespaces created through a self-service template with RBAC, ResourceQuotas, LimitRanges and a default-deny NetworkPolicy. Admission policies with Kyverno or Gatekeeper enforce Pod Security standards, approved registries, required labels and resource requests. Each workload uses its own service account mapped to a cloud role through workload identity, so teams never share credentials. For cost, Karpenter or Cluster Autoscaler handles capacity, and a tool like OpenCost charges spend back per namespace label. Everything is managed through GitOps with Argo CD or Flux. Upgrades follow a fixed cadence: test in a canary cluster, check deprecated APIs, then roll node pools gradually with PodDisruptionBudgets respected.

I treat it as an active incident, because bots scan GitHub for keys within minutes. First I deactivate the access key, and if it belonged to a user with assumed role sessions I revoke those sessions with a deny policy on tokens issued before now. Then I investigate CloudTrail for every API call made with that key ID in all regions, and check GuardDuty findings. I look for persistence such as new IAM users, access keys, roles with odd trust policies, Lambda functions, EC2 instances in unused regions and changes to logging, plus a billing spike from crypto mining. I remove anything the attacker created and rotate any secrets they could have read. Rewriting Git history is worth doing, but the key stays compromised either way. Afterwards I run a postmortem and remove long-lived keys entirely in favor of OIDC and roles, with secret scanning and push protection enabled.

I start from what users feel. I define SLIs such as the share of requests that succeed and the share served under 300 ms, measured at the load balancer or gateway, and set SLOs like 99.9 percent over 30 days, which gives an error budget. Paging alerts are multi-window burn rate alerts on those SLOs: a fast burn pages within minutes, a slow burn opens a ticket. Cause signals like CPU, memory, queue depth or disk go to dashboards and low-priority alerts, not pages. For diagnosis I collect the golden signals per service, distributed traces with OpenTelemetry, and structured logs with trace IDs. Every paging alert must have an owner and a runbook, and we review alert volume each week and delete or tune noisy ones. I also watch telemetry cost by limiting label cardinality and sampling traces.

The API validates the order, writes it to the database and records an event in an outbox table in the same transaction, so we never save an order without publishing its event. A relay or change data capture pushes outbox events to a queue or stream such as SQS, EventBridge or Kafka, which absorbs spikes while consumers scale on queue depth. Delivery is at-least-once, so every consumer is idempotent: payment calls use the order ID as an idempotency key, and we store processed message IDs. Failures retry with exponential backoff, and messages that keep failing go to a dead-letter queue with an alarm and a redrive process. I only enforce ordering where it matters, by keying on order ID. The multi-step flow of payment, inventory and shipping runs as a saga, for example in Step Functions, with compensating actions like refunds.

I separate reusable modules from live configurations. A platform team owns a set of opinionated modules, such as a VPC, an EKS cluster or a service bucket, published to a private registry with semantic versions, tests and changelogs. Product teams compose these in their own live repos. State is split into small units by account, environment, region and component, so one bad apply has a limited blast radius and plans stay fast; layers share data through outputs or data sources, not one giant state. Every backend is remote, encrypted and locked, with access limited to that pipeline role. In CI, policy as code with OPA, Sentinel or Checkov blocks things like public buckets or missing tags. Provider and module versions are pinned, and Renovate opens upgrade PRs so teams move forward regularly instead of falling years behind.