Bicep Safety Review for Small EC Teams Before Azure IaC

Before a sale weekend, a small ecommerce team should not push an old Bicep file to production just because it worked last year. The file may define Storage Accounts, App Service, Key Vault, connection strings, public access, SKU, and output URLs. If scope, secrets, and what-if output are not reviewed, the deployment can create cost, security, and checkout trouble exactly when traffic rises. The first artifact to inspect is main.bicep, the parameters file, what-if output, and rollback note.

This article shows how a small EC team can use Claude Code to read Bicep before adopting Azure infrastructure as code. The goal is not to let AI deploy. The goal is to create a review table that humans can approve.

Key Points

• Check scope, parameters, secrets, public settings, cost, and rollback before production deployment.
• Bicep is readable, but a short file can still change production resources.
• What-if output helps preview resource changes before deployment.
• Claude Code can summarize Bicep resources, parameters, secrets, and stop conditions.
• Humans decide production deploy, payment keys, public URLs, deletion changes, SKU, and rollback.

Where Bicep Reviews Break

Small ecommerce systems change quickly: sale pages, image delivery, inventory APIs, admin screens, payment integration, and email notifications. A team may export portal settings or copy last year’s Bicep file. Without review, public access, SKU, region, secrets, and diagnostics can drift into production.

The common failure is assuming the diff is small. Storage might be replaced, HTTPS may be missing, a secret parameter may be logged, SKU may change, or staging and production names may be too similar. These failures touch revenue directly.

Primary references checked for this article include What is Bicep?, Bicep file structure, Bicep best practices, Bicep what-if, secure parameters and secrets, Bicep modules, and Azure CLI deployment.

Workflow: Turn Bicep Into A Safety Table

Start from main.bicep, the parameters file, environment name, resource group, what-if output, and rollback note. Build one table for resources created, modified, deleted, public, secret, and cost-sensitive. Remove secret values before Claude Code reads the files.

Source	Review field	Claude Code review	Human review
scope	resource group or subscription	blast radius	production target
parameters	location, SKU, appName	missing values and secret names	payment and cost
resources	storage, web app, key vault	public access, HTTPS, identity	customer impact
what-if	Create, Modify, Delete	stop conditions	deployment approval
rollback	stop note, owner	missing plan	sale-day decision

What Claude Code Does And What Humans Decide

Claude Code can read Bicep sections, list resources, flag secret-like parameters, summarize what-if output, and draft stop conditions. Humans decide production deployment, SKU changes, deletion, payment keys, customer data, public URLs, firewalls, private endpoints, cost, and rollback.

Use @secure() or Key Vault patterns for secrets. For EC systems, payment API keys, mail keys, admin passwords, and connection strings must not be placed in plain parameters for AI review.

3 Use Cases

Use case 1: Read deployment scope before production

• Input: main.bicep, resource group, subscription, environment, existing resources.
• Output: create/modify/delete candidates, scope, resource type, EC impact table.
• Human review: production target, SKU, region, public URL, deletion, payment resources.

Start with blast radius, not syntax style. Claude Code extracts targetScope, resources, existing references, and module scopes.

Use case 2: Find risky secrets and parameters

• Input: parameters, parameter file, Key Vault use, connection string names.
• Output: parameters needing @secure(), plain secret candidates, Key Vault candidates.
• Human review: payment key, mail key, database string, customer data, admin password.

If a parameter name contains key, secret, password, or token, review it before deployment.

Use case 3: Read what-if output before deploy

• Input: what-if output, change reason, deployment date, rollback note.
• Output: Create/Modify/Delete table, stop condition, approver, sale checklist.
• Human review: Delete, Replace, SKU, public access, cost, sale impact.

What-if is not a rubber stamp. It is the input for a human deployment decision.

Copy-Paste Prompt

Act as an Azure Bicep safety reviewer for a small ecommerce team.
Goal: turn Bicep files into a human deployment review table before production.

Inputs:
- main.bicep
- parameters file with secret values removed
- targetScope and resource group name
- az deployment what-if summary
- sale date, rollback note, approver

Check scope, secret-like parameters, public access, HTTPS, managed identity, what-if Delete/Replace/SKU changes, and rollback notes.
Never run deployment commands.
Return the five rows to inspect today.

Working Check Code

// verify-bicep-safety-notes.mjs
// No dependencies. Run with: node verify-bicep-safety-notes.mjs
const bicepReview = {
  template: "main.bicep",
  environment: "prod",
  scope: "subscription",
  resources: [
    { type: "Microsoft.Storage/storageAccounts", name: "ecprodstore", publicNetworkAccess: "Enabled", sku: "Standard_LRS" },
    { type: "Microsoft.Web/sites", name: "ec-sale-app", httpsOnly: false, managedIdentity: false },
    { type: "Microsoft.KeyVault/vaults/secrets", name: "payment-api-key", valueFromParameter: "plainTextPaymentKey" }
  ],
  parameters: [
    { name: "location", secure: false, valueExample: "japaneast" },
    { name: "plainTextPaymentKey", secure: false, valueExample: "sk_live_example" }
  ],
  whatIfAttached: false,
  owner: "",
  rollbackNote: ""
};

const problems = [];

if (bicepReview.environment === "prod" && !bicepReview.whatIfAttached) {
  problems.push({ item: "what-if", fix: "attach az deployment what-if output before production deployment" });
}
if (!bicepReview.owner) {
  problems.push({ item: "owner", fix: "assign a human owner for cost, rollback, and approval" });
}
if (!bicepReview.rollbackNote) {
  problems.push({ item: "rollback", fix: "write a rollback or stop-the-line note before sale season" });
}
for (const parameter of bicepReview.parameters) {
  if (/key|secret|password|token/i.test(parameter.name) && !parameter.secure) {
    problems.push({ item: `parameter: ${parameter.name}`, fix: "mark secrets with @secure() or fetch from Key Vault" });
  }
}
for (const resource of bicepReview.resources) {
  if (resource.publicNetworkAccess === "Enabled") {
    problems.push({ item: `public network: ${resource.name}`, fix: "review public access, firewall, private endpoint, or business reason" });
  }
  if (resource.httpsOnly === false) {
    problems.push({ item: `httpsOnly: ${resource.name}`, fix: "enable HTTPS-only before customer traffic" });
  }
  if (resource.type === "Microsoft.Web/sites" && resource.managedIdentity === false) {
    problems.push({ item: `identity: ${resource.name}`, fix: "use managed identity instead of app secrets when possible" });
  }
}

if (problems.length > 0) {
  console.table(problems);
  process.exitCode = 1;
} else {
  console.log("Bicep safety review passed.");
}

The script checks what-if, owner, rollback, secure parameters, public network access, HTTPS-only, and managed identity. In real work, combine Azure CLI, Bicep build, what-if, resource group review, Key Vault, App Service settings, and audit logs.

Pitfall: Common Failure Cases

The first failure is assuming readable Bicep means safe Bicep. Review scope, what-if, secrets, public settings, and rollback. The second failure is putting secrets in parameters. Use secure parameters or Key Vault. The third failure is running what-if but not reading Delete, Replace, SKU, public access, identity, or diagnostics. The fourth failure is deploying before sale season without rollback.

FAQ

Q. Does a small ecommerce team need Bicep?

A. Not for every resource at first. Start where changes repeat: sale pages, image delivery, admin apps, and staging environments.

Q. Can Claude Code read Bicep files?

A. Yes, after removing secrets, tokens, customer data, and contract details. Do not give deployment permissions.

Q. Is what-if enough?

A. No. It is a strong input, but humans still review deletion, replacement, SKU, public access, secrets, and rollback.

Q. What should the team inspect today?

A. targetScope, secret-like parameters, public access, what-if Delete/Modify, and rollback note.

Training And Consultation Signal

Measure what-if items stopped, plain secret candidates, public-setting findings, missing rollback notes, pre-deploy review time, and inquiry rate. If those numbers hurt, Bicep and Azure deployment review are a fit for ClaudeCodeLab training.

What I Verified

I checked Microsoft Learn references for Bicep overview, file structure, best practices, what-if, secure parameters, modules, and Azure CLI deployment. I also checked the CTA, executable JavaScript, internal link, external links, locale coverage, and queue removal.