Microsoft Azure for .NET Developers

In short: IaaS provides virtualised infrastructure — you manage OS and above (Azure VMs, VM Scale Sets).

• PaaS provides a managed platform — you deploy code and data, Azure handles OS, patching and scaling (App Service, Azure SQL Database, Functions, Container Apps).
• SaaS is complete software you just use (Microsoft 365).
• Serverless (Functions, Logic Apps) is PaaS that scales to zero and bills per use.

In short: Entra ID tenant → management groups (policy and RBAC across subscriptions) → subscriptions (billing and access boundary, quotas) → resource groups (containers for resources sharing a lifecycle) → resources (web apps, databases).

• RBAC and Azure Policy inherit downward.
• A resource belongs to exactly one resource group; resources in a group can be in different regions.

In short: An automatically managed identity in Entra ID for an Azure resource (App Service, Functions, VM, AKS pod via workload identity) that lets code authenticate to other Azure services (Key Vault, Storage, SQL, Service Bus) without storing any credentials.

• Azure handles the credentials and rotation.
• System-assigned is tied to one resource's lifecycle; user-assigned is a standalone identity shared by several resources.
• In code, use DefaultAzureCredential.

In short: Live apps with their own hostnames (e.g. app-staging.azurewebsites.net) within the same App Service plan (Standard tier and above).

• You deploy to staging, warm it up and test, then swap with production — near-zero downtime and instant rollback by swapping back.
• Slot-specific (sticky) settings stay with the slot (e.g. connection strings for staging).

In short: Service Bus is for high-value business messages between services where every message must be processed: queues/topics, FIFO with sessions, transactions, duplicate detection, dead-lettering (orders, payments).

• Event Grid routes discrete events (something happened) to subscribers via push with filtering — reacting to blob uploads, resource changes or custom app events.
• Event Hubs ingests high-volume event streams (telemetry, logs, IoT) with partitions, retention and replay for stream processing.

In short: A trigger starts the function (HTTP, Timer, Service Bus, Blob, Queue, Event Grid, Event Hubs, Cosmos DB change feed); exactly one per function.

• Bindings declaratively connect to data as inputs/outputs (read a blob, write to a queue) without SDK code.
• Plans: Flex Consumption (serverless, scale to zero, VNet — the default choice for new apps), Premium (pre-warmed, no cold start, long runs), Dedicated/App Service plan (predictable cost), Container Apps.
• For .NET, use the isolated worker model.

In short: An extension of Azure Functions for stateful workflows in code.

• An orchestrator function coordinates activity functions, and state is checkpointed automatically (event sourcing in storage), so workflows can run for days and survive restarts.
• Patterns: function chaining, fan-out/fan-in, async HTTP APIs (status endpoint), monitoring loops, human interaction (wait for an external event with timeout), durable entities.
• Orchestrator code must be deterministic (no DateTime.Now, no direct I/O).

In short: Azure SQL: relational data, complex joins and transactions, strong consistency, reporting, existing SQL skills — most line-of-business apps.

• Cosmos DB: globally distributed apps needing low latency at any scale, flexible schema JSON documents, massive throughput with predictable performance, multi-region writes, tunable consistency — e.g. catalogues, IoT, user profiles, gaming.
• Cosmos requires careful partition key design and RU cost planning.

In short: From strongest to weakest: Strong (linearizable reads — always latest), Bounded Staleness (reads lag by at most K versions or T time), Session (default — read-your-own-writes within a session), Consistent Prefix (never see out-of-order writes), Eventual (no ordering guarantee, lowest latency/cost).

• Stronger consistency means higher latency and RU cost, and Strong limits multi-region writes.

In short: Deploy the stateless app tier to two or more regions (App Service/Container Apps/AKS), each zone-redundant;

• put Azure Front Door in front for global load balancing, failover, WAF and CDN;
• data: Azure SQL with auto-failover groups (or Cosmos DB with multi-region writes);
• geo-redundant storage;
• Service Bus geo-disaster recovery/replication;
• Key Vault per region;
• health probes and automated failover;
• IaC for identical environments;
• test failover regularly;
• monitor with Application Insights;
• define RTO/RPO targets and back up accordingly.

In short: Short term: configure autoscale rules (scale out on CPU > 70% and schedule-based scale-out before 9 AM).

• Investigate root cause with Application Insights (slow requests, dependencies, profiler): expensive queries (add indexes, caching), sync-over-async, chatty calls, large payloads.
• Consider caching hot data in Redis, moving heavy work to queues and background workers, and scaling up the plan if a single instance is undersized.
• Verify with load tests.

In short: The API saves the order and writes an outbox record in the same transaction; a background publisher sends an OrderPlaced message to a Service Bus topic.

• Inventory, billing and email each have their own subscription (with filters if needed), processed by Functions/Container Apps workers with peek-lock, retries, dead-letter queue monitoring and idempotent handlers (dedupe by MessageId).
• Managed identities for access, Application Insights distributed tracing across services, alerts on DLQ count.

In short: Rotate the password immediately.

• Switch the app to Entra ID authentication for Azure SQL with a managed identity (Authentication=Active Directory Default in the connection string, create a contained user FROM EXTERNAL PROVIDER with minimal roles) — no password at all.
• Put any remaining secrets in Key Vault with Key Vault references.
• Enable secret scanning in the repo and remove SQL admin usage from apps.