Microsoft AZ-400: Containerisatie en Kubernetes — Studiegids

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

Onderdeel van de Microsoft DevOps Engineer Expert AZ-400 — Studiegids. Oefen met geverifieerde antwoorden in het Microsoft-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Containerisatie en Kubernetes vormen de basis van moderne DevOps op Azure door reproduceerbare builds, veilige distributie en declaratieve, zelfherstellende runtime-orkestratie te combineren. Om dit te beheersen, is het essentieel te begrijpen hoe images worden samengesteld en geoptimaliseerd, hoe registries content repliceren en attesteren, hoe AKS is ontworpen en zonder onderbreking wordt geüpgraded, hoe ‘progressive delivery’ wordt geïmplementeerd en hoe workloads end-to-end worden beveiligd. Naast ‘raw’ Kubernetes maak je gebruik van Helm voor packaging, GitOps voor reconciliation en – in de serverless-wereld – Azure Container Apps met Dapr en KEDA om microservices-patronen en event-driven schaling te vereenvoudigen. De volgende paragrafen behandelen de platformkeuzes en operationele praktijken die je nodig hebt om robuuste, compliant pipelines en veerkrachtige productieclusters te implementeren.

Basisprincipes van Build en Registry: Docker en ACR

Een performante container image begint met een deterministische Dockerfile en een gedisciplineerde build context. Multi-stage builds stellen je in staat om compilatiestadia met zware toolchains te scheiden van kleine runtime images. Compileer bijvoorbeeld een .NET- of Go-binary in een ‘builder stage’ en kopieer vervolgens alleen het gecompileerde artefact naar een ‘distroless’ of minimale base image (bijv. mcr.microsoft.com/dotnet/runtime-deps of gcr.io/distroless/base). Dit resulteert in een kleiner aanvalsoppervlak en snellere pull-tijden. Elke RUN, COPY en ADD creëert een layer; herstructureer Dockerfiles om de ’layer cache hits’ te maximaliseren door stappen die zelden veranderen later te plaatsen en commando’s logisch te groeperen met behoud van leesbaarheid. Voeg altijd een .dockerignore toe om bin/obj, node_modules, tests, documentatie en secrets uit te sluiten; een te grote build context vertraagt uploads en vermindert de effectiviteit van de remote cache. Gebruik deterministische package-installaties (version pins, lock files) en ga zorgvuldig om met build-argumenten; omgevingsspecifieke bestanden moeten via runtime-configuratie worden aangeleverd, niet via onveranderlijke images.

Azure Container Registry (ACR) is de ruggengraat voor de opslag en distributie van images. Maak gebruik van ACR Tasks om builds naar Azure te offloaden: ‘quick tasks’ voor on-demand builds (az acr run), geautomatiseerde taken die worden getriggerd door Git-commits, base-image-updates of schedules, en multi-step Task YAML voor multi-arch images met behulp van Buildx. Geo-replicatie (Premium SKU) spiegelt artefacten over regio’s, wat de pull-latency en egress-kosten voor multi-region AKS/ACA-implementaties minimaliseert; combineer dit met private endpoints en repository-scoped RBAC voor ’least privilege’. Schakel ‘content trust’ in om images te signeren en de herkomst te verifiëren: Docker Content Trust/Notary en evoluerende OCI-signature-ecosystemen (bijv. cosign) kunnen worden afgedwongen bij ‘admission’ via OPA Gatekeeper-constraints die signatures vereisen voor beschermde namespaces. Integreer vulnerability scanning: Microsoft Defender for Cloud scant images bij het pushen en ‘at rest’, signaleert CVE’s met advies voor oplossingen, en kan implementaties blokkeren via Azure Policy en CI-checks; voeg automatisering toe voor het vernieuwen van base images om lagen met bekende kwetsbaarheden te verminderen.

AKS Platform en Workload Delivery

Creëer AKS-clusters met standaard veilige instellingen: managed identity, Azure AD-integratie voor RBAC, Azure CNI voor VNET-integratie, network policy (Azure of Calico), Azure Key Vault provider (Secrets Store CSI) voor het gebruik van secrets, en private clusters met geautoriseerde IP-ranges. Kies node pools die geschikt zijn voor de workload: system pools voor componenten die kritiek zijn voor het control plane; user pools voor applicaties; GPU pools voor ML; spot pools voor kostenefficiënte stateless jobs; Windows node pools voor Windows containers. Gebruik taints/tolerations en topology spread constraints om scheduling en veerkracht te beheren. Schaal automatisch met de cluster autoscaler en per-deployment Horizontal Pod Autoscaler; overweeg ephemeral OS disks en availability zones voor betere prestaties en veerkracht.

Plan upgrades om verstoring te minimaliseren. AKS upgradet eerst het control plane, daarna de node pools. Gebruik max-surge bij node pool upgrades om extra capaciteit toe te voegen (surge capacity), nodes zorgvuldig leeg te halen (drain), en PodDisruptionBudgets te respecteren. Gebruik automatische upgradekanalen (rapid/stable/patch-only) voor een voorspelbare cadans; scheid upgrades van system en user pools om de ‘blast radius’ te beperken. Voer regelmatig node image upgrades uit om kernel/runtime-fixes mee te nemen, zelfs zonder een Kubernetes-versieverhoging, en pin compatibele CNI/CSI-versies. Gebruik blue-green node pools voor zero-downtime platformwijzigingen—cordon/drain de ‘green’ pool naar de ‘blue’ pool en schakel over via nodeSelector/affinity.

Deployments in Kubernetes ondersteunen standaard rolling updates met maxUnavailable en maxSurge om de capaciteit tijdens een rollout te behouden; combineer dit met readiness/liveness probes en startup probes om voortijdig verkeer te voorkomen. Blue-green delivery op Kubernetes wordt geïmplementeerd door parallelle Deployments (blue en green) te draaien en een stabiele Service selector of Endpoint-object naar de doelrevisie te schakelen; dit maakt een bijna onmiddellijke fallback mogelijk door labels om te draaien. Canary delivery kan het beste aan de ’edge’ worden uitgevoerd via ingress: NGINX Ingress ondersteunt ‘weighted canary’ via annotaties; Application Gateway Ingress Controller (AGIC) kan verkeer splitsen over backends; service meshes bieden ’traffic shifting’ met granulaire policies en telemetrie. Voor robuuste pipelines, valideer met smoke tests en App Insights availability checks voordat de wegingen worden gepromoveerd.

Helm verpakt Kubernetes-manifesten in charts, die bestaan uit Chart.yaml, templates en een standaard values.yaml. Values-bestanden worden deterministisch over elkaar heen gelegd; gebruik values.<env>.yaml overlays en een “global”-blok voor instellingen die over subcharts heen gelden. Geef de voorkeur aan Helm 3 met OCI-gebaseerde chart-opslag in ACR (helm registry login && helm push oci://…), wat RBAC en geo-replicatiepariteit met images mogelijk maakt. Installeer in Azure Pipelines een vastgepinde versie van Helm (HelmInstaller) en deploy (HelmDeploy) via een Kubernetes/Azure Resource Manager service connection; template linting plus dry-run en diff (helm diff plugin) zouden releases moeten ‘gaten’. Vermijd het committen van secrets in values-bestanden; integreer external-secrets of CSI Key Vault om secrets tijdens runtime te materialiseren. Versioneeer charts semantisch en pin appVersion aan de image digest voor traceerbaarheid.

Operations, Beveiliging en Traffic Control

GitOps met Flux of Argo CD zorgt ervoor dat clusters continu convergeren naar een gedeclareerde staat. Flux v2 integreert standaard met AKS via de Azure CLI/extension, en synchroniseert (reconciling) Sources (Git/OCI/Bucket) en Kustomizations met een vast interval. Het bevat ook image automation om Helm/Kustomize te updaten naar nieuwe tags op basis van policies. Argo CD volgt Applications en hun status (health), ondersteunt SSO met Azure AD, en kan werken in pull-gebaseerde, app-of-apps modellen voor multi-tenant scheiding. Beide detecteren ‘drift’ en kunnen dit automatisch corrigeren, events/alerts uitzenden en ondersteunen progressive delivery; combineer met Flagger om canaries en A/B-tests te automatiseren met NGINX, Istio of Linkerd, waarbij promotie plaatsvindt op basis van metrics en rollback bij het schenden van SLO’s.

Beveiliging begint in de supply chain en wordt afgedwongen bij ‘admission’ en ‘runtime’. Scan images continu met Defender for Cloud en implementeer ‘gates’ in CI/CD. Adopteer Kubernetes Pod Security Standards (baseline/restricted) met Pod Security Admission-labels op namespaces om standaard privileged/hostPath/unsafe sysctls te blokkeren. Dwing organisatiebeleid af met OPA Gatekeeper: constraint templates verbieden ‘privileged containers’, vereisen goedgekeurde registries, dwingen resource limits af en eisen ondertekende images of de aanwezigheid van een SBOM. Pas network policies toe om toegestaan pod-to-pod en egress-verkeer te definiëren; AKS ondersteunt Azure Network Policies (met Azure CNI) en Calico. Vul dit aan met Azure Firewall of NVA egress control en Application Gateway WAF voor ingress. Hard workloads door non-root gebruikers, read-only root filesystems, seccomp- en AppArmor-profielen en regelmatige node image upgrades. Schakel audit en threat detection in via Defender for Kubernetes en aggregeer telemetrie in Azure Monitor Container Insights; standaardiseer logs/traces met OpenTelemetry.

Een service mesh (Istio of Linkerd) voegt uniform traffic management, encryptie en observability toe. Gebruik DestinationRules/VirtualServices (Istio) of ServiceProfiles (Linkerd) om retries, timeouts, circuit breaking en ‘weighted routing’ te definiëren. Schakel mutual TLS in voor service-to-service encryptie en identiteit; dwing policies zoals “STRICT” mTLS af om gaten te dichten. Exporteer metrics naar Prometheus en dashboards naar Grafana; vang distributed traces (Jaeger/Zipkin) op en voed ze aan Application Insights of Azure Monitor via OpenTelemetry collectors. Mesh-gebaseerde canaries en fault injection maken betrouwbaar testen en progressive delivery mogelijk, waarbij Flagger de analyse tegen SLO’s automatiseert.

Ontwikkelaarsproductiviteit en Serverless Containers op Azure

Integratietools voor AKS DevOps stroomlijnen de ‘inner loops’ van ontwikkelaars. Draft detecteert taalframeworks en genereert een basisstructuur (scaffolding) voor Dockerfiles, Helm-charts en launch-configuraties, wat de containerisatie versnelt. Bridge to Kubernetes leidt service-aanroepen van een live cluster om naar uw lokale werkstation, waardoor u lokaal kunt itereren en debuggen op één enkele microservice terwijl de rest in het cluster draait met echte data en afhankelijkheden. Azure Dev Spaces is buiten gebruik gesteld; Bridge to Kubernetes is de ondersteunde ervaring voor lokale ontwikkeling en integreert met VS Code en Visual Studio.

Azure Container Apps (ACA) biedt een serverless, volledig beheerde runtime voor microservices en jobs zonder dat u Kubernetes hoeft te beheren. Elke deployment creëert een revisie; u kunt het verkeer procentueel over revisies verdelen voor blue-green of canary-stijl rollouts met één commando of YAML-wijziging. De natuurlijke Dapr-integratie maakt service-aanroepen, pub/sub, bindings, state stores en secrets mogelijk zonder specifieke koppelcode; inplugbare componenten (bijv. Azure Service Bus, Key Vault, Cosmos DB) versnellen de implementatie van consistente, service-overstijgende functionaliteiten. KEDA zorgt voor event-driven autoscaling op basis van HTTP-concurrency en meer dan 60 ‘scalers’ (Azure Queue/Service Bus, Kafka, Prometheus, custom), waarbij naar nul wordt geschaald voor kostenefficiëntie. Gebruik ACA Environments voor netwerkisolatie en VNET-integratie, koppel ACR via een managed identity en beheer de configuratie via containerapps.yaml om declaratieve pariteit met GitOps-werkwijzen te behouden.

Praktisch Probleemscenario

Adobe moet een multi-region klantanalysedienst moderniseren, waarbij het risico van releases wordt verminderd en tegelijkertijd de beveiliging van de supply chain en de runtime wordt aangescherpt. Het team moet builds standaardiseren, veilige rollouts automatiseren en zorgen voor snelle, conforme levering in de VS en de EU.

Implementeer multi-stage Dockerfiles en .dockerignore voor alle services

Waarom: Minimaliseert de grootte van de image en het aanvalsoppervlak, verbetert de build cache hits en voorkomt dat secrets of grote test-assets per ongeluk in de image terechtkomen.

Bouw en onderteken images met ACR Tasks, push naar een geo-gerepliceerde ACR

Waarom: Cloud builds elimineren lokale verschillen; triggers op updates van de base-image verminderen de blootstelling aan CVE’s. Geo-replicatie van Premium ACR plaatst artefacten dicht bij AKS-clusters, wat de latentie en egress vermindert. Ondertekeningen maken herkomstverificatie mogelijk.

Schakel Defender for Cloud image scanning in en dwing dit af via CI-gates en OPA Gatekeeper

Waarom: Scans bij ‘push’ en ‘at rest’ detecteren CVE’s vroegtijdig. Gatekeeper-constraints dwingen beleid af zoals ‘alleen goedgekeurde registries’, ‘ondertekende images vereist’ en resourcelimieten, en voorkomen zo dat onveilige workloads worden toegelaten.

Provisioneer private AKS-clusters per regio met Azure CNI, network policies en managed identity

Waarom: Private endpoints beperken de blootstelling van de control plane; Azure CNI integreert met VNET’s van de onderneming; network policies beperken laterale bewegingen; managed identity elimineert de wildgroei van secrets.

Creëer aparte system en user node pools, voeg spot pools toe voor batch-jobs

Waarom: Isoleert kritieke platform-pods, biedt kostenefficiënte capaciteit voor niet-kritieke workloads en vereenvoudigt upgrades en het beheer van SLO’s.

Adopteer Helm voor packaging met charts opgeslagen in ACR (OCI), deploy via Azure Pipelines

Waarom: Consistente, geversioneerde releases met ‘values’ per omgeving. Pipelines voeren helm lint, dry-run en diff uit vóór helm upgrade, en gebruiken een Kubernetes service connection om de clusters te targeten.

Implementeer Flux v2 voor GitOps-reconciliatie en drift-detectie, integreer Flagger voor canaries

Waarom: Declaratieve, pull-gebaseerde synchronisatie vermindert de noodzaak voor credentials in CI en zorgt voor convergentie. Flagger automatiseert gewogen canaries op basis van SLO’s met behulp van NGINX Ingress-metrics, en rolt terug bij fouten of pieken in de latentie.

Configureer rolling updates met PDB’s en readiness/startup probes; gebruik blue-green voor risicovolle componenten

Waarom: Rolling updates behouden de capaciteit; probes beschermen het gebruikersverkeer. Blue-green met een label-switch op de Service maakt een onmiddellijke rollback mogelijk voor componenten met een hoog risico, zoals de API-gateway.

Introduceer een Istio service mesh met strikte mTLS, retries en timeouts; exporteer telemetrie naar Application Insights

Waarom: Encryptie over de hele mesh, robuuste traffic policies en uniforme observability. OpenTelemetry collectors versturen traces/metrics naar een centrale store voor SLO-monitoring en het triagen van incidenten.

Zet een gecontroleerde upgrade-strategie op met het AKS auto-upgrade channel en node image upgrades

Waarom: Regelmatige, voorspelbare platformupdates verminderen de blootstelling aan zero-days. Max-surge en PDB’s zorgen voor minimale verstoring; het apart upgraden van user node pools beperkt de ‘blast radius’.

Gebruik Bridge to Kubernetes voor inner-loop development; gebruik Draft voor scaffolding

Waarom: Ontwikkelaars debuggen lokaal tegen afhankelijkheden in het cluster zonder te hoeven mocken. Draft versnelt consistente containerisatie en Helm-scaffolding binnen de teams.

Plaats ’long-tail’ services op Azure Container Apps met Dapr en KEDA

Waarom: Event-driven microservices die naar nul schalen (bijv. voor ingestie en verrijking) draaien goedkoop met ingebouwde traffic splitting voor canaries; Dapr-componenten standaardiseren service-naar-service aanroepen en pub/sub zonder op maat gemaakte code.

Dit end-to-end ontwerp combineert de voorspelbaarheid van builds met veilige distributie, declaratieve operaties en ‘progressive delivery’, waardoor Adobe snelle releases met een laag risico en een geharde runtime in alle regio’s krijgt.

← Infrastructuur als Code en Configuratiebeheer · Alle domeinen · Releasebeheer en Deploymentstrategieën →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →