DevOps interview questions and answers

Structure: role and context, daily work, scale, impact, then the link to the new role.

Sample answer: "I am a [title] with [X] years of experience. I work at [company type], where I look after [environment, for example a multi-account AWS setup running Kubernetes]. My typical day covers three things. First, keeping systems healthy: I check dashboards and alerts, and handle incidents and tickets. Second, delivery: I maintain CI/CD pipelines, review Terraform changes, and support releases. Third, improvement work: cost savings, security fixes, and automation to remove manual steps. Recently I [achievement with a number, for example cut deployment time from 40 to 10 minutes]. I also [mentor juniors or write runbooks]. I want to take on [bigger scope the new role offers]."

Tips:

• Mention real tools (Terraform, Kubernetes, GitHub Actions, CloudWatch or Prometheus) and the scale (services, environments, traffic).
• Show ownership and results, not only tasks.
• Mention networking, DNS, certificates or monitoring only if the job needs them.

What they are checking: Whether your real responsibilities, scale and impact match the level you claim.

RUN executes a command at build time and bakes the result into an image layer. CMD sets the default command when a container starts, and can be overridden on the docker run line. ENTRYPOINT sets the fixed program of the container. Anything you pass after the image name is added to it as arguments.

• Use RUN for installing packages and building code.
• Use CMD for default arguments or a default command.
• Use ENTRYPOINT with CMD when the image behaves like a command: ENTRYPOINT is the program, CMD holds default arguments.
• Prefer the exec (JSON array) form so signals reach your process.

RUN pip install -r requirements.txt
ENTRYPOINT ["python", "app.py"]
CMD ["--port", "8000"]

docker run img --port 9000 replaces only CMD, so the container runs python app.py --port 9000.

What they are checking: Whether you understand build time versus run time and how overriding works.

On a directory, execute (x) means you can traverse it: cd into it and access items inside by name. Read (r) means you can list its names.

• r only (e.g. chmod 400 dir): ls dir shows names. But you cannot cd into it, read file details, or open files inside.
• x only: you can cd and open a file if you know its exact name, but cannot list.
• r + x: the normal read-only access (r-x): list and enter.
• w + x: needed to create, delete or rename files in it.

So to cd into a folder you need x on it and on every parent directory. Read permission alone is not enough to enter or properly list contents.

What they are checking: Whether you understand that directory permissions differ from file permissions

For most teams I choose Terraform, but the right answer depends on context.

Terraform strengths:

• Multi-cloud and many providers (Kubernetes, Cloudflare, Datadog, GitHub), one workflow.
• Easy-to-read HCL, many ready-made modules, and plan shows the exact changes.
• State gives you flexibility (import, move, run on one resource).
• Loops and expressions are more powerful (for_each, dynamic).

CloudFormation strengths:

• Made by AWS, with no state file to manage (AWS keeps it). It has automatic rollback on failure, drift detection (finding manual changes), and StackSets for many accounts.
• New AWS features often arrive first, and it works closely with Service Catalog and SAM.

Downsides: with Terraform you must secure and lock the state yourself. With CloudFormation you are limited to AWS, and templates can be long.

My choice: Terraform for multi-cloud or platform work. CloudFormation or CDK when the company uses only AWS and wants built-in rollback and control.

What they are checking: Whether you can compare tools by their good and bad points, not just name a favorite.

I start with top or htop for live CPU and memory, then use targeted commands.

top                      # live CPU/memory per process (press M or P to sort)
ps aux --sort=-%cpu | head    # top CPU consumers
free -h                  # memory and swap
df -h                    # disk usage per filesystem
du -sh /var/log/*        # folder sizes
uptime                   # load average
kill <PID>               # polite stop (SIGTERM)
kill -9 <PID>            # force kill (SIGKILL), last resort

Find a process by name with pgrep -a nginx or ps aux | grep nginx. Check logs with journalctl -u <service>. For storage problems, df -h shows which filesystem is full and du pinpoints the folder.

What they are checking: Whether you have day-to-day Linux troubleshooting habits

Each file has permissions for three classes: owner, group and others. Each class gets read (4), write (2) and execute (1), added together.

chmod 755 deploy.sh
chmod u+x,g-w file
chown appuser:appgroup file
ls -l file

chmod changes permissions and chown changes owner and group. 777 is a security risk because any user can modify or replace the file. Use the least permission that works.

What they are checking: Whether you can read and set permissions and avoid dangerous defaults

Create a user for each developer and add their public key to that user's authorized_keys. Never share one private key.

sudo adduser alice
sudo mkdir -p /home/alice/.ssh
echo "ssh-ed25519 AAAA... alice@laptop" | sudo tee -a /home/alice/.ssh/authorized_keys
sudo chmod 700 /home/alice/.ssh
sudo chmod 600 /home/alice/.ssh/authorized_keys
sudo chown -R alice:alice /home/alice/.ssh
sudo usermod -aG sudo alice      # only if needed

The developer generates the pair with ssh-keygen -t ed25519 and sends only the public key. Open port 22 only from trusted IPs. For many users, use SSM Session Manager, EC2 Instance Connect, or central user management (LDAP/SSO). Remove keys when people leave.

What they are checking: Whether you handle SSH access securely and per user

A CI/CD pipeline is an automatic path from a code commit to a running deployment. It runs checks at every step, so problems are found early.

Typical stages:

1. Source: a push or pull request triggers the pipeline.
2. Build: compile code, install dependencies, build a Docker image.
3. Test: unit tests, linting, static analysis, security and dependency scans.
4. Package and publish: push the image or artifact to a registry (ECR, Docker Hub, Artifactory).
5. Deploy: release to dev, then staging, then production.
6. Verify: smoke tests, health checks, monitoring, and automatic rollback on failure.

Benefits: faster and more frequent releases, fewer manual mistakes, the same build every time, and quick feedback for developers. Common tools are GitHub Actions, GitLab CI, Jenkins, AWS CodePipeline and Argo CD.

What they are checking: Whether you can describe the whole flow from commit to production, not only the buzzwords.

Use a present, past, future structure in about a minute:

1. Present: who you are, your degree or current role, and your main skills.
2. Past: one or two projects or experiences that show those skills.
3. Future: why this role, and what you want to grow into.

Sample answer: "I am a [your degree] graduate. For the past [time] I have focused on cloud and DevOps. I am comfortable with Linux, Git, Docker and AWS basics. I built [your project], where I put an app in a container and deployed it with a CI pipeline in GitHub Actions. I enjoy automating repeated work and learning how systems run in production. Now I am looking for a [role] where I can learn from a strong team and help with deployments and monitoring."

Keep it relevant to the job. Do not read out your whole CV. End by linking to the role.

What they are checking: Whether you can communicate clearly and tie your background to the role.

Attack both: smaller layers and better cache use.

Image size

• Use a slim, alpine or distroless base. Use multi-stage builds so compilers stay out of the final image.
• Combine related RUN steps and clean caches in the same layer (apt-get install --no-install-recommends then remove /var/lib/apt/lists/*).
• Use a .dockerignore to keep .git, node_modules and logs out of the context.

Build time

• Order instructions from least to most frequently changing: copy package.json or requirements.txt, install, then copy the source.
• Use BuildKit cache mounts (RUN --mount=type=cache,target=/root/.cache/pip pip install ...).
• In CI, reuse cache with --cache-from/--cache-to (registry or GitHub Actions cache), and build independent stages in parallel.
• Pin base images so the cache is not invalidated by surprise.

Measure with docker history and docker build --progress=plain to see which step is slow.

What they are checking: Whether you understand layer caching and can name concrete, practical optimisations.

The state file (terraform.tfstate) is Terraform's record of the real resources it manages. It links each resource block in your code to a real object (for example an instance ID) and stores its attributes. So when planning, Terraform can compare your code, the state and the real resources.

• Without state, Terraform could not know what it already created.
• It can contain secrets in plain text (passwords, keys), so it must be protected.
• Never edit it by hand. Use terraform state subcommands.
• Do not commit it to Git. Use a remote backend such as S3 with locking.

To keep it safe, do these things. Turn on versioning on the bucket, so you can recover from damage or a bad apply. Encrypt it with KMS. Limit access with IAM. Turn on locking. Keep one state for each environment or part, so a mistake affects only a small area.

What they are checking: Whether you know state links code to real resources, holds sensitive data, and needs a remote, locked and versioned home.

A common open source answer is Prometheus, Grafana, Loki and Alertmanager.

• Metrics: Node Exporter for hosts, kube-state-metrics and cAdvisor for Kubernetes, and client libraries for application metrics. Prometheus scrapes (pulls) them. On Kubernetes, use the kube-prometheus-stack Helm chart.
• Logs: Promtail or Grafana Alloy sends container and system logs to Loki. Query them with LogQL in Grafana.
• Dashboards: Grafana with Prometheus and Loki as data sources.
• Alerting: Prometheus alert rules fire to Alertmanager. It groups alerts, removes duplicates, and sends them to Slack, email or PagerDuty by severity and team.
• Good alerts: alert on symptoms (error rate, latency, pod restarts, pending pods, disk filling within 4 hours). Do not alert on every CPU spike. Each alert should link to a runbook.
• Managed option: CloudWatch with SNS, or Datadog, when you do not want to run the stack yourself.

- alert: HighErrorRate
  expr: sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05
  for: 10m
  labels: {severity: page}

What they are checking: Whether you have really built an observability stack and know how alerts reach people.

A short set covers most cases:

df -h                  # filesystem usage
du -sh /var/*          # size of folders
du -ah . | sort -rh | head   # biggest items
lsblk                  # block devices and volumes (EBS disks)
sudo ss -tulpn         # listening ports + process
sudo lsof -i :8080     # who uses port 8080
sudo netstat -tulpn    # older alternative

To then manage the process found: ps -p <PID> -o pid,cmd and kill <PID>. lsblk shows attached EBS volumes and their size even if they are not mounted yet. df -h shows only mounted filesystems.

What they are checking: Whether you can quickly find disk, port and process information

A multi-stage build uses several FROM lines in one Dockerfile. Early stages build the app with compilers and dev tools. The final stage copies only the finished files into a small runtime image.

Benefits:

• Much smaller images, because build tools never ship.
• A smaller attack surface, with fewer packages to patch.
• One Dockerfile for build and run, so no separate build scripts.
• Faster pulls and deploys.

FROM node:22 AS build
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

Copying the dependency file (package.json) before the source means the install layer stays cached until dependencies change.

What they are checking: Whether you know how to keep images small and use the build cache well.

Terraform is an open-source Infrastructure as Code tool. You describe cloud resources in config files (HCL), and Terraform creates, changes and deletes them in a repeatable way. The files say what you want, not how to do it (declarative).

• You declare the desired end state, and Terraform works out the steps to reach it.
• Providers (AWS, GCP, Azure, Kubernetes, Docker and so on) turn your code into API calls.
• It keeps a state file that maps your code to real resources, so it can work out the differences.
• Code lives in Git, is reviewed in pull requests, and the same code can build dev, staging and production.

Typical use: write main.tf with a provider and resources, run terraform init, plan to preview, then apply. In a team I store state remotely, run plan in CI on pull requests, and apply after approval.

provider "aws" { region = "ap-south-1" }

resource "aws_s3_bucket" "logs" {
  bucket = "my-team-logs-bucket"
}

What they are checking: Whether you understand declarative IaC and the basic plan and apply steps, not just the name of the tool.

Do not copy the resource block 100 times. Use count or for_each, and build the name from the index or a key.

• Simple, identical servers: count = 100 with Name = "web-${count.index + 1}".
• Servers with set names from a list or map: use for_each with the names as keys. Then removing one does not affect the others.
• Use format("web-%03d", count.index + 1) for names with leading zeros.
• Put shared settings (AMI, type, subnet, tags) in variables or locals. Put per-instance changes in a map.
• Watch the API limits and quotas. In real work, a module or an Auto Scaling group is usually better than 100 separate instances.

resource "aws_instance" "web" {
  count         = 100
  ami           = var.ami_id
  instance_type = "t3.micro"
  tags = {
    Name = format("web-%03d", count.index + 1)
  }
}

What they are checking: Whether you use count or for_each, naming functions and variables instead of copy and paste, and think of ASGs.

Elastic Load Balancing has four types: Application (ALB), Network (NLB), Gateway (GWLB) and the legacy Classic (CLB). ALB and NLB are the two you use most.

• Use ALB for web apps and microservices that need path-based routing, redirects, or authentication.
• Use NLB for non-HTTP protocols, extreme throughput, or when clients must whitelist fixed IPs.
• GWLB fronts third-party firewalls and inspection appliances.

What they are checking: Whether you can pick the right load balancer for a workload instead of reciting definitions

First find out what is using space, then prune what is unused.

docker system df            # usage by images, containers, volumes, cache
docker container prune      # stopped containers
docker image prune -a       # images not used by any container
docker builder prune        # build cache
docker volume prune         # unused volumes (check first, this deletes data)
docker system prune -a      # most of the above in one go

• Be careful with volumes: unused volumes can still hold database data.
• Large container logs are a common culprit. Set log rotation in /etc/docker/daemon.json ("log-driver": "json-file", "log-opts": {"max-size": "10m", "max-file": "3"}).
• Prevent a repeat with a scheduled prune, smaller images, and disk alerts.

What they are checking: Whether you can diagnose disk usage and clean up safely without deleting live data.

Write the matching resource block. Then import the real object into state. Terraform will then manage it and not try to create a copy.

• Classic way: terraform import aws_s3_bucket.logs my-existing-bucket.
• Modern way (Terraform 1.5+): an import block, which you can review in a plan. It can also write the config for you with terraform plan -generate-config-out=generated.tf.
• After importing, run plan and adjust the code until it shows no changes.
• The classic import does not write code for you, and it imports only one resource at a time.
• Use remote state with locking while doing this, so nobody changes the state at the same time.

import {
  to = aws_s3_bucket.logs
  id = "my-existing-bucket"
}
resource "aws_s3_bucket" "logs" {
  bucket = "my-existing-bucket"
}

What they are checking: Whether you can bring existing infrastructure under code safely, without rebuilding it.

Write the differences as data in a map. Then loop over it with for_each.

• Define a variable of type map(object({...})) with one entry per resource.
• for_each = var.buckets creates one resource for each key, and each.value holds the settings.
• For Lambda, use the same zip file, but give each function its own name, handler or environment from the map.
• For optional blocks like lifecycle rules, use dynamic blocks too.
• Put it in a module if many teams repeat the pattern.

variable "queues" {
  type = map(object({ visibility = number, fifo = bool }))
}
resource "aws_sqs_queue" "q" {
  for_each                   = var.queues
  name                       = each.value.fifo ? "${each.key}.fifo" : each.key
  fifo_queue                 = each.value.fifo
  visibility_timeout_seconds = each.value.visibility
}

What they are checking: Whether you write differences as data and use for_each instead of copying blocks.

An ALB receives web traffic (HTTP and HTTPS) on listeners and sends it to target groups based on rules. Each target group holds the real backends (EC2 instances, IPs, Lambda or ECS tasks) and runs health checks.

• Listener: port and protocol (80, 443). Rules match on host header, path, headers or query string.
• Rules: api.example.com goes to the API target group, /images/* goes to another, and the default action handles the rest. This is how one ALB serves several domains or services.
• Target group: only healthy targets get traffic. ECS services register their tasks automatically.
• DNS: the ALB gets an AWS DNS name. In Route 53, create an alias A record from your domain to that name. In other DNS providers, use a CNAME for names that are not the root domain.
• Security: put the ALB in public subnets and the backends in private subnets. Let the backend security groups accept traffic only from the ALB security group.

What they are checking: Whether you understand listener rules, target groups, health checks and how DNS points to the ALB

A security group is a stateful firewall on an instance or network interface. A network ACL is a stateless firewall on a subnet. Stateful means the firewall remembers connections.

Use security groups as the main control (for example, DB group allows 5432 only from the app group). Use NACLs as a rough extra layer, such as blocking a bad IP range. Remember that a NACL needs the temporary ports (1024-65535) open for return traffic.

What they are checking: Whether you know the difference between stateful and stateless, and where each is used

Answer with the services you have really used, grouped by purpose, and say what problem each solved. Do not list everything on the console.

Structure that works:

• Compute: EC2 for long-running servers, Lambda for event-driven jobs, ECS/Fargate for containers.
• Storage: S3 for objects and backups, EBS for instance disks, EFS for shared files.
• Network: VPC with public and private subnets, ALB, Route 53, CloudFront.
• Data: RDS or DynamoDB for application data.
• Security and ops: IAM for access, CloudWatch for logs, metrics and alarms, Secrets Manager or SSM Parameter Store.
• Delivery: CloudFormation or Terraform, CodePipeline or GitHub Actions.

Sample line: "I ran a web app on EC2 behind an ALB in private subnets. I stored uploads in S3 and watched it with CloudWatch alarms. I used IAM roles instead of keys for access." Be ready for follow-up questions on any service you name.

What they are checking: Whether your hands-on experience is real and you can explain why you chose each service

Use groups and standard permissions first, and ACLs when the simple owner/group/others model is not enough.

# group-based: team A writes, team B reads
groupadd teama; groupadd teamb
chown -R deploy:teama /srv/app
chmod -R 2775 /srv/app          # setgid keeps the group on new files
setfacl -R -m g:teamb:rX /srv/app          # B: read + traverse
setfacl -R -d -m g:teamb:rX /srv/app       # default ACL for new files

# single user, read-only
setfacl -m u:alice:rX /srv/data
getfacl /srv/data

Capital X gives execute only on directories. So the user can enter the folder and read files, but cannot change them. Without execute on the directory, the user could not enter it even with read permission. Mind the ACL mask and parent directory traverse rights.

What they are checking: Whether you know groups, setgid and ACLs for multi-team access

A public subnet has a route to an Internet Gateway (IGW). A private subnet has no direct route to the internet.

• Public subnet: route table has 0.0.0.0/0 -> igw-xxxx. Instances need a public or Elastic IP to be reachable. Used for load balancers, bastion hosts and NAT gateways.
• Private subnet: route table has no IGW route. Used for application servers and databases.
• Internet Gateway: a managed AWS part that scales by itself. It allows two-way internet traffic for resources with public IPs.
• NAT Gateway: lives in a public subnet. Private subnets route 0.0.0.0/0 -> nat-xxxx, so instances can start outbound connections (updates, API calls) but cannot be reached from the internet.

What makes a subnet public or private is its route table, not its name.

What they are checking: Whether you know that routing, not a name, decides the subnet type

A bastion host is a locked-down server in a public subnet. It is the only entry point for SSH into private instances.

• Bastion: the security group allows port 22 only from known IPs. Private instances allow port 22 only from the bastion's security group. Use SSH agent forwarding or ssh -J bastion private-host (ProxyJump). Never copy private keys onto it.
• AWS Systems Manager Session Manager: no open ports, no keys and no public IP. IAM controls access, and it is logged to CloudTrail or S3. It is often the best choice today.
• Site-to-site VPN or Direct Connect: connects your office or data center network to the VPC.
• Client VPN / Tailscale / WireGuard: gives engineers private network access without opening SSH to the internet.

If port 22 is blocked by a NACL or security group, fix the rule (and open the NACL's return ports) or switch to Session Manager.

What they are checking: Whether you prefer safe access with records over open SSH

DNS turns names that people can read, such as example.com, into IP addresses. It uses port 53, UDP for normal queries and TCP for large answers and zone transfers (copying DNS data between servers).

How a name is resolved: first the browser cache, then the OS resolver, then a recursive resolver. The recursive resolver asks the root servers, then the TLD (.com) servers, then the domain's own name server. It then keeps the answer in its cache for the TTL (the time the answer stays valid).

Check with dig example.com A +short.

What they are checking: Whether you understand how a name becomes an IP and know the basic record types

CIDR notation a.b.c.d/n means the first n bits are the network part. The other 32 - n bits are for hosts.

• /24 has 8 host bits: 256 addresses (10.0.1.0 - 10.0.1.255), 254 can be used in a classic network.
• /16 has 65,536 addresses, /28 has 16 addresses.
• Usable hosts = 2^(32-n) - 2 in a traditional network, so /28 gives 14. AWS reserves 5 addresses per subnet, so a /28 gives 11 usable in a VPC.
• Subnetting means splitting a big block into smaller ones. For example, split 10.0.0.0/16 into 10.0.0.0/24, 10.0.1.0/24 and so on. Usually you make one for each tier in each AZ.

Each extra bit in the prefix cuts the block size in half.

What they are checking: Whether you can do CIDR math quickly and know the AWS reserved addresses

Nginx and Apache are web servers. Nginx is event-driven and very good at static files, reverse proxying and load balancing. Apache uses processes and threads, and has rich .htaccess and module support.

The main config is /etc/nginx/nginx.conf, with sites in /etc/nginx/conf.d/ or sites-enabled/.

upstream app {
    server 10.0.1.10:3000;
    server 10.0.1.11:3000;
}
server {
    listen 80;
    server_name example.com;

    location /static/ { root /var/www; }          # static content

    location / {                                   # reverse proxy + LB
        proxy_pass http://app;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Test with nginx -t and apply with systemctl reload nginx. For HTTPS add listen 443 ssl; with ssl_certificate and ssl_certificate_key (Let's Encrypt via certbot).

What they are checking: Whether you have really set up Nginx and know how its config is organized

Sample answer:

"A developer creates a feature branch from main and opens a pull request. The PR starts CI: install with cache, lint, unit tests, security scans, and a build that makes a Docker image. The image is tagged with the commit SHA and pushed to [registry]. Reviewers approve, and branch protection requires that all checks pass.

When the PR is merged to main, the pipeline deploys the same image to dev automatically and runs smoke tests (quick basic checks). Then it moves to staging for integration tests and QA. Production needs a manual approval. It then rolls out with [rolling/canary] and is watched with [monitoring]. It rolls back automatically if health checks fail.

Config for each environment comes from Helm values or a parameter store. Secrets come from [secrets manager]. Infrastructure changes follow a separate Terraform pipeline. We use version tags for releases and keep a changelog."

Change the tools to match your real experience, but keep the flow: branch, PR, CI, artifact, promote, approve, deploy, verify.

What they are checking: Whether you can explain the whole flow with approval steps, moving one artifact up the environments, and rollback.

DevOps is a culture and a set of practices that bring development and operations together. Software is delivered faster and more reliably, and everyone shares ownership. The main principles are:

• Collaboration and shared ownership: developers and operations work as one team. Both care about running the service, not only writing or deploying code.
• Automation: build, test, infrastructure setup and deployment are scripted. So they can be repeated and do not depend on one person.
• Continuous integration and delivery: merge small changes often, test each one automatically, and keep the main branch ready to release.
• Infrastructure as code: servers and networks are defined in files kept in version control (Terraform, CloudFormation) and reviewed like application code.
• Monitoring and fast feedback: metrics, logs and alerts show how a release behaves, so problems are found and fixed fast.
• Continuous improvement: reviews after incidents that blame no one, and small, frequent changes, lower the risk over time.

In an interview, link each principle to something you did. For example "I automated deploys with GitHub Actions and Terraform, so releases stopped depending on manual steps".

What they are checking: Whether you understand DevOps as culture plus automation, not only a list of tools

Name what you have used. Show that you know the matching services in other clouds.

Sample answer: "I have the most hands-on experience with AWS ([your services]). I have used [GCP/Azure services] for [your project]. The ideas (networks, IAM, compute, storage) carry over. So I can learn the rest quickly from documentation and infrastructure as code." Be honest, and give a real project.

What they are checking: Whether you are honest about experience and understand the common concepts across clouds.

Group your answer by service area and say what you personally did.

Sample answer: "I have worked with AWS for [X] years. For compute I have run [EC2, ECS or EKS] workloads with autoscaling. For networking I designed VPCs with public and private subnets, NAT, security groups and Route 53. For storage and data I used S3, RDS and DynamoDB, with lifecycle rules and backups. For security I managed IAM roles and policies with least privilege, SSO and KMS. Everything is defined in Terraform, and deployed through CI/CD. For observability I set up CloudWatch metrics, alarms and logs. My own responsibilities are [for example on-call, cost reviews, building new environments]. One example: [project], where I [result]."

Prepare one deep story per area, because follow-up questions will test the details of what you claim.

What they are checking: Whether your depth matches your CV and you can back claims with examples.

Keep the bucket private and put CloudFront in front of it. Use Origin Access Control (OAC) so only CloudFront can read the objects.

Steps:

• Create the bucket with Block Public Access on. Do not turn on S3 static website hosting, since that endpoint is public only.
• Create a CloudFront distribution with the bucket as origin and attach an OAC.
• Add a bucket policy that allows cloudfront.amazonaws.com to s3:GetObject, and limit it with AWS:SourceArn to your distribution.
• Attach an ACM certificate (issued in us-east-1) and redirect HTTP to HTTPS.
• Point Route 53 at the distribution with an alias record.
• You can also add AWS WAF and security headers (through a response headers policy). Use CloudFront signed URLs or cookies for private content.

If one site has public and private content, serve public paths openly. Protect the private path pattern with a trusted key group, so only signed requests work.

Deploy with aws s3 sync ./dist s3://my-site-bucket --delete and invalidate the cache with aws cloudfront create-invalidation --distribution-id <id> --paths "/*".

What they are checking: Whether you know the private bucket plus OAC pattern rather than a public bucket

The load balancer spreads requests across healthy instances. The Auto Scaling Group (ASG) changes how many instances run, based on metrics.

Flow when the system slows:

• Load rises, a CloudWatch metric such as average CPU or RequestCountPerTarget crosses the target.
• A scaling policy (target tracking or step) raises desired capacity.
• The ASG launches instances from the launch template in several AZs.
• Once an instance passes the target group health check, the ALB starts sending it traffic.
• When load falls, the ASG scales in; connection draining (deregistration delay) lets in-flight requests finish.

Points interviewers like:

• Turn on ELB health checks on the ASG, so unhealthy instances are replaced. EC2 status checks alone are not enough.
• Set a health check grace period longer than app start time.
• Keep instances stateless (sessions in Redis or DynamoDB, files in S3 or EFS).
• If the database is the bottleneck, scaling the web tier will not help; use read replicas, caching or connection pooling.

What they are checking: Whether you understand the scale-out loop end to end, including health checks and statelessness

docker pull nginx:1.27                       # download the image
docker run -d --name web -p 8080:80 nginx:1.27   # run detached, map host 8080 to container 80
docker ps                                    # running containers (-a for all)
docker exec -it web sh                       # shell inside the running container
docker logs -f web                           # follow logs
docker stop web && docker start web          # stop and restart (start runs detached by default)
docker rm -f web                             # remove

• -d runs in the background, -it gives an interactive terminal.
• docker start brings back a stopped container in the background. Add -a to attach.
• Use bash instead of sh if the image includes it.

What they are checking: Whether you have hands-on daily Docker command fluency.

Docker Compose describes all the services, networks and volumes of an app in one compose.yaml. It starts them together.

services:
  web:
    build: .
    ports:
      - "8000:8000"
    environment:
      DATABASE_URL: postgres://app:secret@db:5432/app
    depends_on:
      - db
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

docker compose up -d --build
docker compose logs -f web
docker compose down

Compose puts services on a shared network, so web reaches the database simply as db. It is ideal for local development and small single-host setups; use Kubernetes for production scale.

What they are checking: Whether you can model a multi-service stack and understand service discovery by name.

-p HOST_PORT:CONTAINER_PORT publishes a container port on the host. Traffic to the host port is forwarded to the container.

docker run -d -p 8080:80 nginx          # host 8080 -> container 80
docker run -d -p 127.0.0.1:5432:5432 postgres   # only reachable locally
docker run -d -P nginx                  # publish all EXPOSEd ports on random host ports

For several services on one host, give each a different host port (-p 8081:3000, -p 8082:3000). The container ports can be the same because each container has its own network namespace. In Compose use ports: ["8081:3000"].

For many sites on the standard ports 80 and 443, put a reverse proxy (nginx, Traefik) in front. Route by hostname instead of opening many ports.

What they are checking: Whether you understand host versus container ports and a sane way to host several services.

Use a full Node image to install and build. Then use a slim or distroless image to run only the production output.

FROM node:22 AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci

FROM deps AS build
COPY . .
RUN npm run build && npm prune --omit=dev

FROM gcr.io/distroless/nodejs22-debian12
WORKDIR /app
ENV NODE_ENV=production
COPY --from=build /app/dist ./dist
COPY --from=build /app/node_modules ./node_modules
USER nonroot
EXPOSE 3000
CMD ["dist/server.js"]

• Build stage: node:22 (or -slim) has npm and build tooling.
• Runtime stage: node:22-alpine or distroless for a small, low-attack-surface image.
• The package files are copied first so npm ci stays cached.
• For Next.js, enable output: "standalone" and copy .next/standalone and .next/static.
• Add a .dockerignore for node_modules and .git.

What they are checking: Whether you can write a production-grade Dockerfile with caching, small runtime and non-root user.

Helm is the package manager for Kubernetes. A chart is a versioned bundle of template manifests plus default settings. A release is one installed copy of a chart.

A chart contains Chart.yaml (metadata), values.yaml (defaults), and templates/ (Go-templated YAML). You override values per environment with -f values-prod.yaml or --set.

helm install web ./web -f values-prod.yaml -n prod
helm upgrade web ./web -f values-prod.yaml -n prod
helm rollback web 1 -n prod
helm list -n prod

Why it helps: one template works for dev, staging and prod. Releases have versions, history and rollback. You can install third-party software with one command.

What they are checking: Whether you have used Helm for templates and releases.