Google PCA: DevOps, Delivery Engineering en Infrastructure as Code — Studiegids

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Onderdeel van de Google Professional Cloud Architect — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

DevOps, Delivery Engineering en Infrastructure as Code (IaC) op Google Cloud richten zich op het continu leveren van betrouwbare wijzigingen met sterke traceerbaarheid, automatisering en veiligheid. Architecturen moeten geoptimaliseerd zijn voor korte feedbackcycli, herhaalbare deployments, immutable infrastructuur en vangrails die meeschalen met de organisatie. Op Google Cloud combineert dit doorgaans best practices voor source control; CI met Cloud Build; artifact management met Artifact Registry; CD met Cloud Deploy; Kubernetes met GKE via manifests, Helm of Kustomize; GitOps voor het beheersen van configuratie-drift; en IaC met Terraform of Google Cloud deployment templates. Operational excellence vereist progressive delivery (blue-green, canary, traffic splitting en feature flags), controles voor de software supply chain (scannen, herkomst, ondertekening), test- en deployment-gates, en governance die een balans vindt tussen snelheid, veiligheid, auditeerbaarheid en eigenaarschap.

CI/CD, source control en release-orkestratie

• CI/CD-principes

  • Houd master/main release-klaar; pas trunk-based development toe met kortlevende feature branches.
  • Automatiseer build, test, scan en package bij elke wijziging; vereis code review met verplichte goedkeuringen en statuscontroles.
  • Behoud volledige traceerbaarheid van commit → build → artifact digest → release naar omgeving; sluit commit-SHA’s en build-metadata in in images en deployment-annotaties.
  • Faalmodi: langlevende branches, handmatige overdrachten, onstabiele tests, niet-reproduceerbare builds en het ontbreken van artifact immutability leiden tot late verrassingen en rollbacks.

• Source control, branching, pull requests, code review en traceerbaarheid

  • Gebruik protected branches, verplichte reviews en commit signing. Tag releases en onderhoud een changelog die wordt gegenereerd uit merge commits.
  • Pas CODEOWNERS en metadata voor service-eigenaarschap toe om domeinbeheer af te dwingen.
  • Koppel commits aan issues en deployments; exporteer CI/CD-logs en metadata naar Cloud Logging en BigQuery voor audits en DORA-metrics.

• Cloud Build

  • Triggers: worden geactiveerd door Git-events (branch, tag, PR), handmatige aanroepen of Pub/Sub. Parametriseer met substituties voor versie, omgeving en feature flags om pipelines DRY te houden.
  • Build steps: voer officiële builders uit of containers die je zelf definieert; gebruik parallelle stappen waar onafhankelijk om de latency te verlagen; gebruik caches voor taalafhankelijkheden om builds te versnellen.
  • Artifacts: push images naar Artifact Registry met immutable tags en digests; sla SBOM’s en build-logs op; publiceer testrapporten als build artifacts.
  • Beveiligde build-identiteiten: voer Cloud Build uit met een specifieke service account met least privilege en, waar mogelijk, per-repo Workload Identity Federation. Gebruik Private Pools voor private netwerken of om egress te vermijden. Beperk het gebruik van service account keys; geef de voorkeur aan kortlevende tokens.
  • Voorbeeld (ingekort):
    • cloudbuild.yaml:
      • steps:
        • name: gcr.io/cloud-builders/docker args: [build, -t, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA, .]
        • name: gcr.io/cloud-builders/docker args: [push, $REGION-docker.pkg.dev/$PROJECT/app/web:$COMMIT_SHA]
      • substitutions:
        • _ENV=staging

• Cloud Deploy

  • Releases en targets: modelleer een delivery pipeline met promotie over verschillende targets (bv. dev → staging → prod). Een release bevat een immutable artifact-referentie en deployment-configuratie.
  • Goedkeuringen en promotie: vereis handmatige of geautomatiseerde goedkeuringen met op rollen gebaseerde controle. Promotie moet een snelle actie met laag risico zijn, omdat het artifact en de manifests ongewijzigd blijven.
  • Canary rollout en rollback: definieer strategieën voor progressieve blootstelling, health checks en automatische rollback bij SLO-fouten. Leg elke promotie, goedkeurder en verificatieresultaat vast voor auditdoeleinden.
  • Faalmodi: mutable artifacts tussen omgevingen, handmatige kubectl-commando’s in productie, of overgeslagen pre-deploy verificatie veroorzaken drift en niet-traceerbare storingen.

Infrastructure as Code en configuratiebeheer

• Terraform
  • Modules: leg herbruikbare patronen vast (bijv. VPC’s, GKE-clusters, service accounts, IAM-bindingen). Versioneer en pin module-releases; publiceer interne module registries.
  • Remote state: sla op in Cloud Storage met versiebeheer, bewaarbeleid en CMEK; schakel locking in; beperk de toegang via IAM en uniforme toegang op bucket-niveau; maak back-ups van de state.
  • Plans en beleidscontroles: voer

undefined

uit in CI; vereis een menselijke beoordeling van het plan; dwing policy as code (OPA/Conftest, Sentinel of Policy Controller) af om overtredingen te blokkeren (bijv. publieke buckets, brede IAM-bindingen).

• Omgevingspromotie: gebruik aparte workspaces of aparte state/backends per omgeving; promoot wijzigingen via dezelfde moduleversies en variabelen; bewerk cloud resources nooit handmatig. Gevoelige input moet afkomstig zijn van Secret Manager of automatisering, nooit hardgecodeerd.

• Faalscenario’s: het lekken van secrets in de state, gelijktijdige wijzigingen zonder locking, drift door out-of-band bewerkingen en impliciete afhankelijkheden die destroy/replace breken.

• Google Cloud deployment templates en declaratieve configuratie

  • Gebruik declaratieve tools (Terraform, Google Cloud Deployment Manager of Kubernetes Configuration as Code) om de gewenste staat te definiëren in plaats van scripts met imperatieve stappen.
  • Geef de voorkeur aan immutable infrastructuur: vervang instance templates en rol MIGs uit; rol nieuwe GKE Deployments uit in plaats van pods ter plekke te patchen. Immutable patronen maken rollback en audit eenvoudig.
  • Deployment Manager ondersteunt Jinja/Python-templates voor Google Cloud-resources maar is beperkt tot Google Cloud; Terraform biedt een breder ecosysteem en policy-tooling. Selecteer op basis van organisatorische standaardisatie en vaardigheden.

• Kubernetes manifests, Helm, Kustomize en GitOps

  • Manifests: bewaar basis-templates met omgevings-overlays; parameteriseer alleen wat per omgeving moet variëren (bijv. replica’s, limieten, endpoints).
  • Helm: package, template en versioneer services met charts; zet afhankelijkheden vast; pin image digests. Faalscenario: overmatig gebruik van templates verdoezelt de intentie en bemoeilijkt de review.
  • Kustomize: beheer overlays (basis + omgevingspatches); eenvoudiger dan Helm wanneer pure Kubernetes volstaat.
  • GitOps: een controller (bijv. Config Sync, Argo CD, Flux) brengt clusters continu in overeenstemming met de gewenste staat in Git; elke wijziging is een PR met een review en een audittrail. Detecteer en corrigeer drift automatisch.

Progressieve delivery, supply chain, testen en verificatie

• Feature flags en traffic management

  • Feature flags ontkoppelen de implementatie van de release; gebruik ze voor geleidelijke blootstelling, A/B-tests en ’emergency kill switches’. Zorg ervoor dat de statussen van flags geversioneerd en auditeerbaar zijn; verwijder verouderde flags.
  • Traffic splitting: gebruik op Cloud Run procentuele routering over revisies; gebruik op GKE een service mesh of ingress controllers die ‘weighted routing’ ondersteunen. Voor API’s onder één hostnaam/TLS, houd aparte backend services per pad achter de HTTP(S) Load Balancer; padroutering isoleert oude/nieuwe versies netjes terwijl één URL en certificaat behouden blijven.
  • Blue-green: draai twee productieklare stacks; schakel verkeer atomair om via de load balancer, service selectors of Cloud Run-revisieverkeer. Maakt onmiddellijke rollback mogelijk, maar verdubbelt de kosten in stabiele toestand.
  • Canary en progressieve rollout: verhoog geleidelijk het verkeer vanaf een klein deel terwijl je ‘golden signals’ en zakelijke KPI’s meet; automatiseer rollback bij regressie.

• Software supply-chain controles

  • Image scanning: schakel Artifact Analysis vulnerability scanning in; laat builds falen bij kritieke kwetsbaarheden of bekende slechte basis-images; houd een patch-cadans aan.
  • Herkomst en ondertekening: genereer SLSA-conforme build-herkomst in Cloud Build; onderteken artefacten met Cosign; dwing Binary Authorization-beleid af dat attesten vereist vóór de deployment.
  • Dependency management: pin versies en digests, onderhoud SBOMs, ‘vendor’ kritieke afhankelijkheden en verifieer checksums. Faalscenario’s omvatten drift van transitieve afhankelijkheden en gecompromitteerde registries.

• Testpiramide, deployment gates en post-deployment verificatie

  • Piramide: leg de nadruk op snelle unit tests; voeg integratie- en contracttests toe; voer gerichte end-to-end tests uit. Houd testdata realistisch en geanonimiseerd (gebruik Cloud DLP om PII te verwijderen).
  • Deployment gates: dwing drempelwaarden af voor slagingspercentage van tests, kwetsbaarheidsstatus, beleidsnaleving en code review vóór promotie; vereis handmatige goedkeuring voor productie bij verhoogd risico.
  • Post-deployment verificatie: voer smoke tests, synthetische controles en canary-analyses uit met Cloud Monitoring, Error Reporting en Trace. Als KPI’s verslechteren, trigger dan een geautomatiseerde rollback en open een incident met de vastgelegde context.
  • Operationele diagnostiek: implementeer de Cloud Logging-agent waar nodig, en instrumenteer services voor Trace en Debugger. Houd runbooks bij voor veilige herstelacties (bijv. het online resizen van een persistent disk en het uitvoeren van

undefined

met minimale downtime).

Governance, veiligheid, auditeerbaarheid en eigenaarschap

• Snelheid met veiligheid

  • Trunk-based development met kortlevende PR’s en verplichte reviews handhaaft de flow zonder in te boeten aan kwaliteit.
  • Self-service pipelines met templates voor veelgebruikte stacks (GKE + Helm, Cloud Run, Dataflow) versnellen teams en verminderen het risico van maatwerkoplossingen.

• Toegang, identiteit en goedkeuringen

  • Gebruik per pipeline-fase dedicated service accounts met het ’least privilege’-principe en Workload Identity Federation; vermijd statische sleutels.
  • Scheiding van taken: ontwikkelaars bouwen; release managers keuren promotie naar productie goed; runtime operators zijn eigenaar van de runtime-configuratie en budgetten.

• Auditeerbaarheid en compliance

  • Exporteer Cloud Build-, Cloud Deploy- en Cloud Audit Logs naar BigQuery. Gebruik dataset-views en IAM om afgebakende auditdata te delen met auditors. Bewaar metrics op lange termijn door ze te exporteren naar Cloud Storage of BigQuery volgens het beleid.
  • Leg artifact digests vast in deployment-metadata. Beheer een end-to-end SBOM en provenance voor elke release.

• Eigenaarschap en SLO’s

  • Elke service heeft een eigenaar, een on-call-rooster, SLO’s en error budgets die releases bewaken. Koppel deployment-beleid aan SLO-compliance om te voorkomen dat wijzigingen worden doorgevoerd wanneer het budget is opgebruikt.

• Veelvoorkomende afwegingen en valkuilen

  • Blue-green-kosten versus rollback-snelheid; canary-vertrouwen versus tijd tot volledige release.
  • GitOps-consistentie versus operationele flexibiliteit; sta gecontroleerde ‘break-glass’-procedures toe met logging en opvolgende PR’s.
  • Overmatig gebruik van templates vermindert de leesbaarheid; houd de configuratie expliciet en minimaal.
  • Centraal beleid voorkomt misconfiguratie, maar moet iteratief worden uitgerold om te voorkomen dat teams onnodig worden geblokkeerd.

Praktijkscenario

Bedrijf: Borealis Fintech

Uitdaging: Borealis lanceert een nieuwe betalings-API op GKE en wil tegelijkertijd v1 en v2 onder dezelfde hostnaam en TLS behouden. Ze hebben end-to-end traceerbaarheid, ‘progressive delivery’ met canary en feature flags, sterke supply-chain-controles en geauditeerde promoties nodig voor dev, staging en prod. Ze willen ook GitOps gebruiken voor clusterconfiguratie en Terraform voor platformresources.

Aanpak:

1. Broncodebeheer en branching-strategie opzetten

   • Maak een mono-repo met mappen per service en een aparte infra-repo. Dwing een beschermde main-branch, verplichte PR-reviews, CODEOWNERS en ondertekende commits af. Rationale: een trunk-based flow met duidelijk eigenaarschap en een auditeerbare geschiedenis.

2. Artefacten bouwen met Cloud Build en Artifact Registry

   • Definieer een cloudbuild.yaml om images te bouwen en te pushen die zijn getagd met $COMMIT_SHA en geannoteerd met SBOM en provenance. Gebruik een dedicated Cloud Build service account met ’least privilege’ en een Private Pool. Rationale: reproduceerbare, geïsoleerde builds met traceerbare digests.

   • Voorbeeld:

undefined

3. Software supply-chain-controles implementeren

   • Activeer vulnerability scanning in Artifact Registry. Genereer provenance en onderteken images met Cosign in de post-build-stappen van Cloud Build. Configureer Binary Authorization om handtekeningen en een geslaagde scan te vereisen voordat er naar GKE wordt gedeployed. Rationale: blokkeer onvertrouwde of kwetsbare artefacten op het moment van handhaving.

4. Delivery modelleren met Cloud Deploy

   • Definieer een delivery pipeline met targets dev, staging, prod en een canary-strategie voor prod. Vereis handmatige goedkeuring voor prod met rolgebaseerde goedkeurders. Rationale: onveranderlijke promotie en auditeerbare goedkeuringen.

   • clouddeploy.yaml (fragment):

undefined

5. v1- en v2-API’s routeren onder dezelfde hostnaam
   • Configureer een externe HTTP(S) Load Balancer met afzonderlijke backend services voor de paden /v1 en /v2, die elk verwijzen naar de corresponderende GKE NEG. Rationale: schone, op paden gebaseerde isolatie, hetzelfde certificaat en DNS, en onafhankelijke deploybaarheid.

   • Voorbeeld (fragment):

undefined

6. Infrastructuur beheren met Terraform
   • Maak modules voor VPC, GKE, Artifact Registry, service accounts en IAM. Sla de remote state op in een met CMEK beveiligde Cloud Storage-bucket met versioning en retentie. Dwing OPA-beleid af in CI om risicovolle wijzigingen te voorkomen. Rationale: herbruikbare, reviewbare en beheerde platform-provisioning.

undefined

7. Kubernetes configureren met Helm/Kustomize en GitOps

   • Beheer basis-manifesten voor de API en overlays per omgeving met Kustomize. Gebruik Config Sync of Argo CD om clusters te reconciliëren met de Git-status. Rationale: declaratieve, auditeerbare en driftbestendige operaties.

8. Progressive delivery met canary en feature flags

   • Gebruik de canary-functionaliteit van Cloud Deploy voor prod en een feature-flag SDK (OpenFeature) om nieuwe logica af te schermen. Begin met 5% van het verkeer, promoveer automatisch bij gezonde SLO’s; voer een automatische rollback uit bij degradatie en gebruik de flag als een ‘kill switch’. Rationale: verklein de ‘blast radius’ en ontkoppel de deploy van de release.

9. Kwaliteitspoorten en verificatie

   • Pipeline-fasen: unit tests → integratietests tegen een tijdelijke omgeving → container scan → beleidscontroles → staging end-to-end tests → prod canary met geautomatiseerde, op SLO gebaseerde verificatie (Cloud Monitoring, Error Reporting, Trace). Rationale: vroege en snelle feedback, sterke veiligheid vóór productie en objectieve health checks na de deploy.

10. Operations, logging en audit

    • Installeer Cloud Logging/Monitoring agents voor ondersteunende VM’s en activeer GKE workload logs/metrics. Exporteer CI/CD- en Audit Logs naar BigQuery met afgebakende views voor auditors. Onderhoud runbooks (inclusief veilige rollback- en noodprocedures voor DNS- of LB-switches). Rationale: observability voor snelle herstelacties en compliance-gereed bewijsmateriaal.

Dit ontwerp waarborgt snelheid door een trunk-based flow en geautomatiseerde pipelines; veiligheid door canary, feature flags en Binary Authorization; auditeerbaarheid door onveranderlijke artefacten, goedkeuringen en gecentraliseerde logs; en duidelijk eigenaarschap via CODEOWNERS en door GitOps beheerde omgevingen.

← Operations · Alle domeinen · Kosten →

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

Blader door Google →