SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsazure-infra-validation

azure-infra-validation

Deployment & operations

View repository

Updated 10-15 16:46

About this skill

Azure Infra Validation

A workspace skill for proceeding with verification, PoC, construction, and confirmation involving configuration changes in an Azure environment under the premise of a safe lab/sandbox.

Read-only triage of production incidents is out of scope; this skill covers creation of verification configurations, state monitoring, constraint workarounds, before/after comparison, cleanup up to these.

When to Use

  • When you want to newly build a verification environment on Azure and try out features and constraints
  • When you want to test networking features in a lab such as VPN Gateway, VNet peering, BGP, Route Server, Private Endpoint, and Hub-and-Spoke
  • When you want to assemble a minimal Azure-only verification as an alternative to a production ExpressRoute configuration
  • When you want to proceed with read/write infrastructure verification using Azure CLI
  • When you want to monitor Azure resources during deployment and move to the next step once they become READY
  • When you want to move forward while working around Azure SKU / zone / auth / region constraints that arise during verification on the spot
  • When you want to reflect the construction results and before/after observed values in Answer/ や reports/ when you want to reflect it in

When NOT to Use

  • When you want to triage a production incident in read-only mode
  • When you only want simple product Q&A or specification confirmation
    • → Normal Docs research
  • When you want to complete end-to-end verification of a production ExpressRoute that requires a carrier or on-premises hardware here and now
    • With this skill, approximate verification in a lab is possible, but provider-side peering and actual hardware FIC are not covered
  • When you want to design and deploy a configuration intended for reuse with Bicep / AVM

Inputs

At minimum, receive two or more of the following.

  • tenant ID
  • subscription ID
  • The name of the feature you want to verify
  • The assumed topology (e.g., hub-and-spoke, VPN BGP, private endpoint)
  • Cost tolerance
  • Whether cleanup is required

If anything is missing,どの tenant/subscription に作るか と 検証したい到達点 confirm with top priority.

Core Rules

  • First, whether you will touch production or use a lab/sandbox make this clear
  • If touching production, do not make destructive changes. For verification, prioritize a separate subscription
  • For verification involving changes,minimal configuration / low-cost configuration start from
  • Do not build the full configuration right away;the minimal unit necessary to achieve the objective divide by this and then expand
  • Fix the Azure CLI authentication state, tenant, and subscription first
  • Deploy after checking prerequisites and constraints in Microsoft Learn
  • Before deployment,whether the verification truly holds with Azure-only / whether actual hardware or a provider is required perform a feasibility check
  • For long-running Azure operations during deployment,state monitoring script use this or status polling to proceed to the next step
  • In verification of configuration changes or setting changes,prepare an observation script before the changeand capture the control-plane change time and the dataplane / route impact time separately
  • consider control-plane validation and data-plane / route validation separately
  • always leave a before/after comparison
  • あとで Activity Log を見ればよい without assuming that, use polling immediately after the change to capture reconvergence time and whether there was a brief outage
  • after validation, clearly state the cleanup policy

Decision Points

1. Is ExpressRoute itself necessary?

  • if what is needed is only functional validation of route advertisement , then prioritize an Azure-only lab based on VPN Gateway
  • if validation requires active circuit / private peering / BGP peering / provider-side provisioning , then explicitly state that this skill cannot "fully substitute" for production ExpressRoute validation

2. Is Azure-only minimal validation sufficient?

  • Sufficient: VNet-to-VNet VPN + BGP + hub/spoke + summarizedGatewayPrefixes
  • Insufficient: you want to see the quirks of on-prem physical peer or FIC-specific constraints
    • → In a second phase, extend to pseudo on-prem using NVA / FRR / strongSwan / Bird

2.5. Pass the feasibility check first

Before starting, briefly determine the following.

  • The purpose is functional feasibility confirmation か、production-equivalent end-to-end validation か
  • Can it be substituted with Azure-only?
  • Can you start with a low-cost SKU / minimal number of spokes?
  • Can you assume you will increase them along the way?

If this determination shows Azure-only is sufficient, then at first proceed with minimal number of spokes / minimal number of gateways / minimal number of routes .

For deployment constraints, READY determination, and detailed phase procedures, refer to references/validation-runbook.md .

Workflow

  1. Feasibility: decide the validation goal, Azure-only feasibility, minimal configuration, cost/cleanup
  2. Scope: fix tenant / subscription / lab or production boundary / target endpoint
  3. Official grounding: check prerequisites / limits / supported SKUs in Microsoft Learn
  4. Preflight: az account show, check provider registration, region availability, RBAC, and observation methods
  5. Build: create the minimal Resource Group / VNet / GatewaySubnet / peering / core resources
  6. Observe: READY / Connected wait until , then save baseline routes / peer status / metrics
  7. Change: change only one target setting, and record the requested time, Succeeded time, and correlation ID
  8. Compare: evaluate before/after, reconvergence time, and whether there was a brief outage using polling evidence
  9. Cleanup or persist: keep or delete the lab, and reflect the results in the report / Answer

Detailed steps: references/validation-runbook.md

Done Criteria

  • The target tenant / subscription is fixed
  • The validation topology is a minimal configuration
  • SKU / zone / address plan have been adjusted according to Azure constraints
  • READY / Connected you have confirmed before proceeding to the next process
  • before/after route information remains
  • any of the change request time, Succeeded time, or impact observation time remains
  • The reconvergence time or presence/absence of momentary interruptions can be explained not only by the Activity Log but also by polling evidence
  • The results were Answer/ や reports/ reflected in
  • left a cleanup policy

Output Shape

Include in the report 検証目的、検証構成、事前状態、変更内容、変更時刻、事後状態、評価、Cleanup The template uses references/output-template.md .

Example Prompts

  • /azure-infra-validation <lab-subscription> で VPN Gateway ベースの summarizedGatewayPrefixes 検証ラボを作って
  • /azure-infra-validation Azure-only で route advertisement の before/after を見たい。最小構成を作って
  • /azure-infra-validation hub-and-spoke + BGP の lab を構築し、設定変更後の learned routes を比較して
  • /azure-infra-validation Azure CLI だけで構築可能な検証プランを作って、そのまま実行して
  • /azure-infra-validation デプロイ中の Gateway を監視し、READY になったら次工程へ進めて

Integration Notes

  • This skill is limited to read-write verification in lab/sandbox, and separates responsibilities from read-only investigation of production incidents
  • If the verification results are useful for interpreting a production incident, the investigation results may be passed as input to the production investigation

References