Key difference from AWS

In AWS, a subnet exists in exactly one AZ. In Azure, a subnet spans all AZs in the region — you control AZ placement at the resource level (VM availability zone, not subnet). This makes Azure VNet design simpler but AZ redundancy is controlled differently.

AKS vs EKS — Key Differences

Azure Monitoring Stack

Azure DevOps vs GitHub Actions

Azure DevOps Pipelines is Microsoft's enterprise CI/CD. Tightly integrated with Azure — uses service connections for Azure auth, Environments for deployment gates, built-in task library for Azure services. GitHub Actions is simpler and more popular for new projects. Azure DevOps is preferred when: already using Azure Repos or Azure Boards, need enterprise audit trails, working in regulated industries.

The Azure hierarchy — most important concept to understand first

Tenant

Your organisation's dedicated instance of Azure Active Directory (now called Microsoft Entra ID). Created when your company signs up for Azure or Microsoft 365. Every user, group, application, Managed Identity, and Service Principal belongs to a Tenant. Identified by a Tenant ID (GUID): xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

Analogy: Azure is an apartment building. Your Tenant is your company's floor — your own private space with your own security rules. Other companies are on other floors. Azure AD is the security desk for your floor.

Subscription

The billing and resource boundary. One Tenant can have many Subscriptions. Common pattern: Dev Subscription, Staging Subscription, Production Subscription — each with its own cost centre and access controls. Resources like AKS clusters and Key Vaults live inside a Subscription.

Resource Group

A logical container for related resources. All resources for the production platform go in rg-upward-production. Delete the Resource Group and everything inside is deleted. Apply RBAC at the Resource Group level — a developer can have Contributor on the dev Resource Group but only Reader on production.

What GitOps is — one sentence

GitOps means Git is the single source of truth for what runs in production. Every change goes through a Git commit. No one runs kubectl apply directly on production.

The problem GitOps solves

Without GitOps: someone runs helm upgrade manually. Someone changes a ConfigMap in the portal. A pipeline runs with a different image tag than what's in Git. Result: nobody knows the true state of production. This is called configuration drift.

ArgoCD — the engine that makes GitOps work

ArgoCD runs inside your AKS cluster as pods. You tell it: "watch this Git repo, deploy to this namespace." Every 3 minutes (or instantly via webhook) it checks whether the cluster matches Git. If not — it syncs.

ArgoCD key features

• App-of-Apps pattern — one ArgoCD Application manages many child applications. One Git repo change can trigger coordinated updates across 20 microservices.
• Sync waves — control deployment order. Wave 0: databases. Wave 1: backend services. Wave 2: frontend. Dependencies respected automatically.
• Drift detection — compares Git (desired) with cluster (actual). Shows you a diff before you sync.
• Rollback — revert the Git commit → ArgoCD applies previous version. No complex procedures.
• RBAC — who can sync which applications. Developers can sync dev. Only release team can sync production.

Why Key Vault, not Kubernetes Secrets?

What Key Vault stores

• Secrets — passwords, API keys, connection strings, tokens
• Keys — cryptographic keys for encryption/decryption operations
• Certificates — SSL/TLS certificates with automatic renewal

CSI Driver — How pods access Key Vault

The Secrets Store CSI Driver is a Kubernetes plugin that mounts secrets from external stores (Key Vault, AWS Secrets Manager, HashiCorp Vault) as volumes inside pods.

# Step 1: Enable CSI driver add-on on AKS
az aks enable-addons --addons azure-keyvault-secrets-provider \
  --name myaks --resource-group myrg

# Step 2: SecretProviderClass — tell CSI what to fetch
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: payment-secrets
  namespace: production
spec:
  provider: azure
  parameters:
    clientID: "<workload-identity-client-id>"
    keyvaultName: "kv-upward-prod"
    tenantID: "<tenant-id>"
    objects: |
      array:
        - |
          objectName: database-connection-string
          objectType: secret
        - |
          objectName: payment-api-key
          objectType: secret

# Step 3: Mount in Pod
spec:
  serviceAccountName: payment-service-sa  # workload identity SA
  volumes:
  - name: secrets-store
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: payment-secrets
  containers:
  - name: payment-api
    volumeMounts:
    - name: secrets-store
      mountPath: /mnt/secrets   # secrets appear as files here

Three types of identity — know all three

How Workload Identity works — step by step

# 1. Create User-Assigned Managed Identity
az identity create --name payment-svc-identity --resource-group myrg

# 2. Give it Key Vault permission
az keyvault set-policy --name kv-upward-prod \
  --object-id <identity-object-id> \
  --secret-permissions get list

# 3. Create K8s ServiceAccount linked to the identity
kubectl annotate serviceaccount payment-service-sa \
  azure.workload.identity/client-id=<identity-client-id>

# 4. Federate — "trust tokens from this AKS cluster for this ServiceAccount"
az identity federated-credential create \
  --name payment-federation \
  --identity-name payment-svc-identity \
  --issuer <aks-oidc-issuer> \
  --subject system:serviceaccount:production:payment-service-sa

Why Workload Identity replaced AAD Pod Identity

The old approach (AAD Pod Identity) let any pod claim any Azure identity using node-level labels. A misconfigured pod could claim a high-privilege identity. Workload Identity ties identity to a Kubernetes ServiceAccount — access controlled by K8s RBAC. Only the pods explicitly using that ServiceAccount can get that identity. Much more secure and auditable.

Three tools that solve different problems — use all three together

OpenTelemetry — why it matters

OpenTelemetry is the CNCF standard for application instrumentation. The three signals: Traces (end-to-end request journey across microservices), Metrics (numeric measurements over time), Logs (structured event records). You instrument the application once with the OTel SDK. You configure where to send the data. Today: Application Insights. Tomorrow: Datadog. The application code never changes.

# KQL query example — error rate per 5-minute window in Log Analytics
ContainerLog
| where LogEntry contains "ERROR"
| summarize ErrorCount = count() by bin(TimeGenerated, 5m)
| render timechart

# Application Insights — find slowest dependencies
dependencies
| where timestamp > ago(1h)
| summarize avg(duration) by name, type
| order by avg_duration desc
| take 10

Troubleshooting with Application Insights

Application Insights → Failures blade → drill into failed operation → see the full end-to-end transaction trace → identify which dependency (database, external API, another microservice) failed. Correlate timestamp with Prometheus pod restart metrics. If pods restarted: check kubectl describe pod for OOMKilled. This multi-tool correlation is what experienced engineers do.