Scenario based DevOps interview questions

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

CPU-threshold target tracking reacts only after the load has arrived. New instances need minutes to start and warm up. So a sharp spike can overload the fleet first.

Ways to cope:

• Scheduled scaling: raise min and desired capacity before known peaks (sale, campaign, office hours).
• Predictive scaling: learns daily and weekly patterns and scales ahead.
• Better metrics: scale on ALB RequestCountPerTarget, queue depth, or latency rather than CPU alone.
• Lower the target (for example 50 percent CPU) to keep spare room. Use shorter cooldowns or instance warm-up settings.
• Warm pools or pre-baked AMIs so new instances join quickly.
• Absorb bursts: CloudFront caching, a queue between tiers, and rate limiting at the edge.
• Keep min capacity across at least two AZs so one AZ failure is also covered.

aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name web-asg --scheduled-action-name morning \
  --recurrence "0 8 * * *" --min-size 4 --desired-capacity 6

What they are checking: Whether you know scaling is reactive and can combine scheduled, predictive and metric choices

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.

Control how fast the queue drives the function. This stops it from using up account concurrency or overloading other systems.

Keep the web, application and data tiers in different subnets across at least two AZs. Expose only the front door.

Put API Gateway in front, one or a few Lambda functions behind it, and DynamoDB for storage. There are no servers to patch, and cost follows usage.

Scale on the backlog per worker, not on raw CPU, so capacity follows the work waiting.

Plan the rollback before the change, because RDS cannot undo a bad write in place.

Build the new version into an AMI. Create a new launch template version that points to it. Then replace instances slowly.

Connect the two VPCs privately, then allow the traffic with routes and security groups.

Start with the address plan, then subnets, routing and connectivity.

Use Route 53 routing policies, or AWS Global Accelerator, in front of identical stacks in each region.

Define the configuration as an image plus a template, and copy or rebuild both in each region.

Staging should look like production in design, but not in size or uptime. This cuts cost without losing test value.

An S3 access decision combines the caller's IAM policy, the bucket policy, and several guardrails. Work through each.

Find what changed with Cost Explorer, fix it, then add guardrails.

The usual cause is a deleted file that a running process still holds open. The space is not freed until the process closes it.

Find out which resource is saturated first: CPU, memory, disk IO or network, then which process is responsible.

Read the unit status and the journal. Then check the command, user, paths and environment the unit uses.

Run the client in verbose mode to see which key is offered. Then check the key, the permissions and the server logs.

Avoid storing changing state on the instances, and pick a shared or build-time approach.

Manage access in one place instead of copying keys by hand. Keep a second way in, so a lost key does not lock you out.

Check the kernel log for the out-of-memory killer, then fix the memory demand or limits.

Check inode exhaustion: a filesystem can run out of inodes (file entries) before it runs out of bytes.

Another process is already listening on that port. Find it, then decide whether to stop it or change the port.

Cron runs with a very small environment and no terminal. So most failures are path, permission or environment problems.

First stop the damage and check what changed. Then restore the right modes from a known good source, instead of guessing.

High wa means the CPUs are idle and waiting for storage. Find the device, then the process, then the reason.

Use logrotate to rotate, compress and expire logs automatically, and handle the live file correctly.

Grow the block device first, then the partition or logical volume, then the filesystem. You can do all this while it is mounted.

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.

Work from outside in.

A container exits when its main process (PID 1) ends, so find out why that process stopped.

Inside a container, localhost means the container itself, not the host or another container. So the app connects to nothing.

Running as non-root is the secure default, but it often breaks things written assuming root.

A 10-second stop usually means your app never got SIGTERM. Docker waited for the grace period and then sent SIGKILL.

Exit code 137 is 128 + 9, meaning the process was killed by SIGKILL. The most common reason is the kernel OOM killer, after the container hit its memory limit. But docker kill or a failed clean stop also give 137.

It means something already listens on that host port, either another container or a host process.

Find the owner:

docker ps --format 'table {{.Names}}\t{{.Ports}}'
sudo ss -ltnp | grep ':8080'

CI runners are usually clean machines with no local cache, so every build starts from zero. Fix that first, then optimise the Dockerfile.

Containers remove many differences, but not all. Compare what is still different.

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.

NotReady means the control plane stopped getting healthy signals (heartbeats) from the kubelet. Start at the node and work outward.

OOMKilled (exit code 137) means the container used more memory than its limit, so the kernel killed it.

Confirm:

kubectl describe pod web-abc | grep -A5 'Last State'
kubectl top pod web-abc --containers

Follow the path from the Ingress down to the Pod and find where it breaks.

Start with kubectl describe hpa and kubectl get hpa; the Conditions and metrics columns show what is wrong.

Use a rolling update together with correct health checks and a clean shutdown.

Plan, test and roll out step by step, one minor version at a time.

Scale at two levels: pods and nodes.

Roll back with the Deployment revision history:

Follow the path step by step.

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.

It depends on whether you used count or for_each.

The cleanest way is to remove the resource block from the code and apply. The plan then destroys only that resource, and the change is reviewed in Git.

Restore the last good copy first. Then check that it matches the real resources.

Use protection in Terraform and protection in AWS together.

Drift is when real infrastructure is different from the code or state. It usually comes from manual changes in the console.

Detect:

• terraform plan (or plan -refresh-only) shows differences.
• Schedule a nightly plan in CI that alerts on any diff.
• For CloudFormation, use stack drift detection.

First, read the plan. Terraform marks the setting that forces the rebuild with # forces replacement. Then decide if the rebuild is really needed.

Do not force anything yet. First find out who or what holds the lock.

Terraform saves each resource in state as soon as it is created. So after a half-finished apply, the state is usually correct for what worked. Recovery is mostly "fix the cause and run again".

Treat it as leaked. Change the secret first, then clean up.

Immediate steps:

1. Change the credential at the source (RDS master password, API key).
2. If it was committed to Git, cleaning the history comes second. Changing the secret is what protects you.
3. Restrict who can read the state bucket and check access logs.

If you change a resource address, Terraform thinks the old one is deleted and a new one is needed. Tell it the object is the same. Then only the state changes, not the infrastructure.

Preferred way, which you can review: a moved block in code.

Upgrade on purpose, one small step at a time, and let plan show that it is safe.

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

Start from the user and move outward, checking one layer at a time.

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.

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

The pod subnets have no free IPs left. You need more address space, or you need to use it better.

Only the load balancer is public. The application instances stay in private subnets with no public IPs.

Resolvers and clients keep the old answer in their cache until its TTL runs out, so the change is not instant everywhere. This is DNS caching. People often wrongly call it propagation.

A 502 Bad Gateway means the load balancer got a bad answer, or no answer, from a backend. A 504 Gateway Timeout means the backend did not answer within the idle timeout.

Renew and install the certificate right away. Then add automation and alerts, so it cannot expire without notice.

The likely cause is running out of source ports on the NAT device. Each connection through PAT uses its own source port on the shared public IP. Each destination IP and port pair can use only about 55,000 ports at once.

This pattern usually means a path MTU problem. MTU is the biggest packet size a link allows. Packets bigger than some link's MTU are dropped. The ICMP "fragmentation needed" message that should tell the sender never arrives, because ICMP is blocked.

Split the request time into DNS, connect, TLS, wait for the first byte and download. Then see which part is big.

First measure which steps are slow. Then fix the biggest one.

• Cache dependencies (npm, pip, Maven) and Docker layers (BuildKit cache, registry cache).
• Order the Dockerfile layers so steps that rarely change (dependency install) come before the source copy. Use multi-stage builds and small base images.
• Run in parallel: split lint, unit tests and builds into jobs that run at the same time. Split long test suites into parts.
• Build only what changed: path filters, monorepo tools, and finding which services changed.
• Faster runners: bigger or self-hosted machines with ready caches.
• Skip what is not needed: do not rebuild for docs-only changes. Reuse the artifact across environments.
• Faster deploys: pull smaller images, tune the health checks and rolling-update settings, and keep images already pulled on nodes.

Report the numbers before and after. This shows that you worked step by step.

What they are checking: Whether you measure first and know caching, parallel jobs and builds that run only for changes.

Plan rollback before releasing.

Rollback:

• Keep the previous artifacts: image tags by SHA, Helm revisions, ECS task definition revisions.
• Kubernetes: kubectl rollout undo deployment/app or helm rollback app 12. GitOps: revert the commit. Blue/green: switch traffic back.
• Automate it with health checks and alarms that start the rollback.

Tracking releases: use version tags, release notes, deployment events in the pipeline, and a deploy marker on dashboards. Then an incident can be linked to a change.

Database migrations:

• Use migration tools that keep versions (Flyway, Liquibase, Alembic).
• Follow expand and contract. First add columns or tables in a way that works with old code. Then deploy the code. Remove the old structures in a later release.
• Take a backup or snapshot before risky migrations. Do not ship changes that delete data in the same release as the code.
• Move forward with a fix when a rollback would lose data.

What they are checking: Whether you can roll back safely and know that database schema changes are the hard part.

Make things stable first. Investigate second.

Immediate:

1. Roll back to the last good version (redeploy the previous artifact, run helm rollback, or switch the blue-green router). Do not debug live while users are getting errors.
2. Tell people the status and keep a timeline.

Unstable tests (tests that fail sometimes and pass other times) destroy trust in the pipeline. Treat them as bugs, not noise.

Assume it is stolen the moment it appears, and act in this order:

Start with what Argo CD itself says.

Use the expand and contract method. In rolling, blue-green or canary releases, both versions use the same database.

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

Servers that run workloads should be in private subnets. Only load balancers and entry points like a bastion are public. Pipelines reach the servers without opening SSH to the whole world.

A queue means there are more jobs than executors, or builds cannot find a matching agent.

Automate it with metric analysis, so nobody has to watch the dashboard.

Break the loop by making the CI trigger ignore the commit that CI itself makes.

Treat the secret as stolen. Rotate it first, then clean the history, then stop it from happening again.

The commits still exist in someone's clone and in the reflog. Find the last good commit and move the branch back to it.

Use the reflog. It records every place HEAD and branch tips have been, for about 90 days by default.

Revert the bad commit on main so history stays intact. Ship the revert through the normal pipeline. Then fix the problem properly in a new change.

Integrate more often and make Git remember resolutions.

• Merge or rebase main into the branch daily so each conflict is small.
• Break the work into smaller PRs, hide unfinished features behind flags and merge them to main early.
• Enable rerere so Git replays conflict resolutions you already did:

Use git bisect, which binary searches the history, so about 8 steps cover 200 commits.

Usually it is long history, large binaries committed to Git, or both, and there are both client-side and repo-side fixes.

Copy the commit to the correct branch, then remove it from the wrong one, provided it is not pushed.

Use an interactive rebase to squash, reword and reorder commits on your own branch, then force push safely.

Make main protected so the only way in is a reviewed, passing pull request.

Create the hotfix branch from what is in production (the main branch or the release tag), not from develop. Then merge it back everywhere.

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

Start with the legal basics. Sign a Business Associate Agreement (BAA) with AWS. Use only HIPAA-eligible services for anything that touches PHI (protected health information). Then build the controls around that.

• Account structure: a separate AWS account for PHI workloads under AWS Organizations. Use service control policies to block risky actions.
• Network: private subnets for compute and databases. No public database endpoints. VPC endpoints for AWS services. A WAF and load balancer at the edge.
• Encryption: TLS in transit. KMS encryption at rest for S3, EBS, RDS and backups, with customer managed keys and key rotation.
• Access: least-privilege IAM roles, MFA, SSO, and no long-lived keys on servers.
• Audit and monitoring: CloudTrail in all regions with log file validation, AWS Config rules, GuardDuty and CloudWatch alarms. Keep logs in a locked-down bucket.
• Data handling: keep as little PHI as possible. Mask or de-identify it in non-production. Define how long to keep data. Test backups and disaster recovery.

Being HIPAA-eligible does not make an application compliant. It is a shared responsibility model. AWS secures the platform. You must set up and run your part correctly.

What they are checking: Whether you can combine compliance requirements with concrete AWS controls and the shared responsibility model

Use defence in depth: private networking, tight rules at each layer, encryption everywhere, and logging.

• Topology: public subnets hold only the load balancer. App and database tiers sit in private subnets with no public IPs. Reach AWS services through VPC endpoints.
• Security groups: chain them. The database allows only the app group. The app allows only the load balancer group.
• Load balancer: use HTTPS listeners with ACM certificates. Redirect HTTP to HTTPS. Use a modern TLS policy. Use WAF for OWASP rules and rate limiting. Limit origin access to the CDN. Turn on access logs.
• Encryption: TLS in transit, KMS at rest for databases and S3.
• Access: no direct DB access. Use SSM or VPN, IAM auth, and secrets in Secrets Manager.
• Sensitive data: classify it (Macie) and keep as little as possible. Mask it in logs. Limit it by data residency. Keep audit trails (CloudTrail, Config).
• Compliance: map controls to the standard (PCI, HIPAA, SOC 2). Automate checks with Config and Security Hub.

What they are checking: Whether you layer controls from edge to data rather than relying on one

Secure the whole path: build, registry, runtime and the host.

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

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

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

Make sure the only way in is through the CDN or proxy. Also harden the instance itself.

Keep private resources (databases, internal APIs) in private subnets, and expose only a controlled entry point.

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.

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.

First make things stable, then find the cause, then recover. Do not reboot blindly, because you may lose evidence.

• Check status: look at the EC2 console status checks. A failed system check points to the AWS host. Stop and start the instance to move it to new hardware. A failed instance check points to the OS (kernel panic, full disk, bad fstab).
• Metrics and logs: look at CloudWatch CPU, credit balance, disk and network graphs. Also read the console output and screenshot (aws ec2 get-console-output --instance-id i-0abc).
• If SSH fails: try SSM Session Manager first. If that fails, stop the instance and detach the root volume. Attach it to a healthy rescue instance and mount it. Then read /var/log, fix fstab, free disk space or fix sshd_config. Finally reattach the volume and start the instance.
• If it is just too small: stop it, change the instance type, and start it. Or snapshot the volume and launch a larger instance from it.
• Avoid a repeat: set alarms on CPU, disk and status checks. Use an Auto Scaling group with health checks so it heals itself. Hold a short review after the incident.

aws ec2 describe-instance-status --instance-ids i-0abc --include-all-instances

What they are checking: Whether you have a calm, ordered recovery process and know the detach-volume rescue trick.

Start with the user impact, then narrow down layer by layer using data, not guesses.

1. Scope it: which endpoint, since when, which users? Check recent deploys or config changes.
2. Golden signals (latency, traffic, errors, saturation) on a Grafana or CloudWatch dashboard.
3. Resources: CPU throttling, memory pressure and swap, disk I/O, network, connection limits.
4. Distributed tracing (OpenTelemetry with Jaeger or Tempo, or X-Ray): the slowest span shows which service or call is guilty.
5. Dependencies: slow SQL (slow query log, pg_stat_statements), locks, cache misses, third-party APIs, DNS.
6. Logs: correlate by request ID, look for timeouts and retries.
7. Fix and verify: add an index, cache, scale out (HPA), tune pool sizes, or roll back. Then confirm the latency graph recovered.

The key is to change one thing at a time and measure.

What they are checking: Whether you follow a structured, data driven approach and know tracing.

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.

Aurora is AWS's cloud native engine (compatible with MySQL and PostgreSQL). Standard RDS runs the regular engine on EBS volumes.

Writer crash in Aurora: the cluster detects the failure and promotes a reader to writer automatically. It picks by failover priority tier (then size). Readers share storage, so no data copy is needed. The cluster endpoint then points at the new writer, so applications that reconnect keep working. The failed instance is replaced and joins again as a reader. Clients must retry dropped connections. They must use the cluster (writer) endpoint and the reader endpoint, not instance endpoints.

For RDS Multi-AZ, the standby is promoted and DNS flips. So keep the DNS TTL low and retry connections.

What they are checking: Whether you know the shared storage design and how failover is exposed to applications.

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.

Look at what the database is doing. Then fix the query or the connection handling.

Make costs visible per team. Set budgets. Then act on the biggest items.

Run active copies in each region. Send users to the nearest healthy one. Replicate data.

Default to a managed database outside the cluster, and self-host only with a good reason.

Choose by data shape, consistency needs and access pattern.

Treat AI tools like any other powerful third party that can reach your code and systems.

Pick the service by how much control you need.

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.

They measure different layers.

Alert from metrics. Then investigate with kubectl.

Check each hop between the two, starting at the backend.

Use the exit information Kubernetes already records.

HPA adds or removes pod replicas. VPA changes the CPU and memory requests of each pod.

Find the blocker. Decide whether to kill it. Stop it from happening again.

Most problems come from what an EC2 app assumes about its machine.

Find out which layer is still serving old content.

Separate the resolver, the DNS records and the network path.

Restore service first. Find the root cause second.

Retention is set per log group, and search uses Logs Insights or filter patterns.

• Retention: by default logs never expire, which costs money. Set a retention period in the console, with Terraform (retention_in_days), or the CLI:

Ship logs from every host and pod to one searchable store.

• Collect: Fluent Bit, Promtail or Grafana Alloy as a DaemonSet or agent, tagging logs with labels like namespace, pod and app. Prefer structured JSON logs with a request ID.
• Store and search: Loki or Elasticsearch/OpenSearch.

Instrument with OpenTelemetry, collect with a collector, and view in a tracing backend.

Check from outside the system, as a user would. Alert on failures.

Aurora Global Database spans multiple regions. It has one primary region and read-only secondary regions. It copies data at the storage level.

Put RDS in private subnets. Never expose it to the internet.

Combine automated backups, copies in another region and account, and tested restores.

Choose by recovery targets: how much data you can lose (RPO) and how fast you must be back (RTO).

DynamoDB queries must use a key, so indexes give you extra access patterns.

Describe the path from model to a secure, scalable endpoint.

Automate it from a template instead of clicking 50 times.

• Template: build one VM, install the OS and agents, generalise it (cloud-init or sysprep), and convert it to a template.
• Terraform with the vSphere provider:

Make the environments hard to confuse and hard to touch by accident.

Scale turns small issues into daily problems.

First find which role is making the call, and which policy is missing or blocking it.

Give a short map of what you built. Then name the tooling.

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

Start with a typical web application. Add each requirement as a layer.

Architecture

• Route 53 and CloudFront (with WAF) at the edge, caching static content.
• ALB across 3 AZs. Targets are in an Auto Scaling group (or ECS/EKS) in private subnets. Scale on CPU or request count.
• Aurora or RDS Multi-AZ for the database with read replicas, ElastiCache for hot data, S3 for objects.
• Stateless app tier, config in SSM/Secrets Manager, infrastructure in Terraform.

Recovery and DR

• Health checks, retries with backoff, timeouts, circuit breakers.
• For low RPO and RTO beyond one region: use Aurora Global Database or a cross-region read replica. Add S3 cross-region replication, infrastructure code ready for a second region, and Route 53 failover. Warm standby gives an RTO of minutes and an RPO of seconds.
• Regular restore tests and game days.

Cost

• Right-size instances.
• Use Savings Plans for the baseline.
• Use Spot for stateless or batch workers.
• Use S3 lifecycle tiers.
• Scale in at night.
• Keep the standby region small.

State the cost link: lower RTO/RPO costs more. Pick targets from the business impact.

What they are checking: Whether you can combine HA, scaling, DR and cost into one clear design and discuss the pros and cons

Three tiers: presentation, application and data. Each is in its own subnet or managed service.

• Edge:
  • A global external Application Load Balancer with a static IP.
  • Cloud CDN for static assets.
  • Cloud Armor for WAF and rate limits.
  • Managed SSL certificates.
• Web/app tier: a regional managed instance group (MIG) spread across zones, or Cloud Run/GKE. Use an autoscaling policy based on CPU use or load balancer requests per instance. Add autohealing health checks. Instances have no external IPs.
• Data tier: Cloud SQL with high availability (regional, standby in another zone) and read replicas, or Spanner/Firestore. Memorystore for caching. Cloud Storage for files.
• Network:
  • Custom-mode VPC with private subnets.
  • Cloud NAT for outbound traffic.
  • Firewall rules by network tag or service account (frontend can reach app, app can reach DB only).
  • Private Service Connect or private IP for Cloud SQL.
• Operations: Cloud Monitoring and Logging, instance templates built by CI, Terraform for everything.

Explain scaling: the stateless app tier scales horizontally. The database scales vertically, plus replicas.

What they are checking: Whether you can map the three-tier pattern to GCP services and explain autoscaling and network isolation

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

RPO (Recovery Point Objective) is how much data you can afford to lose, measured in time since the last good copy. RTO (Recovery Time Objective) is how long you can be down before service is back.

They come from the business impact. They then decide the strategy and the cost:

Plan for a single region failure on AWS:

• Copy data to another region (S3 CRR, Aurora Global Database, DynamoDB global tables, copied AMIs and ECR images).
• Keep infrastructure as code ready to deploy in the second region.
• Use Route 53 health checks and failover records.
• Write runbooks and test failovers regularly.

A DR plan that is never tested is a guess.

What they are checking: Whether you can define RPO/RTO precisely and match DR tiers to them

Use separate accounts (AWS) or projects/folders (GCP) as the main isolation boundary. They limit the damage from a problem, and they separate permissions and billing.

AWS structure with Organizations:

• Management account (billing and governance only).
• Security / log-archive accounts (CloudTrail, Config, GuardDuty aggregation).
• Shared services / network account (Transit Gateway, DNS, CI runners, ECR).
• Workload accounts per environment (dev, staging, prod), possibly per team or product.
• SCPs set guardrails per organisational unit. IAM Identity Center gives role-based access.

GCP equivalent: organization, folders per environment or team, one project per workload, Shared VPC from a host project, and org policies for guardrails.

Why clusters per environment: prod isolation, independent upgrades, separate quotas and cost reports. For thousands of machines, also use naming and labelling standards, IaC modules and pipelines per environment, and central monitoring. Avoid sharing databases across environments.

Cost of this: more accounts mean more overhead (networking, access). So automate with Terraform and landing-zone tooling (Control Tower).

What they are checking: Whether you understand account-level isolation, guardrails and the cost of operating many accounts

Match the method to how the data changes. Follow 3-2-1: three copies, two storage types, one off-site (another region or account).

• Databases: automated backups plus point-in-time recovery (RDS/Aurora, continuous transaction logs, restore to any second in the retention window). Add manual snapshots before risky changes. For copies with no downtime, use read replicas or snapshots instead of dumping the primary.
• Block storage: EBS snapshots (incremental) through AWS Backup or Data Lifecycle Manager on a schedule.
• Objects: S3 versioning plus cross-region replication. Object Lock protects against ransomware.
• Cross-region: copy snapshots to another region and, ideally, another account with a separate KMS key. Then a hacked account cannot delete them. AWS Backup supports cross-region and cross-account copy rules.
• Retention: lifecycle rules that move old backups to cheaper tiers.
• Verify: restore tests and alerts on failed jobs. A backup you have never restored is unproven.

Choose the frequency from the RPO. If you can lose 5 minutes, snapshots every night are not enough.

What they are checking: Whether you know PITR, snapshots, cross-account copies and the need to test restores

The queue is doing its job (it absorbs the burst). The fix is to control the consumption rate, not to speed up the consumers.

• Limit worker concurrency so total calls to the API stay under 20 per minute. A single worker with a rate limiter or token bucket, or a small fixed pool, enforces this. Do not autoscale consumers on queue depth blindly, because that makes the problem worse.
• Slow down in the worker: sleep or use a rate-limiting library. Respect 429 and Retry-After responses.
• Retry with exponential backoff and jitter (random delay). Send messages that keep failing to a dead-letter queue.
• Visibility timeout longer than the processing plus wait time, so messages are not delivered again while waiting.
• Idempotent processing (running it twice gives the same result), so retries are safe.
• Capacity maths: 2000 messages at 20 per minute takes about 100 minutes. If that is too slow, ask the API owner to raise the limit, batch requests, or put important messages in a separate queue.
• Alert on queue age (oldest message), not only depth.

What they are checking: Whether you throttle at the consumer and use backoff, DLQs and idempotency instead of just scaling out

Cross-AZ is simple and should be the default. Multi-region is a deliberate step up with real cost and complexity.

Cross-AZ: subnets and instances in 2 to 3 AZs, a load balancer across them, a Multi-AZ database, and stateless services.

Choose by data size, bandwidth and deadline.

Keep the cheap, stateless application tier apart from the expensive GPU workers. Let a queue connect them.

A 3 to 4 second response is impossible if each request pays the load time. So the model must already be loaded when requests arrive.

An API gateway is the single entry point for clients. It receives external requests, handles shared tasks, and sends each request to the right internal service.

Flow: client to gateway (HTTPS) to service (HTTP or gRPC over the internal network) and back.

Compute Engine and GKE need real subnets with IP ranges you plan up front. Serverless (Cloud Run, Cloud Functions) needs little, unless it must reach private resources.

At this size, full restores take days. So design around incremental, replicated and tiered protection and a realistic RTO.

An RTO and RPO of 1 hour is relaxed enough for pilot light or warm standby in a second region. You do not need to pay for active-active.

Typical flow: data lands in S3. Scheduled or event-driven ECS tasks transform it. Results load into a warehouse (Redshift, BigQuery or Snowflake).

Build it with Terraform, in this order.

Answer in three parts: how traffic flows, how the migration was done, and what changed. Use your own project. Here is a typical structure.