Azure Resource Group Deletion — How One Click Erased an App

Why Deleting an Azure Resource Group Is a Nuclear Option

An Azure Resource Group is a logical container that holds related resources for an application — VMs, databases, storage accounts, App Services, and more. The core mechanic: deleting the resource group is an atomic, irreversible operation that removes every resource inside it. There is no recycle bin, no soft delete for the group itself. One REST API call or portal click cascades into a delete operation on each child resource, each of which may have its own hard-delete semantics (e.g., a SQL database is dropped, a storage account is purged).

Practically, resource groups enforce a lifecycle boundary. Every resource must belong to exactly one group, and the group’s Azure Resource Manager (ARM) lock or RBAC permissions apply to all contained resources. The group itself has no cost — it’s a management construct — but its deletion triggers a synchronous, ordered teardown. If any child resource fails to delete (e.g., due to a lock or a pending backup), the entire group deletion fails, leaving the group in a partially deleted state that requires manual cleanup.

Use resource groups to model deployment units — one group per environment (dev, staging, prod) or per microservice. The critical rule: never grant delete permissions on a resource group to anyone who doesn’t need to destroy the entire application. In production, always apply a CanNotDelete lock on the resource group to prevent accidental deletion. This is not optional — it’s the single most effective guard against a self-inflicted outage.

Core Compute Services

Azure offers four primary compute models. The choice depends on how much infrastructure you want to manage and how predictable your workload is.

Azure Virtual Machines (VMs) – Full IaaS. You manage the OS, updates, scaling. Good for lift-and-shift migrations and apps that require OS-level access.

Azure App Service – PaaS for web apps. No server management. Supports .NET, Java, Node, Python. Auto-scaling based on demand. Best for stateless web applications with standard request-response patterns.

Azure Kubernetes Service (AKS) – Managed Kubernetes. Microsoft handles the control plane; you manage worker nodes and pods. Ideal for containerized microservices.

Azure Functions – Serverless. Pay per execution, scale to zero automatically. Use for event-driven workloads, webhooks, or scheduled tasks.

# Azure CLI — must-know commands

# Login
az login

# Create a resource group (logical container for Azure resources)
az group create --name myapp-rg --location eastus

# Create a VM
az vm create \
  --resource-group myapp-rg \
  --name myapp-vm \
  --image Ubuntu2204 \
  --admin-username azureuser \
  --generate-ssh-keys

# Deploy a container to Azure Container Instances (quick, no K8s needed)
az container create \
  --resource-group myapp-rg \
  --name myapp-container \
  --image myapp:latest \
  --cpu 1 \
  --memory 1.5 \
  --ports 8000

# Create an Azure Function (serverless)
az functionapp create \
  --resource-group myapp-rg \
  --consumption-plan-location eastus \
  --runtime python \
  --functions-version 4 \
  --name myapp-functions \
  --storage-account mystorageaccount

Azure Storage

Azure Storage is the umbrella for four data services. They share a common authentication mechanism (storage account keys or Azure AD) and redundancy options.

Blob Storage – Object storage for unstructured data like images, backups, logs. Supports tiered access (hot, cool, archive) to optimise cost.

File Storage – Fully managed SMB file shares. Mountable from VMs and on-premises via VPN. Ideal for shared config files or legacy apps.

Queue Storage – Simple message queue for asynchronous task passing. Cheaper than Service Bus but only supports basic FIFO and no pub/sub.

Table Storage – NoSQL key-value store with schema-less entities. Useful for logs, metadata, or any dataset that needs fast key lookups but not complex queries.

# pip install azure-storage-blob
from azure.storage.blob import BlobServiceClient

connection_string = 'DefaultEndpointsProtocol=https;AccountName=...'
client = BlobServiceClient.from_connection_string(connection_string)

# Upload file to blob storage
container = client.get_container_client('documents')
with open('report.pdf', 'rb') as data:
    container.upload_blob('reports/2025/report.pdf', data, overwrite=True)

# Download
blob = container.get_blob_client('reports/2025/report.pdf')
with open('local-report.pdf', 'wb') as f:
    f.write(blob.download_blob().readall())

# List blobs
for blob in container.list_blobs(name_starts_with='reports/2025/'):
    print(blob.name, blob.size)

Azure Networking — Virtual Networks (VNet)

Azure Virtual Network (VNet) is the building block for private networking. Think of it as your own isolated segment of Azure's network.

Subnets – Divide a VNet into address ranges. Resources inside the same VNet can communicate by private IP unless blocked by Network Security Groups (NSGs).

Network Security Groups (NSGs) – Stateful firewalls that filter traffic based on source/destination IP, port, and protocol. Applied to subnets or individual NICs.

Peering – Connect VNets across regions for low-latency communication. Global peering is possible but data moves over Microsoft backbone.

Load Balancer & Application Gateway – Distribute traffic. Load Balancer works at Layer 4, Application Gateway at Layer 7 (HTTP/HTTPS with path-based routing and WAF).

# Create a VNet with two subnets
az network vnet create \
  --resource-group myapp-rg \
  --name myapp-vnet \
  --address-prefix 10.0.0.0/16 \
  --subnet-name web-subnet \
  --subnet-prefixes 10.0.1.0/24

az network vnet subnet create \
  --resource-group myapp-rg \
  --vnet-name myapp-vnet \
  --name db-subnet \
  --address-prefixes 10.0.2.0/24

# Create an NSG rule to allow HTTP from internet
az network nsg rule create \
  --resource-group myapp-rg \
  --nsg-name web-nsg \
  --name AllowHTTP \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --destination-port-ranges 80

# Peer two VNets
az network vnet peering create \
  --resource-group myapp-rg \
  --name myapp-to-other \
  --vnet-name myapp-vnet \
  --remote-vnet /subscriptions/.../resourceGroups/other-rg/providers/Microsoft.Network/virtualNetworks/other-vnet \
  --allow-vnet-access

Identity and Access Management (Entra ID / Azure AD)

Azure Active Directory (now called Microsoft Entra ID) is the identity backbone of Azure. It authenticates users, groups, and service principals (service accounts for apps).

Role-Based Access Control (RBAC) – Assign roles at management group, subscription, resource group, or individual resource scope. Built-in roles include Owner, Contributor, Reader. Custom roles are also possible.

Managed Identities – Azure gives your app an identity without requiring explicit credentials. Use system-assigned (tied to a resource) or user-assigned (shared across resources) identities to access other Azure services securely.

Conditional Access – Policies that evaluate signals (user, device, location) before granting access. For example, require multi-factor authentication (MFA) when accessing from outside the corporate network.

Service Principals – App-level identities used for automated tooling (CI/CD, Terraform). Authenticate with client ID + secret or certificate.

# List roles assignable at subscription scope
az role definition list --custom-role-only true --output table

# Assign Reader role to a user at resource group scope
az role assignment create \
  --assignee user@company.com \
  --role Reader \
  --resource-group myapp-rg

# Create a managed identity for a VM
az vm identity assign --resource-group myapp-rg --name myapp-vm

# Assign managed identity to Storage Blob Data Contributor role
az role assignment create \
  --assignee $(az vm show --resource-group myapp-rg --name myapp-vm --query identity.principalId -o tsv) \
  --role 'Storage Blob Data Contributor' \
  --scope /subscriptions/.../resourceGroups/myapp-rg/providers/Microsoft.Storage/storageAccounts/mystorage

Management and Monitoring — Azure Monitor

Azure Monitor aggregates logs, metrics, and alerts from across your Azure estate. It consists of:

Metrics – Numerical data points collected at regular intervals (CPU usage, requests per minute). Stored for 93 days by default.

Logs – Full text log files from Azure resources (VM system logs, App Service errors, SQL audit logs). Requires a Log Analytics workspace.

Alerts – Rules that trigger when a metric crosses a threshold or a log query returns results. Actions can notify via email, SMS, or push to ITSM tools.

Application Insights – Application Performance Management (APM) for your apps. Tracks request rates, response times, exceptions, and dependency calls. Works for .NET, Java, Node.js, Python.

# Create a Log Analytics workspace
az monitor log-analytics workspace create \
  --resource-group myapp-rg \
  --workspace-name myapp-logs \
  --location eastus

# Query logs using KQL (example: failed requests in last hour)
# Not a direct CLI command – uses the portal or REST API
# KQL: requests | where timestamp > ago(1h) and success == false

# Create an alert rule for high CPU
az monitor metrics alert create \
  --resource-group myapp-rg \
  --name 'High CPU Alert' \
  --scopes /subscriptions/.../resourceGroups/myapp-rg/providers/Microsoft.Compute/virtualMachines/myapp-vm \
  --condition 'avg Percentage CPU > 80' \
  --window-size 5m \
  --evaluation-frequency 1m \
  --action email admin@company.com

What Prerequisites Actually Matter (and What Doesn't)

Before you touch Azure, forget the fluff. You don't need a PhD in networking or a certification in cloud architecture. What you do need is a working understanding of how operating systems handle memory and I/O, because every VM, function, and container you spin up will fight for those resources. You also need to know the basics of TCP/IP—subnets, CIDR notation, and DNS resolution. If you can't explain why your app's connection pool exhausted under load, Azure will make that failure spectacularly public. Finally, have a credit card ready. The free tier gives you $200 credit for 30 days, but forget to delete a resource group and you'll wake up to a bill that teaches you the cost of laziness. The rest—machine learning, IoT, cognitive services—you'll learn when the business need arrives. Focus on the fundamentals first.

#!/bin/bash
# io.thecodeforge
# Validate you have the baseline knowledge before touching Azure
echo "Checking prerequisites..."

# Can you explain CIDR?
if [[ ! $(ipcalc 10.0.0.0/24) ]]; then
  echo "FAIL: install ipcalc and learn subnetting"
  exit 1
fi

# Do you understand memory pressure?
top -b -n1 | head -20
echo "If 'used' RAM exceeds 90%, you are not ready for cloud scaling."

echo "PREREQ CHECK PASSED"

Cognitive Services: Don't Train a Model You Can Buy

Every new team wants to build their own machine learning model for sentiment analysis or object detection. Stop. Azure Cognitive Services gives you pre-built, API-accessible models for vision, speech, language, and decision-making. You call a REST endpoint with your data and get back structured JSON—no GPU clusters, no training data curation. The why is simple: training a custom model costs time and money, and your business probably doesn't have a competitive advantage in recognizing handwritten text. Use the pre-built APIs to ship features in days, not quarters. If you genuinely have a unique dataset and need customization, you can fine-tune using Custom Vision or Custom Translator later. But start with the off-the-shelf solution. Production tip: these APIs throttle at 20 requests per second on the free tier. Move to standard pricing before your demo goes viral.

# io.thecodeforge
import requests
import os

# Requires env vars: AZURE_COGNITIVE_KEY and AZURE_COGNITIVE_ENDPOINT
def analyze_sentiment(text):
    endpoint = os.environ["AZURE_COGNITIVE_ENDPOINT"]
    key = os.environ["AZURE_COGNITIVE_KEY"]
    url = f"{endpoint}/text/analytics/v3.0/sentiment"
    
    headers = {"Ocp-Apim-Subscription-Key": key}
    body = {"documents": [{"id": "1", "text": text}]}
    
    r = requests.post(url, headers=headers, json=body)
    r.raise_for_status()
    return r.json()["documents"][0]["sentiment"]

print(analyze_sentiment("This deployment failed catastrophically."))

Databases: Choose the Wrong One and You Redesign in 6 Months

Azure offers a spectrum of database flavors: Cosmos DB for global NoSQL, Azure SQL for relational, Azure Database for PostgreSQL, MySQL, and MariaDB, plus managed services like Azure Cache for Redis. The rookie mistake is picking what's familiar over what fits the data. If your workload needs ACID transactions and complex joins, use Azure SQL or PostgreSQL—don't force relational data into Cosmos DB and hack around lack of joins. Conversely, if you're storing session state or IoT telemetry with a flexible schema, Cosmos DB's multi-master replication and 99.999% SLA justifies its higher cost. The why: re-architecting data access patterns six months into production costs ten times more than choosing correctly upfront. Use the Azure Portal's Data Migration Assistant to test your schema against each service before committing. And for the love of everything, always use connection pooling and enable geo-redundancy if your users span regions.

// io.thecodeforge
using Microsoft.Azure.Cosmos;

// Use connection pooling via singleton client
// NEVER create a new CosmosClient per request
public class CosmosService
{
    private static readonly CosmosClient _client = new CosmosClient(
        accountEndpoint: Environment.GetEnvironmentVariable("COSMOS_ENDPOINT"),
        authKeyOrResourceToken: Environment.GetEnvironmentVariable("COSMOS_KEY"),
        new CosmosClientOptions() 
        { 
            ConnectionMode = ConnectionMode.Direct,
            MaxRetryAttemptsOnRateLimitedRequests = 9
        });

    public async Task<ItemResponse<T>> GetItemAsync<T>(string id, string partitionKey)
    {
        Container container = _client.GetContainer("mydb", "mycontainer");
        return await container.ReadItemAsync<T>(id, new PartitionKey(partitionKey));
    }
}