Kubernetes manifests, Helm charts, scaling strategies, service mesh, and cluster management
Kubernetes Specialist
Purpose
Design and produce production-grade Kubernetes configurations including deployments, services, ingress, Helm charts, autoscaling, RBAC, and operational patterns for managing containerized workloads at scale.
# Rolling restart
kubectl rollout restart deployment/app -n production
# Check rollout status
kubectl rollout status deployment/app -n production
# View pod resource usage
kubectl top pods -n production --sort-by=memory
# Debug failing pod
kubectl describe pod <pod-name> -n production
kubectl logs <pod-name> -n production --previous
# Port forward for debugging
kubectl port-forward svc/app-service 3000:80 -n production
Guide container orchestration decisions and implementations beyond Kubernetes. Covers Docker Swarm, HashiCorp Nomad, AWS ECS/Fargate, container networking, service discovery, and health checks. Helps choose the right orchestrator for the team's complexity budget.
Platform Comparison
Feature
Docker Swarm
Nomad
ECS/Fargate
Kubernetes
Complexity
Low
Medium
Medium
High
Learning curve
Shallow
Moderate
Moderate (AWS-specific)
Steep
Multi-cloud
Yes
Yes
No (AWS only)
Yes
Non-container workloads
No
Yes (VMs, Java, batch)
No
Via CRDs
Built-in service mesh
No
Consul Connect
App Mesh
Istio/Linkerd
Auto-scaling
Limited
Autoscaler plugin
Native
HPA/VPA/KEDA
Best for
Small teams, simple apps
Mixed workloads, HashiStack
AWS-native teams
Large-scale, multi-tenant
Key Patterns
Docker Swarm
Stack deployment — Use docker-compose.yml with deploy directives:
# docker-compose.yml (Swarm mode)version:'3.8'services:api:image:myapp/api:latestdeploy:replicas:3update_config:parallelism:1delay:10sorder:start-first# Blue-green within rolling updatefailure_action:rollbackrollback_config:parallelism:0# Rollback all at oncerestart_policy:condition:on-failuredelay:5smax_attempts:3resources:limits:cpus:'0.5'memory:512Mreservations:cpus:'0.25'memory:256Mhealthcheck:test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval:15stimeout:5sretries:3start_period:30snetworks:-app-networknginx:image:nginx:alpineports:-"80:80"-"443:443"deploy:mode:global# One per nodeplacement:constraints:-node.role==managernetworks:-app-networknetworks:app-network:driver:overlayattachable:true
# Deploy the stack
docker stack deploy -c docker-compose.yml myapp
# Scale a service
docker service scale myapp_api=5
# Rolling update
docker service update --image myapp/api:v2.0 myapp_api
# View service status
docker service ps myapp_api
# Docker Swarm: Built-in DNS resolution# Services resolve each other by name within overlay networkservices:api:environment:-REDIS_HOST=redis# Resolves via Docker DNS-DB_HOST=postgresredis:image:redis:7-alpinepostgres:image:postgres:16-alpine
Match orchestrator to team size — Swarm for small teams (<5 services), ECS for AWS shops, Nomad for mixed workloads, k8s for large-scale.
Always define health checks — Every container needs a health endpoint; orchestrators use it for routing and restart decisions.
Use rolling updates with rollback — Configure start-first ordering and automatic rollback on failure.
Separate liveness from readiness — Liveness = "is the process alive?"; readiness = "can it serve traffic?".
Set resource limits — Prevent a single container from consuming all host resources.
Use overlay networks — Isolate service traffic and enable cross-node communication.
Externalize configuration — Use environment variables, secrets managers, or config maps rather than baking config into images.
Log to stdout/stderr — Let the orchestrator collect and route logs; do not write to files inside containers.
Common Pitfalls
Pitfall
Problem
Fix
No health checks
Orchestrator routes traffic to broken containers
Define HTTP health checks with appropriate intervals
No resource limits
One service starves others
Set CPU and memory limits on every container
Hardcoded service addresses
Breaks when containers move
Use DNS-based service discovery
Missing rollback config
Bad deploys require manual intervention
Configure auto_revert (Nomad) or deployment_circuit_breaker (ECS)
Single replica in production
Zero availability during deploys
Run at least 2 replicas with rolling updates
No graceful shutdown
Requests dropped during redeploy
Handle SIGTERM, drain connections, use stop_grace_period
From terraform
Infrastructure as Code with Terraform, module design, state management, provider patterns, and drift detection
Terraform Specialist
Purpose
Design modular, maintainable, and safe Terraform configurations for managing cloud infrastructure. This skill covers HCL authoring, module patterns, state management, provider configuration, CI integration, and drift detection strategies.
Configure Nginx for reverse proxying, load balancing, SSL termination, caching, rate limiting, and security hardening. This skill covers both traditional server deployments and container-based Nginx configurations.
Linux server management, systemd, networking, troubleshooting, security hardening, and performance tuning
Linux Administration Specialist
Purpose
Manage Linux servers including initial setup, security hardening, service management, networking, performance tuning, and troubleshooting. This skill covers Ubuntu/Debian and RHEL/CentOS distributions with systemd.
DNS record management, propagation debugging, Cloudflare DNS configuration, SSL/TLS setup, domain migration, and email authentication records (SPF, DKIM, DMARC)
DNS & SSL/TLS Skill
Purpose
DNS is the foundation of every web application's reachability. Misconfigured DNS causes downtime, email deliverability failures, and SSL errors that are notoriously difficult to debug. This skill covers record types, Cloudflare DNS setup, SSL/TLS certificate management, email authentication (SPF/DKIM/DMARC), domain migrations, and propagation troubleshooting.
Key Concepts
DNS Record Types
Type
Purpose
Example Value
When to Use
A
Maps domain to IPv4
93.184.216.34
Pointing to a server with a static IP
AAAA
Maps domain to IPv6
2606:2800:220:1:...
IPv6-enabled servers
CNAME
Alias to another domain
app.vercel.app
Pointing subdomains to hosting providers
MX
Mail server routing
10 mx1.emailprovider.com
Email delivery configuration
TXT
Arbitrary text data
v=spf1 include:...
Domain verification, SPF, DKIM, DMARC
NS
Nameserver delegation
ns1.cloudflare.com
Delegating DNS to a provider
CAA
Certificate authority authorization
0 issue "letsencrypt.org"
Restricting which CAs can issue certs
SRV
Service location
10 5 5060 sip.example.com
Service discovery (rare in web apps)
Important Rules
CNAME cannot coexist with other records at the same name (the "CNAME at apex" problem). Use ALIAS/ANAME or Cloudflare's CNAME flattening for root domains.
TTL (Time to Live) controls how long resolvers cache a record. Lower TTL = faster propagation but more DNS queries.
Propagation is not instant — it depends on the old TTL. If TTL was 86400 (24h), changes can take up to 24 hours.
Workflow
Step 1: Configure DNS Records
Vercel Deployment (Typical Setup)
# Root domain (@ or example.com)
Type: A
Name: @
Value: 76.76.21.21
TTL: Auto (or 300)
# www subdomain
Type: CNAME
Name: www
Value: cname.vercel-dns.com
TTL: Auto
# API subdomain (if separate)
Type: CNAME
Name: api
Value: cname.vercel-dns.com
TTL: Auto
Cloudflare with Proxy (Orange Cloud)
# Root domain — Cloudflare proxied (orange cloud)
Type: A
Name: @
Value: <origin server IP>
Proxy: Proxied (orange cloud)
TTL: Auto
# www — CNAME to root, proxied
Type: CNAME
Name: www
Value: example.com
Proxy: Proxied
# API — DNS only (gray cloud) if origin handles TLS
Type: A
Name: api
Value: <api server IP>
Proxy: DNS only (gray cloud)
Cloudflare API (Terraform or Script)
# Create a DNS record via Cloudflare API
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/dns_records" \
-H "Authorization: Bearer ${CF_API_TOKEN}" \
-H "Content-Type: application/json" \
--data '{
"type": "CNAME",
"name": "app",
"content": "cname.vercel-dns.com",
"ttl": 1,
"proxied": false
}'
# Terraform — Cloudflare DNS
resource "cloudflare_record" "app" {
zone_id = var.cloudflare_zone_id
name = "app"
content = "cname.vercel-dns.com"
type = "CNAME"
ttl = 1 # Auto when proxied
proxied = false
}
resource "cloudflare_record" "root" {
zone_id = var.cloudflare_zone_id
name = "@"
content = "76.76.21.21"
type = "A"
proxied = true
}
Step 2: SSL/TLS Configuration
Cloudflare SSL Modes
Off → No encryption (NEVER use this)
Flexible → HTTPS client↔Cloudflare, HTTP Cloudflare↔origin (insecure!)
Full → HTTPS everywhere, but origin cert not validated
Full (Strict) → HTTPS everywhere, origin cert must be valid ← USE THIS
Cloudflare Origin Certificate
# Generate an origin certificate via Cloudflare dashboard or API# Valid for up to 15 years, free, trusted ONLY by Cloudflare# On origin server (nginx):
ssl_certificate /etc/ssl/cloudflare-origin.pem;
ssl_certificate_key /etc/ssl/cloudflare-origin-key.pem;
# Allow Google Workspace and Resend to send email on your behalf
Type: TXT
Name: @
Value: v=spf1 include:_spf.google.com include:amazonses.com ~all
# Breakdown:
# v=spf1 — SPF version
# include:... — Authorize these senders
# ~all — Soft fail others (use -all for hard fail after testing)
DKIM (DomainKeys Identified Mail)
# Provider gives you a CNAME or TXT record
# Example for Resend:
Type: CNAME
Name: resend._domainkey
Value: resend._domainkey.resend.dev
# Example for Google Workspace:
Type: TXT
Name: google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkq... (public key from admin console)
DMARC (Domain-based Message Authentication)
# Start with monitoring mode (p=none), then tighten
Type: TXT
Name: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; pct=100
# After confirming legitimate mail passes:
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100
# After full confidence:
Value: v=DMARC1; p=reject; rua=mailto:dmarc@example.com; pct=100
Step 4: Domain Migration (Zero-Downtime)
Migration Timeline:
Day -7: Lower TTL on ALL records being changed
Old TTL: 86400 (24h) → New TTL: 300 (5 min)
Day -1: Verify low TTL has propagated
$ dig example.com +short | head -1
# Confirm TTL is 300 in responses
Day 0: Update DNS records to new values
- Change A/CNAME records to new hosting provider
- Monitor for errors in both old and new infrastructure
Day 0 + 1h: Verify propagation across regions
$ dig @8.8.8.8 example.com # Google DNS
$ dig @1.1.1.1 example.com # Cloudflare DNS
$ dig @208.67.222.222 example.com # OpenDNS
Day +3: Old infrastructure can be decommissioned
Day +7: Raise TTL back to production values
New TTL: 3600 (1h) or 86400 (24h)
# "DNS_PROBE_FINISHED_NXDOMAIN" → Domain does not resolve at all
dig example.com NS +short
# If empty: nameservers not delegated. Check registrar NS records.# "ERR_SSL_VERSION_OR_CIPHER_MISMATCH" → SSL mode conflict# Cloudflare Flexible SSL + origin expecting HTTPS = redirect loop# Fix: Set Cloudflare SSL to "Full (Strict)" and install origin cert# "Too many redirects" → HTTP↔HTTPS redirect loop# Cloudflare "Always Use HTTPS" + origin 301 to HTTPS = infinite loop# Fix: Set Cloudflare SSL to "Full (Strict)", remove origin HTTP→HTTPS redirect
Best Practices
Always use Full (Strict) SSL on Cloudflare — "Flexible" mode means traffic between Cloudflare and your origin is unencrypted.
Lower TTL before migrations — Drop to 300s at least 48 hours before changing records, so old caches expire before the switch.
Set CAA records — Prevent unauthorized certificate issuance by restricting which CAs can issue for your domain.
Deploy DMARC in stages — Start with p=none to monitor, then p=quarantine, then p=reject once you confirm no legitimate mail is failing.
Use CNAME for subdomains, A for apex — CNAMEs are more flexible (they follow the target if the IP changes), but cannot be used at the zone apex without provider support.
Add both IPv4 and IPv6 — Modern clients prefer AAAA records. Dual-stack avoids connectivity issues.
Document your DNS zone — Keep a table of all records and their purpose. DNS changes without context cause debugging nightmares months later.
Test email authentication — Use mail-tester.com or mxtoolbox.com to verify SPF, DKIM, and DMARC pass before relying on them.
Common Pitfalls
Pitfall
Symptom
Fix
CNAME at zone apex
Registrar rejects the record or resolution fails
Use A record pointing to IP, or use Cloudflare/Route53 ALIAS/ANAME flattening
Cloudflare Flexible SSL
Infinite redirect loop or mixed content
Switch to Full (Strict) and install an origin certificate
High TTL during migration
Users stuck on old IP for hours/days
Lower TTL to 300s at least 48 hours before migration
Missing SPF record
Emails land in spam or get rejected
Add v=spf1 include:<provider> ~all TXT record
SPF too many lookups
SPF validation fails (max 10 DNS lookups)
Consolidate includes; use ip4:/ip6: for known IPs instead of include:
Proxying non-HTTP through Cloudflare
SSH, database connections fail
Set DNS-only (gray cloud) for non-HTTP services
Wildcard cert without DNS challenge
Certbot HTTP challenge fails for *.example.com
Use --preferred-challenges dns with certbot for wildcard certificates
Forgot to update nameservers at registrar
All DNS changes at new provider are ignored
Update NS records at the registrar to point to the new DNS provider's nameservers
Provide expert guidance on designing, configuring, and managing multi-environment deployment pipelines. Covers environment architecture (development, staging, preview, production), promotion strategies, per-environment configuration, and environment parity to minimize "works on staging, breaks in prod" failures.
Key Patterns
Environment Architecture
A typical environment ladder for production applications:
local -> preview (per-PR) -> staging -> production
Environment
Purpose
Data
Lifetime
Access
Local
Developer workstation
Seed/mock data
Permanent
Developer only
Preview
Per-PR verification
Seed or staging snapshot
Ephemeral (PR lifecycle)
Team
Staging
Pre-production validation
Sanitized production copy
Permanent
Team + QA
Production
Live users
Real data
Permanent
Public
Per-Environment Configuration
Use environment variables with validation at startup:
# Set environment variables per environment
vercel env add DATABASE_URL production
vercel env add DATABASE_URL preview
vercel env add DATABASE_URL development
# Pull env vars for local development
vercel env pull .env.local
# Link to specific environments
vercel --prod # Deploy to production
vercel # Deploy to preview
Vercel vercel.json with environment-specific headers:
Design efficient, reliable CI/CD pipelines with GitHub Actions. Covers matrix builds, dependency caching, artifact management, deployment gates with manual approvals, canary deployments, and rollback strategies.
Key Patterns
Optimized CI Pipeline
# .github/workflows/ci.ymlname:CIon:pull_request:branches: [main]
push:branches: [main]
concurrency:group:${{github.workflow}}-${{github.ref}}cancel-in-progress:truejobs:# Fast checks first — fail earlylint:runs-on:ubuntu-lateststeps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:node-version:20cache:'pnpm'-run:pnpminstall--frozen-lockfile-run:pnpmlint-run:pnpmtype-checktest:runs-on:ubuntu-latestneeds:lint# Only test if lint passesstrategy:fail-fast:falsematrix:shard: [1, 2, 3, 4]
steps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:node-version:20cache:'pnpm'-run:pnpminstall--frozen-lockfile-run:pnpmtest--shard=${{matrix.shard}}/4-uses:actions/upload-artifact@v4if:failure()with:name:test-results-${{matrix.shard}}path:test-results/retention-days:7build:runs-on:ubuntu-latestneeds:lintsteps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:node-version:20cache:'pnpm'-run:pnpminstall--frozen-lockfile# Cache Next.js build-uses:actions/cache@v4with:path:.next/cachekey:nextjs-${{runner.os}}-${{hashFiles('pnpm-lock.yaml')}}-${{hashFiles('**/*.ts','**/*.tsx')}}restore-keys:|
nextjs-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}-
nextjs-${{ runner.os }}-
-run:pnpmbuild-uses:actions/upload-artifact@v4with:name:build-outputpath:.next/retention-days:1
Matrix Builds
# Test across multiple Node versions and OSjobs:test-matrix:runs-on:${{matrix.os}}strategy:fail-fast:falsematrix:os: [ubuntu-latest, macos-latest]
node: [18, 20, 22]
exclude:-os:macos-latestnode:18# Skip older Node on macOSinclude:-os:ubuntu-latestnode:20coverage:true# Only collect coverage oncesteps:-uses:actions/checkout@v4-uses:actions/setup-node@v4with:node-version:${{matrix.node}}cache:'pnpm'-run:pnpminstall--frozen-lockfile-run:pnpmtest${{matrix.coverage&&'--coverage'||''}}-if:matrix.coverageuses:actions/upload-artifact@v4with:name:coveragepath:coverage/
# .github/workflows/deploy.ymlname:Deployon:push:branches: [main]
jobs:build-and-test:# ... build and test steps ...deploy-staging:needs:build-and-testruns-on:ubuntu-latestenvironment:name:stagingurl:https://staging.example.comsteps:-uses:actions/download-artifact@v4with:name:build-output-run:./deploy.shstaging# Smoke tests on stagingsmoke-test:needs:deploy-stagingruns-on:ubuntu-lateststeps:-uses:actions/checkout@v4-run:pnpmexecplaywrighttest--config=e2e/smoke.config.tsenv:BASE_URL:https://staging.example.com# Manual approval gate before productiondeploy-production:needs:smoke-testruns-on:ubuntu-latestenvironment:name:productionurl:https://example.comsteps:-uses:actions/download-artifact@v4with:name:build-output-run:./deploy.shproduction-name:Notifydeploymentrun:|
curl -X POST "$SLACK_WEBHOOK_URL" \
-H 'Content-Type: application/json' \
-d '{"text": "Deployed ${{ github.sha }} to production"}'
Rollback Strategies
# Manual rollback workflowname:Rollbackon:workflow_dispatch:inputs:environment:description:'Environment to rollback'required:truetype:choiceoptions: [staging, production]
commit_sha:description:'Commit SHA to rollback to'required:truetype:stringjobs:rollback:runs-on:ubuntu-latestenvironment:${{github.event.inputs.environment}}steps:-uses:actions/checkout@v4with:ref:${{github.event.inputs.commit_sha}}-uses:actions/setup-node@v4with:node-version:20cache:'pnpm'-run:pnpminstall--frozen-lockfile-run:pnpmbuild-run:./deploy.sh${{github.event.inputs.environment}}-name:Notifyrollbackrun:|
curl -X POST "$SLACK_WEBHOOK_URL" \
-H 'Content-Type: application/json' \
-d '{"text": "Rolled back ${{ github.event.inputs.environment }} to ${{ github.event.inputs.commit_sha }}"}'
Canary Deployment
# Progressive rollout with health checksjobs:canary:runs-on:ubuntu-latestenvironment:productionsteps:-name:Deploycanary(10%traffic)run:./deploy.shproduction--canary--weight=10-name:Monitorcanary(5minutes)run:|
for i in {1..10}; do
ERROR_RATE=$(curl -s "$MONITORING_API/error-rate?deployment=canary")
if (( $(echo "$ERROR_RATE > 1.0" | bc -l) )); then
echo "Error rate exceeds threshold. Rolling back."
./deploy.sh production --rollback-canary
exit 1
fi
echo "Canary healthy: error rate check $i/10"
sleep 30
done
-name:Promotecanarytofullrun:./deploy.shproduction--promote-canary
# Use GitHub environments for secret scopingjobs:deploy:environment:productionenv:DATABASE_URL:${{secrets.DATABASE_URL}}API_KEY:${{secrets.API_KEY}}steps:# Use OIDC for cloud provider auth (no long-lived secrets)-uses:aws-actions/configure-aws-credentials@v4with:role-to-assume:arn:aws:iam::123456789:role/deployaws-region:us-east-1# Mask sensitive values in logs-run:|
echo "::add-mask::${{ secrets.API_KEY }}"
./deploy.sh
Best Practices
Fail fast — Run lint and type-check before tests. Cancel in-progress runs on new pushes with concurrency.
Cache aggressively — Cache dependencies (pnpm), build output (.next/cache), and Docker layers. Saves minutes per run.
Shard tests — Split test suites across parallel runners. Use --shard=1/4 for Jest/Vitest.
Use environments for gates — GitHub Environments support required reviewers, wait timers, and scoped secrets.
Detect changes in monorepos — Only build/deploy what changed using path filters. Saves CI minutes and prevents unnecessary deploys.
Pin action versions — Use SHA-pinned actions (actions/checkout@abc123) for security, not just major versions.
Canary before full deploy — Route 10% traffic to canary, monitor error rates, then promote or rollback.
Always have a rollback plan — workflow_dispatch rollback workflow that can redeploy any previous commit.
Common Pitfalls
Pitfall
Problem
Fix
No concurrency control
Multiple CI runs for same PR waste resources
Use concurrency with cancel-in-progress: true
Caching node_modules
Cache invalidation issues, platform mismatches
Cache pnpm store, not node_modules. Use setup-node cache
Secrets in logs
Credentials exposed in CI output
Use ::add-mask:: and never echo secrets
No artifact retention policy
Storage costs grow unbounded
Set retention-days: 7 on artifacts
Sequential test execution
CI takes 20+ minutes
Shard tests across matrix runners
No smoke tests after deploy
Broken deploys not caught until users report
Run Playwright smoke suite against staging URL
Force-merging past failed checks
Broken code reaches production
Require status checks in branch protection rules
Long-lived feature branches
Merge conflicts and integration pain
Merge main into feature branches daily; use trunk-based development
Provide expert guidance on GitHub Actions workflow authoring, reusable workflows, composite actions, matrix builds, caching strategies, and security hardening. Covers the latest GitHub Actions features including artifact v4, Node 20 runners, and reusable workflow improvements.
