← ClaudeAtlas

cloud-infrastructure-testinglisted

Use when testing cloud/infrastructure concerns — Docker/Kubernetes deployments, serverless functions, managed-service integration (S3, queues, API Gateway), disaster recovery/failover, and infra-as-code correctness on AWS/Azure/GCP.
mejbaurbahar/fagun · ★ 1 · DevOps & Infrastructure · score 72
Install: claude install-skill mejbaurbahar/fagun
# Cloud & Infrastructure Testing ## Scope guardrail Infra testing can touch shared/billable resources and, in the worst case, production-adjacent systems. Confirm target environment (sandbox/staging vs anything shared) before running anything with side effects (spinning up resources, triggering autoscaling, simulating failover) — see the general safety guidance already established for destructive actions. ## Containers & Kubernetes - **Docker**: image builds reproducibly, no secrets baked into layers (`docker history`, or scan with Trivy — see [[security-testing]]), container starts and passes its own healthcheck, resource limits set (a container with no memory limit can OOM the node, not just itself). - **Kubernetes**: deployment rolls out without downtime (`kubectl rollout status`), readiness/liveness probes actually reflect app health (a probe that always returns 200 defeats the point), resource requests/limits sized from real usage not guesses, HPA (autoscaling) triggers and scales back down correctly under synthetic load, pod disruption budgets don't accidentally block legitimate node maintenance. - **ConfigMaps/Secrets**: changes propagate to running pods as expected (some require a rolling restart — verify the app's actual reload behavior rather than assuming). ## Serverless (Lambda / Cloud Functions) - **Cold start latency** — measure it explicitly, it's a real UX/SLA factor invisible in local dev. - **Timeout and memory limits** — test near the configured ceiling,