Azure IaC Review: Don’t Merge Just Because Validation Passed

By Prateek SinghPublished July 1, 2026

Cloudeval AI with Azure and GitHub logos for Azure infrastructure review workflows

Core idea

Template validation proves the file can deploy. It does not prove the Azure change is safe to merge.

Architecture

Blast radius, dependencies, exposure, and Well-Architected posture.

Security

Ingress, identity, Key Vault controls, and high-risk findings.

Cost

Monthly run rate, budget gates, expensive services, and savings signals.

Gate

PR evidence, workflow artifacts, and the policy that comments or blocks.

An Azure IaC PR can pass template validation and still open public ingress, weaken Key Vault controls, push monthly cost above budget, or change the architecture blast radius in a way the raw diff does not make obvious. That is the gap Cloudeval is built for: not “does this template parse?” but “is this cloud change safe enough to merge?” This walkthrough shows how to attach source provenance, cost impact, Well-Architected posture, architecture blast radius, AI summary, and configurable merge gates to an Azure ARM or Bicep-generated pull request.

Inspect the real PR

Start with the public cost regression pull request.

Copy the action

Add the same review workflow to your repository.

Tune the gates

Start non-blocking, then enforce the thresholds your team trusts.

A real PR that should not merge

The public Cloudeval Azure ARM review example has a demo pull request called analytics capacity cost regression. The change sounds reasonable on the surface: temporary analytics capacity for a launch reporting window. Under the hood, it adds a fixed fleet of 160 analytics workers, scales App Service to PremiumV3 capacity 8, increases an Application Gateway WAF, switches storage to RA-GRS, and raises the branch budget gate to $5,000/month. Cloudeval fails the review because the impact is no longer theoretical:

Gate

FAIL

Posture

23.9/100

Cost

$11,674.89/mo

Findings

843 high risk

The same comment also reports 3 failed unit tests, 387 resources, 384 relationships, and a cost gate failure because the monthly estimate exceeds the configured budget. This is the point: the PR description explains intent, but the review must expose impact.

Cloudeval pull request review comment with source provenance, review status, report links, and workflow run — The PR review comment keeps source provenance, gate result, report links, cost, posture, validation, and workflow artifacts close to the code review.

Why the PR diff is not enough

Azure infrastructure review usually spans more than the pull request. The diff shows intent; the decision needs current cloud state, cost, validation output, security posture, architecture dependencies, and the team policy that decides whether a warning should block release. Cloudeval solves the problem by making the review object shared. Source provenance, Azure and IaC evidence, reports, diagrams, PR comments, and gates all hang from the same project context instead of forcing reviewers to reconcile separate tools by hand.

See the review evidence in motion

These videos belong in the article because they show two review surfaces that are hard to reconstruct from a raw template diff: blast radius in the architecture graph and grounded AI context tied back to the same project evidence.

Blast-radius diagram
Grounded AI context

Video: Cloudeval visualizes impacted resources and dependency paths so reviewers can check blast radius before approval.

The 4 things every Azure IaC PR should prove

Before approval, the pull request should answer four evidence questions: what source was evaluated, what architecture changed, what it costs, and which policy decides whether the change can merge.

Source provenance

Repository, branch, commit, template entry point, parameters, and workflow run.

Architecture impact

Posture, affected resources, dependency paths, exposure, and blast radius.

Cost impact

Monthly run rate, budget status, top services, and savings opportunities.

Merge policy

Well-Architected thresholds, validation failures, high-risk findings, and team gates.

Cloudeval report overview showing posture score, critical issue count, monthly run rate, savings, priority decisions, maturity, and freshness context — Cloudeval reports put posture, critical issues, run rate, savings, maturity, priority decisions, and evidence freshness in one review surface.

How Cloudeval attaches evidence to the PR

The useful review surface is the pull request comment. It should be close enough to the code review that a reviewer can decide what to open next without hunting through a dashboard.

Source provenance

A useful review states the Cloudeval project, repository, ref, commit, and workflow run that were evaluated.

Gate failures

The review should separate the observed posture from the configured gate: score thresholds, validation failures, high-risk findings, and monthly budget.

Deterministic drilldowns

Review output can include Well-Architected scores, cost threshold status, service-cost details, validation failures, and report links.

AI summary

AI text is useful for triage, but the merge decision should still be grounded in deterministic evidence and configured gates.

Expanded Cloudeval PR comment showing Well-Architected pillar ratings and monthly cost drilldowns — Review drilldowns expand from the PR comment so reviewers can inspect Well-Architected scores, cost signals, and validation context without leaving GitHub.

Start comment-only. Block only after tuning.

Engineers distrust tools that block merges before the team understands the thresholds. Start with comments and artifacts, review the results on real pull requests, then switch enforcement only after the policy reflects how your team actually reviews Azure risk.

name: Cloudeval review
on:
  pull_request:

permissions:
  contents: read
  pull-requests: write
  issues: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ganakailabs/cloudeval-action@v1
        with:
          access_key: ${{ secrets.CLOUDEVAL_ACCESS_KEY }}
          project_id: ${{ secrets.CLOUDEVAL_PROJECT_ID }}
          mode: review
          post_pr_comment: true
          upload_artifacts: true

version: 1

stacks:
  - id: production-reference
    name: Production reference architecture
    entry: azuredeploy.json
    parameters: azuredeploy.parameters.json

resolve:
  linked_templates: true

ci:
  gates:
    enforcement: warn
    overall_score_min: 60
    pillar_score_min: 50
    fail_on_high_risk: true
    fail_on_validation_errors: true
    max_monthly_cost: 5000

ci:
  gates:
    enforcement: required
    overall_score_min: 60
    pillar_score_min: 50
    fail_on_high_risk: true
    fail_on_validation_errors: true
    max_monthly_cost: 5000

Do not block production on a threshold your team has not reviewed. Start with comments and artifacts, tune the policy, then switch to enforcement: required.

What this is not

Cloudeval is not a replacement for engineering judgment. It attaches evidence to the PR: source, commit, workflow run, cost, posture, validation, architecture impact, and configured policy. The AI summary helps triage. The gate should be based on deterministic evidence and thresholds your team has reviewed.

Leave a proof trail, not a Slack opinion

When you ask for changes, point to the evidence the next reviewer can inspect: the PR comment, report, architecture diagram, workflow run, artifact, commit, or config threshold. That turns “I think this is risky” into “this change fails the budget gate and here is the report behind it.”

Open the PR comment first

Check the overall gate, source section, workflow run, report links, artifacts, posture, validation, and cost before reading lower-signal recommendations.

Separate posture from policy

The posture explains what Cloudeval observed. The gate explains what your team configured as merge-blocking.

Inspect the highest-risk evidence

Open high-risk architecture findings, failing validation, and budget breaches before lower-severity recommendations.

Use the diagram for blast radius

Confirm the impacted resources and dependency paths match the intended change.

Link the proof

Reference the PR comment, Cloudeval report, workflow artifact, or exported report when asking the author for changes.

Try the same review on public PRs

The sample repository includes nested ARM templates, .cloudeval/config.yaml, a ready-to-copy GitHub Actions workflow, and long-lived demo pull requests.

Passing baseline gates

A green workflow that still exposes posture, validation, cost, source, and report evidence.

Risk regression

A risky infrastructure change with blocking gate failures and high-risk posture signals.

Cost regression

A cost-heavy change with monthly estimate, cost drivers, and a failing budget gate.

Security hardening

Remediation work that still has to satisfy configured thresholds before it is ready.

Tested against a public Azure infrastructure repo with nested ARM templates, GitHub Actions, Cloudeval project sync, and long-lived demo PRs for risk regression, cost regression, security hardening, and baseline gates.

Copy this workflow into your repo

Fork the public Azure ARM review example.
Open the cost regression PR.
Inspect the Cloudeval bot comment, gate failures, reports, and workflow run.
Copy the GitHub Actions workflow into your own repository.
Start with enforcement: warn.
Tune .cloudeval/config.yaml against real team review decisions.
Switch to enforcement: required only after reviewers trust the thresholds.

Fork sample repo

Inspect nested ARM templates, config, workflow, and demo PRs.

Add the GitHub Action

Run Cloudeval review in CI and post PR evidence.

Create a Cloudeval project

Link repository source, branch, commit, and project context.

View cost regression PR

See a review that should stay blocked until cost and risk are addressed.

Reviewer checklist

Does the PR comment show repository, ref, commit, workflow run, and project?
Does the cost estimate fit the branch or environment budget?
Are high-risk architecture findings explained before approval?
Are failed validation or unit tests visible in the review?
Does the architecture diagram match the intended blast radius?
Is the gate configured as warn or required intentionally?
Can another reviewer audit the decision later without private chat context?

Articles

AI review and gates for Azure infra-as-code

Inspect the real PR

Copy the action

Tune the gates

A real PR that should not merge

Why the PR diff is not enough

See the review evidence in motion

The 4 things every Azure IaC PR should prove

Source provenance

Architecture impact

Cost impact

Merge policy

How Cloudeval attaches evidence to the PR

Start comment-only. Block only after tuning.

What this is not

Leave a proof trail, not a Slack opinion

Try the same review on public PRs

Passing baseline gates

Risk regression

Cost regression

Security hardening

Copy this workflow into your repo

Fork sample repo

Add the GitHub Action

Create a Cloudeval project

View cost regression PR

Reviewer checklist

Inspect the real PR

Copy the action

Tune the gates

​A real PR that should not merge

​Why the PR diff is not enough

​See the review evidence in motion

​The 4 things every Azure IaC PR should prove

Source provenance

Architecture impact

Cost impact

Merge policy

​How Cloudeval attaches evidence to the PR

​Start comment-only. Block only after tuning.

​What this is not

​Leave a proof trail, not a Slack opinion

​Try the same review on public PRs

Passing baseline gates

Risk regression

Cost regression

Security hardening

​Copy this workflow into your repo

Fork sample repo

Add the GitHub Action

Create a Cloudeval project

View cost regression PR

​Reviewer checklist

A real PR that should not merge

Why the PR diff is not enough

See the review evidence in motion

The 4 things every Azure IaC PR should prove

How Cloudeval attaches evidence to the PR

Start comment-only. Block only after tuning.

What this is not

Leave a proof trail, not a Slack opinion

Try the same review on public PRs

Copy this workflow into your repo

Reviewer checklist