# App Service production operations

## What people get wrong

- They treat App Service as production-ready because it is PaaS. The workload still needs health, scaling, network, identity, release, and recovery design.
- They trust slots without checking warm-up, sticky settings, dependency compatibility, and rollback drills.
- They confuse VNet integration with private ingress. VNet integration controls outbound access; private endpoint and access restrictions control inbound exposure.
- They put secrets in app settings instead of using managed identity and Key Vault references.
- They configure backup but never prove restore, especially for state stores outside the app.

## Officially grounded service shape

Microsoft Learn frames App Service readiness around Well-Architected pillars. Production web apps need appropriate plan tier and instance count, health checks, diagnostics, HTTPS/TLS, managed identity, private networking where needed, deployment slots for release safety, autoscale, zone or regional resilience where required, and clear backup/restore ownership.

## Non-negotiable design rules

1. Use multiple instances for production workloads unless the business explicitly accepts single-instance risk.
2. Enable health check with a path that proves critical dependency readiness without leaking sensitive data.
3. Use managed identity and Key Vault references for secrets; never normalize pasted secrets.
4. Validate inbound and outbound networking separately.
5. Use staging slots for risky deployments and prove swap/rollback behavior.
6. Use native database backup/restore for linked state stores; do not rely on App Service backup as a database recovery strategy.
7. Enable diagnostics, metrics, alerts, and operator runbooks before go-live.

## Minimal safe implementation flow

1. Inventory app, plan, OS, region, tier, instances, deployment model, and dependencies.
2. Verify ingress: public endpoint, access restrictions, private endpoint, DNS, Front Door/Application Gateway, WAF, and SCM exposure.
3. Verify outbound: VNet integration, route-all, DNS, private endpoints, Key Vault, database, storage, registry, and firewall paths.
4. Verify identity and secrets: system/user-assigned identity, Key Vault role or access policy, slot-specific references, and no embedded secret values.
5. Verify release: staging slot, warm-up path, swap with preview if needed, sticky settings, rollback, and smoke tests.
6. Verify resilience: health check, auto-heal, autoscale, zone/multiregion posture, backup, restore test, and dependency retry/circuit breakers.
7. Deliver go/no-go with blockers.

## High-risk assumptions to kill

- App Service being managed PaaS does not prove production readiness; plan sizing, instance count, health checks, release safety, and dependency recovery still matter.
- A staging slot is not a rollback plan unless sticky settings, warm-up path, smoke tests, and swap reversal are rehearsed.
- VNet integration is outbound connectivity only; it does not provide private inbound access to the app.
- App Service backup does not restore every surrounding dependency, network feature, identity, alert, or deployment slot.
- A green health endpoint is weak evidence if it does not represent critical dependency readiness or if it leaks sensitive internals.

## Safe command/code verification targets

- Inspect IaC for plan SKU, worker count, zone redundancy, Always On, health check path, autoscale rules, diagnostics, and backup configuration.
- Review deployment automation for staging-slot deployment, smoke testing, swap operation, rollback operation, and tagged container/image provenance.
- Check app configuration for Key Vault references, managed identity use, slot-specific settings, no embedded secrets, and SCM access restrictions.
- Validate templates distinguish private endpoint inbound access from VNet integration outbound access and include private DNS where required.
- Review restore/runbook evidence for app content, configuration, custom domains, TLS, identities, networking, databases, and alerts instead of assuming one backup covers all.

## Safe verification targets

- Plan SKU/tier, worker count, autoscale rules, Always On, health check, and auto-heal.
- Slot list, slot settings, traffic routing, swap behavior, and rollback evidence.
- Public network setting, access restrictions, private endpoints, DNS, reverse proxy, and SCM restrictions.
- Managed identity, Key Vault reference resolution, network-restricted vault access, and config separation.
- Diagnostic settings, App Insights, alerts, log retention, backup schedule, and restore test results.

## When to push back

Push back on production launch if rollback is manual guesswork, health check is absent, public access is unexplained, secrets are embedded, linked database backup is assumed, or no one owns alerts and restore drills.

# MCP and evidence path for App Service production operations

Use Microsoft Learn documentation through the user's configured documentation MCP as the first grounding path for Azure service behavior. This file defines evidence boundaries; it must not imply that documentation proves the user's tenant, subscription, RBAC, quotas, deployed resources, or production readiness.

## Evidence ladder

1. `docs_only`: Microsoft Learn documentation and official architecture guidance. Use for documented behavior, caveats, and safe review criteria.
2. `sampled_read_only`: configured-environment evidence from read-only tools, if available and explicitly scoped. Use only for the sampled resource/time window.
3. `user_supplied`: sanitized outputs, IaC, diagrams, or metrics provided by the user. Treat as unverified unless independently checked.
4. `mutation_ready`: documentation plus current-state evidence plus explicit approval, blast-radius statement, and rollback path.

## Rules

- Do not expose environment-specific implementation details in committed docs or user-facing guidance.
- Do not ask for credentials, tokens, tenant identifiers, subscription identifiers, connection strings, private keys, customer data, or raw secrets.
- If current-state evidence was not sampled, say `not sampled`; do not imply it.
- If evidence is representative or partial, say so. A sample does not prove broad regional availability or production readiness.
- Prefer read-only evidence before mutation planning. Stop for approval before write operations.

## Final-answer evidence language

Use phrases like:

- "Based on Microsoft Learn documentation..."
- "Configured-environment evidence was not sampled in this review."
- "The following is an inference from the provided configuration, not proven live state."
- "This recommendation is mutation-ready only after explicit approval and rollback review."

# Official sources for Azure App Service Production Readiness

Use Microsoft Learn documentation through the user's configured documentation MCP to ground App Service reviews. Documentation proves service guidance; it does not prove the user's app settings, plan SKU, network routes, diagnostics, backup success, or production readiness.

## Primary Microsoft Learn sources

| Source | Review implication |
| --- | --- |
| [Architecture best practices for Azure App Service Web Apps](https://learn.microsoft.com/en-us/azure/well-architected/service-guides/app-service-web-apps) | Ground reliability, security, cost, operational excellence, scaling, health check, slots, managed identity, diagnostics, and tradeoff guidance. |
| [Reliability in Azure App Service](https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service) | Use for shared responsibility, zone/region outage posture, backup, transient faults, maintenance, and SLA framing. |
| [Deploy to deployment slots](https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots) | Use for slot strategy, swap behavior, warm-up, sticky settings, and rollback checks. |
| [Key Vault references for App Service](https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references) | Use for managed identity, secret reference, and network-restricted vault behavior. |
| [Monitor App Service instances with health check](https://learn.microsoft.com/en-us/azure/app-service/monitor-instances-health-check) | Use for health path, unhealthy instance removal, and readiness checks. |
| [App Service networking features](https://learn.microsoft.com/en-us/azure/app-service/networking-features) | Use for VNet integration, private endpoints, access restrictions, and outbound routing semantics. |
| [Manage backup and restore in App Service](https://learn.microsoft.com/en-us/azure/app-service/manage-backup) | Use for backup support and linked-database backup deprecation caveats. |
| [Baseline highly available zone-redundant web application](https://learn.microsoft.com/en-us/azure/architecture/web-apps/app-service/architectures/baseline-zone-redundant) | Use for production architecture, slots, package deployment, Key Vault references, private endpoints, and zone redundancy pattern. |

## Source-grounding rules

- A plan SKU recommendation from docs is not proof the current app is correctly scaled.
- A configured slot in code is not proof of safe swap. Validate sticky settings, warm-up, health, and rollback evidence.
- A private endpoint is not proof of private-only app posture. Check public access/access restrictions, DNS, reverse proxy path, and outbound dependencies.
- Backup configured is not recovery proven. Require restore test evidence.

# Safety checklist for Azure App Service Production Readiness

## Non-negotiable gates

- Never ask for publish profiles, connection strings, certificates, private keys, app secrets, tenant identifiers, subscription identifiers, or customer data.
- Do not approve production if rollback, health checks, diagnostics, managed identity, secret flow, networking, and owner/runbook evidence are missing.
- Treat app settings as sensitive. Do not echo values; reason about names and references only.
- Require explicit approval before app setting changes, slot swaps, scale changes, network changes, identity changes, backup changes, or restart operations.
- Do not equate App Service managed platform with workload resilience. Application dependencies and state stores remain the user's responsibility.

## High-risk assumptions to kill

- "Premium plan means production-ready." SKU is one input, not evidence of readiness.
- "Slots make deployment safe." Slot settings, warm-up, health, dependency compatibility, and rollback must be proven.
- "Private endpoint means no public exposure." Public access, access restrictions, DNS, reverse proxy, and SCM endpoint behavior still need review.
- "App Service backup covers the database." Linked database backup support has deprecation caveats; use native database backup/restore for state stores.
- "Key Vault references remove all secret risk." Managed identity permissions, network routing, slot settings, and reference resolution must be checked.

## Evidence labels

- `docs_only`: Microsoft Learn guidance only.
- `sampled_read_only`: current app or plan evidence was sampled safely.
- `config_review`: IaC/app configuration was reviewed but not proven live.
- `restore_proven`: backup/restore or rollback was tested and evidence exists.
- `mutation_ready`: blast radius, rollback, and explicit approval exist.

## Minimum safe evidence

- App Service plan tier, instance count, OS, region, zone posture, and scale rules.
- Deployment slot count, swap strategy, sticky settings, warm-up path, and rollback path.
- Ingress model, public access/access restrictions, private endpoint, DNS, WAF/reverse proxy, and SCM restrictions.
- VNet integration, outbound routing, private dependencies, Key Vault references, and managed identity permissions.
- Health check, diagnostics, alerts, dashboards, backup/restore tests, and on-call ownership.

# Workflow and output contract for Azure App Service Production Readiness

## Minimal safe workflow

1. Classify workload: public web app, internal app, API, custom container, WebJob, or mixed.
2. Ground the review with Microsoft Learn through the user's configured documentation MCP.
3. Define current evidence: docs only, read-only current-state sample, IaC/config review, or user-supplied sanitized evidence.
4. Review reliability: instances, zones, health check, auto-heal, scaling, statelessness, dependencies, backup, and recovery.
5. Review security: managed identity, Key Vault references, HTTPS/TLS, public access, private endpoint, access restrictions, SCM, CORS, logs, and secret handling.
6. Review operations: slots, warm-up, swap, rollback, diagnostics, alerts, release flow, ownership, and drills.
7. Deliver verdict and blockers. Do not soften no-go findings.

## Output contract

```markdown
## Verdict
<go | conditional-go | no-go | docs-only advisory>

## Evidence level
- Documentation: <sources used>
- Runtime/config evidence: <sampled_read_only | config_review | not sampled>

## Findings
1. <finding> — Evidence: <docs_only|sampled_read_only|config_review|inference>

## Production blockers
- <blocker>

## Safe next actions
- <least-risk action>

## Open questions
- <question needed for readiness>
```

## Pushback triggers

Push back on direct-to-production deployments, no slot rollback, no health endpoint, public access with no threat model, secrets in app settings, no restore test, no alerts, or no named operational owner.