Senior devops
Comprehensive DevOps skill for CI/CD, infrastructure automation, containerization, and cloud platforms (AWS, GCP, Azure).
How to use it
Claude Code
- Run the line below. It pulls the whole folder into
~/.claude/skills/senior-devops, including the files SKILL.md points to. - Describe your job in plain words. Claude Code follows the skill from there.
npx degit alirezarezvani/claude-skills/engineering-team/skills/senior-devops#main ~/.claude/skills/senior-devopsFor one project only, change the path to .claude/skills/senior-devops. This skill also uses Node.js — copying SKILL.md alone won't be enough. See the folder on GitHub.
Claude (web or desktop app)
- On this page open ⋯ → Download .md.
- Save it as SKILL.md in a folder, zip the folder, then Customize → Skills → + → Create skill → Upload a skill.
- Pick the file and Save. Claude shows the name and description and runs a security scan.
- Check the skill is switched on.
- Start a new chat and describe your job in plain words. The AI follows the skill from there.
ChatGPT or another app
- ChatGPT: make a Project and paste it into Instructions.
- Neither? Paste it at the top of a new chat — it works for that chat.
Not working?
- Check which app you pasted it into — the steps above name the right one.
- Some skills need the paid tier of Claude or ChatGPT.
Paste into Claude, ChatGPT or Cursor.
Source of Senior devops
Show the full text324 lines
| name | description |
|---|---|
| senior-devops | Comprehensive DevOps skill for CI/CD, infrastructure automation, containerization, and cloud platforms (AWS, GCP, Azure). Includes pipeline setup, infrastructure as code, deployment automation, and monitoring. Use when setting up pipelines, deploying applications, managing infrastructure, implementing monitoring, or optimizing deployment processes. |
Senior Devops
Complete toolkit for senior devops with modern tools and best practices.
Quick Start
Main Capabilities
This skill provides three core capabilities through automated scripts:
# Script 1: Pipeline Generator — scaffolds CI/CD pipelines for GitHub Actions or CircleCI
python scripts/pipeline_generator.py ./app --platform=github --stages=build,test,deploy
# Script 2: Terraform Scaffolder — generates and validates IaC modules for AWS/GCP/Azure
python scripts/terraform_scaffolder.py ./infra --provider=aws --module=ecs-service --verbose
# Script 3: Deployment Manager — generates deployment manifests + runbooks with rollback support
python3 scripts/deployment_manager.py deploy --env=staging --image=app:1.2.3 --strategy=blue-green --verbose --json
Core Capabilities
1. Pipeline Generator
Scaffolds CI/CD pipeline configurations for GitHub Actions or CircleCI, with stages for build, test, security scan, and deploy.
Example — GitHub Actions workflow:
# .github/workflows/ci.yml
name: CI/CD Pipeline
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
cache: 'npm'
- run: npm ci
- run: npm run lint
- run: npm test -- --coverage
- name: Upload coverage
uses: codecov/codecov-action@v4
build-docker:
needs: build-and-test
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build and push image
uses: docker/build-push-action@v5
with:
push: ${{ github.ref == 'refs/heads/main' }}
tags: ghcr.io/${{ github.repository }}:${{ github.sha }}
deploy:
needs: build-docker
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
steps:
- name: Deploy to ECS
run: |
aws ecs update-service \
--cluster production \
--service app-service \
--force-new-deployment
Usage:
python scripts/pipeline_generator.py <project-path> --platform=github|circleci --stages=build,test,deploy
2. Terraform Scaffolder
Generates, validates, and plans Terraform modules. Enforces consistent module structure and runs terraform validate + terraform plan before any apply.
Example — AWS ECS service module:
# modules/ecs-service/main.tf
resource "aws_ecs_task_definition" "app" {
family = var.service_name
requires_compatibilities = ["FARGATE"]
network_mode = "awsvpc"
cpu = var.cpu
memory = var.memory
container_definitions = jsonencode([{
name = var.service_name
image = var.container_image
essential = true
portMappings = [{
containerPort = var.container_port
protocol = "tcp"
}]
environment = [for k, v in var.env_vars : { name = k, value = v }]
logConfiguration = {
logDriver = "awslogs"
options = {
awslogs-group = "/ecs/${var.service_name}"
awslogs-region = var.aws_region
awslogs-stream-prefix = "ecs"
}
}
}])
}
resource "aws_ecs_service" "app" {
name = var.service_name
cluster = var.cluster_id
task_definition = aws_ecs_task_definition.app.arn
desired_count = var.desired_count
launch_type = "FARGATE"
network_configuration {
subnets = var.private_subnet_ids
security_groups = [aws_security_group.app.id]
assign_public_ip = false
}
load_balancer {
target_group_arn = aws_lb_target_group.app.arn
container_name = var.service_name
container_port = var.container_port
}
}
Usage:
python scripts/terraform_scaffolder.py <target-path> --provider=aws|gcp|azure --module=ecs-service|gke-deployment|aks-service [--verbose]
3. Deployment Manager
Generates Kubernetes deployment manifests and ordered kubectl runbooks for blue/green or rolling strategies, with health-check gates before traffic switches and rollback runbooks. The tool writes manifests and prints the commands — it never applies them to a cluster itself, so every change gets a human review.
Example — Kubernetes blue/green deployment (blue-slot specific elements):
# k8s/deployment-blue.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: app-blue
labels:
app: myapp
slot: blue # slot label distinguishes blue from green
spec:
replicas: 3
selector:
matchLabels:
app: myapp
slot: blue
template:
metadata:
labels:
app: myapp
slot: blue
spec:
containers:
- name: app
image: ghcr.io/org/app:1.2.3
readinessProbe: # gate: pod must pass before traffic switches
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
Usage:
python scripts/deployment_manager.py deploy \
--env=staging|production \
--image=app:1.2.3 \
--strategy=blue-green|rolling \
--health-check-url=https://app.example.com/healthz
python scripts/deployment_manager.py rollback --env=production --to-version=1.2.2
python scripts/deployment_manager.py --analyze --env=production # audit current state
Resources
- Pattern Reference:
references/cicd_pipeline_guide.md— detailed CI/CD patterns, best practices, anti-patterns - Workflow Guide:
references/infrastructure_as_code.md— IaC step-by-step processes, optimization, troubleshooting - Technical Guide:
references/deployment_strategies.md— deployment strategy configs, security considerations, scalability - Tool Scripts:
scripts/directory
Development Workflow
1. Infrastructure Changes (Terraform)
# Scaffold or update module
python scripts/terraform_scaffolder.py ./infra --provider=aws --module=ecs-service --verbose
# Validate and plan — review diff before applying
terraform -chdir=infra init
terraform -chdir=infra validate
terraform -chdir=infra plan -out=tfplan
# Apply only after plan review
terraform -chdir=infra apply tfplan
# Verify resources are healthy
aws ecs describe-services --cluster production --services app-service \
--query 'services[0].{Status:status,Running:runningCount,Desired:desiredCount}'
2. Application Deployment
# Generate or update pipeline config
python scripts/pipeline_generator.py . --platform=github --stages=build,test,security,deploy
# Build and tag image
docker build -t ghcr.io/org/app:$(git rev-parse --short HEAD) .
docker push ghcr.io/org/app:$(git rev-parse --short HEAD)
# Deploy with health-check gate
python scripts/deployment_manager.py deploy \
--env=production \
--image=app:$(git rev-parse --short HEAD) \
--strategy=blue-green \
--health-check-url=https://app.example.com/healthz
# Verify pods are running
kubectl get pods -n production -l app=myapp
kubectl rollout status deployment/app-blue -n production
# Switch traffic after verification
kubectl patch service app-svc -n production \
-p '{"spec":{"selector":{"slot":"blue"}}}'
3. Rollback Procedure
# Immediate rollback via deployment manager
python scripts/deployment_manager.py rollback --env=production --to-version=1.2.2
# Or via kubectl
kubectl rollout undo deployment/app -n production
kubectl rollout status deployment/app -n production
# Verify rollback succeeded
kubectl get pods -n production -l app=myapp
curl -sf https://app.example.com/healthz || echo "ROLLBACK FAILED — escalate"
Multi-Cloud Cross-References
Use these companion skills for cloud-specific deep dives:
| Skill | Cloud | Use When |
|---|---|---|
| aws-solution-architect | AWS | ECS/EKS, Lambda, VPC design, cost optimization |
| azure-cloud-architect | Azure | AKS, App Service, Virtual Networks, Azure DevOps |
| gcp-cloud-architect | GCP | GKE, Cloud Run, VPC, Cloud Build (coming soon) |
Multi-cloud vs single-cloud decision:
- Single-cloud (default) — lower operational complexity, deeper managed-service integration, better cost leverage with committed-use discounts
- Multi-cloud — required when mandated by compliance/data residency, acquiring companies on different clouds, or needing best-of-breed services across providers (e.g., AWS for compute + GCP for ML)
- Hybrid — on-prem + cloud; use when regulated workloads must stay on-prem while burst/non-sensitive workloads run in the cloud
Start single-cloud. Add a second cloud only when there is a concrete business or compliance driver — not for theoretical redundancy.
Cloud-Agnostic IaC
Terraform / OpenTofu (Default Choice)
Terraform (or its open-source fork OpenTofu) is the recommended IaC tool for most teams:
- Single language (HCL) across AWS, Azure, GCP, and 3,000+ providers
- State management with remote backends (S3, GCS, Azure Blob)
- Plan-before-apply workflow prevents drift surprises
- Cross-reference terraform-patterns for module structure, state isolation, and CI/CD integration
Pulumi (Programming Language IaC)
Choose Pulumi when the team strongly prefers TypeScript, Python, Go, or C# over HCL:
- Full programming language — loops, conditionals, unit tests native
- Same cloud provider coverage as Terraform
- Easier onboarding for dev teams that resist learning HCL
When to Use Cloud-Native IaC
| Tool | Use When |
|---|---|
| CloudFormation | AWS-only shop; need native AWS support (StackSets, Service Catalog) |
| Bicep | Azure-only shop; simpler syntax than ARM templates |
| Cloud Deployment Manager | GCP-only; rare — most GCP teams prefer Terraform |
Rule of thumb: Use Terraform/OpenTofu unless you are 100% committed to a single cloud AND the cloud-native tool offers a feature Terraform cannot replicate (e.g., AWS Service Catalog integration).
Troubleshooting
Check the comprehensive troubleshooting section in references/deployment_strategies.md.
| 1 | |
| 2 | name "senior-devops" |
| 3 | description Comprehensive DevOps skill for CI/CD, infrastructure automation, containerization, and cloud platforms (AWS, GCP, Azure). Includes pipeline setup, infrastructure as code, deployment automation, and monitoring. Use when setting up pipelines, deploying applications, managing infrastructure, implementing monitoring, or optimizing deployment processes. |
| 4 | |
| 5 | |
| 6 | # Senior Devops |
| 7 | |
| 8 | Complete toolkit for senior devops with modern tools and best practices. |
| 9 | |
| 10 | ## Quick Start |
| 11 | |
| 12 | ### Main Capabilities |
| 13 | |
| 14 | This skill provides three core capabilities through automated scripts: |
| 15 | |
| 16 | |
| 17 | # Script 1: Pipeline Generator — scaffolds CI/CD pipelines for GitHub Actions or CircleCI |
| 18 | python scripts/pipeline_generator.py ./app --platform=github --stages=build,test,deploy |
| 19 | |
| 20 | # Script 2: Terraform Scaffolder — generates and validates IaC modules for AWS/GCP/Azure |
| 21 | python scripts/terraform_scaffolder.py ./infra --provider=aws --module=ecs-service --verbose |
| 22 | |
| 23 | # Script 3: Deployment Manager — generates deployment manifests + runbooks with rollback support |
| 24 | python3 scripts/deployment_manager.py deploy --env=staging --image=app:1.2.3 --strategy=blue-green --verbose --json |
| 25 | |
| 26 | |
| 27 | ## Core Capabilities |
| 28 | |
| 29 | ### 1. Pipeline Generator |
| 30 | |
| 31 | Scaffolds CI/CD pipeline configurations for GitHub Actions or CircleCI, with stages for build, test, security scan, and deploy. |
| 32 | |
| 33 | **Example — GitHub Actions workflow:** |
| 34 | |
| 35 | # .github/workflows/ci.yml |
| 36 | name: CI/CD Pipeline |
| 37 | on: |
| 38 | push: |
| 39 | branches: [main, develop] |
| 40 | pull_request: |
| 41 | branches: [main] |
| 42 | |
| 43 | jobs: |
| 44 | build-and-test: |
| 45 | runs-on: ubuntu-latest |
| 46 | steps: |
| 47 | - uses: actions/checkout@v4 |
| 48 | - name: Set up Node.js |
| 49 | uses: actions/setup-node@v4 |
| 50 | with: |
| 51 | node-version: '20' |
| 52 | cache: 'npm' |
| 53 | - run: npm ci |
| 54 | - run: npm run lint |
| 55 | - run: npm test -- --coverage |
| 56 | - name: Upload coverage |
| 57 | uses: codecov/codecov-action@v4 |
| 58 | |
| 59 | build-docker: |
| 60 | needs: build-and-test |
| 61 | runs-on: ubuntu-latest |
| 62 | steps: |
| 63 | - uses: actions/checkout@v4 |
| 64 | - name: Build and push image |
| 65 | uses: docker/build-push-action@v5 |
| 66 | with: |
| 67 | push: ${{ github.ref == 'refs/heads/main' }} |
| 68 | tags: ghcr.io/${{ github.repository }}:${{ github.sha }} |
| 69 | |
| 70 | deploy: |
| 71 | needs: build-docker |
| 72 | if: github.ref == 'refs/heads/main' |
| 73 | runs-on: ubuntu-latest |
| 74 | steps: |
| 75 | - name: Deploy to ECS |
| 76 | run: | |
| 77 | aws ecs update-service \ |
| 78 | --cluster production \ |
| 79 | --service app-service \ |
| 80 | --force-new-deployment |
| 81 | |
| 82 | |
| 83 | **Usage:** |
| 84 | |
| 85 | python scripts/pipeline_generator.py <project-path> --platform=github|circleci --stages=build,test,deploy |
| 86 | |
| 87 | |
| 88 | ### 2. Terraform Scaffolder |
| 89 | |
| 90 | Generates, validates, and plans Terraform modules. Enforces consistent module structure and runs `terraform validate` + `terraform plan` before any apply. |
| 91 | |
| 92 | **Example — AWS ECS service module:** |
| 93 | |
| 94 | # modules/ecs-service/main.tf |
| 95 | resource "aws_ecs_task_definition" "app" { |
| 96 | family = var.service_name |
| 97 | requires_compatibilities = ["FARGATE"] |
| 98 | network_mode = "awsvpc" |
| 99 | cpu = var.cpu |
| 100 | memory = var.memory |
| 101 | |
| 102 | container_definitions = jsonencode([{ |
| 103 | name = var.service_name |
| 104 | image = var.container_image |
| 105 | essential = true |
| 106 | portMappings = [{ |
| 107 | containerPort = var.container_port |
| 108 | protocol = "tcp" |
| 109 | }] |
| 110 | environment = [for k, v in var.env_vars : { name = k, value = v }] |
| 111 | logConfiguration = { |
| 112 | logDriver = "awslogs" |
| 113 | options = { |
| 114 | awslogs-group = "/ecs/${var.service_name}" |
| 115 | awslogs-region = var.aws_region |
| 116 | awslogs-stream-prefix = "ecs" |
| 117 | } |
| 118 | } |
| 119 | }]) |
| 120 | } |
| 121 | |
| 122 | resource "aws_ecs_service" "app" { |
| 123 | name = var.service_name |
| 124 | cluster = var.cluster_id |
| 125 | task_definition = aws_ecs_task_definition.app.arn |
| 126 | desired_count = var.desired_count |
| 127 | launch_type = "FARGATE" |
| 128 | |
| 129 | network_configuration { |
| 130 | subnets = var.private_subnet_ids |
| 131 | security_groups = [aws_security_group.app.id] |
| 132 | assign_public_ip = false |
| 133 | } |
| 134 | |
| 135 | load_balancer { |
| 136 | target_group_arn = aws_lb_target_group.app.arn |
| 137 | container_name = var.service_name |
| 138 | container_port = var.container_port |
| 139 | } |
| 140 | } |
| 141 | |
| 142 | |
| 143 | **Usage:** |
| 144 | |
| 145 | python scripts/terraform_scaffolder.py <target-path> --provider=aws|gcp|azure --module=ecs-service|gke-deployment|aks-service [--verbose] |
| 146 | |
| 147 | |
| 148 | ### 3. Deployment Manager |
| 149 | |
| 150 | Generates Kubernetes deployment manifests and ordered kubectl runbooks for blue/green or rolling strategies, with health-check gates before traffic switches and rollback runbooks. The tool writes manifests and prints the commands — it never applies them to a cluster itself, so every change gets a human review. |
| 151 | |
| 152 | **Example — Kubernetes blue/green deployment (blue-slot specific elements):** |
| 153 | |
| 154 | # k8s/deployment-blue.yaml |
| 155 | apiVersion: apps/v1 |
| 156 | kind: Deployment |
| 157 | metadata: |
| 158 | name: app-blue |
| 159 | labels: |
| 160 | app: myapp |
| 161 | slot: blue # slot label distinguishes blue from green |
| 162 | spec: |
| 163 | replicas: 3 |
| 164 | selector: |
| 165 | matchLabels: |
| 166 | app: myapp |
| 167 | slot: blue |
| 168 | template: |
| 169 | metadata: |
| 170 | labels: |
| 171 | app: myapp |
| 172 | slot: blue |
| 173 | spec: |
| 174 | containers: |
| 175 | - name: app |
| 176 | image: ghcr.io/org/app:1.2.3 |
| 177 | readinessProbe: # gate: pod must pass before traffic switches |
| 178 | httpGet: |
| 179 | path: /healthz |
| 180 | port: 8080 |
| 181 | initialDelaySeconds: 10 |
| 182 | periodSeconds: 5 |
| 183 | resources: |
| 184 | requests: |
| 185 | cpu: "250m" |
| 186 | memory: "256Mi" |
| 187 | limits: |
| 188 | cpu: "500m" |
| 189 | memory: "512Mi" |
| 190 | |
| 191 | |
| 192 | **Usage:** |
| 193 | |
| 194 | python scripts/deployment_manager.py deploy \ |
| 195 | --env=staging|production \ |
| 196 | --image=app:1.2.3 \ |
| 197 | --strategy=blue-green|rolling \ |
| 198 | --health-check-url=https://app.example.com/healthz |
| 199 | |
| 200 | python scripts/deployment_manager.py rollback --env=production --to-version=1.2.2 |
| 201 | python scripts/deployment_manager.py --analyze --env=production # audit current state |
| 202 | |
| 203 | |
| 204 | ## Resources |
| 205 | |
| 206 | Pattern Reference: `references/cicd_pipeline_guide.md` — detailed CI/CD patterns, best practices, anti-patterns |
| 207 | Workflow Guide: `references/infrastructure_as_code.md` — IaC step-by-step processes, optimization, troubleshooting |
| 208 | Technical Guide: `references/deployment_strategies.md` — deployment strategy configs, security considerations, scalability |
| 209 | Tool Scripts: `scripts/` directory |
| 210 | |
| 211 | ## Development Workflow |
| 212 | |
| 213 | ### 1. Infrastructure Changes (Terraform) |
| 214 | |
| 215 | |
| 216 | # Scaffold or update module |
| 217 | python scripts/terraform_scaffolder.py ./infra --provider=aws --module=ecs-service --verbose |
| 218 | |
| 219 | # Validate and plan — review diff before applying |
| 220 | terraform -chdir=infra init |
| 221 | terraform -chdir=infra validate |
| 222 | terraform -chdir=infra plan -out=tfplan |
| 223 | |
| 224 | # Apply only after plan review |
| 225 | terraform -chdir=infra apply tfplan |
| 226 | |
| 227 | # Verify resources are healthy |
| 228 | aws ecs describe-services --cluster production --services app-service \ |
| 229 | --query 'services[0].{Status:status,Running:runningCount,Desired:desiredCount}' |
| 230 | |
| 231 | |
| 232 | ### 2. Application Deployment |
| 233 | |
| 234 | |
| 235 | # Generate or update pipeline config |
| 236 | python scripts/pipeline_generator.py . --platform=github --stages=build,test,security,deploy |
| 237 | |
| 238 | # Build and tag image |
| 239 | docker build -t ghcr.io/org/app:$(git rev-parse --short HEAD) . |
| 240 | docker push ghcr.io/org/app:$(git rev-parse --short HEAD) |
| 241 | |
| 242 | # Deploy with health-check gate |
| 243 | python scripts/deployment_manager.py deploy \ |
| 244 | --env=production \ |
| 245 | --image=app:$(git rev-parse --short HEAD) \ |
| 246 | --strategy=blue-green \ |
| 247 | --health-check-url=https://app.example.com/healthz |
| 248 | |
| 249 | # Verify pods are running |
| 250 | kubectl get pods -n production -l app=myapp |
| 251 | kubectl rollout status deployment/app-blue -n production |
| 252 | |
| 253 | # Switch traffic after verification |
| 254 | kubectl patch service app-svc -n production \ |
| 255 | -p '{"spec":{"selector":{"slot":"blue"}}}' |
| 256 | |
| 257 | |
| 258 | ### 3. Rollback Procedure |
| 259 | |
| 260 | |
| 261 | # Immediate rollback via deployment manager |
| 262 | python scripts/deployment_manager.py rollback --env=production --to-version=1.2.2 |
| 263 | |
| 264 | # Or via kubectl |
| 265 | kubectl rollout undo deployment/app -n production |
| 266 | kubectl rollout status deployment/app -n production |
| 267 | |
| 268 | # Verify rollback succeeded |
| 269 | kubectl get pods -n production -l app=myapp |
| 270 | curl -sf https://app.example.com/healthz || echo "ROLLBACK FAILED — escalate" |
| 271 | |
| 272 | |
| 273 | ## Multi-Cloud Cross-References |
| 274 | |
| 275 | Use these companion skills for cloud-specific deep dives: |
| 276 | |
| 277 | | Skill | Cloud | Use When | |
| 278 | |-------|-------|----------| |
| 279 | | **aws-solution-architect** | AWS | ECS/EKS, Lambda, VPC design, cost optimization | |
| 280 | | **azure-cloud-architect** | Azure | AKS, App Service, Virtual Networks, Azure DevOps | |
| 281 | | **gcp-cloud-architect** | GCP | GKE, Cloud Run, VPC, Cloud Build *(coming soon)* | |
| 282 | |
| 283 | **Multi-cloud vs single-cloud decision:** |
| 284 | **Single-cloud** (default) — lower operational complexity, deeper managed-service integration, better cost leverage with committed-use discounts |
| 285 | **Multi-cloud** — required when mandated by compliance/data residency, acquiring companies on different clouds, or needing best-of-breed services across providers (e.g., AWS for compute + GCP for ML) |
| 286 | **Hybrid** — on-prem + cloud; use when regulated workloads must stay on-prem while burst/non-sensitive workloads run in the cloud |
| 287 | |
| 288 | > Start single-cloud. Add a second cloud only when there is a concrete business or compliance driver — not for theoretical redundancy. |
| 289 | |
| 290 | |
| 291 | |
| 292 | ## Cloud-Agnostic IaC |
| 293 | |
| 294 | ### Terraform / OpenTofu (Default Choice) |
| 295 | |
| 296 | Terraform (or its open-source fork OpenTofu) is the recommended IaC tool for most teams: |
| 297 | Single language (HCL) across AWS, Azure, GCP, and 3,000+ providers |
| 298 | State management with remote backends (S3, GCS, Azure Blob) |
| 299 | Plan-before-apply workflow prevents drift surprises |
| 300 | Cross-reference **terraform-patterns** for module structure, state isolation, and CI/CD integration |
| 301 | |
| 302 | ### Pulumi (Programming Language IaC) |
| 303 | |
| 304 | Choose Pulumi when the team strongly prefers TypeScript, Python, Go, or C# over HCL: |
| 305 | Full programming language — loops, conditionals, unit tests native |
| 306 | Same cloud provider coverage as Terraform |
| 307 | Easier onboarding for dev teams that resist learning HCL |
| 308 | |
| 309 | ### When to Use Cloud-Native IaC |
| 310 | |
| 311 | | Tool | Use When | |
| 312 | |------|----------| |
| 313 | | **CloudFormation** | AWS-only shop; need native AWS support (StackSets, Service Catalog) | |
| 314 | | **Bicep** | Azure-only shop; simpler syntax than ARM templates | |
| 315 | | **Cloud Deployment Manager** | GCP-only; rare — most GCP teams prefer Terraform | |
| 316 | |
| 317 | > **Rule of thumb:** Use Terraform/OpenTofu unless you are 100% committed to a single cloud AND the cloud-native tool offers a feature Terraform cannot replicate (e.g., AWS Service Catalog integration). |
| 318 | |
| 319 | |
| 320 | |
| 321 | ## Troubleshooting |
| 322 | |
| 323 | Check the comprehensive troubleshooting section in `references/deployment_strategies.md`. |
| 324 |
Discussion
Browse more free Claude skills or everything in Development.