"I check the four resources one at a time: CPU, memory, disk and network. For CPU I use top to see the load average and which process is busy, and whether the time is user, system or I/O wait. For memory I use free -h and check dmesg for the OOM killer. For disk I check space with df -h and pressure with iostat -xz. Once I know the process, I check its logs and what changed recently. I mitigate first, for example by moving traffic away or scaling out, before I restart anything."

"The script calls the health endpoint with curl -f, which fails on HTTP errors, and sets a timeout. If it fails, it retries a few times with a growing wait so one blip doesn't page anyone. It saves the last state in a file, so it alerts only when the state changes: once when the service goes down, and once when it recovers. Then I run it from cron or a systemd timer."

"I'd list failed units with systemctl --failed. 'Safely' means four things: only restart services on an allow-list, log the last error lines first so we don't lose the evidence, use a lock so two copies never run at once, and check after the restart that the service actually came back. If it's still failing, I escalate instead of restarting in a loop. I'd also say the first line of defence should be systemd's own Restart=on-failure setting."

"First the browser resolves the name with DNS: it checks its cache, then asks a resolver, which goes to the authoritative server (Route 53) and gets the load balancer's IP. Then the browser opens a TCP connection to that IP on port 443 and does a TLS handshake to set up encryption and check the certificate. It sends the HTTP request. In the cloud, that request enters the VPC through the internet gateway and hits the load balancer, which forwards it to a healthy server or pod in a private subnet. Security groups must allow each hop. The app may query the database, then the response goes back the same way."

"CIDR describes a range of IPs. The number after the slash is how many bits are fixed, so a smaller number means a bigger range. A /16 has 65,536 addresses, which is typical for a whole VPC. A /24 has 256, which is typical for one subnet, and the cloud reserves 5 of those. A subnet is public when its route table sends 0.0.0.0/0 to an internet gateway. It's private when it doesn't; then it can only get outbound internet through a NAT gateway. I'd also make sure CIDRs don't overlap with other VPCs or on-prem, otherwise peering or VPN won't work later."

"First I'd confirm the exact need: which source, which destination, which port. Then I'd add the narrowest rule: inbound TCP 5432 on the database's NSG, with the source as the app subnet or app security group, never 'Any' or 0.0.0.0/0. In Azure NSGs, rules run by priority, lowest number first, so I'd check no higher-priority deny blocks it, and that I'm not overriding something important. I'd make the change through Terraform and a pull request so it's reviewed and recorded. Then I'd test with nc -zv db-host 5432 from the app, and document it."

"The risk with DNS changes is caching, so I plan around the TTL. A day or so before, I lower the TTL, say from 3600 to 60 seconds, and wait for the old TTL to expire. I make sure the new load balancer is healthy and serving correctly by testing it directly. Then I update the record. On AWS I'd use an alias record pointing to the ALB. I verify with dig against the authoritative name server and public resolvers, and I keep the old load balancer running until its traffic drops to zero. Then I raise the TTL again. For a riskier change, I'd use weighted records to shift traffic gradually."

"I go up the layers. dig first: does the name resolve to the right IP? Then nc -zv host 443: is the port reachable? A timeout means a firewall or route is dropping the traffic. 'Connection refused' means I reached the host but nothing is listening. Then curl -v: what does the app answer, what status code, and does TLS work? I use ping and traceroute to see where the path stops, but carefully, because many cloud networks block ICMP, so a failed ping doesn't prove the host is down."

"I'd start with the error message, because it tells me the layer. A timeout means a network problem: I'd check the security group allows port 22 from my IP, the NACL allows 22 in and ephemeral ports out, the subnet's route table has an internet gateway route, and the instance has a public IP, or I'm coming through a VPN or bastion. Permission denied means the network is fine and it's the key or the username, like ec2-user vs ubuntu, or key file permissions. If it's the OS itself, like a full disk or sshd stopped, I'd check the instance status checks and system log, and get in another way with SSM Session Manager or the serial console. Long term, I'd use Session Manager and close port 22."

"I'd follow the packet. First, the private subnet's route table: does it really have 0.0.0.0/0 pointing to the NAT gateway, and is the subnet associated with that route table and not the main one? Second, the NAT gateway itself must sit in a public subnet whose route table points to the internet gateway, with an Elastic IP and status Available. Third, the firewalls: the security group's outbound rules, and NACLs allowing outbound traffic and the inbound return traffic on ephemeral ports. Then DNS: can the instance even resolve the name? I test with curl -v rather than ping, and VPC Flow Logs show me where packets are rejected."

"'Intermittent' usually means some answers or some backends are bad, not all of them. On the DNS side, I'd check whether the record returns several values and one of them is dead, whether health checks on failover or weighted records are flapping, whether an old IP is still cached somewhere because of a long TTL, and whether the name servers at the registrar match the hosted zone. I'd query from different resolvers with dig to compare. If DNS is consistent, the problem is behind it, like one unhealthy target or one bad AZ, so I'd check load balancer target health and 5xx metrics per AZ."

"Intermittent between VPCs usually means it works from some subnets or AZs and not others. So first I'd find the pattern: which source subnets and which destinations fail. Then I check routes on both sides: every subnet's route table needs the route to the other VPC's CIDR via the peering connection or Transit Gateway. With Transit Gateway, I'd check the attachment has a subnet in every AZ, plus the TGW route table associations and propagations. Then security groups and NACLs on both sides. VPC Flow Logs show REJECTs, and Reachability Analyzer tests a specific path."

"First I protect users: if it's behind an Auto Scaling Group, I make sure it scales out, or I raise the desired capacity manually so the load spreads. I don't reboot a busy production server. Then I find out whether it's just more traffic or something abnormal. I compare request count on the load balancer with CPU. If traffic doubled and CPU doubled, that's capacity. If traffic is flat but CPU jumped, it's a code or process problem. I check with top or through SSM which process is hot, and whether a deploy or cron job lined up with it. On T-instances I check CPU credits. Long term: autoscaling policies, rightsizing, caching or fixing the code."

"A 502 means the load balancer reached the target but got a bad response or the connection was closed. So the problem is usually the app or how it talks to the ALB, not DNS. I'd check the ALB metrics to see whether the 502s are generated by the ELB or the target. Then target health, and the ALB access logs, which show the target's status code and timings per request. Common causes are the app crashing or restarting, the app's keep-alive timeout being shorter than the ALB's idle timeout, the wrong protocol or port, for example the ALB speaking HTTP to an HTTPS port, or the response headers being too big. Then I'd read the app logs at the same timestamps."

"When all targets are unhealthy at once, it's usually the health check or the network, not every server breaking at the same time. First I read the reason code on the target group, like timeout or 'health checks failed with these codes'. A timeout points to the security group: the targets must allow the health-check port from the ALB's security group. A wrong code, like 404 or 301, means the health-check path is wrong, or the app redirects HTTP to HTTPS. Then I test the path from inside the VPC with curl. I also check whether a recent deploy changed the port or the health endpoint, or whether the endpoint depends on a database that's down."

"I'd split it in two: is the ASG trying to launch and failing, or is it not trying? The ASG's activity history answers that, with an error message. If it's not trying: the max size is already reached, the scaling policy or CloudWatch alarm isn't triggering because it's on the wrong metric or threshold, it's in cooldown, or processes are suspended. If it's trying and failing: insufficient capacity for that instance type in the AZ, a vCPU service quota limit, a broken launch template like a deleted AMI or a missing key pair or IAM role, no free IPs in the subnet, or a KMS key permission for encrypted volumes. Or instances launch but fail health checks and get terminated in a loop."

"First I'd get the app writing again by freeing space quickly, like rotating or compressing old logs. Then I'd take a snapshot as a safety net. EBS Elastic Volumes let me increase the size online, without stopping the instance. After the volume shows 'optimizing' or 'completed', I extend the partition with growpart and then the filesystem with resize2fs for ext4 or xfs_growfs for XFS, all online. Finally I add a disk-usage alarm, because CloudWatch doesn't collect disk usage by default; you need the CloudWatch agent."

"Production has more load and different networking than test, so I'd compare those. In CloudWatch I'd look at Duration, Errors, Throttles and concurrent executions, and check whether timeouts line up with traffic peaks. Memory: Lambda gives CPU in proportion to memory, so raising memory often makes it faster. VPC: if the function is in a VPC, it needs a NAT gateway or VPC endpoints to reach the internet or AWS services, otherwise calls just hang until the timeout. That's a classic. Downstream: a slow database or API, or too many connections from many concurrent Lambdas; RDS Proxy helps. I'd turn on X-Ray tracing to see which call is slow, and set client timeouts shorter than the Lambda timeout."

"I'd check what changed first: a new deploy often brings a new or unindexed query. Then I'd open Performance Insights, which shows the top SQL statements and wait events causing the load. I'd look at CloudWatch for CPU, DatabaseConnections, Read/Write IOPS and FreeableMemory, to see if it's a connection storm or I/O. For the fix: short term, kill a runaway query, roll back the bad deploy, or scale up the instance class (with Multi-AZ that's a quick failover). Longer term: add the missing index, cache with ElastiCache, move reads to read replicas, and use RDS Proxy for connection pooling."

"Think of one request and one server's life. The load balancer receives traffic and sends it only to healthy instances across several AZs. The Auto Scaling Group keeps the right number of instances: it adds them when load rises, and replaces any that fail health checks. Each instance launches from a launch template with an IAM role attached, so the app gets temporary credentials to reach S3 or Secrets Manager, with no keys stored on disk. That matters because instances are disposable. Disaster recovery is the same idea at region level: backups, AMIs and infrastructure code ready in another region, and DNS failover, so we can rebuild or switch over."

"I start from a small, pinned base image, copy the dependency file first and install, so that layer is cached, then copy the code. I run as a non-root user, expose the port, and set the start command. I build with a meaningful tag, usually the git commit SHA, test it locally with docker run, then log in to the registry, like ECR or ACR, tag and push. I also add a .dockerignore so .git, local env files and secrets never go into the image."

"For a crash, I check the exit code and the logs of the dead container: docker ps -a, docker logs, and docker inspect for the exit code. Exit 1 is usually an app error like a missing env var. 127 means the start command wasn't found. 137 means it was killed, often for memory. For OOMKilled, inspect shows OOMKilled: true: either the memory limit is too low for normal use, or the app leaks memory, which I check by watching usage over time with docker stats or metrics. For image pull failures, I try the pull by hand: is the name and tag right, am I logged in to the private registry, am I hitting Docker Hub rate limits, and can the host even reach the registry over the network?"

"Multi-stage builds let me compile in one stage with all the build tools, then copy only the final artifact into a small runtime image. That makes it smaller, so it's faster to pull and starts faster, and it's more secure because there are no compilers or source code for an attacker to use, and fewer packages with vulnerabilities. Layers are cached, so I order the Dockerfile from least to most frequently changed to make builds fast. I also remember that deleting a file in a later layer doesn't remove it from the image, so secrets must never be copied in. For networking, the default bridge network isolates containers and uses port mapping. Host networking is a little faster but removes isolation. I'd only publish the ports that are needed."

"The Deployment says: run three replicas of this image, with these labels. Its selector must match the pod template labels. I set a specific image tag, resource requests and limits, readiness and liveness probes, and load environment variables from a ConfigMap. The Service selects pods by the same label and gives them a stable name and port inside the cluster. I apply it with kubectl apply -f, check with kubectl rollout status, and confirm the Service has endpoints."

"Environment variables from a ConfigMap are read only when the container starts, so changing the ConfigMap doesn't affect running pods. I need to restart them, ideally with kubectl rollout restart deployment, which replaces pods gradually without downtime. If the ConfigMap is mounted as a file, Kubernetes does update the file after a short delay, but the app still has to re-read it. In Helm we often add a checksum of the config as a pod annotation, so a config change automatically triggers a rollout. I'd keep the ConfigMap in git so the change is reviewed and can be rolled back."

"My first two commands are always kubectl describe pod, where I read the Events at the bottom, and kubectl logs --previous. Pending means the scheduler can't place the pod. The event says why: not enough CPU or memory for the requests, a taint or node selector mismatch, or a volume that can't bind. The fix is lower requests, or more nodes through the autoscaler. ImagePullBackOff means the image can't be pulled: wrong name or tag, missing registry permission, or no network route to the registry. CrashLoopBackOff means the container starts and dies. I check the previous logs and the exit code: 1 is an app error like missing config, 137 with OOMKilled means raise the memory limit or fix a leak. I also check whether a liveness probe is killing a healthy but slow-starting app."

"I follow the path: client → Ingress → Service → pods, and test each hop from inside the cluster with a debug pod. For the Service, the number one check is kubectl get endpoints. If it's empty, the selector labels don't match the pods, or the pods aren't Ready. Then I check that targetPort matches the container port. For the Ingress, I check the host and path rules, the ingress class, and the ingress controller's logs. For DNS, I run nslookup my-svc.my-namespace from a pod and check CoreDNS is healthy. For NetworkPolicy, if there's a default deny, I need an explicit allow, and egress to DNS on port 53 is often forgotten, so everything fails to resolve."

"'Running' only means the process is alive. It doesn't mean requests succeed. A 504 means a proxy in front, the load balancer or the ingress controller, waited for the app and gave up. So I'd find out which hop times out. First I check whether it's all requests or only some endpoints, and whether the timing lines up with a deploy. Then I test from inside: port-forward to a pod and curl it directly. If the pod answers fast, the problem is between the LB and the pod: empty Service endpoints, a NetworkPolicy, or a node security group. If the pod itself is slow, it's the app or its dependency, like a slow database or CPU throttling. I'd also compare timeouts: if the app needs 70 seconds but the ingress timeout is 60, every slow request becomes a 504."

"Requests are what a pod reserves. The scheduler uses them to decide which node has room. Limits are the maximum: if a container exceeds its memory limit it's OOMKilled, and if it hits its CPU limit it's throttled. The HPA watches metrics like CPU as a percentage of the request, and changes the number of replicas. When new replicas can't fit on existing nodes, they go Pending, and the Cluster Autoscaler or Karpenter adds nodes. When nodes are underused, it removes them. So the chain is: traffic up → HPA adds pods → pods Pending → autoscaler adds nodes. That's why requests must be realistic: too low and nodes get overloaded, too high and you pay for idle capacity."

"Helm is a package manager for Kubernetes. A chart is a set of templated YAML files plus a values.yaml with defaults. When I install it, I get a release, and every upgrade creates a new numbered revision, stored in the cluster. So I can see the history and roll back to any revision with helm rollback. For configuration, I keep one chart and a values file per environment, like values-dev.yaml and values-prod.yaml, in git. In CI I use helm upgrade --install with --atomic, which automatically rolls back if the upgrade fails. And I avoid editing Helm-managed resources by hand with kubectl, because the next upgrade will overwrite them."

"CoreDNS down means almost every service-to-service call fails, so this is a high-severity incident. I'd declare it and communicate first. Then restore DNS as fast as possible: check the CoreDNS pods and logs and the Corefile ConfigMap. The most likely reason it worked in staging but not prod is a difference: prod often has custom DNS config, like forwarding to corporate DNS, that the upgrade overwrote or that's incompatible with the new version. The fastest fix is to restore the previous CoreDNS config or add-on version that matches the cluster version. The control plane usually can't be downgraded, so I fix forward on the add-on. Then I verify with nslookup from a test pod and watch error rates recover. Afterwards: back up configs before upgrades, keep staging closer to prod, and upgrade in smaller steps."

"I never change main directly. I create a branch, make a small, focused change, commit it with a clear message, push, and open a pull request. CI runs checks, for example terraform plan or a manifest lint, and posts the result, and a teammate reviews it. After approval it's merged and the pipeline deploys it. For a merge conflict, I update my branch from main. Git marks the conflicting lines between <<<<<<<, ======= and >>>>>>>. I decide which version is correct, or combine them, remove the markers, test, and commit. If I'm not sure about the other person's change, I ask them."

"'Suddenly' means something changed, so I compare the last green run with the first red one. I read the log for the first error, not the last line. Then I ask what changed: our code; a dependency that isn't pinned and got a new version; the base Docker image; the runner image; or an expired credential or token. It can also be an external outage, a rate limit, or a full disk on a self-hosted runner. I re-run once to check whether it's flaky. Then I try to reproduce the failing step locally with the same versions. The fix is usually pinning versions, renewing the secret, or fixing the code, and adding a check so it fails earlier and more clearly next time."

"First I'd prove which version is answering, with a version endpoint or response header, and whether it's every user or just some. Then I'd walk the path from the user inward, because any layer can still point at the old version. Caches: the browser or the CDN serving cached content, which needs an invalidation. DNS: still pointing at the old load balancer or blue environment because of TTL. Load balancer: the new targets aren't registered, or the listener weights still send 100% to the old target group. Kubernetes: did the rollout really finish? Is the Service selector still matching old pods? Did the pipeline deploy to the wrong namespace or cluster? And a classic: the image tag didn't change, for example 'latest', so the nodes used the cached old image."

"Zero downtime: in Kubernetes, a rolling update with maxUnavailable: 0 and good readiness probes, so new pods only get traffic when they're ready, plus graceful shutdown so old pods finish their requests. For bigger risk, blue-green or canary. Automated rollback: the pipeline watches health after deploying. helm --atomic or kubectl rollout status failing triggers a rollback, and tools like Argo Rollouts or CodeDeploy can roll back when error-rate alarms fire. Approval gates: production deploys need a manual approval, for example GitHub Environments with required reviewers, a GitLab protected environment with a manual job, or a Jenkins input step. And database changes must be backward compatible, so old and new versions can run together."

"I wouldn't debug the script. In 5 minutes the goal is to restore service by the fastest safe path. First I tell the incident lead and call for help, because escalating early is right. Then I pick a manual way to get back to the last known good version that skips the broken script: kubectl rollout undo or helm rollback, re-running the pipeline with the previous image tag, switching the load balancer back to the blue environment, or turning off the feature flag. If none of that is possible, I reduce the impact, by scaling out or failing over. I verify with the dashboards, and I keep giving status updates. If we breach the SLA, we communicate it honestly. Afterwards: the postmortem, and testing rollbacks regularly, because an untested rollback isn't a rollback."

"First I'd measure: get the duration of every stage and job, because you can't optimise what you don't measure, and usually two or three steps take most of the time. Then the usual big wins: caching dependencies and Docker layers; running jobs in parallel instead of one after another, and splitting tests into shards; doing less, like running only the tests affected by changed paths, shallow git clones, and building the image once and promoting it through environments instead of rebuilding; and failing fast by putting lint and unit tests first. Slow end-to-end tests can move to after merge or a nightly run, as long as there's a smoke test before prod. And I'd remove flaky retries and sleeps."

"The state file is Terraform's record of which real resources it manages, so it must be shared, safe and never edited by hand. I store it in a remote backend: on AWS an S3 bucket with versioning and encryption, on Azure a Storage Account container. Locking stops two applies at the same time from corrupting it. On S3 that's the native lock file in newer Terraform versions, or a DynamoDB table in older setups. Azure uses blob leases automatically. To avoid concurrent runs, applies only happen from the CI pipeline, not laptops, and I split state per environment and component, so a network change and an app change don't block each other. force-unlock is only for a lock I'm sure is stale."

"Drift means the real infrastructure no longer matches the code, usually because someone changed it in the console. I detect it with terraform plan, ideally on a schedule in CI so we find out early. To resolve it safely, I don't just run apply. I read the plan and first ask: was the manual change intentional, like a hotfix during an incident? If it was, I update the code to match reality, so the plan becomes clean, with zero risk. If it was a mistake, I revert it with a targeted, reviewed apply in a quiet window. The danger signal is any resource marked replace (-/+), which can mean downtime. I'd stop and find another way, for example fixing the attribute that forces replacement, or using lifecycle rules. Then I prevent drift: console access read-only for prod, and changes only through PRs."

"That error means the resource exists in AWS but not in Terraform's state. Maybe someone created it by hand, or a previous apply half-failed, or it was removed from state. I don't delete the real resource. I import it into state, with terraform import or an import block, and adjust the code until terraform plan shows no changes. If it's a duplicate nobody needs, I confirm with the owner before removing it. If the code was just refactored and renamed, I use a moved block or terraform state mv instead of destroying and recreating."

"I acknowledge the alert so others know someone's on it, and open the runbook linked from the alert. I check the dashboard to understand the impact: how many errors, which endpoints, how many users. Then what changed: recent deploys, config changes, an AWS or Azure health event. If there was a recent deploy, I roll it back, because restoring service comes before finding the root cause. If it's bigger than I can handle, or past the runbook's time limit, I escalate to the on-call owner without waiting. I post short updates in the incident channel. When it's resolved, I confirm the metrics are back to normal and write up the timeline for the postmortem."

"I start on the service's Grafana dashboard with the golden signals: latency, traffic, errors, saturation. I look at p95 and p99 latency, not the average, because averages hide slow requests. Then I narrow it down: which service, which endpoint, which pod or node, and when it started. I overlay deploy annotations to see if it lines up with a release. Then I check saturation, like CPU throttling, memory, and database connections, and the latency of dependencies. Once I know where, I jump to logs or traces for the slow requests to find exactly what's slow."

"If the problem started right at the deploy and users are affected, I roll back first and investigate after. A successful deploy only means the pods started, not that the code is good. I confirm the timing matches the deploy on the dashboard, then roll back with kubectl rollout undo, helm rollback, or by redeploying the previous image through the pipeline, and watch the metrics recover. That also proves the cause. Then, without pressure, I compare the versions: code diff, new database queries, config or environment changes, resource limits, new dependencies. And I'd suggest adding a canary step and an automatic rollback on error rate, so next time it's caught with 5% of traffic, not 100%."

"I believe the user experience, and then I get data, rather than choosing a side. If people say it's slow and dashboards are green, the dashboards are probably measuring the wrong thing. First I'd get a concrete example: which page or API, when, for whom. Then I'd check what monitoring is missing: averages instead of p99, server-side timing that excludes the network or front end, health checks that only test 'is the process up', or one region or customer that's hidden in the totals. I'd reproduce it with curl timings or a trace, check dependencies like the database or a third-party API, then add an SLI that would have shown this, so the next time green really means good."

"An SLI is a measurement of what users feel, usually 'good events divided by all events', for example the percentage of requests that succeed and are faster than 300 ms. An SLO is the target for that SLI over a time window, like 99.9% over 30 days. The error budget is what's left: 0.1%, which is about 43 minutes of failure a month. If we're within budget, teams can ship fast. If the budget is burning too fast, we slow down releases and focus on reliability. An SLA is the contract version with customers, with penalties, so it's set looser than the SLO."

"OpenTelemetry is a vendor-neutral standard and set of SDKs for producing all three signals. Apps are instrumented once, and the data goes to an OTel Collector, which receives it, processes it, for example batching, filtering or adding tags, and exports it to whatever backend we use: Prometheus, Grafana Tempo and Loki, Datadog, CloudWatch and X-Ray, or Azure Monitor. The key to integration is context propagation: every request carries a trace ID across services, and that same trace ID is written into the logs. So I can go from a latency spike in a metric, to an example trace of a slow request, to the exact log lines for that request."

"First I'd confirm the app is really using that role, with aws sts get-caller-identity from where the app runs, because environment variables or an old credentials file can override it. Then I'd remember that AWS needs every layer to allow the request, and any explicit deny wins. So beyond the role's policy I check: the bucket policy, for example a deny unless the request comes over HTTPS or through a VPC endpoint; the KMS key policy if the bucket uses SSE-KMS, because the role also needs kms:Decrypt; SCPs from AWS Organizations; permission boundaries; a VPC endpoint policy; and whether the ARN is right: bucket vs bucket/*. CloudTrail shows the exact denied call, and the IAM Policy Simulator helps test."

"I assume the secret is compromised, because once it's pushed and cloned, deleting the commit doesn't take it back. Step one, immediately: revoke or rotate the secret at its source, like deactivating the AWS access key or rotating the database password, and update the apps that use it through the secrets manager. Step two: check the audit logs, like CloudTrail, for any use of that key since the leak. Step three: remove it from the code and, if policy requires, from git history with git filter-repo or BFG, then force-push and ask everyone to re-clone. Step four: report it to security as an incident. Step five: prevent it: enable GitHub secret scanning and push protection, add a pre-commit hook like gitleaks, and use short-lived credentials like OIDC so there are no long-lived keys to leak."

"Secrets live in one managed store, like AWS Secrets Manager or Azure Key Vault, never in git, images or plain config. In CI/CD, I avoid long-lived cloud keys entirely: GitHub Actions uses OIDC to assume an IAM role or federate to Azure, and any remaining pipeline secrets are scoped to an environment and masked in logs. In Kubernetes, native Secrets are only base64, so I enable encryption at rest with KMS and restrict access with RBAC. Better still, I sync from the secret store with the External Secrets Operator or the Secrets Store CSI driver. Pods access cloud services with workload identity, like IRSA or EKS Pod Identity, or Azure Workload Identity, instead of keys. And I rotate secrets regularly."

"I'd 'shift left': scan as early as possible, so problems are cheap to fix. On every pull request: a secret scan like gitleaks, a dependency scan like Dependabot or Snyk, and an IaC scan like Checkov or Trivy config on Terraform and Kubernetes YAML. After the image is built: an image scan with Trivy, Grype, ECR scanning or Defender for Containers. The pipeline fails on critical or high findings with a known fix, and lower ones become tickets, so developers aren't blocked by noise. Optionally, sign images and have an admission controller like Kyverno only allow signed, scanned images into the cluster."

"To restore: confirm it's really an AZ issue with the AWS Health Dashboard, then move capacity to the healthy AZs. If the app is in an Auto Scaling Group across several AZs, it should replace instances automatically. I'd check it's doing so, and raise desired capacity if the remaining AZs are overloaded. A Multi-AZ RDS database fails over on its own in a minute or two. If something was single-AZ, I'd restore it in another AZ from the latest snapshot or AMI. To improve: run across at least two or three AZs with enough spare capacity to lose one, Multi-AZ databases, stateless app servers, load balancer health checks, everything in IaC, and practise failure with game days."

"The principle is 'no single point of failure'. In one region: DNS, then a load balancer across at least two Availability Zones, an Auto Scaling Group or Kubernetes nodes spread across those zones, stateless app servers, a Multi-AZ managed database, and S3 or Blob for files, which are already replicated. Health checks everywhere, so failed parts are removed automatically, and everything defined in code. If the business needs more, add a second region with data replication and DNS failover. Then I'd test it, because untested HA is a guess. The picture in Chapter 2 is exactly this design."

"Recovery first. If versioning was on, a delete only adds a 'delete marker', so I remove the marker or copy back the previous version and the data returns. If the whole bucket was deleted, the data is gone unless we have replication to another bucket or an AWS Backup copy, so I'd restore from that. To investigate, I use CloudTrail: DeleteBucket is logged by default, but individual DeleteObject calls only appear if data events are enabled, otherwise S3 server access logs. Then I find out who or what did it and why. Prevention: versioning, MFA delete or Object Lock for critical data, a bucket policy denying deletes, least-privilege IAM, and backups in another account."

"It depends on the DR strategy chosen in advance, based on RTO, how long we can be down, and RPO, how much data we can lose. During the event, I follow the DR runbook: declare the disaster, then promote the database copy in the second region, like a cross-region read replica or Aurora Global Database. I scale up the infrastructure there, which already exists in IaC, and switch DNS with Route 53 failover records or Application Recovery Controller. Then I verify with smoke tests and communicate. Failback later is planned just as carefully. The key point: DR only works if it's been practised."

"I'd build it in layers. Infrastructure: managed Kubernetes, EKS or AKS, created with Terraform, with nodes in private subnets across three AZs. Scaling: the HPA for pods and Karpenter or the Cluster Autoscaler for nodes, with sensible requests. Traffic: an ingress controller behind a cloud load balancer with WAF and TLS. Security: RBAC, network policies, pod identity instead of keys, secrets from a secrets manager, image scanning and admission policies. Delivery: GitOps with Argo CD or Flux, so the cluster state is in git. Observability: Prometheus and Grafana, central logs, and alerts on SLOs. DR: everything is in code, so a cluster can be rebuilt; Velero backs up cluster resources and volumes, and data is replicated to a second region."

"First I'd find where, using Cost Explorer at daily granularity, grouped by service, then by usage type, account, region and tags. Cost Anomaly Detection may have flagged it already. 'No deployments' doesn't mean no changes, so I'd consider four groups. Security: leaked keys used for crypto mining, often in unusual regions with GPU instances. If I see that, it's a security incident first: I'd revoke the keys and terminate the resources. Automation: autoscaling runaway, a recursive Lambda, a scheduled job, a log-level change causing huge CloudWatch Logs ingestion. Traffic: a spike or a bot driving data transfer or NAT gateway charges. Pricing: a Savings Plan or Reserved Instance that expired, so the same usage is now billed on-demand, or a one-time upfront charge. Then I use CloudTrail to see who created what, fix it, and set budgets and alerts so we catch it within hours next time."

"First I'd understand what they need: which services, how long, what data, who needs access. Then I'd build it from a reusable Terraform module, not by hand, so it's consistent and easy to delete later. It goes in an isolated place: a separate account, or a subscription and resource group in Azure, or at least a separate VPC or namespace, so testing can't hurt production. It gets least-privilege access for the team, tags for owner, project and expiry date, a budget alert, and an auto-shutdown schedule for nights and weekends. Then I'd give them a short README: how to access it, how to deploy, who to ask, and when it will be removed."

"That's fair. I haven't held the engineer title yet. But I've worked with cloud infrastructure every day from the cost and usage side: I've analysed EC2 and storage usage, explained network and data transfer costs, and worked with engineering teams to rightsize and clean up resources safely. So I already understand how these systems are built and why. In the last few weeks I've been closing the hands-on gap in my lab: I've containerised an app, deployed it on a local Kubernetes cluster with a Deployment, Service and ConfigMap, broken it on purpose and fixed it, and provisioned resources with Terraform. This role is described as assisting and growing, and I learn fast. On top of that, I'd bring cost awareness to every change, which saves the team money from day one."

"Situation: in FinOps, I often had to ask engineering teams to change their resources, for example rightsizing or deleting idle environments, and teams were worried about breaking things. Task: reduce cost without hurting reliability. Action: instead of sending a list, I sat with them, showed the utilisation data, asked about their peak periods, and we agreed on a safe change with a rollback plan and a review date. Result: we saved [X%] with no incidents, and they started asking me for advice proactively. As a cloud engineer, I'd do the same: understand what developers need, explain infrastructure limits in simple terms, document things so they can self-serve, and follow up."

"I write it for someone who's tired at 3 a.m. and has never seen the system. It starts with what the alert or task is, how severe it is, and who owns it. Then numbered steps with copy-paste commands and the expected result of each, how to verify it worked, how to roll back, and when and who to escalate to. I keep it in Markdown in git next to the code, so it's reviewed like code, and I add a 'last reviewed' date. After every incident I update it with what we learned. And I test it by having someone else follow it."

"What happened: [one or two sentences: what you changed, and what broke]. How I noticed and fixed it: [who alerted, how fast, what you did, and that you told people straight away]. Root cause: [the real reason, e.g. no review, no testing, an assumption]. What I learned: [one lesson]. What changed after: [a process you put in place: a checklist, a dry-run, a tag check, peer review, a runbook]."