How these five were selected
SkillSignal compared the Microsoft Azure Skills already indexed in the directory and selected roles that answer different cloud-operations questions: access, preparation, validation, incident evidence, and machine capacity. The shortlist uses source-grounded scope, permission boundaries, workflow fit, and reviewability rather than treating a popularity signal as a security approval.
This is an editorial starting point, not a benchmark or a recommendation to install five packages at once. Keep the smallest set that has a named owner, a reversible first task, and an acceptance check. If the project does not use the corresponding Azure workflow, choose a different role or skip it.
- The Skill owns one clear Azure decision or evidence role.
- The required access is proportionate to that role.
- The source, limitations, and live-data dependencies are visible before installation.
- A human reviewer can verify the resulting plan, finding, or assignment.
1. azure-rbac — best starting point for access scope
azure-rbac is the narrowest first step when the question is whether a user, group, service principal, or managed identity has the right access. It helps inspect role definitions and assignments, distinguish management-plane from data-plane permissions, and choose the smallest practical scope before a change.
Treat every assignment as a controlled access change. A broad role, inherited scope, wrong principal, or premature removal can create either privilege escalation or an outage. Resolve immutable identifiers, review effective access, and verify propagation after an approved change.
2. azure-prepare — plan before generating infrastructure
azure-prepare owns the planning stage for azd-oriented Azure applications. It researches the application and its dependencies, records decisions in .azure/deployment-plan.md, and only then prepares azure.yaml, Bicep or Terraform, and container assets after approval.
It is not a general deployment shortcut. The plan should identify the target subscription, region, identity, networking, services, and recipe. Keep the generated diff reviewable and hand it to Azure Validate before any production write.
3. azure-validate — readiness gate for RBAC and IaC
azure-validate is the evidence gate between preparation and deployment. It checks application configuration, azure.yaml, Bicep or Terraform, managed identity, RBAC prerequisites, and what-if results, then records the actual checks that support a Validated plan.
A passing preflight reduces known risk but cannot prove the deployed application will behave correctly. Do not mark a plan Validated by hand or omit a failed check; preserve the commands and results so the later deployment step can verify what was actually reviewed.
4. azure-diagnostics — production evidence when something breaks
azure-diagnostics structures an incident investigation from symptoms to resource health, logs, metrics, recent changes, and service-specific next steps. It is useful when an operator needs to reduce uncertainty before deciding whether a remediation is justified.
Diagnosis is not permission to change production. Separate read-only evidence collection from writes, use an appropriate time window, redact shared telemetry, and require a reviewed plan before remediation. Missing telemetry or an external dependency can still leave the root cause unresolved.
5. azure-compute — capacity and cost decisions for VMs
azure-compute is the fit when the workload is a bare Azure VM or VM Scale Set and the decision involves SKU, image, quota, pricing, autoscale, orchestration, or reservations. It keeps machine-capacity questions separate from application-platform deployment.
Capacity and cost data change by region and time. Verify live quota, pricing, image availability, network exposure, and the exact provisioning plan before creating or resizing resources. For a web app, container service, or serverless workload, route back to the application-specific preparation workflow instead.
A safer order of operations
For a new Azure workload, resolve access with azure-rbac, capture the approved design in azure-prepare, and let azure-validate record readiness evidence. Azure Deploy is intentionally a separate production action, not part of the default install list. If the workload later fails, use azure-diagnostics to collect evidence before proposing a fix; if the uncertainty is machine capacity, use azure-compute with live pricing and quota checks.
The useful stack is the smallest sequence that produces inspectable artifacts. A five-item list is not a requirement: a team that only needs an access review may need azure-rbac alone, while a prepared VM migration may need a different combination and a separate human approval.
- Access: the principal, role, and scope are explicit.
- Plan: the target subscription, region, identity, services, and recipe are recorded.
- Readiness: failed checks are resolved or explicitly stopped, not hidden.
- Operations: read-only evidence is separated from production writes.
- Capacity: current quota, price, image, and exposure are checked for the target region.