DevOps interview questions for freshers

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

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

Configure an S3 event notification on the bucket that targets the Lambda function. Two permissions must exist: S3 must be allowed to invoke the function, and the function must be allowed to read the bucket.

Steps:

• Add a resource-based policy on the function so s3.amazonaws.com can call lambda:InvokeFunction. Set SourceArn to the bucket ARN and SourceAccount to your account ID. This stops the confused deputy problem (another account tricking S3 into calling your function).
• In the bucket, add an event notification that points to the function (for example s3:ObjectCreated:*, with optional prefix and suffix filters).
• Give the function's execution role s3:GetObject on the bucket, plus the basic logging permissions.

aws lambda add-permission --function-name my-fn --statement-id s3-invoke \
  --action lambda:InvokeFunction --principal s3.amazonaws.com \
  --source-arn arn:aws:s3:::my-bucket --source-account 123456789012

Do not write output back to the same prefix that triggers the function, or it will loop. For size, start with 256 to 512 MB and check real use in CloudWatch. Then tune the memory, because CPU grows with it.

What they are checking: Whether you know both sides of the permission: S3 invoking Lambda and Lambda reading S3

Lambda runs code in response to events without managing servers, and you pay only for execution time. Use it for event-driven, short, spiky workloads; use EC2 for long-running or highly customized ones.

Key limits:

• Maximum run time: 15 minutes.
• Memory: 128 MB to 10,240 MB, with CPU scaling with memory.
• Package size: 50 MB zipped, 250 MB unzipped; container images up to 10 GB.
• Temporary storage /tmp: 512 MB by default, up to 10 GB.
• Concurrency: default 1,000 per region (can be increased).
• Cold starts add latency on first invocations.

Triggers: API Gateway, S3, SQS, SNS, EventBridge schedules, DynamoDB Streams, Kinesis and more.

Choose Lambda for APIs, file processing, cron jobs and glue logic. Choose EC2 (or containers) for constant heavy load, long jobs, special software or GPUs. Per-hour pricing is cheaper there.

What they are checking: Whether you know the main limits and can choose serverless versus servers sensibly

Use Amazon EFS. It is a managed NFS file system that many Linux EC2 instances can mount at the same time, across Availability Zones.

• EBS volumes attach to one instance at a time in one AZ (io2 Multi-Attach is a small exception). So they are not for sharing.
• EFS grows and shrinks automatically, and you mount it with the NFS client or the amazon-efs-utils helper.
• For Windows servers use Amazon FSx for Windows File Server.
• For objects shared through an API instead of a mounted path, use S3.

sudo mount -t efs -o tls fs-0123456789abcdef0:/ /mnt/shared

Control access with security groups on the mount targets (allow TCP 2049) and IAM or POSIX permissions.

What they are checking: Whether you can tell block, file and object storage apart

Pick the simplest service that meets the need, and add pieces only as complexity grows.

Simple static site:

• Files in S3, served through CloudFront, DNS in Route 53, HTTPS from ACM. No servers to manage and very cheap.

Simple dynamic site:

• One EC2 instance (or Elastic Beanstalk / Lightsail) with a security group, an Elastic IP, and backups.

Complex application:

• VPC with public and private subnets across two AZs.
• ALB in public subnets, application on EC2 Auto Scaling or ECS/Fargate in private subnets.
• RDS or DynamoDB for data, ElastiCache for caching, S3 for uploads.
• CloudWatch for monitoring, IAM roles, Secrets Manager, and CI/CD with CodePipeline or GitHub Actions.
• Infrastructure defined in Terraform or CloudFormation.

You pay for it in cost and work, and you gain availability, scale and security.

What they are checking: Whether you scale the architecture to the problem rather than over-engineering

Use S3 as the landing zone. Send an event to SQS for each new file, and let Lambda process the queue.

SQS has two queue types: Standard and FIFO.

An IAM user is a long-term identity for one person or application, with a password and/or access keys. An IAM role is an identity with no long-term credentials that anyone allowed can assume to get temporary credentials. A trust policy is the resource policy on a role that says who may assume it.

EC2 instance types are grouped into families by the resource they favour. The name encodes it, for example m7g.large: family m, generation 7, g = Graviton, size large.

EC2 has four main ways to pay, and a good setup mixes them.

S3 classes trade storage price against retrieval cost, speed and minimum storage time. All of them offer 11 nines of durability.

CloudWatch is AWS's monitoring service. It collects metrics, stores logs, raises alarms and drives dashboards.

Choose RDS when the data is relational and needs joins, transactions and SQL. Choose DynamoDB when you need huge scale with simple key-based access and little operations work.

SQS is a queue where consumers pull messages, and SNS is a topic that pushes each message to all its subscribers.

EC2 (Elastic Compute Cloud) provides resizable virtual servers. You choose an AMI, an instance type, storage, a VPC subnet and a security group. You pay for what you run.

Identity-based policies attach to an IAM user, group or role and say what that identity can do. Resource-based policies attach to a resource (S3 bucket, SQS queue, KMS key, Lambda function, role trust policy). They say who can access that resource.

An Amazon Machine Image (AMI) is a template used to launch EC2 instances. It contains the root volume snapshot (operating system, installed software, configuration), launch permissions, and block device mappings.

User data is a script or cloud-init setting passed to an instance when it starts. It sets up the instance automatically, for example installing packages, pulling code, or joining a cluster.

An EBS snapshot is a point-in-time, incremental backup of an EBS volume stored in S3-managed storage. After the first full copy, only changed blocks are saved. A snapshot can create a new volume in any AZ of the region.

An S3 bucket policy is a JSON resource-based policy attached to a bucket. It controls who can do what on the bucket and its objects.

Elements: Effect, Principal, Action, Resource (bucket ARN and bucket/* for objects), and optional Condition.

In Route 53 you create a hosted zone for your domain. Then you add records that map names to resources.

Use S3 Object Lock, which enforces write-once-read-many (WORM) retention. It needs versioning, and it is best turned on when you create the bucket.

Vertical scaling (scale up) means giving one server more resources, such as a bigger EC2 instance type. Horizontal scaling (scale out) means adding more servers and spreading the load across them.

Elastic Beanstalk is a platform-as-a-service on AWS: you upload your application code (Java, .NET, Node.js, Python, PHP, Ruby, Go, or Docker). It sets up and manages the infrastructure for you.

CloudFront is AWS's content delivery network (CDN). It caches content at edge locations close to users. Responses are faster, and the origin has less load.

A routing policy decides which answer Route 53 returns for a name.

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 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

SSH key authentication uses a key pair: the private key stays with the user and the public key is placed on the server. The user proves they own the key without sending the private key.

1. Client connects and the server verifies its host key (known_hosts).
2. Client says it wants to use a public key. The server checks ~/.ssh/authorized_keys.
3. The server sends a challenge; the client signs it with the private key.
4. The server verifies the signature with the public key and allows login.

ssh-keygen -t ed25519
ssh-copy-id user@server
ssh -i ~/.ssh/id_ed25519 user@server

Private key permissions must be 600. Disable password login (PasswordAuthentication no in /etc/ssh/sshd_config) for better security.

What they are checking: Whether you understand asymmetric keys in practice

A private instance has no public IP. So you connect through a bastion/jump host, a VPN, or AWS Systems Manager.

# via bastion with ProxyJump
ssh -J ec2-user@<bastion-public-ip> [email protected]

# via SSM, no open port 22 needed
aws ssm start-session --target i-0123456789abcdef0

• The private instance's security group allows port 22 only from the bastion's security group (or VPN range).
• To log in, you need the key pair used at launch (-i key.pem, permission 400) or a user added with your own public key.
• With SSM the instance needs the SSM agent and an IAM role with AmazonSSMManagedInstanceCore.

What they are checking: Whether you know the secure ways into private servers

First find the PID. Then send SIGTERM so the process can clean up. Use SIGKILL only if it does not stop.

pgrep -a nginx            # find by name
sudo ss -tulpn | grep :8080   # find by port
sudo lsof -i :8080
kill <PID>                # SIGTERM (15), graceful
kill -9 <PID>             # SIGKILL (9), forced, no cleanup
pkill -f myapp            # by name pattern

For services managed by systemd prefer systemctl stop <service>, otherwise it may restart automatically. A process stuck in state D (uninterruptible I/O) may not die even with -9.

What they are checking: Whether you know graceful versus forced termination

A DevOps engineer should be comfortable with the shell, files, users, processes, networking and services.

ls, cd, pwd, cp, mv, rm, mkdir, cat, less, tail -f   # files
grep, find, sed, awk, cut, sort, uniq                # text search and processing
chmod, chown, sudo, useradd                           # permissions and users
ps, top, kill, systemctl, journalctl                  # processes and services
df, du, free, lsblk                                   # resources
ip a, ss -tulpn, curl, ping, dig                      # networking
ssh, scp, rsync, tar                                  # remote and archives
apt / yum                                             # packages (Ubuntu / RHEL)

Also know the filesystem layout (/etc config, /var/log logs, /home, /tmp). Know how to edit files with vim or nano. Know basic bash scripting with variables, loops and conditions.

What they are checking: Whether you have a working command-line foundation

SSH uses TCP port 22 and encrypts all traffic. Telnet (port 23) sends everything, including passwords, as plain text.

Structure for the answer: level, 2 or 3 concrete examples, impact, and how you keep scripts safe.

A hard link is another name for the same inode. A soft link is a small file that stores the path to another file.

Use grep for text, find for files, and awk or sed for transforming lines.

Pipes send the output of one command into the next command. Redirection sends a stream to or from a file.

Every process has three streams: stdin (0), stdout (1) and stderr (2).

A crontab line has five time fields followed by the command: minute, hour, day of month, month, day of week.

systemd is the init system (PID 1) on most modern Linux distributions. It starts services, manages dependencies and collects logs.

Traditional logs are text files under /var/log, and systemd services also log to the journal.

Work from the bottom up: interface, route, DNS, then the port.

Write a script that dumps the database, compresses it, uploads it, and removes old copies. Then schedule it with cron.

A daemon is a background process that starts at boot (or on demand). It gives a service without a user screen, such as sshd, nginx or cron. Their names often end in d.

Batch (.bat / .cmd) runs in the Windows command prompt. Bash runs on Linux and macOS (and on Windows through WSL or Git Bash).

A zombie is a process that has finished running. It still has an entry in the process table because its parent has not read its exit status.

chmod changes who can read, write or execute. chown changes the owner and group. umask sets the default permissions for new files.

Ubuntu and Debian use apt, RHEL, CentOS, Rocky and Amazon Linux use dnf (or yum).

Everything hangs off a single root /, and each top-level directory has a conventional purpose.

su switches to another user with that user's password. sudo runs a single command with extra rights, using your own password and a policy.

Environment variables are named values that a process gets from its parent. PATH is the list of directories searched when you type a command.

top shows live processes. The three load average numbers are the average count of running plus waiting tasks over the last 1, 5 and 15 minutes.

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.

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.

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.

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.

A Dockerfile is read top to bottom, and each instruction adds a layer or metadata.

• FROM picks the base image.
• WORKDIR sets the working directory for the later instructions.
• COPY copies files from the build context into the image.
• RUN executes a command at build time (install packages, build code).
• EXPOSE documents the port the app listens on. It does not publish it.
• CMD is the default command at container start.

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "app.py"]

What they are checking: Whether you can read and write a basic Dockerfile and know each step's purpose.

ENTRYPOINT defines the program that always runs. CMD supplies default arguments to it. When both exist in exec form, the container runs ENTRYPOINT + CMD.

• Arguments after the image name in docker run replace CMD but are appended to ENTRYPOINT.
• To replace ENTRYPOINT itself, use docker run --entrypoint.

A network driver decides how containers connect to each other and the outside world.

Docker is a platform that packs an application and its dependencies into a container image. The image runs the same way on any host with a container runtime. Containers share the host kernel. So they start in seconds and use much less memory than virtual machines.

Write a Dockerfile that installs dependencies and sets the start command.

Work from outside in.

An image is a read-only template made of layers. A container is a running (or stopped) copy of that image, with a thin writable layer on top.

Use COPY for plain file copying; ADD does the same plus two extras that are usually unwanted.

Each instruction creates a layer. Docker reuses a cached layer when the instruction and its inputs have not changed. Once one layer changes, every layer after it is rebuilt.

So put things that change rarely first and things that change often last. The classic case is dependencies before source code:

All three give a container storage outside its writable layer. They differ in who manages it and where it lives.

Log in, tag the image with the registry path, then push.

ARG is a build-time variable; ENV is set in the image and is available at runtime too.

On a user-defined bridge network, containers find each other by container name or service name. Docker's built-in DNS does this.

• Virtual environment (venv): isolates only Python packages inside one machine. It does not isolate the OS, system libraries, processes or network.
• Container: isolates a whole process tree, filesystem and network using kernel namespaces and cgroups, but shares the host kernel. Light and fast, and it packages system libraries too.
• Virtual machine: a full guest operating system with its own kernel on a hypervisor. Strongest isolation, but heavier and slower to start.

Container filesystems are temporary, so data must live in a volume outside the container layer.

A .dockerignore file lists paths that Docker must leave out of the build context. It works like .gitignore does for git.

Use docker logs for output and docker stats for live resource usage.

stop shuts a container down gracefully, kill stops it immediately, and rm deletes a stopped container.

Use both: pull the right pods to the nodes, and push other pods away.

• nodeSelector: the simplest way. It matches a node label.
• Node affinity: more detailed rules (required or preferred).
• Taints and tolerations: taint the GPU nodes so only pods that tolerate the taint can run there.
• Resource requests: nvidia.com/gpu: 1 (needs the NVIDIA device plugin) makes sure the pod runs on a GPU node.

spec:
  nodeSelector:
    node-type: gpu
  tolerations:
    - key: "nvidia.com/gpu"
      operator: "Exists"
      effect: "NoSchedule"
  containers:
    - name: train
      image: trainer:1.0
      resources:
        limits:
          nvidia.com/gpu: 1

kubectl taint nodes gpu-1 nvidia.com/gpu=true:NoSchedule

The taint keeps normal apps off the costly nodes. The selector or GPU request sends GPU jobs to them.

What they are checking: Whether you know selectors, affinity and taints, and when to use each.

A Service gives pods a stable virtual IP and DNS name and load balances across them.

• ClusterIP (default): reachable only inside the cluster.
• NodePort: opens a port (30000-32767) on every node. Mostly for testing.
• LoadBalancer: asks the cloud to create an external load balancer (an NLB or CLB on AWS) pointing at the service.
• ExternalName: a DNS alias to an outside name.

Ingress is a web traffic routing layer on top. One ingress controller serves many services by host and path. It can be NGINX, or the AWS Load Balancer Controller that creates an ALB. It also handles TLS, and you do not pay for one load balancer per service.

rules:
  - host: api.example.com
    http:
      paths:
        - path: /
          pathType: Prefix
          backend:
            service: {name: api, port: {number: 80}}

What they are checking: Whether you know how traffic gets into a cluster and why Ingress saves load balancers.

A Pod is the smallest deployable unit in Kubernetes: one or more closely linked containers. They share one network (one IP), the same storage volumes and the same lifecycle.

• A container is a single packaged process. A Pod wraps one or more containers and is what the scheduler places on a node.
• Containers in a Pod talk to each other over localhost and can share volumes.
• Most Pods hold one main container; extra containers are helpers (sidecars, init containers).
• Pods are short-lived. If one dies, a new Pod with a new IP replaces it. This is why you use Deployments and Services instead of running bare Pods.

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

What they are checking: Whether you understand the main building block of Kubernetes.

A cluster has a control plane that decides what should run, and worker nodes that run the Pods.

Control plane

• kube-apiserver: the front door. All components and kubectl talk to it.
• etcd: a key-value store that holds the cluster state.
• kube-scheduler: picks a node for each unscheduled Pod.
• kube-controller-manager: runs controllers that move actual state toward desired state (ReplicaSet, Node, Job and others).
• cloud-controller-manager: connects Kubernetes to the cloud (load balancers, nodes, routes).

Worker node

• kubelet: makes sure the containers of assigned Pods are running and healthy.
• kube-proxy: programs Service networking rules.
• Container runtime: containerd or CRI-O.

In managed services (EKS, GKE, AKS) the provider runs and upgrades the control plane for you.

What they are checking: Whether you can describe how a request flows through the cluster.

A Deployment manages ReplicaSets, and a ReplicaSet manages Pods.

The main commands are get, describe, logs, exec, apply and delete.

Create a ConfigMap with non-sensitive settings, then inject it as environment variables or as files in a volume.

Probes let the kubelet check if a container is healthy.

Requests are what the scheduler reserves for a container; limits are the maximum it may use.

They keep apart how storage is made and how Pods ask for it.

A Service gives a stable IP and DNS name to a group of Pods that keeps changing. It shares traffic across the ready ones.

CrashLoopBackOff means the container keeps starting, crashing and restarting, with longer waits each time. Find out why the process exits.

Pending means the Pod was accepted but not placed on a node yet (or its volumes or image are not ready). kubectl describe pod and its Events tell you which.

The kubelet cannot download the image. Read the exact message in the Pod events.

Never bake secrets into images or commit them to Git.

Docker

• docker run -e KEY=value or --env-file .env; in Compose use environment: or env_file:.
• For build-time secrets use BuildKit: RUN --mount=type=secret,id=npmrc ....

Scale at two levels: pods and nodes.

Prefer one central Argo CD (in a management cluster) that deploys to many clusters. Do not run one Argo CD per cluster.

EKS runs the control plane for you, but you still manage much of the rest.

Namespaces split one cluster into smaller virtual clusters. Teams or environments can share it without name clashes.

Labels are key-value tags on objects. Selectors find objects by those labels.

A Job runs Pods until they finish a one-time task. A CronJob creates Jobs on a schedule.

Managed services run the control plane for you. kubeadm and Minikube are for clusters you run yourself or on your laptop.

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.

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.

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.

Both create many copies of a resource or module, but they track the copies differently.

Use count for identical copies or a simple on and off switch (count = var.enabled ? 1 : 0). Use for_each when items have different settings or fixed names. This is most real cases.

resource "aws_s3_bucket" "b" {
  for_each = toset(["logs", "backups", "assets"])
  bucket   = "acme-${each.key}"
}

What they are checking: Whether you know the problem with count, where numbers shift, and prefer for_each for fixed keys.

The main commands are init, plan, apply and destroy.

Use the kreuzwerker/docker provider, which talks to the Docker daemon. You write images and containers as resources, and Terraform manages them with the usual steps.

Infrastructure as Code (IaC) means you describe servers, networks and databases in text files. The files have versions, are reviewed, and a tool applies them. You do not click in a console.

A provider is a plugin that lets Terraform talk to an API such as AWS, Azure, Kubernetes or GitHub. It defines the resource types and data sources you can use.

You list the providers you need and their version rules. Then terraform init downloads them from the registry into the .terraform folder.

They are the main steps, run in this order:

A module is a folder of Terraform files that you use as one reusable unit. Every configuration is already a module (the root module). Other modules are called from it.

Use modules to avoid copy and paste. They also enforce rules (for example, every S3 bucket is encrypted). They hide complex parts behind a few inputs.

A backend decides where Terraform stores its state and how operations run. The default is a local file. Teams use a remote backend such as S3, so the state is shared, safe to keep and can be locked.

A data source reads information about something that already exists. A resource creates and manages something. Terraform never changes or destroys what a data source reads.

They are three kinds of named values:

The lock file records the exact provider versions and checksums that terraform init picked. Yes, commit it to Git.

terraform fmt rewrites files into the standard style (indentation, alignment). terraform validate checks that the config is written correctly and fits together (types, references). It does not contact any cloud API.

A .tfvars file holds values for input variables. The same code can then run with different settings for each environment, for example prod.tfvars.

Idempotent means running the same operation again and again gives the same result. If you run terraform apply a second time with no code changes, Terraform sees that the real infrastructure already matches the config. It reports "No changes".

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

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

A NAT Gateway lets instances in private subnets start connections to the internet. It blocks connections that start from outside.

• It sits in a public subnet with an Elastic IP. Private route tables send 0.0.0.0/0 to it.
• An outside site sees the NAT Gateway's Elastic IP as the source, not the instance's private IP. This helps when a partner needs to allow one fixed IP.
• Traffic from an instance to RDS stays inside the VPC on private IPs and does not use NAT.
• A normal auto-assigned public IP is released when the instance is stopped, and a new one is given when it starts. An Elastic IP stays with you until you release it.
• For high availability, create one NAT Gateway in each AZ.

What they are checking: Whether you know how NAT works and the difference between auto-assigned IPs and Elastic IPs

The simplest options are to go through S3, or to connect the VPCs and use scp or rsync over private IPs.

• S3 as a middle step: the source instance runs aws s3 cp file s3://bucket/ and the destination downloads it. Both use IAM roles and a gateway endpoint, so no internet or keys are needed. Best for one-time or large transfers.
• VPC peering (or Transit Gateway): add routes in both directions, and allow port 22 in the destination security group from the source. Then:

scp -i key.pem /data/file.tar.gz [email protected]:/tmp/
rsync -avz /data/ [email protected]:/data/

• Via a bastion: scp -J bastion ... when no direct path exists.
• SSM: use Session Manager port forwarding if SSH is not allowed.

The CIDR ranges of the two VPCs must not overlap for peering.

What they are checking: Whether you can pick a safe transfer path without exposing servers

VPC peering is a private network link between two VPCs. A VPC endpoint is a private path from your VPC to an AWS service, without using the internet.

• Peering: traffic flows over the AWS backbone using private IPs. CIDR ranges must not overlap. It is non-transitive: if A is linked to B and B is linked to C, A is not linked to C. You must add routes and allow the traffic in security groups. It works across accounts and regions.
• Gateway endpoints: free, only for S3 and DynamoDB. You add them as a route in the route table.
• Interface endpoints (PrivateLink): a network interface with a private IP in your subnet, for services like SQS, ECR, Secrets Manager or your own service. They cost money for each hour and each GB.
• Endpoints let private subnets reach AWS services without a NAT Gateway.

What they are checking: Whether you know how to connect VPCs and reach AWS services in private

A three-tier design puts the web, application and data layers into different subnets across at least two Availability Zones.

Pick ranges that are big enough and private (RFC 1918). They must not overlap with other VPCs, office networks or future peers.

An IP address is a number that identifies a network interface (IPv4 is 32 bits, IPv6 is 128 bits). On Linux, packet filtering and NAT are done with iptables or nftables (netfilter).

A security group has allow rules only. Each rule has a protocol, a port range, and a source (inbound) or destination (outbound). It is stateful.

The TCP/IP model has four layers (Link, Internet, Transport, Application). It squeezes the seven OSI layers into them. OSI is used for teaching. TCP/IP is what the internet really runs.

The browser asks a recursive resolver. The resolver goes through the DNS levels until it finds the IP, then saves the answer in its cache.

HTTPS is HTTP inside a TLS-encrypted connection. The traffic is encrypted, the server is proven to be real, and nobody can change the data on the way. HTTP uses port 80, HTTPS port 443.

Subnetting takes host bits to make smaller networks. For /26 there are 26 network bits and 6 host bits.

NAT (Network Address Translation) changes IP addresses in packets as they cross a router or firewall. Private hosts can then reach the internet through a public address.

A VLAN is a virtual Layer 2 network made inside one physical switch. Devices in different VLANs cannot talk to each other directly, even if they are plugged into the same switch.

Use them in layers, from basic reachability up to the application.

Run the ETL job inside the VPC (or connected to it), so it can reach the private database. Send the data to the warehouse over a secure channel.

The usual default ports are:

TCP sets up a connection first and is reliable. UDP has no connection and is fast, but it does not promise delivery.

The three-way handshake is how TCP sets up a reliable connection before it sends data.

DHCP gives hosts an IP address, subnet mask, default gateway and DNS servers automatically. Nobody has to set them by hand.

Split the network into zones by trust level. Let a firewall control all traffic between the zones, and deny everything by default.

You point the domain's nameservers to Cloudflare. You create DNS records with the proxy (orange cloud) turned on. Then you secure the link from Cloudflare to the origin.

The OSI model has seven layers, from bottom to top:

Firewalls filter traffic by rules. They differ in how much of the traffic they understand.

A forward proxy sits in front of clients and talks to the internet for them. A reverse proxy sits in front of servers and talks to clients for them.

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.

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

Pick the tool that fits where your code lives and how much you want to maintain.

• GitHub Actions: no server to run, works closely with GitHub, a big marketplace, and OIDC to clouds. The best default if your code is on GitHub.
• Jenkins: very flexible, with many plugins and full control. But you maintain the controller, agents, plugins and upgrades.
• GitLab CI: very good if you use GitLab. It has a built-in registry and scanning.
• AWS CodePipeline/CodeBuild: good for teams that use only AWS, with access through IAM.

Triggers: a push to a branch, a pull request, a tag push (releases), a schedule (cron), a manual start, or a webhook from another system.

I usually pick GitHub Actions because it needs less maintenance. I use Jenkins only when we need custom, on-premises or old integrations. Self-hosted runners help with private networks or heavy builds.

What they are checking: Whether you can explain a tool choice by maintenance, integration and cost.

GitOps means Git is the one source of truth for the state you want. An automatic agent keeps making the live system match Git.

Argo CD is a Kubernetes controller that does this:

• You point an Application at a Git repo path (plain YAML, Helm or Kustomize) and a target cluster and namespace.
• It compares live state to Git and reports Synced or OutOfSync.
• With auto-sync it applies changes. With selfHeal it undoes manual changes.
• Rollback is a Git revert. Every change has a record in commits and reviews.

Flow: CI builds and pushes an image, then updates the image tag in the manifest repo. Argo CD sees the commit and deploys. Benefits: no cluster credentials in CI, easy rollback, drift fixing, and a clear history. Databases are usually better as managed services or run by operators. GitOps then manages the operator and its custom resources.

What they are checking: Whether you understand the pull model, drift fixing and how CI passes the work to Argo CD.

• Continuous integration (CI): developers often merge small changes to a shared branch. Each merge builds and tests the code automatically, to find problems early.
• Continuous delivery (CD): every change that passes the pipeline is built into an artifact that is ready to release. It is deployed to a staging-like environment. But releasing to production needs a manual approval.
• Continuous deployment: the same as delivery, except that production releases happen automatically when all checks pass. No person has to approve.

In short: CI means merge and test automatically. Delivery means always ready to release, and a person presses the button. Deployment means there is no button. Choose deployment when tests are strong and the service is low risk. Choose delivery when rules or business timing need an approval.

What they are checking: Whether you can explain the three terms clearly, especially the manual approval in delivery.

GitOps means Git is the one source of truth for the state you want. An agent in the cluster keeps making the cluster match Git. Changes happen through pull requests. This gives you review, a history of changes, and an easy rollback by reverting a commit.

Argo CD is a common GitOps controller. It watches a repo path (plain YAML, Helm or Kustomize), compares it with the live cluster and syncs the differences. It can also auto-sync and self-heal.

For blue/green or canary releases, Argo Rollouts adds a Rollout resource. It runs the new version beside the old one and moves traffic, or switches the service. It can stop and roll back if the analysis fails.

My flow: CI builds and pushes the image and updates the image tag in the config repo. Then Argo CD deploys it.

What they are checking: Whether you understand pull-based deployment and can explain how Argo CD works in real life.

GitHub Actions pipelines are YAML workflows stored in .github/workflows/. A workflow has triggers (on), jobs and steps. Jobs run on GitHub-hosted or self-hosted runners.

Without CI/CD (manual): build and push the image, SSH to the server, then docker pull and docker run.

Jenkins is an open-source automation server for CI/CD. A controller schedules jobs, and agents run them.

GitHub Actions is the CI/CD system built into GitHub. These are its main terms:

A Jenkinsfile is a text file in the repository that defines a Jenkins pipeline as code. So the pipeline has versions and is reviewed like application code.

The controller (formerly master) runs the web page, the configuration, job scheduling and plugin management. Agents (nodes) are the machines where builds really run.

An artifact is the result of a build that you deploy or keep: a Docker image, JAR, wheel, npm package, zip, or test report.

Secrets (tokens, passwords, cloud keys) must never be in the repository or in plain pipeline files.

Blue-green keeps two identical production environments. Blue serves live traffic. You deploy the new version to green and test it. Then you switch the router (load balancer, DNS or Kubernetes Service selector) to green. Blue stays idle, ready for an instant rollback.

A canary release sends the new version to a small share of users (for example 5 percent) and watches it. If it is healthy, it slowly sends more traffic. The name comes from the canary bird that miners used to warn of danger.

Use Docker's official actions to log in, build and push. For AWS ECR, log in with OIDC to an IAM role. Do not store access keys.

Give each service its own Dockerfile and pipeline job. Start a job only when its files change.

They change at different speeds, carry different risks and need different permissions. So keep them apart.

Run fast tests first and slow ones later, as in the test pyramid:

In push-based deployment, the CI system runs commands that push the new version into the environment (kubectl apply, helm upgrade, ssh). The pipeline needs credentials for the cluster.

Each environment is a stage that adds more trust. The same build output moves through all of them.

• Dev: deploys on every merge, so developers can test quickly.
• QA/Test: automated and manual tests run against realistic data.
• UAT/Staging: looks like production. Used for final business sign-off and performance checks.
• Production: real users. Deployed with approval and a safe strategy.

How to keep them separate:

• Use separate AWS accounts (best). At least use separate VPCs, namespaces and IAM roles for each environment.
• Use separate databases and secrets. Never share production data or credentials with lower environments.
• Use the same infrastructure code and pipeline with different variables, so environments stay alike.
• Move the same image tag forward instead of building again. Limit who can approve production.

What they are checking: Whether you understand environment isolation and moving the same build forward.

Daily workflow: git checkout -b feature/x (or git switch -c), git add, git commit, git push, git status, git log --oneline, git diff.

• stash: saves uncommitted changes for later so you can switch branches. git stash pop brings them back.
• fetch: downloads new commits from the remote. It does not change your working branch.
• pull: fetch plus merge (or rebase with --rebase) into your current branch.
• merge: joins two branches. It keeps history and creates a merge commit.
• rebase: replays your commits on top of another branch to give a straight history. Never rebase commits that are already shared.

Other useful commands:

• git cherry-pick copies single commits.
• git reset and git revert undo changes. Revert is safe for shared history.
• git reflog helps you get back lost commits.

git fetch origin
git rebase origin/main

What they are checking: Whether you are comfortable with everyday Git and know when to use merge or rebase.

Git is a distributed version control tool that runs on your machine. GitHub is a hosting service built around Git repositories.

• Git tracks history, branches and merges locally. It needs no server.
• GitHub (like GitLab and Bitbucket) hosts the remote copy of the repo.
• GitHub adds pull requests, code review, issues, Actions CI/CD, access control and a web UI.
• You can use Git without GitHub, but not GitHub without Git.

git init
git remote add origin [email protected]:org/repo.git
git push -u origin main

What they are checking: Whether you separate the tool from the platform.

They are the three places a change moves through: working directory, staging area (index), then the repository.

• Working directory: the files you edit on disk.
• Staging area: the snapshot of what will go into the next commit, filled by git add.
• Repository (.git): the committed history, created by git commit.

git status            # see all three states
git add app.py        # working directory -> staging
git commit -m "Fix login"   # staging -> repository
git diff              # working vs staging
git diff --staged     # staging vs last commit

The staging area lets you commit only part of your work, for example git add -p to pick hunks.

What they are checking: Whether you understand why git add exists.

Merge joins branches with a merge commit that keeps both histories. Rebase replays your commits on top of another branch to give a straight line.

git switch feature && git merge main      # merge main into feature
git switch feature && git rebase main     # replay feature on main

Golden rule: never rebase commits that others already pulled. A common team habit is to rebase your local feature branch to stay current. Then merge it (often squash) through a pull request.

What they are checking: Whether you know the safety rule about rewriting shared history.

git fetch downloads new commits from the remote. It does not change your working files. git pull is fetch followed by a merge (or rebase) into your current branch.

git fetch origin               # update origin/* references only
git log HEAD..origin/main      # inspect what is new
git merge origin/main          # integrate when ready

git pull                       # fetch + merge
git pull --rebase              # fetch + rebase

Fetch is the safe, read-only choice. Use git config --global pull.rebase true if your team wants a linear history.

What they are checking: Whether you know pull is two operations.

Revert creates a new commit that cancels an earlier one. History stays intact. Reset moves the branch pointer back and drops commits from the branch.

git revert a1b2c3d         # safe on shared branches
git reset --hard HEAD~1    # drop last commit and its changes (local only)
git restore file.py        # discard unstaged edits to a file
git restore --staged file.py   # unstage

• Use revert for anything already pushed to a shared branch.
• Use reset only on local, unpushed work.
• If a reset goes wrong, you can usually fix it with git reflog.

What they are checking: Whether you pick the safe option for pushed commits.

git stash saves your uncommitted changes on a stack. It gives you a clean working directory, so you can switch tasks and come back.

git stash push -m "wip login form"
git stash list
git stash pop            # apply the newest and remove it
git stash apply stash@{1}   # apply but keep it
git stash drop stash@{0}
git stash -u             # include untracked files

Typical use: an urgent bug arrives while you are in the middle of a feature. Stash, switch branch, fix the bug, come back and pop. Stashes are local only and easy to forget, so do not use them as storage.

What they are checking: Whether you handle context switching without throwaway commits.

A conflict happens when both branches changed the same lines. Git stops and asks you to choose the final content.

git merge feature          # CONFLICT in app.py
git status                 # lists 'both modified' files
# open the file, find the markers:
# <<<<<<< HEAD
# your version
# =======
# their version
# >>>>>>> feature
# edit to the final result, remove markers
git add app.py
git commit                 # or: git rebase --continue
git merge --abort          # to back out

Tips:

• Pull often to keep conflicts small.
• Use git mergetool or an IDE.
• Run tests after you resolve.
• Talk to the author when you are not sure what they meant.

What they are checking: Whether you have really resolved one and know how to abort.

A tag is a fixed, human-readable name for a commit, usually used to mark releases such as v1.4.0.

git tag v1.0.0                       # lightweight: just a pointer
git tag -a v1.0.0 -m "Release 1.0.0" # annotated: has author, date, message
git push origin v1.0.0               # tags are not pushed by default
git push origin --tags
git tag -d v1.0.0 && git push origin :refs/tags/v1.0.0   # delete

Annotated tags are stored as full objects, can be signed, and are the right choice for releases. CI/CD pipelines commonly trigger release builds from tags following semantic versioning.

What they are checking: Whether you use tags for release management.

git cherry-pick applies the changes of one or more specific commits onto your current branch as new commits.

Git is a distributed version control system. It tracks changes, helps people work together, and lets you go back to any earlier state.

A .gitignore lists patterns of files Git should not track, such as build output, dependencies, logs and secrets.

A clone copies a repository to your machine. A fork copies a repository to your own account on the hosting service. A branch is a separate line of work inside one repository.

Use log for history, diff for differences, show for one commit and blame for per-line authorship.

A pull request asks the team to review a branch and merge it into another, usually main. Review, CI checks and discussion happen there.

HEAD is the pointer to the commit you currently have checked out, normally through a branch name. A detached HEAD means HEAD points straight to a commit, not to a branch.

Use git commit --amend, which replaces the last commit with a new one.

Both work, SSH uses a key pair and HTTPS uses a username with a personal access token or credential helper.

Use a role in the bucket's account that the other account can assume. Or use a bucket policy that names the other account's principal. Often you use both, together with IAM policies on the caller's side.

• Bucket policy approach: the bucket policy allows arn:aws:iam::<other-account-id>:role/app-role. The caller also needs an IAM policy that allows s3:GetObject on that bucket. Cross-account access needs both sides to allow it.
• Role approach: create a role in the bucket-owner account with S3 permissions and a trust policy for the other account. The caller runs sts:AssumeRole and gets temporary credentials.
• For an ECS task or Lambda in another account, give the task role the S3 permissions. Then add that role to the bucket policy. No access keys are needed.

{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::222222222222:role/app-task-role"},
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-bucket/data/*"
}

If objects are encrypted with a KMS key, the key policy must also allow the other account.

What they are checking: Whether you know cross-account access needs permission on both the resource and the caller, and prefer roles over keys

SSH key authentication uses an asymmetric key pair. The public key sits on the server. The private key never leaves your machine.

How it works: the client offers a public key that the server has in ~/.ssh/authorized_keys. Then it signs data unique to the session with the matching private key. The server checks that signature with the public key. The private key never crosses the network, and no password does either.

Handling private keys:

• Keep the .pem file at chmod 400. Never commit it to Git or share it over chat.
• Use a passphrase and ssh-agent on your laptop.
• Use one key per person, not a shared key. Remove keys when people leave.
• Better: avoid keys altogether with SSM Session Manager or EC2 Instance Connect. Access then goes through IAM and is logged, and port 22 can stay closed.
• If you must use SSH, limit the security group on port 22 to known IPs.

chmod 400 mykey.pem
ssh -i mykey.pem ec2-user@<public-ip>

What they are checking: Whether you understand asymmetric keys and know safer modern options like Session Manager

Shift security left: run automated checks at every stage of the pipeline. Fail the build on serious findings.

• Secret scan and dependency scan (SCA) on commit or PR: Gitleaks, npm audit, Trivy, Dependabot.
• SAST (static analysis of source code): SonarQube runs in the build stage. A quality gate fails the pipeline on new vulnerabilities.
• Container image scan: Trivy or ECR scanning before you push.
• DAST (testing the running app): deploy to a test environment, then run OWASP ZAP against it. Run a baseline scan on every build and a full scan every night.
• IaC scan: tfsec or Checkov for Terraform.

- name: ZAP baseline scan
  run: |
    docker run --rm -v $(pwd):/zap/wrk ghcr.io/zaproxy/zaproxy:stable       zap-baseline.py -t https://staging.example.com -r report.html

SAST finds code flaws without running the app. DAST finds runtime and config problems. Save the reports and review the findings. Otherwise teams start to ignore the noise.

What they are checking: Whether you have wired real security gates into a pipeline and know the SAST versus DAST difference

Yes. TLS gives confidentiality, integrity and server authentication. A man in the middle cannot read or change the payload without being detected.

Handshake in short (TLS 1.3):

1. The client sends the ciphers it supports and a key share.
2. The server replies with its certificate and its key share. The client checks the certificate chain against trusted CAs and checks the hostname.
3. Both sides work out the same session key with a temporary key exchange (ECDHE). Asymmetric crypto is used here. The server proves its identity by signing with its private key.
4. All application data is then encrypted with the fast symmetric key (AES-GCM or ChaCha20). It also adds an authentication tag that detects tampering.

So asymmetric crypto is used to prove identity and agree on a key. Symmetric crypto is used for the bulk data. Caveat: HTTPS protects data in transit only. A bad client can still send tampered input, so the server must validate it.

What they are checking: Whether you understand why TLS mixes asymmetric and symmetric crypto

Both filter traffic in a VPC, but at different levels.

Use security groups as the main control (the app tier allows only the ALB's group). Use NACLs as a rough extra layer, for example to block a bad IP range. Other protections: WAF and Shield at the edge, GuardDuty, VPC Flow Logs, private subnets and Security Hub.

What they are checking: Whether you know stateful versus stateless filtering and the layers of defence

Injection happens when untrusted input is sent to an interpreter as part of a command or query.

Common types: SQL injection, NoSQL injection (for example {"$ne": null} to bypass a login), OS command injection, LDAP injection, and XSS (script injected into pages).

JSON tampering: an attacker can edit any request body with a proxy such as Burp. For example:

• Change "price": 100 to 1.
• Change "role": "user" to "admin" (mass assignment).
• Change an id to read another user's data (IDOR).

HTTPS does not stop this, because the client itself is the attacker.

Defences:

• Use parameterised queries and ORMs. Never join strings to build queries.
• Do server-side validation against a schema. Allow only known fields. Ignore roles and prices sent by the client.
• Check authorisation on every object access.
• Escape output. Use a WAF as an extra layer. Give database accounts least privilege.

cur.execute("SELECT * FROM users WHERE email = %s", (email,))

What they are checking: Whether you know injection types and that the server must never trust client input

They are the identity types in AWS IAM.

• IAM role: an identity with permission policies. Something else assumes it to get temporary credentials.
• Trust policy: the role's resource policy. It says who may assume it (for example ec2.amazonaws.com, another account, or an OIDC provider). The permission policies say what it can do. -...

Work out who is calling, what action, on which resource. Then check each policy layer.

Never hardcode secrets in code, images or Git. Keep them in a secrets manager. Give the app permission to fetch them at runtime.

Encoding changes data into another format so systems can use it. There is no secret, and anyone can reverse it. Encryption changes data with a key, so only someone with the key can read it.

Use Let's Encrypt (free, automated, 90 day certificates) or the free managed certificates from your cloud provider.

By default every pod can talk to every pod. NetworkPolicy objects limit this. But they only work if the CNI supports them (Calico, Cilium, or VPC CNI with network policy turned on).

Approach: apply a default deny policy in the namespace. Then add explicit allows.

Do not patch a running container. Containers are immutable (you do not change them after they are built). Fix the image and redeploy.

Use short-lived, limited credentials instead of shared passwords.

Nmap is an open source network scanner. It finds hosts, open ports, running services and their versions. Sometimes it also finds the operating system.

A SIEM (Security Information and Event Management) collects logs and events from many sources. It puts them in one format, links related events, and raises alerts on suspicious patterns.

The CIA triad is the three core goals of information security.

Vulnerability scanning is automated checking of systems, images, code dependencies or web apps for known weaknesses (CVEs, misconfigurations, missing patches). Tools: Trivy, Nessus, OpenVAS, AWS Inspector, OWASP ZAP. It finds known issues, it does not prove they are exploitable.

Prefer a proven identity provider or framework over writing your own, and follow these basics.

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.

Work from the outside in: status, events, logs, then a shell inside the container.

kubectl get pods -n app                     # status: Pending, CrashLoopBackOff, ImagePullBackOff
kubectl describe pod web-7d9 -n app         # events: scheduling, probes, OOMKilled, image errors
kubectl logs web-7d9 -n app --previous      # logs of the last crashed container
kubectl exec -it web-7d9 -n app -- sh       # look around inside
kubectl get events -n app --sort-by=.lastTimestamp

• Pending: not enough resources, taints, or an unbound PVC.
• ImagePullBackOff: wrong image name or tag, or a missing registry secret.
• CrashLoopBackOff: the app exits, so read the previous logs; check env vars, config and probes.
• OOMKilled: raise memory limits or fix the leak.

If the image has no shell, use kubectl debug -it web-7d9 --image=busybox --target=web.

What they are checking: Whether you have a repeatable kubectl debugging routine rather than guessing.

Use built-in tools for a quick look. Use a metrics agent for history.

• top / htop: live CPU, memory and per-process usage. Sort by CPU or memory.
• free -h: memory and swap. Look at "available", not "free".
• vmstat 1 and iostat -x 1: run queue, swapping and disk wait.
• ps aux --sort=-%mem | head: the top memory users.
• uptime: load average. Compare it with the number of cores (nproc).
• df -h and du -sh: disk space.

For long-term monitoring, run Node Exporter with Prometheus and Grafana, or the CloudWatch agent. Alert on high CPU, low available memory and full disks.

What they are checking: Whether you know the basic Linux toolkit and the difference between live checks and ongoing monitoring.

Keep data outside the container's writable layer so it survives restarts.

• Locally with Docker: use a named volume.

docker run -d --name pg -e POSTGRES_PASSWORD=secret \
  -v pgdata:/var/lib/postgresql/data -p 5432:5432 postgres:16

• On Kubernetes: use a StatefulSet with volumeClaimTemplates. Each pod gets a stable name and its own PersistentVolumeClaim. A StorageClass backs it (for example the EBS CSI driver), so data stays after the pod moves. A headless Service gives stable DNS names. Store passwords in Secrets.

For production, a managed database such as RDS is usually safer than running your own. Backups, failover and patching are handled for you.

What they are checking: Whether you know volumes, PVCs and why StatefulSets exist.

ETL means extract, transform, load.

• Extract: read files from S3 (CSV, JSON, Parquet) or databases.
• Transform: clean the data. Drop or fill nulls, remove duplicates, fix types and formats, and join sources. In a graphical tool such as AWS Glue Studio, Talend or Azure Data Factory, you drag source, transform and target nodes and set the rules.
• Load: write into the warehouse. For Redshift use COPY from S3 (parallel and fast). For Snowflake use COPY INTO from a stage.

COPY sales FROM 's3://my-bucket/sales/'
IAM_ROLE 'arn:aws:iam::123456789012:role/redshift-load'
FORMAT AS PARQUET;

• Make queries fast: use columnar formats (Parquet), partitioned files, good distribution and sort keys, and compression. Avoid SELECT *. Use pre-aggregated tables.
• Schedule the job. Add data quality checks and alerts.

What they are checking: Whether you understand ETL stages and the basics of warehouse loading.

The path from code to a live site, in a few steps.

1. Build: develop the front end (HTML, CSS, JavaScript framework) and the backend API. Store data in a database. Keep code in Git.
2. Package: build the app, or a Docker image.
3. Infrastructure: a server or cloud service (VM, container service, or static hosting), a database, and a firewall that opens only ports 80 and 443.
4. Deploy: a CI/CD pipeline (GitHub Actions) tests, builds and ships the release. A web server such as Nginx serves the app and sends requests on to the backend.
5. Domain and HTTPS: point a DNS record to the server or load balancer. Add a TLS certificate (Let's Encrypt or ACM).
6. Operate: logs, monitoring, backups, and scaling or a CDN for speed.

This also touches operating systems (processes, files), networks (DNS, TCP, HTTP) and web technologies.

What they are checking: Whether you understand the whole lifecycle at a high level and the pieces involved.

Prometheus collects and stores metrics. Grafana shows them.

Check whether the app, the host and the network each allow the traffic.

Failures usually come from the network, the key, or the user.

Nagios runs checks on a schedule using plugins, and agents expose host data.

SQL lets you create tables and query rows.

The backend uses a driver or ORM with a connection string, host, port and credentials.

Snowflake separates storage and compute and needs little care. Redshift is tied closer to AWS and its cluster sizing.

Scrapy is a fast crawler for static pages. Selenium controls a real browser for pages that need JavaScript or interaction.

RAG (retrieval augmented generation) gives a language model relevant documents at question time, so answers are grounded in your data.

Virtualization lets one physical machine run several isolated virtual machines. Each has its own OS. They share the hardware through a hypervisor.

Error 525 means Cloudflare could not finish a TLS handshake with your origin server.

TLS 1.3 sets up an encrypted connection in one round trip.

OOP organises code into objects that combine data and behaviour.

In event-driven programming, events control the flow of the program. An event can be a click, a message or a file upload. Handlers react to them.

• An event is a signal that something happened.
• A handler/listener is code that runs in response.
• An event loop or broker waits for events and passes them on.

High availability (HA) means a system keeps working when a part fails, so downtime is small. It is usually given as uptime. 99.9% allows about 8.7 hours of downtime a year. 99.99% allows about 52 minutes.

Remove every single point of failure:

• Multiple AZs: run instances in at least two AZs behind a load balancer with health checks. Then traffic skips a failed zone.
• Auto Scaling group across AZs replaces failed instances automatically.
• Database: Multi-AZ RDS (synchronous standby, automatic failover) or Aurora with replicas.
• Stateless apps: keep sessions in Redis or a database, and files in S3. Then any instance can serve any request.
• Managed services that are already multi-AZ (S3, DynamoDB, SQS).
• Monitoring and automatic recovery (CloudWatch alarms, health checks).

HA protects against instance and AZ failure. A full region outage needs disaster recovery. That is a separate plan.

What they are checking: Whether you know HA means removing single points of failure and can name the AWS building blocks

For a purely static React build, S3 + CloudFront is usually the better choice. It is cheap and highly available. There are no servers to patch. It has a global CDN and almost nothing to scale. No load balancer is needed.

Reasons to run it in containers instead:

• Server-side rendering (Next.js) or a Node server that needs a runtime.
• The team already runs everything on one platform and wants one deployment and monitoring model.
• Same-origin routing to backend services, custom headers, or auth middleware at the app layer.
• Strict network requirements such as private-only access.

Cost view: a small static site on EKS pays for the control plane, nodes and a load balancer. S3 + CloudFront costs a few dollars. EKS is rarely cost-effective for a simple frontend.

Load balancers are needed in front of container or EC2 services (an ALB, or an Ingress on Kubernetes). They spread traffic and run health checks. Use an internal ALB for a private backend.

What they are checking: Whether you choose the simplest cost-effective hosting and justify containers only when needed

Layout in one VPC (for example 10.0.0.0/16), across two AZs.

• Public subnets: the Application Load Balancer and NAT gateways. Route table: 0.0.0.0/0 to the Internet Gateway.
• Private app subnets: EC2 instances (in an Auto Scaling group) running the backend. Route table: 0.0.0.0/0 to the NAT gateway. This lets them download updates and call external APIs. But nothing from the internet can reach them directly.
• Private data subnets: RDS (Multi-AZ), with no internet route.
• Frontend: host the React build on S3 + CloudFront. API calls go to the ALB, which passes them to the private backend.
• Security groups: the ALB allows 443 from the internet. The backend allows its port only from the ALB group. The database allows 5432/3306 only from the backend group.
• Access: SSM Session Manager instead of a public bastion.

What they are checking: Whether you understand subnet types, routing and why private tiers use a NAT gateway

A clear way to explain it is to follow the flow from commit to running traffic.

1. Terraform creates the VPC, EKS cluster, ECR, RDS and IAM roles, with state in S3.
2. A developer pushes code to GitHub.
3. GitHub Actions runs tests and linting. It builds the Docker image, scans it (Trivy), tags it with the commit SHA and pushes it to ECR. It signs in to AWS with OIDC, so no keys are stored.
4. Deployment: the pipeline updates the Kubernetes manifests or Helm values with the new tag and applies them. Or Argo CD syncs from Git, which is GitOps. A rolling update replaces pods, guarded by health checks and readiness probes.
5. Traffic: Route 53 sends users to the ALB (Ingress controller). It sends / to the frontend service and /api to the backend service. The backend talks to RDS in private subnets.
6. Operations: Prometheus and Grafana or CloudWatch for metrics, HPA for autoscaling.

What they are checking: Whether you can narrate a full delivery pipeline end to end and name the tools' roles

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.

Show a method you can repeat, plus a recent example.

Structure: pick a goal, read the official docs, build something small, break it and fix it, then write it down or share it.

Sample answer: "When I need a new tool, I start with the official documentation and a short tutorial. Then I build a small lab, for example [deploying a sample app with Terraform and GitHub Actions on a free-tier account]. I write down what I learn and what went wrong. I follow release notes and a few blogs and communities. I also practise on real problems at work. Recently I learned [tool] in [time] and used it to [result]."

Mention hands-on practice, not just videos. Say that you ask for help when you are stuck after trying yourself.

What they are checking: Whether you are self-driven and learn in a practical, structured way.

Show a logical, genuine path. Give proof that you have already started.

Sample answer: "In my [data role] I noticed that I enjoyed the pipeline work more than the analysis. I liked deploying jobs, automating runs, fixing failures and making things reliable. That led me to learn Linux, Docker, Git, CI/CD and AWS on my own. I built [project] to practise. My data background helps. I understand pipelines, data quality and the needs of teams who depend on stable platforms. DevOps lets me do that work full time and at a larger scale."

Show proof of effort (projects, certifications). Show how your old skills help in the new role.

What they are checking: Whether the switch is deliberate and backed by real effort.

Answer with what attracts you to DevOps. Do not put the other field down.

Sample answer: "Both fields interest me, and they overlap in DevSecOps. I chose DevOps because I like building and automating systems from start to end. I like to see a change go from code to production. The feedback is quick, and the work is hands-on with tools like Docker, Kubernetes and Terraform. I still care about security. I use least privilege, secret management and image scanning. I may specialise more in that direction later."

Keep it positive. Show that you understand the overlap. Do not sound undecided.

What they are checking: Whether you chose the path deliberately and understand how DevOps and security relate.

Make the knowledge easy to find. Make the setup automatic.

• Documentation: an up-to-date README, an architecture overview and runbooks, kept in the repo.
• Automation: setup with one command (Docker Compose, a Makefile or devcontainer), and infrastructure as code so environments can be rebuilt the same way.
• Access: a checklist and scripted access requests, so permissions on day one are not delayed.
• People: a buddy, a starter task, and a short first-week plan.
• Feedback: ask each new joiner what was confusing. Then fix the docs.

Sample: "On my last team I wrote a setup guide and a script that started the whole stack locally. It cut setup time from a day to about an hour."

What they are checking: Whether you think about documentation, automation and team experience.

Pick one project. Explain it in layers: what it does, how it scales, how you watch it.

Sample answer: "In [project], I deployed [app] on [AWS service]. For scalability, I used [autoscaling group or HPA] with a load balancer, stateless containers and a managed database. For monitoring, I collected metrics and logs with [CloudWatch or Prometheus and Grafana]. I made dashboards for latency, errors and CPU. I set alarms that notify [Slack or email]. I ran a load test and tuned the thresholds. The result was [for example it handled X times the traffic without manual changes]."

Be ready for follow-up questions. What would you improve? What failed along the way?

What they are checking: Whether you can explain a design clearly and understand scaling and monitoring basics.

Use a short project story: problem, what you built, technologies, result, what you learned.