AWS, cloud and DevOps interview questions

How cloud and DevOps rounds are structured

The job titles overlap but the emphasis does not. A cloud engineer interview leans on services and networking, a DevOps or platform role on pipelines and infrastructure as code, an SRE role on reliability, on-call and troubleshooting. A data engineering role on a cloud platform asks about pipelines and orchestration instead, which is why tools such as Azure Data Factory or AWS Glue appear in those postings rather than in platform ones.

The formats are consistent. A screening call checks that you have genuinely used the platform in the posting, a technical round mixes definitions with a scenario, and many companies add a practical task: write a pipeline, write a module, or debug a broken deployment in a sandbox. Certification practice exams are useful for coverage, but interviews ask you to justify a choice and its failure modes, so learn the services as trade-offs rather than as definitions.

IAM, networking and storage questions

The IAM question comes up almost every time: when do you use a role instead of a user. The AWS documentation gives you the exact answer. A role is similar to a user in that both are identities with permission policies, but a role is intended to be assumable by anyone who needs it, and a role does not have standard long-term credentials such as a password or access keys; when you assume a role, it provides temporary security credentials for your role session. That is why an application on EC2 or in Lambda should use a role, and why hard-coded access keys in code are the answer interviewers hope you will reject.

Around that, be ready for the policy model: identity-based policies on users, groups and roles, resource-based policies such as a bucket policy, an explicit deny always winning, and least privilege as the default. Asked how to grant another team access to a bucket, say role assumption with a trust policy, not shared keys.

Networking questions test whether you can reason about a VPC: subnets split across availability zones, route tables, an internet gateway for public subnets, and a NAT gateway so private instances can reach out without being reachable. The classic pairing question is security groups against network ACLs, and the documented comparison is short enough to memorise.

The documentation makes the stateful part concrete: if you send a request from an instance, the response traffic for that request is allowed to reach the instance regardless of the inbound security group rules. The debugging version of this question is “my instance cannot be reached”, and the method is to walk the layers in order: route table, network ACL, security group, then the host and its process.

For storage, know the shape rather than the price list. S3 is object storage reached over an API, with storage classes that trade retrieval speed against cost. EBS is a block volume attached to one instance. EFS is a shared file system several instances can mount. Picking between those three covers most of what is asked.

EC2, containers and Lambda

The compute question is a trade-off: EC2, a container service, or a function. Instances give full control and suit long-running or legacy workloads. Containers suit services you deploy often, on ECS or EKS, with Fargate when you would rather not manage nodes. Functions suit event-driven work and spiky traffic.

Lambda has documented limits that interviewers like to probe, and the quota page states them plainly: a function timeout of 900 seconds, which is 15 minutes, memory from 128 MB to 10,240 MB in 1 MB increments, with CPU allocated in proportion to memory, a default of 1,000 concurrent executions per Region, and temporary directory storage between 512 MB and 10,240 MB. The page also states the design intent: Lambda is designed for short-lived compute tasks that do not retain or rely upon state between invocations.

Those numbers answer the most common follow-up. A job that takes an hour does not belong in a single Lambda invocation, so you split it, move it to a container, or use a workflow service to coordinate steps. Cold starts come up next: keep the package small and initialisation out of the handler, and name provisioned concurrency as the option when latency matters.

Scaling questions follow the same pattern. Put instances in an auto scaling group behind a load balancer, spread across at least two availability zones, with health checks that test the application rather than the port. Add that stateless application servers are what make this work, because the session has to live in a store rather than on the instance.

Infrastructure as code and Terraform state

Every DevOps interview asks about infrastructure as code, and most ask about Terraform. Start with what the tool guarantees: you declare the desired state, it computes a plan, and applying converges reality onto that state, so running it twice does not create two buckets.

variable "environment" {
  type    = string
  default = "staging"
}

resource "aws_s3_bucket" "logs" {
  bucket = "example-app-logs-${var.environment}"

  tags = {
    Environment = var.environment
    ManagedBy   = "terraform"
  }
}

That configuration passes terraform validate as written. Keep your examples that simple in an interview; the depth comes from the next question, which is almost always about state. The Terraform documentation explains why state exists: Terraform must store state about your workspace’s managed infrastructure and configuration, and its primary purpose is to store bindings between objects in a remote system and resource instances declared in your configuration. By default each workspace’s state lives in a local file named terraform.tfstate, which is exactly why teams move it to a remote backend: a local file cannot be shared safely and can be lost.

From there the questions get practical. Why locking matters: two engineers applying at once can corrupt state. What goes in a module: anything you build more than once. How you handle secrets: a secrets manager with references, never the repository. What you do about a resource someone changed by hand: import it or correct the drift.

CI/CD, containers and deployment strategies

Describe a pipeline as stages with a gate between them: build once into an immutable artifact, run tests, scan dependencies and images, deploy to staging, then promote the same artifact to production. The common follow-up is why you promote rather than rebuild, and the answer is that a rebuild is a different artifact and invalidates everything you just tested.

Container questions stay practical. An image is built in layers from a Dockerfile and a container is a running instance of one, so you pin a version rather than trusting the latest tag, keep images small with a multi-stage build, run as a non-root user, and never bake secrets into a layer. For orchestration, expect to read or write a manifest like this one, which a client-side kubectl dry run accepts as valid:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 5

Be ready to explain each part: the replica count and what keeps it there, why the selector has to match the pod labels, and the difference between a readiness probe, which decides whether traffic is sent to the pod, and a liveness probe, which decides whether it is restarted.

Then deployment strategies. A rolling update replaces instances gradually and is the default. Blue and green runs two environments and switches traffic, so rollback is instant but capacity doubles during the change. A canary sends a small share of traffic to the new version first and is safest when you have the metrics to judge it. Say which you have used and what the rollback plan was, because the rollback is the part interviewers care about.

Monitoring, incidents and cost

Operational questions separate people who have been on call. Start with the three streams: metrics for numbers over time, logs for events with detail, traces for a request’s path across services, which in AWS terms means CloudWatch metrics and alarms, CloudWatch Logs and a tracing service. Add that you alert on symptoms users feel, such as error rate and latency, rather than on every CPU spike, and that an alert nobody acts on should be deleted.

The scenario question is usually some version of “the service is returning errors, what do you do first”. Answer with a sequence: confirm the problem is real and how wide it is, check what changed because deployment history is the fastest explanation, decide whether to roll back or mitigate and prefer rolling back, communicate while you work, and only then dig for the cause and write the review with actions that are owned and dated.

If you are asked for a story rather than a method, use a structure so it stays short: the situation, what you were responsible for, the steps you took, and the outcome. Keep it to a couple of minutes and do not blame a colleague.

Cost questions arrive at the end and are easy marks. Right-size instances, use committed-use discounts for steady workloads and spot capacity for interruptible work, put lifecycle rules on storage, and tag everything so the bill can be attributed to a team.

Azure, multi-cloud and how to answer scenarios

Many postings are not AWS at all, and the concepts transfer if you say what you are mapping: a VPC becomes a virtual network, IAM becomes Entra ID with role-based access control, S3 becomes Blob Storage, Lambda becomes Functions. For an Azure DevOps role, expect pipelines in YAML, service connections and the agent model; for a data platform role, expect pipelines, triggers and how you handle a failed run. If the posting names a tool you have not used, do not bluff: say which equivalent you have used, describe the model, and name the one difference you would check first.

For scenario questions, use the same four beats every time. Ask what the constraint is: cost, latency, compliance or time. State your assumptions out loud. Give an answer with a trade-off attached, as in “I would start with the managed service because it removes the operational load, and move off it if the per-request cost became the problem”. Then say how you would verify it. Interviewers are grading the method, and the method is the one part you can prepare completely.