# Deployment approval checklist

One authorized finite Azure trial is documented in VALIDATION.md. It does not approve another deployment or certify compatibility elsewhere. Do not treat compilation or mocked tests as a compatibility claim; independent replay and release review remain outstanding.

## Scope and permissions

Use a lab-only subscription under your authority, a new `ra-lab-...` group, a unique run ID, a named operator and recovery owner, and an external restricted evidence directory. No production peering, resolvers, data, group adoption or arbitrary test targets are supported. Check current policies, resource-provider registration, quotas, Ubuntu 24.04 image version and VM size availability in the chosen region. The image version is mandatory and pinned; `latest` is rejected.

The operator needs resource-group creation/deletion, resource deployment/validation/what-if and reads/writes for the resource types in `main.bicep`. Role assignment creation **and deletion** are separate from Contributor: review `Microsoft.Authorization/roleAssignments/write` and `/delete` on only this disposable group, plus role-definition reads and required principal lookup permissions. Do not grant the worker role-assignment authority or subscription Owner to avoid a permission review.

VM-agent Run Command is privileged guest execution. Verify the current CLI operation's exact action/managed API permissions and regional command-read dependency; do not assume one documentation action covers every API. NIC effective-route/NSG reads and VM instance-view reads are needed for evidence. CLI failures stop execution and are retained privately. The operator must be able to recover/clean up even when guest tests fail.

Blob diagnostics require the selected service categories and workspace linkage. Log Analytics query access is a separate permission; validate actual resource-specific `StorageBlobLogs` routing and schema in the deployed region. This kit does not change subscription Activity Log diagnostic settings: collect lab-scoped management history through the reviewed procedure instead. Resource logs are not management logs.

Worker baseline grants: Blob Data Reader on two disposable accounts. Narrow state: reader only on the required container. Seeder: temporary Blob Data Contributor on the three synthetic containers, removed before tests, followed by verified VM deallocation. This separation is a lab design, not a credential revocation guarantee.

## Spend approval: complete before deploy

No price is fabricated in this preview. Produce a **dated Azure Pricing Calculator estimate or documented official retail-price estimate with contingency** using your actual region, currency, subscription offer, duration, request count and expected log volume. Retail pricing is not an offer-specific invoice; record that uncertainty. Include:

- Two selected VMs while provisioning/seeding, then one running VM; disks remain billable after deallocation.
- NAT Gateway hours/processing and its Standard public IP; no inbound VM exposure but explicit broad Azure public management HTTPS egress.
- Two private endpoints, private-link data processing, DNS zone/query costs and two Standard_LRS accounts/transactions.
- Log Analytics ingestion/retention and any additional management or export cost. The template's daily workspace cap is a coarse ingestion control, not a complete spend ceiling.
- Teardown delay, retained evidence/storage and cost-reporting lag.

Record a positive `estimated_total` and approved `maximum_spend`, the review timestamp, cleanup deadline and owner. Price review must be within seven days at execution; approval must not be expired. The numeric cap is a reviewed go/no-go bound, **not an automatic budget monitor or billing stop**. Monitor current usage manually; stop and clean up before an adverse forecast exceeds the accepted amount.

Cleanup remains available after expiry with the original approval file. Never edit that file after deployment: its SHA-256 binds ownership tags and the evidence manifest. If approval/manifest is lost or Azure rejects deletion, use a separately reviewed manual cleanup against the exact recorded group. No code may infer ownership from a name alone.

## Source/API assumptions

`main.bicep` pins Network 2024-05-01, Compute 2024-07-01, Storage 2023-05-01, private DNS 2024-06-01, workspace 2023-09-01, Authorization 2022-04-01 and diagnostic settings 2021-05-01-preview. The diagnostic-settings API version is explicitly preview-labelled even though the feature is established. Review these schemas and service support before approval; change source before the run, recompile, record hashes, then create a fresh run.

Guest requests use IMDS 2018-02-01 and Storage REST 2023-11-03. Record Azure CLI, Bicep, Python and image versions with the evidence. Package hashes establish source identity, not event authenticity.

References:

- https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/deploy-what-if
- https://learn.microsoft.com/en-us/azure/storage/blobs/assign-azure-role-data-access
- https://learn.microsoft.com/en-us/azure/virtual-machines/linux/run-command
- https://learn.microsoft.com/en-us/azure/storage/common/storage-private-endpoints
- https://azure.microsoft.com/en-us/pricing/calculator/