Skip to main content
Use this workflow when the question is about what exists today in Azure, not just what is defined in source control. This is the Cloud sync workflow. It uses a least-privilege service principal to read deployed Azure resources, export deployment templates, and enrich the graph with Network Watcher topology when that permission is available.

​
Best for

  • Subscription reviews
  • Environment health checks
  • Architecture and cost baselining
  • Stakeholder-ready snapshots before planning work

​
Workflow

  1. Create an Azure Cloud sync connection.
  2. Scope it to the right subscription or resource groups.
  3. Create a project from that connection.
  4. Sync the project.
  5. Run cost and architecture reports.
  6. Share the project internally or publish a read-only view.

​
What makes this workflow valuable

It gives you current-state context. That is useful when the real question is about drift, active cost exposure, or the architecture that is actually running now.

​
Good output

A good first review ends with:
  • one project per environment or scope that matters
  • a recent cost snapshot
  • an architecture score the team can discuss
  • a short list of fixes or follow-up questions

​
Common mistake

Do not start with a huge multi-subscription scope if your goal is to validate the product quickly. Start with one representative environment, then expand. Do not use Contributor for production sync. Use the CloudEval Live Sync Reader custom role from Azure Cloud sync permissions.

​
Next step

Use Connect an Azure environment to set it up, then continue to Run your first reports.
Last modified on May 22, 2026