The Cloud Engineer's Field Guide to Claude Code

Who This Is For

This isn't a "getting started with AI" piece. If you're an Azure engineer, cloud architect, or DevOps practitioner who already knows the platform and wants to move faster — this is for you.

I've been working with Azure for 9+ years. I've got 10+ certifications. I'm a Microsoft Certified Trainer. And I use Claude Code every single day. Not because I don't know how to write Bicep or debug a deployment — but because there are only so many hours in a day, and some of those hours shouldn't be spent reading 40 pages of docs to find one property name.

Here's how I actually use it.

1. Debugging Failed Deployments

This is the one that saves me the most frustration. You run a deployment, it fails, and Azure gives you an error message that's either too vague or too verbose to be useful.

Instead of digging through the Activity Log, cross-referencing the error code on Microsoft Learn, and trying to figure out which of your 15 resources actually failed — I paste the error into Claude Code.

This Bicep deployment failed. Here's the error:
 
{"code": "InvalidTemplateDeployment", "message": "The template
deployment 'main' is not valid according to the validation
procedure. The tracking id is '...'. See inner errors for details.",
"details": [{"code": "PreflightValidationCheckFailed", "message":
"Preflight validation failed. Please refer to the details for the
specific errors.", "details": [{"code": "AccountNameInvalid",
"target": "lab-PE-storage", "message": "lab-PE-storage is not a
valid storage account name. Storage account name must be between
3 and 24 characters in length and use numbers and lower-case
letters only."}]}]}
 
What's wrong and how do I fix it in my Bicep template?

Claude Code doesn't just say "the name is invalid" — it tells me the storage account name has uppercase letters and a hyphen, explains the naming constraints, and suggests a fix using toLower() and replace() in Bicep:

// Before — this will fail
var storageName = '${prefix}-storage'
 
// After — strip hyphens, force lowercase, truncate to 24 chars
var storageName = take(toLower(replace('${prefix}storage', '-', '')), 24)

That's a 30-second fix instead of a 10-minute docs hunt.

The Pattern That Works Best

Don't just paste the error. Give context:

Deploying a Container Apps environment with Bicep. The deployment
was working yesterday. I added a custom domain binding and now
it fails with this error: [paste error]
 
The relevant Bicep resource is: [paste the resource block]

The more context you give, the more targeted the answer. Claude Code can cross-reference the error with your specific resource configuration rather than giving you a generic "check the docs" response.

2. Writing and Refactoring Bicep

I write a lot of Bicep. For client environments, for labs, for my own infrastructure. Claude Code handles three specific Bicep tasks really well:

Scaffolding New Templates

When I need a new deployment — say, a Container Apps environment with Log Analytics, managed identity, and ACR integration — I describe the architecture and let Claude Code generate the first draft.

Create a Bicep template with three modules:
 
1. shared-environment.bicep — Log Analytics workspace (30-day
   retention), Container App Environment, user-assigned managed
   identity with AcrPull role on an existing ACR
 
2. app.bicep — Container App pulling from ACR using the managed
   identity, with HTTP scaling (10 concurrent requests), health
   probes, and environment-specific min/max replicas passed as
   parameters
 
3. main.bicep — orchestrator that deploys shared once, then calls
   app.bicep for dev and prod with different parameters
 
Use canadacentral. Follow Azure naming conventions (camelCase
resource names, kebab-case for Azure resource names with prefixes).

This is exactly how I scaffolded the infrastructure for this portfolio site — three Bicep modules, environment-specific parameters, managed identity for ACR. Claude Code generated the structure, I refined the details.

Refactoring Existing Templates

This is where it gets really useful. I have a 200-line monolithic Bicep file from a client engagement. I need to break it into modules.

Read this Bicep file. Refactor it into modules:
- networking.bicep (VNet, subnets, NSGs)
- compute.bicep (VMs, availability sets)
- monitoring.bicep (Log Analytics, diagnostic settings)
- main.bicep (orchestrator with outputs)
 
Keep all existing parameter names. Don't change any resource
configurations — just restructure. I need to be able to diff
the deployed resources before and after and see zero changes.

That last line is critical. You're telling Claude Code "don't be clever, just move things around." Without it, you'll get "improvements" you didn't ask for.

Adding Features to Existing Templates

Add a diagnostic settings resource to every resource in this
template that supports it. Send logs and metrics to the Log
Analytics workspace defined in the shared module. Use the
category groups approach (allLogs, allMetrics) instead of
listing individual categories.

Claude Code knows which Azure resource types support diagnostic settings and which don't. It won't try to add diagnostics to a subnet (which doesn't support it) but will add it to the App Service, the Key Vault, and the NSG.

3. Decoding Cryptic Error Messages

Azure error messages range from "surprisingly helpful" to "what does this even mean." Claude Code is excellent at translating the second kind.

Some real examples I've thrown at it:

What does this error mean?
 
"The resource operation completed with terminal provisioning
state 'Failed'. Code: DeploymentFailed. Details:
GatewaySubnetInUseAndCannotBeDeleted"

Claude Code explains that you're trying to modify a VNet Gateway subnet that has an active gateway attached, tells me to delete the gateway first, and warns me that gateway deletion takes 15-30 minutes (which the docs don't make obvious).

Or this one:

az container create is failing with:
"The image 'myacr.azurecr.io/myapp:latest' in container group
'mygroup' is not accessible. Please check the image and registry
credential."
 
I've verified the ACR login server is correct and the image exists.
What else could cause this?

Claude Code runs through the checklist: admin credentials vs managed identity, ACR network rules blocking the Container Instance, the image being in a private repository without proper authentication, and the Container Instance not having the AcrPull role assignment. It's like having a senior engineer doing a rubber duck debugging session with you — except it's instant.

Error Message Cheat Sheet

Here are the error patterns I throw at Claude Code most often:

4. Exploring Unfamiliar Services

All right, so here's the thing. Azure has 200+ services. Nobody knows all of them. When a client asks me about a service I haven't worked with deeply — say, Azure API Management policies, or Event Grid event subscriptions — I use Claude Code as a research accelerator.

I need to set up Azure API Management to rate-limit API calls
per subscription key. The limit is 100 calls per minute.
 
Show me:
1. The inbound policy XML I need
2. Where this goes in the APIM policy hierarchy
   (global vs product vs API vs operation)
3. What happens when a caller exceeds the limit
   (what HTTP status code, what headers)
4. How to test this with curl

This gives me a working starting point in 2 minutes instead of 20 minutes of reading docs. But — and this is important — I always verify the policy XML against the official APIM policy reference. Claude Code gets the structure right, but sometimes uses attributes that are slightly wrong or outdated.

The "Explain Like I Already Know Azure" Pattern

This is my favorite prompt pattern for service exploration:

Explain Azure Front Door's routing architecture. I already know
Azure well — skip the "what is Azure" intro. Focus on:
- How rules engine works vs classic routing rules
- When to use Front Door vs Application Gateway vs Traffic Manager
- The gotchas around custom domains and managed certificates
- What "Standard" vs "Premium" actually gets me in practice

The "I already know Azure" qualifier is key. Without it, you get paragraphs about "Azure is Microsoft's cloud platform..." which is useless to someone who's been on the platform for years.

5. Quick Automation Scripts

When I need a one-off script — something I'll run once or twice, not something that goes into a CI/CD pipeline — Claude Code is the fastest path.

Write a bash script that:
1. Lists all Azure subscriptions I have access to
2. For each subscription, finds all App Service Plans on
   the Free or Shared tier
3. Outputs a table: subscription name, resource group,
   app service plan name, SKU, number of apps hosted
4. Sorts by number of apps descending
 
I want to find which Free tier plans are actually being used
vs which ones are abandoned.

The output is a clean script using az CLI with --query JMESPath expressions and column -t for formatting. I run it, get my answer, and move on.

#!/bin/bash
echo "Subscription | Resource Group | Plan Name | SKU | App Count"
echo "-------------|----------------|-----------|-----|----------"
 
az account list --query "[].{name:name, id:id}" -o tsv | while IFS=$'\t' read -r sub_name sub_id; do
  az account set --subscription "$sub_id" 2>/dev/null
 
  az appservice plan list \
    --query "[?sku.tier=='Free' || sku.tier=='Shared'].{rg:resourceGroup, name:name, sku:sku.name, apps:numberOfSites}" \
    -o tsv 2>/dev/null | while IFS=$'\t' read -r rg name sku apps; do
    echo "$sub_name | $rg | $name | $sku | $apps"
  done
done | sort -t'|' -k5 -rn | column -t -s'|'

6. Writing IaC Documentation

This one's underrated. You've written a Bicep deployment. It works. Now someone else on the team needs to understand it, modify it, or run it.

Read all the Bicep files in this directory. Write a DEPLOYMENT.md that covers:
- Architecture overview (what gets deployed and how it connects)
- Prerequisites (tools, permissions, existing resources)
- Parameter reference (table with name, type, default, description)
- How to deploy (step-by-step with az CLI commands)
- How to tear down (in the right order to avoid dependency errors)
- Common issues and fixes

Claude Code generates documentation that actually matches the code — because it read the code. No more docs that say "set the location parameter" when the parameter was renamed to region three PRs ago.

What Will Bite You

Outdated Azure CLI Syntax

Claude Code occasionally generates az commands with old syntax. The Azure CLI evolves — commands get restructured, flags get renamed. When I see a command that looks unfamiliar, I always run az <command> --help to verify.

Confidently Wrong About Edge Cases

Claude Code is great at the 80% case. Where it gets dangerous is edge cases — service interactions that have quirky behavior, regional limitations, or undocumented constraints. If you're doing something unusual (cross-tenant Private Endpoints, sovereign cloud deployments, nested ARM template patterns), verify more aggressively.

The "Improvement" Trap

When you ask Claude Code to modify existing code, it sometimes "improves" things you didn't ask it to touch. Parameters get renamed, defaults change, comments get rewritten. Always diff the output against your original. I've learned to be very explicit: "Change ONLY the diagnostic settings. Do not modify any other resources, parameters, or comments."

Cost Assumptions

Claude Code doesn't know your Azure spending limits. It will happily suggest Premium SKUs, reserved instances, and multi-region deployments. Always specify cost constraints in your prompts: "Use the cheapest SKU that supports [feature]. This is a dev environment, not production."

The Right Mental Model

After using Claude Code daily for months, here's how I think about it:

It's a very fast junior engineer who has read all the documentation but has never touched production. It knows the correct answer to most questions. It can generate working code quickly. But it doesn't have the judgment that comes from debugging a 3 AM outage, or the instinct that tells you "this deployment pattern looks correct but will cause problems at scale."

Your job is to bring that judgment. Claude Code's job is to handle the boilerplate so your judgment can focus on the things that actually matter.

That's a good trade.

Prompt Patterns — Quick Reference

What's Next

• If you're building labs or training content, check out How I Use Claude Code to Build Cloud Labs 10x Faster — it covers the lab-specific workflow in detail.
• For IaC fundamentals, Getting Started with Terraform on Azure walks through deploying your first resource — the concepts apply whether you're writing Terraform or Bicep.
• If you're exploring a career move into cloud, the IT Admin to Azure Cloud Engineer Roadmap maps out the path from where you are to where you want to be.