DevOps-interviews testen of je software betrouwbaar kunt uitrollen: hoe code van een laptop naar productie gaat, hoe je weet dat het gezond is, en wat je doet als dat niet zo is. Hieronder staan 20 vragen met antwoorden, van de basis tot de scenariovragen die de meeste interviews bepalen. Waar een commando wordt getoond, is het een standaardcommando dat je kunt controleren in de documentatie van de tool zelf.
Grondbeginselen
1. Wat is DevOps?
Een manier van werken die ontwikkeling en operations samenbrengt, zodat software wordt gebouwd, getest, uitgebracht en gedraaid via hetzelfde gedeelde proces. De doelen zijn snellere, veiligere releases en sneller herstel wanneer er iets misgaat. Het is een cultuur en een set praktijken, met tools als ondersteuning, niet alleen een functietitel.
2. Wat is het verschil tussen continuous integration, continuous delivery en continuous deployment?
| Praktijk | Wat het betekent |
|---|---|
| Continuous integration | Ontwikkelaars voegen vaak kleine wijzigingen samen, en elke samenvoeging start een geautomatiseerde build en testrun |
| Continuous delivery | Elke wijziging die de pipeline doorstaat is klaar voor release, en een persoon beslist wanneer |
| Continuous deployment | Elke wijziging die de pipeline doorstaat wordt automatisch naar productie uitgebracht |
3. Wat zijn de belangrijkste metrieken voor softwarelevering?
Vier worden veel gebruikt, uit het DORA-onderzoeksprogramma: deploymentfrequentie, doorlooptijd voor wijzigingen, faalpercentage van wijzigingen en tijd om de service te herstellen. De eerste twee meten snelheid, en de laatste twee meten stabiliteit. Een goed antwoord legt uit dat je alle vier volgt, zodat je snelheid niet verbetert ten koste van stabiliteit.
4. Hoe ziet een goede CI-pipeline eruit?
- Haal de code op en herstel gecachte dependencies.
- Bouw.
- Draai eerst snelle tests (unit tests), daarna langzamere.
- Draai statische controles, zoals linting en een kwetsbaarheidsscan van dependencies.
- Bouw één keer een artifact (een containerimage of package) en tag het met de commit.
- Publiceer het, en deploy hetzelfde artifact door elke omgeving.
Het kernidee is om één keer te bouwen en hetzelfde artifact te promoveren, zodat wat je hebt getest ook is wat je uitbrengt.
Versiebeheer en releases
5. Hoe branch je en breng je releases uit?
Twee veelvoorkomende benaderingen. Trunk-based development voegt vaak kleine wijzigingen samen naar de main branch, met feature flags om onaf werk te verbergen. Branch-gebaseerde workflows zoals GitFlow gebruiken langlevende branches voor releases. Trunk-based development past meestal beter bij continuous delivery, omdat samenvoegingen klein en frequent zijn.
6. Wat zijn blue-green en canary deployments?
| Strategie | Hoe het werkt | Rollback |
|---|---|---|
| Blue-green | Twee identieke omgevingen. Deploy naar de inactieve, test die, en schakel dan het verkeer om | Schakel het verkeer terug |
| Canary | Stuur een klein deel van het verkeer naar de nieuwe versie, kijk naar de metrieken en verhoog geleidelijk | Zet het aandeel terug naar nul |
| Rolling | Vervang instances een paar tegelijk | Rol vooruit of draai de roll terug |
Blue-green kost extra capaciteit. Canary heeft goede metrieken nodig, omdat je op basis van de data beslist.
7. Wat is een feature flag, en waarom zou je er een gebruiken?
Een schakelaar in de configuratie die een feature aan- of uitzet zonder een deployment. Het scheidt het deployen van code van het uitbrengen van een feature, laat je testen met een kleine groep, en geeft je een snelle uit-schakelaar als er iets misgaat. De keerzijde is dat oude flags zich opstapelen, dus verwijder ze zodra een feature stabiel is.
8. Hoe rol je veilig terug?
Houd het vorige artifact beschikbaar, maak deploys herhaalbaar, en maak databasewijzigingen achterwaarts compatibel, zodat de oude versie nog steeds werkt met het nieuwe schema. Een rollbackplan dat de database negeert is geen plan. Geef bij risicovolle wijzigingen de voorkeur aan vooruit rollen met een fix wanneer een rollback gegevens zou verliezen.
Infrastructuur en containers
9. Wat is infrastructuur als code?
Servers, netwerken en machtigingen definiëren in versiebeheerde bestanden in plaats van te klikken in een console. Het maakt omgevingen reproduceerbaar, reviewbaar en eenvoudig opnieuw op te bouwen. Veelgebruikte tools zijn Terraform, Pulumi en de eigen templates van cloudproviders. Zie onze Terraform interviewvragen.
10. Wat is het verschil tussen een container en een virtuele machine?
Een virtuele machine bevat een volledig gastbesturingssysteem bovenop gevirtualiseerde hardware. Een container deelt de kernel van de host en verpakt alleen de applicatie en zijn afhankelijkheden, waardoor hij sneller opstart en minder geheugen gebruikt. Containers bieden minder isolatie dan een virtuele machine.
11. Wat hoort er in een goede Dockerfile?
Gebruik een kleine, specifieke basisimage, orden de layers zodat degenen die het minst veranderen vooraan staan (om de build-cache te benutten), kopieer dependency-bestanden en installeer ze voordat je de broncode kopieert, draai als een non-root user, en bak geen secrets in de image. Multi-stage builds houden buildtools buiten de uiteindelijke image.
12. Waarom Kubernetes?
Het plant containers over machines, herstart mislukte containers, schaalt ze, en regelt rolling updates en service discovery. Het voegt ook veel complexiteit toe, dus een goed antwoord zegt wanneer je het niet zou gebruiken, zoals bij een kleine app die op een paar servers past of een managed platform. Zie onze Kubernetes interviewvragen.
13. Hoe beheer je secrets?
Zet ze nooit in versiebeheer of images. Gebruik een secrets manager of de secret store van het platform, geef elke service de minimale toegang die nodig is, roteer secrets, en voorkom dat ze in logs terechtkomen. Vertel wat je zou doen als er een uitlekt: intrekken, roteren, en de logs controleren op gebruik.
Betrouwbaarheid en operations
14. Wat zijn monitoring, logging en tracing?
| Signaal | Vertelt je |
|---|---|
| Metrics | Hoe het systeem presteert over tijd, zoals error rate en latency |
| Logs | Wat er gebeurde bij een specifieke gebeurtenis |
| Traces | Hoe één request door meerdere services bewoog |
Alert op symptomen die gebruikers voelen, zoals errors en trage responses, meer dan op oorzaken, zoals hoge CPU op één machine.
15. Wat zijn SLI's, SLO's en SLA's?
Een service level indicator is een meting, zoals het aandeel requests dat slaagt. Een service level objective is het doel daarvoor, zoals 99,9 procent over 30 dagen. Een service level agreement is een belofte aan klanten, vaak met consequenties als die niet wordt nagekomen. De kloof tussen 100 procent en de SLO is een error budget: de ruimte die je hebt voor risico en verandering.
16. Een productieservice is traag. Wat doe je?
- Controleer of het echt is en wie er last van heeft, met behulp van dashboards en error rates.
- Controleer wat er recent is veranderd: een deployment, een configuratiewijziging, een verkeerspiek.
- Vernauw het: een specifiek endpoint, regio of dependency.
- Kijk naar resources (CPU, geheugen, connecties) en naar downstream services.
- Als een recente wijziging de waarschijnlijke oorzaak is, rol die dan eerst terug en onderzoek het daarna.
- Communiceer de status terwijl je werkt.
Interviewers luisteren naar een rustige, gestructureerde aanpak en naar het beperken van de impact voordat je de root cause vindt.
17. Wat is een blameless postmortem?
Een geschreven evaluatie na een incident die zich richt op hoe het systeem en het proces de fout mogelijk maakten, niet op wie een fout maakte. Het behandelt de tijdlijn, de impact, de oorzaken en concrete vervolgacties met eigenaren. Het doel is leren en dezelfde fout moeilijker te herhalen maken.
18. Wat is het verschil tussen horizontaal en verticaal schalen?
Verticaal schalen geeft een machine meer resources. Horizontaal schalen voegt meer machines toe. Verticaal is simpel maar heeft een plafond en een single point of failure. Horizontaal schaalt verder en overleeft het verlies van één machine, maar vereist stateless services of gedeelde state.
Praktisch
19. Hoe beveilig je een pipeline?
Beperk wie de pipeline kan wijzigen en wie naar productie kan deployen. Scan dependencies en images op bekende kwetsbaarheden, signeer en verifieer artifacts, houd credentials kortlevend en met beperkte scope, en review wijzigingen in pipeline-bestanden zoals code. Een build-agent met brede rechten is een geliefd doelwit.
20. Vertel me over een deployment die misging.
Dit is een gedragsvraag binnen een technisch interview. Gebruik een kort verhaal: wat er veranderde, hoe je het opmerkte, wat je als eerste deed (meestal mitigeren, vaak door terug te rollen), wat je ontdekte, en wat je daarna veranderde zodat het niet kan herhalen. Blameless formuleren en een concrete follow-up zijn waar interviewers naar zoeken.
Hoe je je voorbereidt
- Bouw een kleine pipeline van begin tot eind: een repository, een build, een testrun, een container en een deployment naar iets dat je kunt bereiken.
- Zorg dat je één incident of mislukte release uit je eigen ervaring kunt uitleggen.
- Oefen het antwoord op "de service is traag" hardop tot het een rustig, geordend lijstje is.
- Ken één tool goed per gebied, zoals CI, containers, infrastructure as code en monitoring, in plaats van een lange lijst met namen.
Voor gerelateerde oefening kun je onze gidsen bekijken over AWS-interviewvragen, Terraform-interviewvragen, Kubernetes-interviewvragen en interviewvragen over computernetwerken.
Oefen hardop en in je eigen woorden. Een transcript achteraf laat zien waar je afdwaalde of het punt miste. Volg de regels van de werkgever over AI-tools in elk live interview of assessment.
Oefen je antwoorden met YesToTheOffer
Oefen hardop, krijg antwoorden op basis van je eigen cv en bekijk achteraf je transcript. 30 gratis minuten, geen abonnement.
