50 Cloud & DevOps Interview Questions and Answers (2026)

Cloud and DevOps knowledge is no longer optional for backend engineers. AWS Lambda, Docker, and microservices show up in job requirements for roles that were purely application-focused a few years ago. Azure Entra ID is now a standard topic for any role touching enterprise Microsoft environments.

These 50 questions cover what interviewers are actually asking in 2026 across six cloud and DevOps topics: serverless and AWS Lambda, API Gateway, S3, Docker, microservices, and Azure Entra ID. Answers are written to be said out loud in an interview: specific, grounded in real behavior, with working examples where they help. If you're also brushing up on the application side, our Node.js interview questions guide pairs well with the Lambda and serverless sections here, since most serverless backends in 2026 are written in Node.js.

Serverless and Lambda questions test whether you understand the execution model behind the trend, not just the marketing pitch. Expect questions about cold starts, concurrency, and the operational tradeoffs of going serverless.

Serverless computing is a cloud execution model where the cloud provider manages the server infrastructure entirely. You write and deploy code (a function), define what triggers it, and the provider handles provisioning, scaling, patching, and availability. You pay only for actual execution time, not for idle capacity.

The problem it solves: traditional server deployments require you to provision capacity in advance. A VM or container running 24/7 costs money even at 3am when no traffic arrives. Auto-scaling helps, but still requires managing the scaling configuration. Serverless eliminates the operational overhead entirely.

When NOT to use serverless:

Lambda runs your function code inside an execution environment: a managed container that AWS provisions, runs, and destroys. You never see the server.

Execution flow:

Lambda supports Node.js, Python, Java, Go, Ruby, .NET, and custom runtimes via the Runtime API.

A cold start occurs when Lambda must create a new execution environment before running your function. This adds 100ms to several seconds of latency before your handler even starts. Warm starts reuse an existing environment and run in milliseconds.

Cold starts happen when:

Cold start mitigation strategies:

1. Provisioned Concurrency: keeps N execution environments pre-initialized and always warm. Eliminates cold starts for those instances entirely. Costs money even when idle.

Concurrency is the number of Lambda function instances executing at the same time. By default, Lambda can run up to 1,000 concurrent executions per account per region (a soft limit that can be raised).

Unreserved concurrency is the pool shared by all functions in your account. If one function consumes all available concurrency during a spike, other functions in the same account get throttled.

Reserved concurrency is a hard allocation for a specific function. It has two effects: it guarantees that function can always scale up to the reserved amount, and it hard-caps the function at that amount (it cannot use more even if the pool allows).

When Lambda exceeds its concurrency limit it throttles, returning a 429 TooManyRequestsException for synchronous invocations. For asynchronous invocations, Lambda retries automatically.

Provisioned concurrency (different from reserved) pre-initializes environments. Reserved concurrency sets a hard maximum. You can combine both: set reserved concurrency to 50 and provisioned to 10 (10 always warm, up to 50 total).

A Lambda Layer is a .zip archive containing libraries, a custom runtime, configuration, or other dependencies. You attach up to 5 layers to a function. Lambda merges the layer contents into the /opt directory at runtime.

Use layers for:

In your function, access layer contents at /opt:

AWS also publishes public layers, such as the AWS X-Ray SDK layer and the Lambda Powertools layer for Python and Node.js.

Synchronous invocation: the caller waits for Lambda to finish and return a response. API Gateway, ALB, and direct SDK calls use synchronous invocation. If the function throws, the error is returned to the caller immediately. Lambda does NOT automatically retry synchronous failures.

Asynchronous invocation: the caller sends the event and gets a 202 Accepted response immediately. Lambda processes the event in the background. S3 event notifications, SNS, EventBridge, and SES use async invocation. Lambda automatically retries failed async invocations up to 2 times (3 total attempts) with delays between retries.

Dead Letter Queue (DLQ): for async invocations that fail after all retries, configure a DLQ (SQS queue or SNS topic) to receive the failed event. Inspect DLQ messages to diagnose persistent failures.

Lambda Destinations (the newer approach): route invocation results to SQS, SNS, EventBridge, or another Lambda function on success OR failure. More flexible than DLQ because it captures both success and failure events.

VPC-specific behavior: Lambda functions inside a VPC can access private resources (RDS, ElastiCache) but cannot access the public internet unless routed through a NAT Gateway. Always add a NAT Gateway if VPC Lambda functions need outbound internet access.

CloudWatch Logs: every console.log(), print(), or fmt.Println() call from your handler is captured automatically. Each function gets its own log group (/aws/lambda/function-name). Use structured logging (JSON) for better queryability.

CloudWatch Metrics: Lambda automatically publishes:

AWS X-Ray: distributed tracing. Add the X-Ray SDK to trace downstream calls (DynamoDB, S3, HTTP calls) and view flame graphs of where time is spent.

Lambda Powertools (Node.js / Python): an AWS-maintained utility library adding structured logging, tracing, and metrics with minimal code.

API Gateway questions test whether you know which API type and integration to reach for, and how authorization and throttling actually work under the hood.

API Gateway is a fully managed service for creating, publishing, securing, and monitoring APIs at any scale. It acts as the front door for applications to access backend services: Lambda functions, EC2, ECS, or any HTTP endpoint.

REST API: the original, most feature-rich option. Supports request/response transformation, request validation, usage plans, API keys, custom domain names, caching, and fine-grained IAM permissions. More expensive and complex to configure.

HTTP API: launched in 2020 as a simpler, cheaper alternative. Supports Lambda and HTTP integrations, JWT authorizers, and OIDC/OAuth 2.0. Up to 71% cheaper than REST API. Lacks some REST API features (no built-in response transformation, no usage plans). Best for most modern serverless APIs.

WebSocket API: for two-way stateful communication. Maintains persistent connections. Used for real-time chat, live dashboards, and multiplayer games. Supports $connect, $disconnect, and custom route keys.

API Gateway can route requests to different backends depending on the integration type.

Lambda Proxy: the most common. API Gateway passes the full HTTP request (headers, query params, body, path params) to Lambda as a structured event. Lambda returns a structured response object. Zero request/response transformation by API Gateway.

Three built-in authorization mechanisms:

IAM Authorization: requests must be signed with AWS Signature Version 4. Best for internal service-to-service calls and AWS CLI/SDK access. Not for public APIs since every caller needs AWS credentials.

Lambda Authorizer (formerly Custom Authorizer): API Gateway calls a Lambda function with the request token (or full request). The Lambda returns an IAM policy (allow/deny) and optionally a context object passed to the backend. Results can be cached by API Gateway to reduce Lambda calls.

JWT Authorizer (HTTP API only): API Gateway validates JWT tokens directly without invoking a Lambda function. Configure the issuer URL (Cognito, Auth0, Okta) and API Gateway verifies signature and claims automatically. No Lambda cost, lower latency.

API Gateway enforces throttling at two levels.

Account-level throttle: default 10,000 requests/second and 5,000 burst (requests allowed in the first second). Shared across all APIs in the region.

Stage-level and method-level throttle: set per API stage or per individual route/method. Overrides the account default for that specific resource.

When throttled, API Gateway returns 429 Too Many Requests.

Usage Plans (REST API): pair with API keys to set per-customer throttle limits and monthly request quotas. Useful for monetized APIs.

Behind the scenes, API Gateway uses a token bucket algorithm. The burst limit is the bucket capacity (tokens available instantly). The rate limit is the refill rate (tokens added per second).

A stage is a named reference to a specific deployment of your API (e.g., dev, staging, prod). Each stage has its own URL, throttle settings, logging configuration, and stage variables.

Stage variables work like environment variables for API Gateway. Use them to point different stages to different Lambda function aliases or backends.

Canary deployments: route a percentage of traffic to a new stage deployment before full release. If metrics look good, promote the canary. If not, roll back.

Custom domains: map your own domain (api.yourcompany.com) to an API Gateway endpoint using Route 53 and ACM certificates, hiding the default execute-api URL.

Choose HTTP API when you are building a new serverless API, you use JWT auth (Cognito, Auth0), and you do not need request/response transformation or usage plans. It is simpler, cheaper, and faster for the majority of use cases.

Choose REST API when you need built-in caching, response transformation via mapping templates, usage plans for monetization, or API keys with per-key throttle controls.

S3 questions test your understanding of object storage fundamentals: storage classes, versioning, access control, and the presigned URL pattern that almost every file-upload feature depends on. If your data layer also includes a NoSQL store alongside S3, our NoSQL interview questions guide covers DynamoDB and MongoDB patterns that frequently pair with S3 for media and document storage.

Amazon S3 (Simple Storage Service) is AWS's object storage service. It stores any file type as an object inside a container called a bucket. S3 is designed for 99.999999999% (11 nines) durability and scales from bytes to exabytes.

Bucket: a container for objects. Bucket names are globally unique across all AWS accounts. Each bucket lives in one AWS region.

Object: a file stored in S3. Consists of the object data (binary) plus metadata (key-value pairs). Maximum object size is 5TB. Objects over 5GB require multipart upload.

Key: the full path and name of the object within the bucket, for example images/profile/user-1001/avatar.jpg. S3 is flat (no real folders): the slash is just part of the key name, but the console displays it as folders.

Key S3 capabilities:

S3 offers several storage classes optimized for different access patterns and cost profiles.

When versioning is enabled on a bucket, S3 stores every version of every object rather than overwriting. Each PUT creates a new version with a unique version ID. Deleting a versioned object adds a delete marker (it is not truly deleted until you delete all versions).

Problems it solves:

Combined with lifecycle policies, you can expire old versions automatically to control costs (keep last 5 versions, delete older ones after 90 days).

MFA Delete: requires MFA authentication to permanently delete a versioned object. Extra protection against accidental or malicious permanent deletion.

A presigned URL is a time-limited, signed URL that grants temporary access to a specific S3 object to anyone who has the URL, without requiring AWS credentials. The URL encodes the identity of the signer, the target object, and the expiration time.

Use cases:

The direct-upload pattern (presigned PUT) is the right way to handle large file uploads. It offloads all the bandwidth and processing from your server to S3.

S3 can invoke a Lambda function when specific events happen on a bucket:

Lambda receives an S3 event:

S3 Access Control Lists (ACLs) are a legacy mechanism. They define basic read/write permissions per object or bucket for specific AWS accounts or predefined groups (all users, authenticated users). AWS recommends disabling ACLs and using bucket policies instead for all new buckets.

S3 Bucket Policy: a JSON IAM-style resource policy attached to the bucket. Supports fine-grained conditions, IP restrictions, MFA requirements, and cross-account access. More powerful and auditable than ACLs.

Block Public Access settings: a separate account-level and bucket-level setting that overrides ACLs and bucket policies to prevent any public access, even if a policy accidentally grants it. Enable this on all non-public buckets.

Docker questions cover the full lifecycle: images, containers, networking, volumes, multi-stage builds, security, and orchestration. This is the largest category in the guide because Docker fluency underpins almost every microservices and CI/CD question that follows. Once you're comfortable with the concepts here, our NestJS interview questions guide shows how these containers typically run a Node.js backend in production.

Docker is a platform for packaging, distributing, and running applications in containers. A container is an isolated process running on the host OS, packaged with all its dependencies.

The key difference from a virtual machine:

VM: runs a full guest OS on top of a hypervisor. Each VM has its own kernel, virtual hardware, and OS installation. Boot time is measured in minutes, and overhead is gigabytes of memory per VM.

Container: shares the host OS kernel. Only packages the application and its user-space dependencies. Boot time is measured in milliseconds, and overhead is megabytes.

Practical result: you can run dozens of containers on a machine where only 3 to 4 VMs would fit. Containers also start in milliseconds, making them ideal for scaling and CI/CD.

The trade-off: VMs provide stronger isolation (separate kernel). Containers share the host kernel, so a kernel exploit can potentially escape container isolation. In practice, production environments often run containers inside VMs (e.g., EC2 instances running Docker) to get both performance and isolation.

Docker uses a client-server architecture.

Docker CLI (client): the command-line tool you interact with. Sends REST API requests to the Docker daemon via a Unix socket (/var/run/docker.sock).

Docker daemon (dockerd): the long-running background service. Manages images, containers, networks, and volumes. Delegates container lifecycle management to containerd.

containerd: an industry-standard container runtime (CNCF project). Handles the actual container lifecycle: pulling images, creating, starting, and stopping containers. Kubernetes also uses containerd directly.

runc: the low-level container runtime that containerd calls to actually spawn containers using Linux namespaces and cgroups.

Docker Registry: stores and distributes Docker images. Docker Hub is the default public registry. ECR (AWS), GCR (Google), and ACR (Azure) are popular managed alternatives. You can also self-host with Harbor or a private registry.

Image: a read-only, immutable template. Built from a Dockerfile. Consists of stacked layers, each representing a filesystem change. An image is like a class in OOP.

Container: a running (or stopped) instance of an image. Created with docker run. Gets its own writable layer on top of the image layers. All writes go into this ephemeral writable layer: when the container is deleted, the writes are lost unless you use volumes. A container is like an object (instance) of the class.

Multiple containers can run from the same image simultaneously. They all share the same read-only image layers (saving disk space) but each has its own writable layer.

A good Dockerfile produces a small, fast-to-build, secure image.

Key best practices:

Every instruction in a Dockerfile creates a layer. Docker caches each layer. When you rebuild, Docker reuses cached layers from the cache until it encounters a layer that has changed, then it re-executes all subsequent layers.

This means layer order matters for build speed.

In the GOOD example, if you change only a source file, Docker reuses the npm ci layer (which is slow) and only re-executes the COPY . . layer (fast).

Docker Compose defines and runs multi-container applications using a single YAML file. Instead of running docker network create, docker run, and manually linking containers, you describe all services in docker-compose.yml and bring everything up with one command.

Docker Compose is ideal for local development and CI/CD test environments. In production, use Kubernetes or ECS for orchestration.

Docker ships five built-in network drivers.

bridge: the default for containers on the same host. Creates a virtual bridge network. Containers can communicate by container name (automatic DNS). Use for local development multi-container setups.

Volumes: managed by Docker, stored in Docker's storage area (/var/lib/docker/volumes/). Created explicitly or automatically. Portable, shareable between containers, and can be backed up with docker volume commands. Best for production persistent data.

Bind mounts: mount a specific host directory or file into the container. The host path must exist. Commonly used in development to mount source code for hot-reloading.

tmpfs mount: stored in host memory only, never written to disk. For temporary sensitive data (secrets, temp files) that must not persist.

Production rule: use volumes for databases and persistent state. Use bind mounts only in development for code mounting. Never bind-mount secrets.

A multi-stage build uses multiple FROM instructions in a single Dockerfile. Each stage can use a different base image. Only the final stage becomes the shipped image, earlier stages are discarded.

This solves the "fat build image" problem: build tools (compilers, package managers, test frameworks) needed to build the app are not needed to run it.

The production image contains only the Alpine Node.js runtime, production dependencies, and compiled output. The node:22 build environment (3x larger) is discarded.

Result: a production image might be 80MB instead of 800MB. Smaller images mean faster push and pull times, a smaller attack surface, and lower ECR storage costs.

Common causes of container crashes:

Run as non-root:

Use minimal base images:

Scan images for vulnerabilities:

Use a read-only filesystem:

Drop capabilities:

Never run in privileged mode in production:

Limit resources:

Use Docker Content Trust for image signing and verification in production pipelines.

Both are container orchestration platforms that manage clusters of containers across multiple hosts.

Docker Swarm: Docker's native clustering tool. Simple to set up and operate. Built into Docker Engine. Uses docker-compose.yml (stack files) for service definitions. Suitable for smaller deployments and teams migrating from Compose.

Kubernetes: the industry-standard container orchestration platform (CNCF). More complex but far more powerful. Richer ecosystem (Helm, service meshes, operators). Supported by every major cloud provider as a managed service (EKS, GKE, AKS). The standard choice for production at scale.

Key differences:

Microservices questions test whether you understand the distributed systems trade-offs, not just the buzzwords. Expect questions about communication patterns, failure handling, and data consistency across service boundaries.

A monolith is a single deployable unit. All features, business logic, and data access live in one codebase and process. Simple to develop initially but grows harder to scale, deploy, and maintain as teams and complexity grow.

Microservices architecture decomposes an application into small, independently deployable services. Each service owns its domain, its data store, and its deployment lifecycle. Services communicate over the network via APIs or message queues.

Benefits:

Drawbacks:

When to start with a monolith: early-stage product, small team, unknown domain boundaries. Prematurely decomposing into microservices creates distributed system problems before you have the organizational scale to benefit.

Two communication patterns: synchronous (request-response) and asynchronous (message-based).

Synchronous: the caller waits for a response.

Asynchronous: the caller publishes a message and continues.

The general rule: use synchronous communication when you need an immediate response. Use async messaging for operations where eventual processing is acceptable (order placed event, then email notification, then inventory update).

Service discovery is the mechanism by which microservices find each other's network locations. In a static environment, you could hardcode IP addresses. In a dynamic cloud environment where services scale up and down and containers get new IPs constantly, this is impossible.

Two patterns:

Client-side discovery: the calling service queries a service registry (Consul, Eureka, etcd) to get the current list of healthy instances for the target service. The client performs its own load balancing.

Server-side discovery: the client sends a request to a load balancer (AWS ALB, Kubernetes Service). The load balancer queries the registry and routes to a healthy instance. The client does not need to know about discovery.

Kubernetes handles service discovery automatically: every Service gets a DNS name that resolves to healthy pod IPs via kube-dns. The calling service uses http://payment-service/charge and Kubernetes routes it.

AWS App Mesh and Consul Connect are service mesh solutions that add service discovery plus mTLS, circuit breaking, and observability as a sidecar proxy, without changing application code.

The Circuit Breaker prevents a single failing service from causing cascading failures across an entire system. It monitors calls to a downstream service and "trips" when the failure rate exceeds a threshold.

Three states:

The Saga pattern manages distributed transactions across multiple microservices without two-phase commit (2PC). Since each service owns its own database, you cannot do a traditional SQL transaction across them. The Saga breaks the distributed transaction into a series of local transactions, each with a compensating transaction for rollback.

Two Saga implementations:

Choreography: each service publishes events. Downstream services listen and react. No central coordinator.

Orchestration: a central Saga orchestrator sends commands to each service and waits for responses. Step Functions (AWS) is a managed orchestrator.

Choreography is simpler for small flows. Orchestration is easier to reason about and debug for complex multi-step workflows.

Event sourcing is a pattern where instead of storing the current state of an entity, you store the sequence of events that led to that state. The current state is derived by replaying all events.

Benefits:

Drawbacks:

Event sourcing is commonly paired with CQRS (Command Query Responsibility Segregation), where writes go through events and reads come from optimized read models (materialized projections).

Distributed tracing tracks a single request as it flows through multiple microservices. Each service adds a trace span with timing information. You can see the full request lifecycle and identify where latency lives.

Without distributed tracing, debugging a slow request in a 20-service architecture is nearly impossible: the log is split across 20 services with no shared request ID.

Key concepts:

OpenTelemetry is the vendor-neutral standard for generating traces, metrics, and logs. Instrument your service once, export to any backend.

Popular backends: Jaeger (open source), Zipkin (open source), AWS X-Ray (native AWS), Datadog APM, Honeycomb, and Grafana Tempo.

A service mesh is an infrastructure layer that manages all network communication between microservices. It runs as sidecar proxies (one per service pod) that intercept and handle all inbound and outbound traffic without changing application code.

Capabilities a service mesh provides:

Popular service meshes: Istio, Linkerd, Consul Connect, and AWS App Mesh.

When you need a service mesh:

When you probably do NOT need it:

Start without a service mesh. Add it when you have a clear, specific pain point, usually around security or observability at scale.

The 12-factor app is a methodology for building cloud-native, scalable, maintainable software-as-a-service applications. Relevant factors for microservices interviews:

Two patterns dominate.

Centralized authentication with token propagation: one auth service issues JWTs. Each downstream service validates the JWT independently, with no network call to the auth service per request, just local signature verification.

The API Gateway or service mesh validates the token. Services trust the validated identity propagated in headers (X-User-ID, X-User-Roles).

Service-to-service auth: services calling each other must also authenticate.

Authorization: each service enforces its own authorization rules based on the user identity in the token. Central policy enforcement (Open Policy Agent, AWS IAM) handles complex permission models.

The key principle: never pass usernames and passwords between services. Use short-lived tokens. Rotate signing keys regularly.

Azure Entra ID questions test identity and access management knowledge for enterprise Microsoft environments. Expect questions on OAuth flows, managed identities, and the policy engine that controls conditional access.

Azure Entra ID (rebranded from Azure AD in 2023) is Microsoft's cloud-based Identity and Access Management (IAM) service. It is the identity backbone for Microsoft 365, Azure resources, and any third-party application registered with a tenant.

Core functions:

Entra ID is not the same as Windows Active Directory (AD DS). AD DS is an on-premises directory service using LDAP and Kerberos. Entra ID is cloud-native, uses OAuth 2.0 and OpenID Connect, and manages cloud identities. Azure AD Connect synchronizes on-premises AD users to Entra ID for hybrid environments.

App Registration: the global definition of an application in Entra ID. You create one App Registration in the home tenant. It defines the app's identity, redirect URIs, the API permissions it requests, and its certificate or secret credentials. Think of it as the blueprint.

Service Principal: the local instance of the App Registration within a specific tenant. When an app registration is created, or when a multi-tenant app is consented to in another tenant, a Service Principal is automatically created in that tenant. It carries the actual permissions granted to the app in that tenant.

For a single-tenant app, one App Registration creates one Service Principal in the same tenant. For a multi-tenant app, one App Registration creates N Service Principals: one per tenant that installs or consents to the app.

Entra ID supports several OAuth 2.0 and OpenID Connect flows. Picking the right one depends on whether a user is present and whether the client can keep a secret.

A Managed Identity is a Service Principal whose credentials are automatically managed by Azure. You never create, store, or rotate a client secret or certificate: Azure handles the key lifecycle entirely.

There are two types:

Why managed identities are preferred over client secrets:

Conditional Access is Entra ID's policy engine for access control decisions based on contextual signals. Instead of a simple allow or deny on identity, it evaluates who is accessing what, from where, on what device, and at what risk level.

Policy structure: if a set of conditions is met, then grant or block controls apply.

Conditions include:

Controls include:

Common use cases:

Azure RBAC controls access to Azure resources: storage accounts, virtual machines, resource groups, and subscriptions. Roles are assigned at a scope (management group, subscription, resource group, or resource). Built-in roles include Owner, Contributor, Reader, and over 100 service-specific roles.

Entra ID roles (directory roles) control access to Entra ID itself and to Microsoft 365 services. Examples include Global Administrator, User Administrator, Application Administrator, and Security Reader.

SSO lets users authenticate once with Entra ID and access multiple applications without re-entering credentials. Entra ID supports three SSO protocols.

SSO session flow (OIDC):

Token lifetime: access tokens default to 1 hour. Refresh tokens allow silent re-authentication for around 90 days before requiring an interactive login.

PIM is an Entra ID feature that manages just-in-time privileged access to Azure resources and Entra ID roles. Instead of giving permanent admin access (standing privileges), users are made eligible for privileged roles and must activate them when needed.

How it works:

Benefits:

Use this table to scan every question and its core concept in one pass. It's the fastest way to spot the topics you need to revisit before an interview.