DevOps & Kubernetes AI Prompts: Automate Infrastructure Faster in 2026

You are a senior Kubernetes engineer who has run production clusters at scale.

Write a complete Kubernetes Deployment manifest for a Node.js API service:

Deployment requirements:
- replicas: 3 (for HA)
- Strategy: RollingUpdate with maxUnavailable: 0, maxSurge: 1 (zero-downtime deployments)
- Resource requests: cpu: 100m, memory: 128Mi
- Resource limits: cpu: 500m, memory: 512Mi (REQUIRED — explain why missing limits cause node starvation)
- Image: specify imagePullPolicy: Always with SHA digest (not mutable tag)

Probes (explain the difference before writing each):
- startupProbe: GET /health, failureThreshold: 30, periodSeconds: 10 (slow start tolerance)
- readinessProbe: GET /health, failureThreshold: 3, periodSeconds: 5 (traffic control)
- livenessProbe: GET /health, failureThreshold: 3, periodSeconds: 15 (restart trigger)

Security context (REQUIRED on every production deployment):
- runAsNonRoot: true, runAsUser: 1001
- readOnlyRootFilesystem: true
- allowPrivilegeEscalation: false
- capabilities: drop: [ALL]

Also write: Service (ClusterIP), HorizontalPodAutoscaler (min:3, max:10, CPU 70%), PodDisruptionBudget (minAvailable: 2).

Add a comment on every field explaining why it exists.

You are a Helm chart expert.

Create a production Helm chart for a Node.js microservice:

Chart structure:
charts/my-service/
  Chart.yaml (name, version, appVersion, description)
  values.yaml (all defaults)
  templates/
    deployment.yaml
    service.yaml
    ingress.yaml
    hpa.yaml
    pdb.yaml
    configmap.yaml
    secret.yaml (sealed-secrets or external-secrets reference)
    serviceaccount.yaml
    _helpers.tpl (common labels, selector labels, name truncation)

values.yaml defaults:
- replicaCount: 3
- image.repository, image.tag (overridden per environment)
- resources.requests and resources.limits
- autoscaling.enabled, minReplicas, maxReplicas, targetCPU
- ingress.enabled, ingress.hosts, ingress.tls
- env: {} (map of environment variables from ConfigMap or Secret)
- probes: liveness and readiness enabled by default

Environment overrides (values-prod.yaml):
- Higher resource limits, more replicas, different image tag, production ingress host

Provide:
1. All template files with proper Go templating
2. NOTES.txt explaining post-install steps
3. Helm install command for staging and production
4. How to use helm diff before upgrading

You are a GitHub Actions expert building production CI/CD pipelines.

Write a complete GitHub Actions workflow for a Node.js microservice deployed to Kubernetes:

Trigger: push to main, PRs to main, manual dispatch (workflow_dispatch)

Jobs:

test (every push and PR):
- ubuntu-latest
- Setup Node 22, pnpm cache by pnpm-lock.yaml hash
- pnpm install --frozen-lockfile
- TypeScript compile check, ESLint, Prettier
- Jest unit + integration tests (Testcontainers PostgreSQL via Docker-in-Docker)
- Upload coverage to Codecov
- Fail if coverage drops below 80%

security (parallel to test):
- npm audit --audit-level=high
- Trivy image scan: scan Dockerfile for OS vulnerabilities (CRITICAL severity fails build)
- SARIF output uploaded to GitHub Security tab

build (after test passes, main branch only):
- Multi-stage Docker build with BuildKit cache
- Tag with: git SHA (immutable) + 'latest'
- Push to AWS ECR (OIDC auth — no long-lived secrets)
- Image size check: fail if > 200MB

deploy-staging (after build):
- Update Helm values: image.tag = git SHA
- helm upgrade --install my-service charts/my-service -f values-staging.yaml
- Wait for rollout: kubectl rollout status deployment/my-service
- Smoke test: curl staging.api.example.com/health — assert 200

deploy-production (manual approval gate, after deploy-staging):
- environment: production (with required reviewers in GitHub)
- Same helm upgrade to production namespace
- Slack notification: success with deploy URL, failure with rollback command

Secrets: use OIDC for AWS (no access keys), GitHub Environment Secrets for Slack.

You are a Terraform expert for AWS infrastructure.

Write Terraform (1.8+) to provision a production Kubernetes application infrastructure on AWS:

Modules to create:

module/networking:
- VPC with public, private, and database subnets across 3 AZs
- NAT Gateway (one per AZ for HA)
- VPC flow logs to CloudWatch

module/eks:
- EKS cluster 1.30 with managed node groups
- Node groups: general (t3.medium, min:3, max:10), memory-optimised for databases
- IRSA (IAM Roles for Service Accounts) for pods to access AWS services
- aws-load-balancer-controller, cluster-autoscaler, external-dns via Helm

module/rds:
- PostgreSQL 16 Multi-AZ RDS instance
- Subnet group in private subnets
- Security group: only allow from EKS security group on 5432
- Automated backups 7 days, encryption at rest
- Parameter group for performance tuning (shared_buffers, work_mem)

module/elasticache:
- Redis 7 cluster mode disabled (single primary + replica)
- Private subnets only
- Auth token (password) stored in AWS Secrets Manager

Global:
- All resources tagged: Environment, Team, CostCenter, ManagedBy=terraform
- Remote state: S3 bucket + DynamoDB table for locking
- Variables with validation blocks for required values
- Outputs: cluster endpoint, RDS endpoint, ECR URLs

Output: all module files with variables.tf, main.tf, outputs.tf, and root configuration.

You are a Kubernetes observability expert.

Set up production monitoring for a Node.js microservice on Kubernetes:

Prometheus scraping:
- ServiceMonitor (Prometheus Operator CRD) for the microservice
- Expose /metrics endpoint: express-prometheus-middleware for Node.js
- Custom metrics: http_request_duration_seconds (histogram), http_requests_total (counter by status), active_connections (gauge), background_job_duration_seconds

Prometheus Alert Rules (PrometheusRule CRD):
- Critical: error rate > 1% for 5 minutes (5xx / total)
- Critical: pod unavailable (all replicas down)
- Warning: P99 latency > 500ms for 10 minutes
- Warning: pod restarts > 3 in 5 minutes
- Info: deployment rollout in progress

Grafana Dashboard (JSON model for 4 panels):
- Request rate (requests per second by status code)
- Error rate percentage (5xx / total, red threshold at 1%)
- Latency percentiles (P50, P95, P99 on one graph)
- Infrastructure (CPU usage, memory usage, pod count)

AlertManager routing:
- Critical → PagerDuty (immediate)
- Warning → Slack #alerts channel
- Resolved notifications on both channels

Output: ServiceMonitor YAML, PrometheusRule YAML, AlertManager config, and Grafana dashboard JSON.

You are a container security expert.

Write a security-hardened multi-stage Dockerfile for a Node.js API:

Stage 1 (deps):
- node:22-alpine as base
- Set npm config loglevel=error, no-fund, no-audit (faster build)
- COPY package.json pnpm-lock.yaml
- RUN pnpm install --frozen-lockfile --prod (production only)

Stage 2 (build):
- COPY source, run tsc
- RUN pnpm install --frozen-lockfile (includes dev deps for build)

Stage 3 (production — most important):
- Base: gcr.io/distroless/nodejs22-debian12 (Google Distroless — no shell, no package manager, minimal CVE surface)
- Alternative if distroless is too restrictive: node:22-alpine with security updates applied
- COPY from deps stage: /app/node_modules
- COPY from build stage: /app/dist
- USER nonroot:nonroot (distroless built-in non-root user, UID 65532)
- EXPOSE port via ENV, not hardcoded
- No COPY of .env files, secrets, or source code
- HEALTHCHECK CMD ["/nodejs/bin/node", "-e", "require('http').get('http://localhost:3000/health', r => process.exit(r.statusCode === 200 ? 0 : 1))"]

Security scan: show Trivy command to scan the final image and interpret the report.

After Dockerfile: explain attack surface reduction — why distroless has 90% fewer CVEs than ubuntu-based images.

You are a senior DevOps engineer specializing in GitOps with ArgoCD.

Design a complete GitOps deployment pipeline using ArgoCD + Kubernetes:

Repository structure (app-of-apps pattern):
- argocd/apps/: Application CRDs for each service
- argocd/projects/: AppProject definitions with source/destination restrictions
- k8s/services/{service-name}/: Kubernetes manifests per service (not Helm — plain YAML for simplicity)

ArgoCD configuration:
- App-of-apps: root Application watches argocd/apps/, auto-syncs child Applications
- Sync policy: automated sync (every 3 minutes) with selfHeal=true, prune=true
- Sync waves: wave 0 = namespaces + secrets (from Vault), wave 1 = databases, wave 2 = services
- Rollback strategy: manual rollback via argocd app rollback, automated on health check failure

Health checks:
- Custom health check for CronJob: healthy if last run succeeded
- Custom health check for PVC: healthy if not in Pending state

Environment promotion:
- staging: auto-sync from main branch
- production: manual sync, requires approval gate (ArgoCD RBAC: only prod-deployers group can sync)

External secrets: ExternalSecret CRD pulling from AWS Secrets Manager

Output: app-of-apps Application YAML, AppProject with RBAC, 2 example service Application CRDs, and the ExternalSecret for DB credentials.

You are a Kubernetes security engineer.

Harden a production Kubernetes cluster namespace for a multi-tenant SaaS:

Pod Security Admission (PSA):
- Enforce restricted policy on all production namespaces
- Audit on staging namespaces (log violations but don't block)
- Configuration: label namespaces with pod-security.kubernetes.io/enforce: restricted

NetworkPolicy:
- Default deny all ingress and egress for every namespace
- Allow: pods to DNS (port 53), pods to specific services within namespace, ingress from NGINX namespace only
- Block: all cross-namespace traffic except explicitly allowed

RBAC:
- Service accounts: each deployment gets its own ServiceAccount (not default)
- Minimal permissions: no cluster-admin anywhere, no wildcards in Rules
- Role: app-reader (get/list/watch pods, configmaps in namespace), app-writer (above + create/update)

Resource limits (required by PSA restricted):
- Every container: requests and limits for CPU and memory
- LimitRange: default limits if not specified (CPU: 100m request/500m limit, Memory: 128Mi/512Mi)
- ResourceQuota: per-namespace limits (total CPU: 10 cores, Memory: 20Gi, pods: 50)

Security context (required by PSA restricted):
- runAsNonRoot: true, runAsUser: 1000, readOnlyRootFilesystem: true
- allowPrivilegeEscalation: false, capabilities: drop ALL
- seccompProfile: RuntimeDefault

Output: NetworkPolicy manifests (default-deny + allow rules), RBAC Role + RoleBinding, ResourceQuota, LimitRange, and a compliant Deployment example with all security contexts set.

Context for all DevOps/K8s prompts in this session:
- Kubernetes: 1.32+ — all apiVersions must be current
  Never: apps/v1beta1, extensions/v1beta1 (removed years ago)
- Terraform: 1.9+ (OpenTofu compatible), always pin provider versions
- CI/CD: GitHub Actions with reusable workflows
- REQUIRED in every Kubernetes manifest:
  resources.requests AND resources.limits (both CPU and memory — no exceptions)
  livenessProbe AND readinessProbe (different purposes — explain the difference)
  securityContext at pod AND container level:
    runAsNonRoot: true, runAsUser: 1001
    readOnlyRootFilesystem: true
    allowPrivilegeEscalation: false
    capabilities: drop: ["ALL"]
- Container images: never use latest tag — pin to semantic version or digest
- Secrets: never hardcode in YAML — reference from K8s Secret or external secrets operator