DevOps-certificeringer er et valg af retning for ingeniører, der arbejder i et dansk platformteam med de første services i cloud, kerneapplikationer on-premises og et udviklerønske om hurtigere releases og mere stabile pipelines. Valget mellem Azure, AWS, Kubernetes, SRE og generelle DevOps-certificeringer bør derfor styres af ingeniørernes daglige ansvar snarere end af certificeringens navn.
En DevOps-certificering dokumenterer, at en ingeniør kan arbejde struktureret med automatisering, CI/CD, drift, sikkerhed, monitorering og samarbejde mellem udvikling og operations. Den har størst værdi, når den kobles til konkrete opgaver: at forbedre release-flow, reducere manuelle driftsopgaver, gøre infrastruktur reproducerbar og skabe fælles målinger for kvalitet og stabilitet.
Hvorfor DevOps-certificeringer betyder noget i nordiske ingeniørteams
I Danmark og resten af Norden bliver DevOps sjældent behandlet som et isoleret værktøjsområde. Mange organisationer arbejder med små, tværfunktionelle teams, stramme compliancekrav og en blanding af cloud, SaaS og ældre systemer. Derfor efterspørges ingeniører, der både kan forstå pipelines, platforme og sikkerhedskrav og samtidig samarbejde med udviklere, drift, arkitektur og risikofunktioner.
Certificeringer kan hjælpe med at gøre den kompetence synlig. En kandidat med praktisk erfaring og en relevant certificering kan lettere forklare, hvordan vedkommende arbejder med deployment-strategier, infrastructure as code, secrets management, observability og incident response. Det er især nyttigt i mindre teams, hvor rollen ofte er en kombination af cloud engineer, platform engineer, SRE og teknisk generalist.
Det betyder dog ikke, at certificeringen i sig selv er målet. De stærkeste kandidater bruger certificeringsforløbet til at bygge en arbejdsmåde, der kan genbruges: versioneret infrastruktur, automatiserede tests, dokumenterede pipelines, overvågning med klare signaler og en sikkerhedsmodel, der er tænkt ind fra begyndelsen. En certificering uden hands-on øvelse giver sjældent den samme værdi i praksis.
Start med stack og rolle, ikke med certifikatnavnet
Det mest almindelige fejlvalg er at vælge den certificering, der lyder mest ambitiøs, i stedet for den der matcher arbejdet. En Azure-baseret organisation med GitHub eller Azure DevOps har andre behov end et AWS-team med tung brug af CloudFormation, CodePipeline og containeriserede workloads. Et SRE-team på Google Cloud vil typisk prioritere reliability, service health og målebaseret drift, mens et platformteam omkring Kubernetes skal kunne håndtere cluster-drift, networking, RBAC og deployment-mønstre.
- Azure, GitHub eller Azure DevOps som primær platform: vælg typisk Microsoft Certified: DevOps Engineer Expert (AZ-400), især hvis rollen handler om pipelines, source control, release-strategier og Azure-integration.
- AWS-tung infrastruktur: overvej AWS Certified DevOps Engineer – Professional, hvis arbejdet allerede omfatter automatisering, deployment, monitoring og drift i AWS.
- GCP- eller SRE-fokus: Google Professional Cloud DevOps Engineer passer bedst, når service reliability, incident management, performance og release-sikkerhed fylder mest.
- Kubernetes- og platformfokus: Certified Kubernetes Administrator er et bedre førstevalg, når teamets største udfordringer ligger i cluster-administration, containerdrift, networking og adgangsstyring.
- Ny i DevOps eller i en ikke-cloudspecifik rolle: en grundlæggende certificering som DASA DevOps Fundamentals kan give et fælles sprog, før der vælges en cloud- eller platformsspecialisering.
Rammen er enkel, men den forhindrer et dyrt sidespor: certificeringen bør afspejle de systemer, teamet faktisk driver, og de beslutninger ingeniøren forventes at træffe. I et mindre dansk team kan en stærk generalist med én dyb certificering ofte være mere relevant end en profil med mange brede certifikater uden praktisk sammenhæng.
Hvad de mest relevante DevOps-certificeringer tester
Microsofts AZ-400 er rettet mod ingeniører, der arbejder med end-to-end DevOps-praksis i Microsoft-økosystemet. Kandidaten forventes at forstå source control, build- og release-pipelines, sikkerhed i udviklingsprocessen, afhængighedsstyring, compliance, monitorering og løbende forbedring. Microsoft Learn beskriver eksamenskrav, forudsætninger, sprog og tilgængelige eksamensformer, og de bør altid kontrolleres på den officielle eksamensside før tilmelding.
AZ-400 er særlig relevant i organisationer, hvor Azure, GitHub, Azure DevOps, Entra ID og Microsoft-sikkerhedsmodeller allerede er en del af hverdagen. En praktisk gennemgang af AZ-400 i virkelige DevOps-scenarier kan hjælpe kandidater med at se, hvordan pensum omsættes til pipeline-design, governance og drift frem for kun eksamensforberedelse.
AWS Certified DevOps Engineer – Professional er mere relevant, når miljøet allerede er dybt forankret i AWS. Den kræver typisk en solid forståelse af automatisering, infrastruktur som kode, logging, monitoring, incident response og deployment på tværs af AWS-tjenester. AWS offentliggør selv eksamensguide, sample questions og oplysninger om online proctoring og testcentre, og de officielle oplysninger bør bruges som sandhedskilde, fordi eksamensindhold og politikker kan ændre sig.
Google Professional Cloud DevOps Engineer har et tydeligt SRE-præg. Den passer til ingeniører, der arbejder med service reliability, målinger, release-hastighed, fejltolerance og drift af cloud-native services. Den er mindre oplagt som første certificering for en Azure- eller AWS-ingeniør, men kan være stærk for teams, der allerede bruger Google Cloud og organiserer drift omkring SLO’er, incidents og løbende forbedring.
CKA adskiller sig fra cloudleverandørernes DevOps-certificeringer, fordi den går dybt i Kubernetes-administration. Den tester praktiske færdigheder i at konfigurere, fejlfinde og drive clusters. For platform engineers og SRE’er i nordiske miljøer med hybrid infrastruktur, GitOps og interne developer platforms kan CKA være mere direkte anvendelig end en bred cloud-DevOps-certificering. Docker-certificeringer og containerkurser kan stadig være nyttige, men Kubernetes-kompetence fylder ofte mere i teams, der driver moderne platforme.
Certificeringens værdi opstår først i implementeringen
Den største praktiske gevinst kommer, når certificeringsstoffet bliver brugt til at ændre måden software leveres på. Et team kan have Jenkins, GitHub Actions, Azure Pipelines, Terraform, Kubernetes og container-registry på plads uden at have et velfungerende DevOps-flow. Hvis releases stadig kræver manuelle godkendelser uden klar risikologik, hvis rollback ikke er testet, eller hvis drift først involveres efter deployment, er værktøjerne kun en delvis løsning.
En almindelig faldgrube er at memorere værktøjsfunktioner i stedet for at forstå flowet fra commit til produktion. DORA-målinger som deployment frequency, lead time, change failure rate og time to restore er nyttige, fordi de flytter samtalen fra “hvilket værktøj bruger teamet?” til “hvor hurtigt og sikkert kan teamet levere ændringer?”. Certificeringer dækker ofte dele af denne tankegang, men den skal trænes i et sammenhængende labmiljø for at blive operationel.
Sikkerhed er en anden kilde til fejl. DevSecOps handler ikke om at tilføje et scan sidst i pipelinen, men om at indbygge adgangsstyring, secrets management, policy as code, dependency scanning og sporbarhed i hele leverancekæden. I regulerede nordiske miljøer med krav til dokumentation, databeskyttelse og leverandørstyring er dette ofte forskellen mellem en pipeline, der virker teknisk, og en pipeline, der kan godkendes i produktion.
Legacy gør billedet mere komplekst. Mange teams arbejder med systemer, der ikke let kan containeriseres eller deployes flere gange om dagen. Her bør certificeringsarbejdet bruges pragmatisk: automatiser build og test først, gør konfiguration reproducerbar, indfør logging og alarmer, og etabler en sikker release-proces. Platform engineering og interne developer platforms kan derefter give udviklere selvbetjening uden at fjerne de kontroller, som drift og compliance kræver.
En studieplan der skaber arbejdsfærdigheder
En effektiv forberedelse begynder med den officielle eksamensside. Kandidaten bør kontrollere målte færdigheder, forudsætninger, sprog, eksamensformat, ID-krav og muligheder for online proctoring eller testcenter. I Danmark vælger mange online eksamen af praktiske grunde, men et testcenter kan være bedre for kandidater, der vil undgå tekniske problemer med kamera, netværk, arbejdsstation eller lokale proctoringkrav.
Vælg ét primært certifikat ud fra den stack og rolle, der fylder mest i arbejdet.
Læs den officielle eksamensguide og marker de emner, der ikke bruges i hverdagen.
Byg et lille lab med repository, pipeline, container, IaC, miljøvariabler og monitorering.
Tilføj en sikkerhedskontrol som secret scanning, dependency scanning eller policy as code.
Øv en fejl: bryd en deployment, find signalet i logs eller metrics, og dokumentér recovery.
Afslut med prøveopgaver og en gennemgang af eksamenslogistikken flere dage før booking.
Labbet bør være lille nok til at kunne genbygges og stort nok til at vise sammenhængen. Et godt eksempel er en containeriseret webservice med en pipeline, der bygger image, kører tests, scanner afhængigheder, deployer til et testmiljø og eksponerer logs eller metrics. For Kubernetes-kandidater bør labbet også omfatte RBAC, services, ingress eller networking, resource limits og fejlfinding af pods, fordi små detaljer ofte afgør, om kandidaten kan løse opgaven under tidspres.
Teorilæsning alene er sjældent nok. Kandidater, der ikke har bygget en end-to-end pipeline, mangler ofte fornemmelsen for afhængighederne mellem source control, build-agenter, artifacts, miljøer, adgangsstyring og observability. En instruktørstyret tilgang kan være nyttig, når den bruges til at validere labarbejde, afklare eksamensmål og forbinde platformsspecifikke funktioner med generelle DevOps-principper; Readynez kan eksempelvis være relevant for ingeniører, der ønsker struktureret forberedelse til AZ-400 uden at adskille eksamensstoffet fra praktiske scenarier.
Sådan læser arbejdsgivere certificeringer
En certificering fungerer sjældent som selvstændigt bevis på senioritet. Rekrutterende teams ser typisk efter sammenhængen mellem certificering, projekter og konkrete resultater. En kandidat, der kan forklare, hvordan en pipeline blev gjort mere stabil, hvordan deployment-risiko blev reduceret, eller hvordan et team fik bedre observability, står stærkere end en kandidat, der kun kan nævne værktøjer.
I danske jobopslag ses ofte efterspørgsel efter Azure, GitHub, Kubernetes, Terraform, CI/CD og sikkerhedsforståelse i samme rolle. Det afspejler virkeligheden i mange nordiske organisationer: teams er små, platformene er blandede, og ansvar går på tværs af udvikling, drift og cloud. Derfor bør CV og samtale ikke kun fremhæve certificeringsnavnet, men også vise et projekt, et lab eller en konkret forbedring.
Det er også værd at skelne mellem certificeringer, der styrker en DevOps-profil, og certificeringer der tilhører et andet spor. En Microsoft-specialist, der overvejer flere retninger, kan med fordel sammenligne DevOps med andre Microsoft-roller, herunder Azure AI Engineer-certificeringen, men valget bør afgøres af den type systemer og beslutninger, rollen faktisk handler om.
Det rigtige næste skridt
Den bedste DevOps-certificering for en ingeniør er den, der matcher den platform, de services og det ansvar, som fylder mest i arbejdet. Azure- og GitHub-tunge teams bør se nærmere på AZ-400, AWS-teams på AWS DevOps Engineer – Professional, GCP/SRE-profiler på Google Professional Cloud DevOps Engineer og platformteams på CKA. Et bredere fundament kan være rigtigt først, hvis kandidaten stadig mangler fælles begreber for flow, kultur og automatisering.
En praktisk vej frem er at vælge ét certifikat, bygge et lab omkring en virkelig leverancekæde og bruge eksamensmålene som struktur for læringen. Ingeniører, der arbejder i Microsoft-miljøer og ønsker et samlet træningsformat, kan undersøge Readynez Microsoft Unlimited som en mulig ramme for AZ-400 og relateret Microsoft-læring.
