Google PCA: Operations, Observability en Platformautomatisering — 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

Operations, Observability en Platformautomatisering op Google Cloud zorgen ervoor dat services diagnosticeerbaar, onderhoudbaar en continu verbeterd worden, terwijl de beveiliging en kosten beheerst worden. Een samenhangend ontwerp omvat logging, metrics, tracing, auditeerbaarheid, runbooks, incidentrespons, quotum- en capaciteitsbeheer, en automatisering. Het doel is om bruikbare, ruisarme signalen te verkrijgen die gekoppeld zijn aan service-level objectives, in combinatie met deterministische automatisering die ’toil’ en configuratie-afwijkingen (‘configuration drift’) vermindert.

Logging en Auditeerbaarheid

Cloud Logging centraliseert logs van Google Cloud-services, GKE en VM’s. Geef de voorkeur aan gestructureerde logs (JSON) met consistente sleutels voor

undefined

; gestructureerde data maakt precieze query’s, op logs gebaseerde metrics en beleidsevaluatie mogelijk. Installeer op VM’s en GKE-nodes de Ops Agent (voorkeur) of de verouderde logging agent om systeem- en applicatielogs te verzamelen; zorg ervoor dat parsers JSON genereren voor uw frameworks.

Log buckets en retentie: Gebruik regionaal geplaatste log buckets voor dataresidentie en CMEK. Standaard buckets omvatten

undefined

; de laatste bewaart Admin Activity-, System Event- en Policy Denied-auditlogs met een vaste, langdurige retentie. Maak toegewijde buckets per dataklasse (bv. app, security, analytics) met op maat gemaakte retentie en CMEK. Langere retentie verbetert forensisch onderzoek maar verhoogt de kosten; exporteer voor langdurige archivering wanneer retentie in Logging niet vereist is.

Log sinks en exports: Routeer met de Log Router via sinks naar BigQuery (analytics), Pub/Sub (SIEM of pipelines) en Cloud Storage (archivering). Gebruik gepartitioneerde BigQuery-tabellen om volume en kosten te beheren. Geef het serviceaccount van de sink altijd schrijftoegang met de minste privileges (’least-privilege’) tot de bestemming om stille fouten te voorkomen. Vermijd routing-loops door geëxporteerde logs niet opnieuw in Logging op te nemen.
Query’s en op logs gebaseerde metrics: Gebruik Logs Explorer met filters op de velden

undefined

. Leid op logs gebaseerde metrics af (counter of distribution) voor SLI’s van foutpercentages en latency-histogrammen, ter ondersteuning van alerting. Beheers de kardinaliteit door velden met hoge variantie te normaliseren.

Cloud Audit Logs: Admin Activity (schrijfacties op de control-plane), Data Access (lees-/schrijfacties van gebruikersdata), System Event en Policy Denied logs bieden administratieve observeerbaarheid. Data Access-logs hebben een hoog volume en zijn standaard uitgeschakeld voor veel services; schakel ze alleen in waar nodig en routeer ze naar een bucket met de juiste retentie en CMEK. Policy Denied-logs helpen om schendingen van permissies en organisatiebeleid vroegtijdig te detecteren. Zorg voor custodiale scheiding: securityteams zijn doorgaans eigenaar van en hebben toegang tot auditlogs, met beperkte inzage voor andere teams.
Faalmodi en afwegingen:
- Te breed gedefinieerde sinks laten de kosten in BigQuery exploderen; filter nauwkeurig en laat partities verlopen.
- JSON-velden met hoge kardinaliteit (bv. volledige URL’s) verslechteren de prestaties van query’s; schoon ze op en extraheer genormaliseerde labels.
- Onvoldoende retentie belemmert onderzoeken; export naar GCS of BigQuery kan dit verhelpen.
- Een ontbrekende agent of onjuiste parserconfiguraties veroorzaken stil logverlies; stel alerts in op de heartbeat van de agent en opnamefouten.

Voorbeeld: maak een regionale log bucket met aangepaste retentie en exporteer een gefilterde audit sink.

undefined

Monitoring, Tracing en Applicatiediagnostiek

Cloud Monitoring verzamelt systeem- en applicatiemetrics, ondersteunt dashboards, alerting, uptime checks, notificatiekanalen en service-level objectives.

Metrics en dashboards: Gebruik de ingebouwde metrics voor Google-services en maak aangepaste metrics via de Cloud Monitoring API of OpenTelemetry. Leg de nadruk op de ‘four golden signals’: latency, traffic, errors, saturation. Pas labels oordeelkundig toe; vermijd labelwaarden zonder bovengrens (‘unbounded’). Gebruik Metrics Scope om weergaven van meerdere projecten te aggregeren. Gebruik MQL voor expressieve query’s wanneer dat nodig is.
Alerting en notificatiekanalen: Implementeer ‘multi-window, multi-burn-rate’ alerts voor SLO’s om een balans te vinden tussen snelle detectie en ruisonderdrukking. Definieer notificatiekanalen (e-mail, SMS, Pub/Sub, webhooks, externe incident-tools) en neem links naar runbooks en context op in de alert-documentatie. Gebruik ’notification rate limits’ en het automatisch sluiten van incidenten (‘incident autoclose’) om ‘alert storms’ te voorkomen.
Uptime checks: Controleer kritieke endpoints vanuit meerdere regio’s met TLS-verificatie, DNS en content-matching. Koppel uptime checks aan alerting en service-SLO’s. Onthoud dat uptime checks geen interne afhankelijkheden valideren; vul ze aan met synthetische transacties en interne health checks.
SLO’s en SLI’s: Definieer SLI’s voor beschikbaarheid, latency en correctheid. Configureer SLO’s in Cloud Monitoring Service Monitoring en volg de error budgets. Stel alerts in op ‘budget burn’, niet op onbewerkte fouten, om aan te sluiten bij de impact op de klant. Gebruik ‘release gates’ of ‘progressive delivery’ om het resterende error budget te respecteren.
Cloud Trace, Error Reporting, Profiler: Gebruik distributed tracing over services heen met OpenTelemetry om spans te annoteren met metadata van requests en afhankelijkheden. Pas de sampling dynamisch aan per service en per pad om de dekking van kritieke stromen te garanderen en tegelijkertijd de kosten te beheersen. Error Reporting aggregeert automatisch exceptions uit logs, ontdubbelt ze op basis van de stack trace en activeert notificaties. Profiler levert continue CPU-, heap- en wall-time-profielen in productie met lage overhead; gebruik het om ‘hot paths’ te elimineren en kosten te verlagen.
Faalmodi en afwegingen:
- Een te hoge kardinaliteit van metrics verhoogt de kosten en vertraagt query’s; aggregeer voordat u ze verstuurt (’emit’).
- Lage trace sampling verbergt ’tail latency’-problemen; sample met een hogere frequentie voor trage paden.
- Niet goed afgestemde SLO’s (bv. te streng) veroorzaken ‘alert fatigue’; itereer met echte verkeersdata.
- Uptime checks kunnen succesvol zijn terwijl interne afhankelijkheden falen; gebruik SLO’s die rekening houden met afhankelijkheden.

Platformbeheer, draaiboeken en incidentbeheer

Operationele discipline vermindert de gemiddelde tijd voor detectie, mitigatie en leren.

Draaiboeken en escalatie: Elke alert moet linken naar een deterministisch draaiboek met voorwaarden, diagnostische stappen, rollback-procedures en communicatiesjablonen. Definieer duidelijke on-call rotaties en escalatiebeleid. Sla draaiboeken op in versiebeheer en test ze.
Incidentbeheer en postmortems: Gebruik gestandaardiseerde ernstigheidsgraden (severities), rollen (incident commander, communications, ops, SME) en kanalen. Geef de voorkeur aan chat-ops en statuspagina’s voor brede communicatie. Schrijf ‘blameless’ postmortems die de tijdlijn, bijdragende factoren, hiaten in detectie, klantimpact en concrete vervolgacties met eigenaren en datums vastleggen.
Quotabeheer en capaciteitssignalen: Monitor Service Usage en serviceruntime quota metrics met alerts op de gebruiksratio. Vraag proactief quotumverhogingen aan en stem autoscaling-limieten af op quota. Gebruik capaciteitssignalen zoals CPU, memory, file descriptors, connection pools en queue depth. Voor GKE, tune HPA/VPA en de cluster autoscaler; voor GCE MIGs, stel waar van toepassing cool-downs en predictive autoscaling in.
Servicestatus en troubleshooting: Combineer Logs Explorer live tail, op logs gebaseerde metrics, dashboards en Trace om de MTTD te verlagen. Schakel VPC Flow Logs en Firewall Rules Logging in voor netwerk-triage; gebruik de seriële console van de VM voor opstartfouten. Neem packet capture en kernel tracing op in draaiboeken als ‘break-glass’ procedures.
Faalscenario’s:
- Quotumuitputting lijkt op een storing; alerteer bij 80 procent gebruik en pas rate-limiting toe op upstream systemen.
- Autoscaling zonder pre-warming veroorzaakt ‘cold starts’; gebruik een minimumaantal replica’s voor kritieke paden.
- Het ontbreken van synthetische controles maskeert voor de klant zichtbare storingen; implementeer ‘canary transactions’.

Automatisering, Resource-inventaris, Beleid en Drift

Automatiseer herhaalbare taken met ’least privilege’ en idempotentie.

Tooling: Gebruik Cloud Shell voor veilige, efemere administratie met een persistente $HOME; plaats helper-binaries in ~/bin voor PATH-persistentie. Automatiseer met gcloud, REST API’s en client libraries. Gebruik service accounts en workload identity om langlevende sleutels te elimineren.
Schedulers en orchestrators: Gebruik Cloud Scheduler om HTTP- en Pub/Sub-taken te triggeren op basis van cron-schema’s. Gebruik Workflows om automatisering over meerdere services te orkestreren met retries, backoff, compensatie en timeouts. Zorg voor idempotentie en voeg correlatie-ID’s toe aan logs.
Voorbeelden van routine-automatisering:
- Dagelijkse export van assets naar GCS en BigQuery voor inventaris- en drift-rapporten.
- Geautomatiseerde berekening van de SLO burn-rate, gepubliceerd naar een dashboard.
- Periodieke evaluatie van beleid ten opzichte van organisatiebeleid en IAM-anomalieën.
Resource-inventaris en beleidsevaluatie: Cloud Asset Inventory levert point-in-time en real-time change feeds van resources, IAM-bindings en organisatiebeleid. Exporteer naar BigQuery voor historische analyse en drift-detectie; abonneer op Pub/Sub voor bijna-realtime triage van beleidsovertredingen. Gebruik Policy Analyzer en Recommender om te ruime IAM- en ongebruikte permissies te detecteren. Dwing beperkingen af met Organization Policy en valideer configuraties vóór de implementatie met policy-as-code.
Configuratie-drift: Voorkom drift met declaratieve IaC en continue validatie. Bij detectie, ofwel automatisch reconciliëren of resources in quarantaine plaatsen. Tag resources met herkomst (bijv. deployment_id) om beheerde van ad-hoc resources te onderscheiden.
Observability-architectuur voor security, betrouwbaarheid en kosten:
- Security: Routeer auditlogs naar met CMEK beveiligde buckets met beperkte toegang; exporteer naar een toegewijd security-project. Integreer SIEM via Pub/Sub.
- Betrouwbaarheid: Stuur dashboards en alerts aan op basis van SLI’s en traces; oefen incidentautomatisering met workflows.
- Kosten: Beheers de kardinaliteit van metrics, stem de retentie van logs per bucket af, partitioneer BigQuery-exports en gebruik Profiler om ‘hot paths’ te optimaliseren.

Voorbeeld: plan een dagelijkse asset-export en voer een workflow uit.

undefined

Praktisch Probleemscenario

Contoso Commerce lanceert een multi-regionaal, op GKE gebaseerd checkout-platform. Vereisten: auditeerbare administratie, SLO-gestuurde alerts met minimale ruis, end-to-end request tracing, geautomatiseerde nachtelijke compliance-inventarisatie en sterke kostenbeheersing.

Aanpak:

Leg de basis voor logging en auditing

Maak regionale log-buckets met CMEK voor app-, security- en analytics-logs; stel 30 dagen in voor app, 400+ dagen voor security zoals vereist. Routeer Admin Activity, System Event en Policy Denied logs naar de security-bucket; schakel Data Access logs alleen in voor betalingsdiensten.
Rationale: Scheiding op basis van gevoeligheid vermindert de ‘blast radius’ en kosten; CMEK voldoet aan compliance; het beperken van Data Access voorkomt volumepieken.

Implementeer gestructureerde applicatielogging en -verzameling

Implementeer de Ops Agent op GKE-nodes en sidecar/daemonset collectors om app-logs als gestructureerde JSON te versturen met correlatie-ID’s (trace_id, span_id) en voor PII geschoonde user/session-labels.
Rationale: Gestructureerde logs maken precieze queries, op logs gebaseerde metrics en koppeling met traces mogelijk; correlatie-ID’s ondersteunen gedistribueerde diagnostiek.

Implementeer distributed tracing, foutaggregatie en profiling

Instrumenteer microservices met OpenTelemetry SDK’s die exporteren naar Cloud Trace; stel een hogere sampling in voor checkout- en betalingspaden. Schakel Error Reporting in voor alle runtimes en Profiler voor CPU/geheugen-kritieke services.
Rationale: Traces lokaliseren latency per service-hop; Error Reporting groepeert stack traces om triage te versnellen; Profiler vermindert rekenkosten en ’tail latency’.

Definieer SLI’s/SLO’s en configureer alerting en dashboards

Definieer SLI’s: p90 en p99 checkout-latency, beschikbaarheid van de checkout-API en het succespercentage van betalingen. Stel SLO’s in (bijv. 99,9 procent beschikbaarheid, p99-latency onder 800 ms). Configureer burn-rate alerts (2 procent over 1 uur en 1 procent over 6 uur) met runbook-links en PagerDuty-kanaal; bouw dashboards die ‘golden signals’ en trends in het error budget weergeven.
Rationale: Error-budget alerts zijn gekoppeld aan de impact voor de klant en verminderen ruis; dashboards bieden operationeel situationeel bewustzijn.

Voeg externe en interne health checks toe

Configureer multi-region uptime checks voor checkout-eindpunten met contentvalidatie; voeg synthetische transactiechecks toe voor de flow van winkelwagen tot betaling. Integreer GCLB en GKE readiness probes.
Rationale: Uptime checks verifiëren de voor de klant zichtbare beschikbaarheid; synthetische flows detecteren onderbrekingen in afhankelijkheden.

Automatiseer inventarisatie, beleidsmonitoring en drift-detectie

Maak een Security-project om Cloud Asset Inventory-exports naar GCS en BigQuery te ontvangen; schakel real-time Pub/Sub-feeds in voor wijzigingen in IAM en organisatiebeleid. Voer ’s nachts Workflows uit om ‘desired-state’ manifesten te vergelijken met de huidige assets; maak tickets aan of reconcilieer automatisch drift met een laag risico.
Rationale: Gecentraliseerde inventarisatie ondersteunt audits; continue beleidsevaluatie voorkomt ‘privilege creep’; automatisering beperkt drift.

Beheer quota’s en capaciteit

Monitor compute-, load balancer- en API-quota’s met alerts bij 70 en 85 procent verbruik. Vraag vooraf hogere quota’s aan voor de beoogde belasting; lijn de GKE cluster autoscaler en HPA-limieten uit met de quota’s. Schakel predictive autoscaling in voor op MIG gebaseerde services waar de opstarttijd langzaam is.
Rationale: Quota-plafonds kunnen zich voordoen als storingen; proactieve aanpassingen en uitgelijnde autoscaling voorkomen ’throttling’ tijdens pieken.

Optimaliseer kosten in observability

Beperk de retentie van logs per bucket, sluit uitgebreide debug-logs in productie uit via Log Router-filters en exporteer alleen de noodzakelijke velden naar BigQuery met partitie-expiratie. Beperk de kardinaliteit van metric-labels; gebruik de bevindingen van Profiler om ‘hot services’ te verkleinen.
Rationale: Observability moet kosteneffectief zijn; gerichte retentie en exports voorkomen uit de hand lopende uitgaven.

Bereid runbooks en incident-oefeningen voor

Stel geversioneerde runbooks op voor elk alert-beleid, inclusief diagnostische queries, trace-filters, rollback-commando’s en communicatie. Organiseer ‘game days’ om escalatie en automatisering te valideren.
Rationale: Deterministische, geoefende reacties verminderen de MTTR en verbeteren de betrouwbaarheid.

Valideer en itereer

Controleer continu de ruis van alerts, pas drempels aan en verfijn SLO’s op basis van daadwerkelijk verkeer. Volg postmortem-actiepunten op tot de voltooiing, met eigenaren en deadlines.
Rationale: Observability en operations verbeteren door meetbare feedback, wat ’toil’ vermindert en de servicekwaliteit na verloop van tijd verhoogt.

← Migratie · Alle domeinen · DevOps →

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