Google PCD: Continuous Delivery, configuratie en infrastructuurautomatisering — Studiegids

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

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

Overzicht

Continuous delivery op Google Cloud integreert build-automatisering, artefactbeheer, deployment-orkestratie, infrastructure as code en sterke governance om herhaaldelijk en veilig wijzigingen te leveren. Robuuste pipelines combineren onveranderlijke artefacten en declaratieve configuratie met beleid en auditeerbaarheid. Dit gedeelte legt ontwerpkeuzes, operationele praktijken en veelvoorkomende faalscenario’s uit bij het end-to-end implementeren van Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Kubernetes, feature flags en governance-controles.

Build- en Deployment-orkestratie

Cloud Build

• Triggers: Koppel builds aan brongebeurtenissen (branch pushes, tags, PR’s) of schema’s. Geef de voorkeur aan regex voor branches of tags om ervoor te zorgen dat alleen de bedoelde refs worden geactiveerd. Triggers kunnen worden uitgevoerd als een specifiek serviceaccount om ’least privilege’ af te dwingen; vertrouw niet op de standaardinstelling als builds brede API-toegang nodig hebben.
• Build-stappen: Elke stap wordt uitgevoerd in een container. Gebruik speciaal gebouwde builders (docker, gcloud) of aangepaste builders wanneer de standaard toolchain niet volstaat. Gebruik afzonderlijke stappen voor compileren, unit tests, integratietests, linting, beveiligingsscans en het verpakken van artefacten, zodat fouten herleidbaar zijn en effectief worden gecachet.
• Substituties: Gebruik ingebouwde variabelen (PROJECT_ID, SHORT_SHA) en aangepaste substituties (met het voorvoegsel $_) voor geparametriseerde builds. Houd omgevingsspecifieke waarden buiten de build-logica; geef ze door als substituties of los ze later op tijdens de implementatie.
• Serviceaccounts: Het Cloud Build-serviceaccount (PROJECT_NUMBER@cloudbuild.gserviceaccount.com) vereist expliciete rollen (bijvoorbeeld schrijftoegang tot Artifact Registry, beheerder van Cloud Deploy-releases). Wijs minimale rollen toe en beperk de scope per project. Gebruik voor private resources Private Pools met VPC-connectiviteit.
• Artefacten: Publiceer onveranderlijke images naar Artifact Registry en upload optioneel non-container artefacten naar Cloud Storage via de artifacts-sectie. Tag images met zowel een semantische versie als de commit-digest; gebruik image-digests in deployments om ’tag drift’ te voorkomen.

Voorbeeld Cloud Build-configuratie:

• cloudbuild.yaml: steps:

  • name: gcr.io/cloud-builders/docker args: [“build”,"-t","$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}","."]
  • name: gcr.io/cloud-builders/docker args: [“push”,"$REGION-docker.pkg.dev/$PROJECT_ID/app/app:${SHORT_SHA}"]
  • name: gcr.io/cloud-builders/gcloud args: [“deploy”,“releases”,“create”,“app-${SHORT_SHA}”,"–delivery-pipeline=app-pipeline","–images=app=$REGION-docker.pkg.dev/$PROJECT_ID/app/app@sha256:${COMMIT_SHA}"] substitutions: _REGION: us-central1 serviceAccount: projects/$PROJECT_ID/serviceAccounts/cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

• Voorbeeld van een trigger: gcloud builds triggers create cloud-source-repositories –repo=my-repo –branch-pattern=^main$ –build-config=cloudbuild.yaml –service-account=cb-deployer@$PROJECT_ID.iam.gserviceaccount.com

Cloud Deploy

• Delivery pipelines definiëren geordende stadia en targets. Targets verwijzen naar GKE-clusters, Cloud Run-services of andere ondersteunde runtimes. Markeer productiestadia met requireApproval om promotie te bewaken.
• Rollouts koppelen een release aan een target; promotie verplaatst een release door de targets. Gebruik progressieve levering (canary, blue/green) en hooks voor pre-deploy/post-deploy controles.
• Faalscenario’s: Het gebruik van veranderlijke tags veroorzaakt onbedoelde upgrades; pin altijd digests. Ontbrekende IAM-rechten voor het deployer-account blokkeren rollouts. Niet-renderbare manifesten of drift in omgevingsspecifieke configuratie leiden tot promotiefouten; valideer manifesten tijdens de build.

Voorbeeld Cloud Deploy-definities:

• delivery-pipeline.yaml: apiVersion: deploy.cloud.google.com/v1 kind: DeliveryPipeline metadata: name: app-pipeline serialPipeline: stages:

  • targetId: dev
  • targetId: prod strategy: standard: verify: true requireApproval: true

• targets.yaml: apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: dev gke: cluster: projects/PROJECT/locations/REGION/clusters/DEV_CLUSTER

  Definitie van productietarget

  apiVersion: deploy.cloud.google.com/v1 kind: Target metadata: name: prod gke: cluster: projects/PROJECT/locations/REGION/clusters/PROD_CLUSTER

• Release en promotie: gcloud deploy releases create app-20260903-1 –delivery-pipeline=app-pipeline –region=us-central1 –images=app=us-central1-docker.pkg.dev/PROJECT/app/app@sha256:IMAGE_DIGEST gcloud deploy releases promote –delivery-pipeline=app-pipeline –release=app-20260903-1 –region=us-central1

Artefacten en Integriteit van de Supply Chain

Artifact Registry

• Repositories: Maak afzonderlijke repositories per team of omgeving om IAM en opschoning te scopen. Gebruik regionale repo’s dicht bij builders en runtimes om egress en latentie te verminderen. Pakketformaten omvatten Docker-images en taalpakketten (Maven, npm, PyPI).
• Retentie: Definieer opschoonbeleid om niet-gerefereerde of oude tags te verwijderen, met behoud van een veiligheidsmarge voor rollbacks. Vermijd agressieve retentie die de laatst bekende goede versie verwijdert.
• Herkomst (Provenance) en SBOM: Schakel build provenance in zodat images SLSA-conforme attesten bevatten. Genereer SBOM’s tijdens de build en sla ze op als attesten, wat de triage van kwetsbaarheden verbetert.
• Scannen op kwetsbaarheden: Schakel containeranalyse in en onderbreek de build of blokkeer promotie wanneer CVE’s met een hoge ernst worden gedetecteerd zonder beschikbare fixes of beleidsuitzonderingen.
• Afwegingen: Het centraliseren van alle artefacten in één project vereenvoudigt de governance, maar kan een grote ‘blast radius’ creëren; repo’s per omgeving of per applicatie verminderen het risico, maar verhogen de beheerslast.

Handhaving van de supply chain

• Binary Authorization op GKE kan attesten vereisen (bijvoorbeeld ‘gebouwd door Cloud Build in project X’, ‘geen kritieke CVE’s’). Integreer met Cloud Deploy-gates om niet-conforme releases te stoppen.
• Faalscenario’s: Vertrouwen op veranderlijke tags, uitgeschakelde scans of niet-geauthenticeerde pulls kan ertoe leiden dat ongeverifieerde software de productie bereikt. Pin digests en vereis attesten.

Infrastructure as Code en GitOps

Terraform

• Configuratie en modules: Factoriseer herbruikbare modules met duidelijke inputs/outputs en semantische versies. Publiceer modules in een gedeelde repo of registry; pin versies om onverwachte wijzigingen te voorkomen.
• State: Gebruik de GCS-backend voor remote state met IAM op bucket-niveau, object versioning en CMEK. Bescherm de state tegen handmatige aanpassingen en zorg voor state-encryptie. Vermijd secrets in de state door deze tijdens de apply-fase uit Secret Manager te lezen en data sources spaarzaam te gebruiken. terraform { backend “gcs” { bucket = “tf-state-prod” prefix = “networking” } }
• Plans en applies: Voer terraform plan uit met -out en laat een menselijke of geautomatiseerde gate de diff reviewen; pas alleen het eerder goedgekeurde plan toe. Gebruik -refresh-only of -detailed-exitcode in drift detection jobs.
• Omgevingsscheiding: Gebruik aparte projecten, state buckets en service accounts per omgeving. Geef voor complexe organisaties de voorkeur aan een map per omgeving met variabelebestanden boven workspaces. Deel nooit state tussen omgevingen.
• Foutscenario’s: Gelijktijdige applies corrumperen de state; dwing serialisatie af met CI/CD en locking (GCS gebruikt object preconditions). Handmatige wijzigingen in de console veroorzaken drift; beperk directe mutaties en voer periodieke plan jobs uit.

Kubernetes declaratieve configuratie

• Manifesten: Houd Kubernetes-objecten declaratief; vermijd kubectl-imperatieven in productie-flows. Pin image digests en resource requests/limits.
• Kustomize: Gebruik base + overlays om omgevingsspecifieke patches te hanteren zonder charts te forken. kustomization.yaml (overlay): resources:
  • ../../base patches:
  • target: kind: Deployment name: api patch: |
    • op: replace path: /spec/replicas value: 3
• Helm: Gebruik values-bestanden per omgeving; documenteer de voorrangsregels (command-line values overschrijven values-bestanden, die op hun beurt de standaardwaarden van de chart overschrijven). Template en render in CI (skaffold render of helm template) zodat de configuraties op het moment van deployment onveranderlijk zijn.
• GitOps: Sla de gewenste state op in Git. Gebruik Cloud Deploy of Config Sync om clusters te reconciliëren met Git. PR’s worden het raakvlak voor wijzigingsbeheer met audittrails en policycontroles. Vermijd kubectl exec-wijzigingen die niet in Git zijn vastgelegd.

Releaseveiligheid, Configuratie en Governance

Feature flags en runtime-configuratie

• Feature flags ontkoppelen de implementatie van de release; lever slapende code en schakel deze in per cohort, percentage of regio. Sla flag-definities op in een HA-systeem met lage latentie (Firestore, Memorystore) en cache ze met korte TTL’s. Log evaluaties voor traceerbaarheid.
• Geleidelijke uitrol: Combineer traffic splitting (Cloud Run) of canary-subsets (GKE) met flags om de ‘blast radius’ te minimaliseren. Gebruik health-metrics en op SLO gebaseerde geautomatiseerde rollback-triggers.
• Veilige rollback: Geef de voorkeur aan snelle deactivatie via feature flags. Voor een binaire rollback, promoot de laatst bekende goede release of pas de vorige manifest-digest opnieuw toe.

Omgevingsvariabelen, prioriteit en secrets

• De prioriteit is doorgaans als volgt: runtime flags > omgevingsvariabelen > configuratiebestanden > standaardwaarden in de code. Documenteer en standaardiseer dit voor alle services.
• Injecteer configuratie met ConfigMaps en omgevingsvariabelen; gebruik Secret Manager of Kubernetes Secrets voor gevoelige waarden. Roteer ze regelmatig en voorkom het ‘inbakken’ van secrets in images.
• Voorbeelden van secret-injectie:
  • Cloud Run omgevingsvariabele:

undefined

• GKE Secret Manager CSI:

undefined

Quality gates in CI/CD

• Unit tests worden bij elke commit uitgevoerd; snelle feedback is cruciaal.
• Integratietests worden uitgevoerd in tijdelijke (’ephemeral’) omgevingen of sandboxes met vooraf ingevulde data.
• Beveiligingscontroles: SAST, dependency scanning, container vulnerability scanning, IaC-beleidscontroles (Conftest, Policy Controller). Blokkeer merges of promoties bij kritieke bevindingen.
• Deploymentcontroles: Cloud Deploy predeploy- en postdeploy-acties valideren de gereedheid (‘readiness’), de veiligheid van databasemigraties en smoke tests.

Branching, code review, versiebeheer en traceerbaarheid

• Geef de voorkeur aan trunk-based development met kortlevende feature branches en verplichte PR-reviews. Dwing vereiste controles en een lineaire geschiedenis af voor auditeerbaarheid.
• Versiebeheer: Semantische versietags voor releases; image-digests en commit-SHA’s voor onveranderlijkheid (‘immutability’). Vermijd het verplaatsen van tags zoals ’latest’ in productie-deployments.
• Traceerbaarheid: Annoteer builds en releases met commit-, PR- en ticket-ID’s. Verstuur deployment-events naar Logging; koppel labels aan resources voor kosten en eigenaarschap.

Infrastructuur-drift, beleid, audit en wijzigingsbeheer

• Drift-detectie: Geplande terraform plan -detailed-exitcode; alarmeer bij non-zero exitcodes. Voor clusters zorgt Config Sync voor ’eventual convergence’ met Git.
• Beleidshandhaving: Gebruik Organization Policy voor ‘guardrails’ (bijv. het beperken van externe IP’s), Policy Controller voor KRM-constraints en Binary Authorization voor image-beleid.
• Auditlogs: Schakel Admin Activity- en Data Access-logs in; routeer ze naar gecentraliseerde projecten met sinks en retentie die is afgestemd op compliance. Cloud Asset Inventory levert de geschiedenis van wijzigingen en toegangsanalyses.
• Wijzigingsbeheer (‘change control’): Handmatige goedkeuringen voor promoties naar productie, met onderbouwingen vastgelegd als annotaties. ‘Freeze windows’ kunnen worden gecodeerd als beleidscontroles in CI/CD. Zorg ervoor dat noodrollback-procedures gedocumenteerd en geoefend zijn.

Praktijkscenario

Acme Retail moet een nieuwe ‘order-service’ implementeren op GKE voor dev en prod, met veilige canary-rollouts, strikte beleidshandhaving en volledige traceerbaarheid van releases. Het team moet de door Terraform beheerde infrastructuur, declaratieve Kubernetes-configuratie met Kustomize, en een auditeerbare CI/CD met Cloud Build en Cloud Deploy standaardiseren.

Aanpak:

1. Opzetten van artifact repositories en identiteiten

• Maak regionale Artifact Registry-repositories aan: order-docker-dev en order-docker-prod. Geef de Cloud Build-serviceaccount in het app-project de rol roles/artifactregistry.writer en de GKE-runtime nodes de rol roles/artifactregistry.reader voor de betreffende repo.
• Rationale: Gescheiden repo’s verkleinen de ‘blast radius’ en vereenvoudigen lifecycle-beleid. Expliciete IAM voorkomt standaard te ruime permissies (‘overprivileged defaults’).

2. Definiëren van Terraform voor infrastructuur met omgevingsscheiding

• Maak de mappen terraform/envs/dev en terraform/envs/prod aan. Elke configuratie bevat een GCS-backend met aparte state-buckets, een GKE-clustermodule en IAM-bindings voor de Cloud Deploy-serviceaccount. Voer terraform init, plan -out=plan.bin en apply plan.bin uit in een CI-job met ‘gates’ per omgeving.
• Rationale: State en projecten per omgeving voorkomen onbedoelde impact tussen omgevingen; plan-bestanden ondersteunen review en auditeerbaar wijzigingsbeheer.

3. Opstellen van declaratieve Kubernetes-basis en Kustomize-overlays

• Plaats Kubernetes-manifesten in k8s/base voor Deployment, Service en HPA’s met images die vastgepind zijn op digest. Maak k8s/overlays/dev en k8s/overlays/prod aan met replica’s, resource-requests en configuratie-patches. Gebruik een Secret Manager CSI-class voor databank-credentials.
• Rationale: Een ‘single source of truth’ met overlays elimineert drift en houdt configuraties DRY, terwijl het veilige, omgevingsspecifieke verschillen mogelijk maakt.

4. Implementeren van Cloud Build met afzonderlijke test- en package-stappen

• cloudbuild.yaml bevat de volgende stappen: linting en unit tests, integratietests in een tijdelijke (‘disposable’) dev-namespace, container bouwen en pushen naar de omgevings-repo, SBOM- en vulnerability-scanning, en het genereren van ‘provenance’. De trigger wordt uitgevoerd op PR’s naar main voor tests en op merges voor het packagen. Builds worden uitgevoerd met een ’least-privilege’ cb-deployer serviceaccount.
• Rationale: Vroege fouten zijn goedkoop; het scheiden van verantwoordelijkheden (‘separating concerns’) verbetert de ‘observability’ en maakt gerichte ‘retries’ mogelijk. ‘Least-privilege’ vermindert het risico in de supply chain.

5. Configureren van Cloud Deploy delivery pipeline met handmatige productie-goedkeuring en canary-strategie

• Definieer een DeliveryPipeline met dev- en prod-targets. De prod-fase vereist goedkeuring en gebruikt een canary-strategie (bijv. 10 procent en daarna 100 procent). Gebruik predeploy-hooks voor controles op schemacompatibiliteit en smoke tests; postdeploy verifieert de SLO’s.
• Rationale: ‘Progressive delivery’ beperkt de ‘blast radius’ en introduceert geautomatiseerde ‘quality gates’, terwijl handmatige goedkeuring een ‘human-in-the-loop’ afdwingt voor productie.

6. Koppelen van GitOps en beleidshandhaving

• Beveilig de main-branch met verplichte reviews en geslaagde controles. Gebruik Policy Controller-constraints om ‘privileged pods’ te blokkeren en veranderlijke (‘mutable’) tags te verbieden. Schakel Binary Authorization in om Cloud Build ‘provenance’ en ‘attestations’ voor “geen hoge CVE’s” te vereisen vóór ‘admission’.
• Rationale: ‘Policy-as-code’ voorkomt dat risicovolle configuraties het cluster bereiken en zorgt voor consistente handhaving.

7. Beheren van configuratie en feature flags voor een veilige release

• Sla niet-geheime runtime-configuratie op in ConfigMaps; secrets worden aangeleverd via Secret Manager CSI. Introduceer een feature flag order_new_flow die wordt gelezen uit Firestore met een initiële uitrol van 1 procent in productie; flags worden gecachet met een korte TTL en gelogd.
• Rationale: Flags ontkoppelen de release van de implementatie, wat onmiddellijke deactivatie mogelijk maakt als er problemen optreden, zonder de binary terug te hoeven draaien.

8. Zorgen voor observability, drift-detectie en traceerbaarheid

• Annoteer builds en releases met commit-SHA, PR-nummer en change-ticket. Routeer Cloud Deploy-events en GKE-auditlogs naar een centraal Logging-project. Nachtelijke terraform plan-jobs alarmeren bij drift; Config Sync monitort KRM-divergentie en brengt deze in lijn (‘reconciling’) met Git.
• Rationale: Volledige ‘provenance’ en audittrails versnellen de respons op incidenten; continue drift-detectie handhaaft de integriteit van de infrastructuur.

9. Uitvoeren van rollbacks en wijzigingsbeheer

• Bij incidenten, deactiveer eerst order_new_flow via de flag. Promoot indien nodig de vorige succesvolle release in Cloud Deploy naar dev en prod. Alle promoties naar productie vereisen een ticketreferentie in de release-annotaties en goedkeuring van de on-call SRE.
• Rationale: Flags bieden onmiddellijke mitigatie; onveranderlijke (‘immutable’) releases maken een voorspelbare rollback mogelijk. Goedkeuringen en annotaties voldoen aan de operationele governance en compliance.

← Identiteit · Alle domeinen · Observability →

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

Blader door Google →