Cloud Computing Intermediate to Advanced +250 XP

Microsoft Azure

Azure Enterprise Hierarchy: Resource Groups & Subscription Boundaries

To architect solutions on **Microsoft Azure**, you must master its four-tier organizational hierarchy. This hierarchy ensures seamless access control, cascading policy definition, and granular billing segmentation across complex enterprise environments.

The Azure Four-Tier Organizational Tree:
  • Management Groups: The highest structural containers. They allow you to apply governance policies (Azure Policy) and Role-Based Access Control (RBAC) across multiple subscriptions.
  • Subscriptions: The fundamental billing and quota boundary. Every resource must belong to exactly one subscription.
  • Resource Groups (RG): A logical container where Azure resources (VMs, databases, web apps) are deployed and managed. Resources in an RG share a common lifecycle (create, update, delete together). Unlike AWS where resources exist globally or by VPC, Azure resources are strictly bound to a Resource Group.
  • Resources: The actual instances of services you provision (e.g. Azure VM, SQL Database, Storage Account).

Entra ID (formerly Azure Active Directory): Provides identity and access boundaries. Instead of IAM Users in separate accounts, Azure uses a tenant-wide Entra ID directory where **Service Principals** act as application identities and **Managed Identities** allow resources to authenticate securely without secret storage.

Azure Kubernetes Service (AKS) & Key Vault CSI Integration

**Azure Kubernetes Service (AKS)** is a highly optimized, fully managed Kubernetes cluster engine. Understanding how AKS links with Azure Virtual Networks (VNets) and security services is key to passing cloud certification exams and running stable clusters:

Networking Modes: AKS supports **Kubenet** (basic networking where pods receive IPs from a private internal range and rely on NAT) and **Azure CNI** (advanced networking where every pod gets a native IP address directly from the Azure VNet subnet, maximizing performance but requiring careful subnet planning).

Secrets Injection with Secrets Store CSI: Rather than storing raw connection credentials in Kubernetes Secrets manifest files, modern production AKS clusters use the **Secrets Store CSI Driver** with **Azure Key Vault**. This automatically mounts credentials, API tokens, and SSL certificates as virtual filesystem files directly into pod containers, updating them dynamically on rotation.

Interactive Pipeline: AKS Container Provisioning & Ingress Traffic Flow

Observe how modern HTTP/HTTPS client requests travel through Azure boundaries. The external traffic hits the Azure Application Gateway (acting as a dynamic Ingress Controller), which routes the packets natively to pods in the AKS subnet using Azure CNI, while pods retrieve database keys dynamically via the Secrets Store CSI provider from Azure Key Vault.

Pipeline V: AKS Container Provisioning & Ingress Flow

Client
App Gateway
Public SSL/WAF endpoint
Ingress
Ingress Controller
Azure CNI pod routing
Mount
Key Vault CSI
Injects secrets dynamically
Service
AKS Microservices
Execute application codes

Microsoft Azure az CLI reference

Here are the standard production az commands to build Resource Groups, spin up managed Kubernetes environments, and retrieve secure keys from Azure Key Vault:

# Create a Resource Group in West US 3
az group create \
    --name rg-production-services \
    --location westus3

# Provision a production-ready AKS Cluster with Azure CNI
az aks create \
    --resource-group rg-production-services \
    --name aks-prod-cluster \
    --node-count 3 \
    --network-plugin azure \
    --enable-managed-identity \
    --generate-ssh-keys

# Get AKS access credentials for kubectl mapping
az aks get-credentials \
    --resource-group rg-production-services \
    --name aks-prod-cluster

# Retrieve dynamic database connection key from Key Vault
az keyvault secret show \
    --vault-name kv-prod-vault \
    --name db-connection-string \
    --query value -o tsv