Google PCA: Operazioni, osservabilità e automazione della piattaforma — Guida allo studio

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

Fa parte della Google Professional Cloud Architect — Guida allo studio. Esercitati con risposte verificate nel centro esami Google, oppure fai test cronometrati su ExamRoll.io.

Panoramica

L’Operatività, l’Osservabilità e l’Automazione della Piattaforma su Google Cloud assicurano che i servizi siano diagnosticabili, manutenibili e migliorati continuamente, controllando al contempo la sicurezza e i costi. Un design coeso abbraccia logging, metriche, tracciamento, auditabilità, runbook, risposta agli incidenti, governance di quote e capacità, e automazione. L’obiettivo è ottenere segnali utili e a basso rumore legati agli obiettivi di livello di servizio, abbinati a un’automazione deterministica che riduca il lavoro manuale ripetitivo (toil) e la deriva della configurazione.

Logging e Auditabilità

Cloud Logging centralizza i log provenienti dai servizi Google Cloud, GKE e VM. Preferire log strutturati (JSON) con chiavi coerenti per request_id, user_id, service, version, latency_ms e severity; i dati strutturati consentono query precise, metriche basate sui log e valutazione delle policy. Sulle VM e sui nodi GKE, installare l’Ops Agent (preferito) o l’agente di logging legacy per raccogliere i log di sistema e delle applicazioni; assicurarsi che i parser emettano JSON per i propri framework.

Bucket di log e conservazione: Utilizzare bucket di log localizzati a livello regionale per la residenza dei dati e CMEK. I bucket predefiniti includono _Default e _Required; quest’ultimo archivia i log di audit di Admin Activity, System Event e Policy Denied con una conservazione fissa a lungo termine. Creare bucket dedicati per classe di dati (es. app, sicurezza, analytics) con conservazione e CMEK personalizzati. Una conservazione più lunga migliora le analisi forensi ma aumenta i costi; esportare per l’archiviazione a lungo termine quando la conservazione in Logging non è richiesta.
Sink di log ed esportazioni: Instradare con il Log Router usando i sink verso BigQuery (analytics), Pub/Sub (SIEM o pipeline) e Cloud Storage (archiviazione). Utilizzare tabelle partizionate in BigQuery per gestire volume e costi. Concedere sempre all’account di servizio del sink l’accesso in scrittura con il minimo privilegio alla destinazione per evitare fallimenti silenziosi. Evitare loop di routing non re-ingerendo i log esportati di nuovo in Logging.
Query e metriche basate sui log: Utilizzare Logs Explorer con filtri sui campi logName, resource.type, severity, labels e jsonPayload. Derivare metriche basate sui log (contatore o distribuzione) per SLI sul tasso di errore e istogrammi di latenza, a supporto dell’alerting. Controllare la cardinalità normalizzando i campi ad alta varianza.
Cloud Audit Logs: I log di Admin Activity (operazioni di scrittura sul piano di controllo), Data Access (operazioni di lettura/scrittura dei dati utente), System Event e Policy Denied forniscono osservabilità amministrativa. I log di Data Access sono ad alto volume e disabilitati per impostazione predefinita per molti servizi; abilitarli solo dove necessario e instradarli verso un bucket con conservazione e CMEK appropriati. I log di Policy Denied aiutano a rilevare precocemente le violazioni dei permessi e delle policy dell’organizzazione. Assicurare la segregazione delle responsabilità: i team di sicurezza tipicamente possiedono e accedono ai log di audit, con viste limitate per gli altri team.
Modalità di fallimento e compromessi:
- Sink troppo ampi fanno esplodere i costi in BigQuery; filtrare con precisione e far scadere le partizioni.
- Campi JSON ad alta cardinalità (es. URL completi) degradano le prestazioni delle query; sanificare ed estrarre etichette normalizzate.
- Una conservazione insufficiente compromette le indagini; le esportazioni verso GCS o BigQuery mitigano il problema.
- Configurazioni errate dell’agente o del parser causano una perdita silenziosa di log; impostare alert sul heartbeat dell’agente e sugli errori di ingestione.

Esempio: creare un bucket di log regionale con conservazione personalizzata ed esportare un sink di audit filtrato.

gcloud logging buckets create app-logs –location=us-central1 –retention-days=30
gcloud logging sinks create bq-audit-sink bigquery.googleapis.com/projects/PROJECT/datasets/audit –log-filter=“logName:cloudaudit.googleapis.com AND protoPayload.serviceName:*” –use-partitioned-tables

Monitoraggio, Tracciamento e Diagnostica delle Applicazioni

Cloud Monitoring raccoglie metriche di sistema e applicative, supporta dashboard, alerting, controlli di uptime, canali di notifica e obiettivi di livello di servizio.

Metriche e dashboard: Utilizzare le metriche integrate per i servizi Google e creare metriche personalizzate tramite l’API di Cloud Monitoring o OpenTelemetry. Enfatizzare i quattro segnali d’oro: latenza, traffico, errori, saturazione. Applicare le etichette con giudizio; evitare valori di etichetta non limitati. Usare Metrics Scope per aggregare le viste multi-progetto. Usare MQL per query espressive quando necessario.
Alerting e canali di notifica: Implementare alert multi-finestra e multi-burn-rate per gli SLO per bilanciare il rilevamento rapido e la riduzione del rumore. Definire canali di notifica (email, SMS, Pub/Sub, webhook, strumenti di incident management di terze parti) e includere link ai runbook e contesto nella documentazione degli alert. Usare limiti di frequenza delle notifiche e la chiusura automatica degli incidenti per prevenire tempeste di alert.
Controlli di uptime: Sondare endpoint critici da più regioni con verifica TLS, DNS e corrispondenza del contenuto. Collegare i controlli di uptime all’alerting e agli SLO del servizio. Ricordare che i controlli di uptime non convalidano le dipendenze interne; integrare con transazioni sintetiche e controlli di integrità interni.
SLO e SLI: Definire SLI per disponibilità, latenza e correttezza. Configurare gli SLO in Cloud Monitoring Service Monitoring e monitorare gli error budget. Impostare alert sul consumo del budget (burn), non sugli errori grezzi, per allinearsi con l’impatto sul cliente. Utilizzare release gate o delivery progressivo per rispettare l’error budget rimanente.
Cloud Trace, Error Reporting, Profiler: Utilizzare il tracciamento distribuito tra i servizi con OpenTelemetry per annotare gli span con metadati di richiesta e dipendenza. Regolare il campionamento (sampling) dinamicamente per servizio e per percorso per garantire la copertura dei flussi critici controllando i costi. Error Reporting aggrega automaticamente le eccezioni dai log, le deduplica in base allo stack trace e attiva le notifiche. Profiler fornisce profili continui di CPU, heap e wall-time in produzione con basso overhead; usarlo per eliminare i percorsi critici (hot path) e ridurre i costi.
Modalità di fallimento e compromessi:
- Un’eccessiva cardinalità delle metriche aumenta i costi e rallenta le query; aggregare prima dell’emissione.
- Un basso campionamento del tracciamento nasconde problemi di latenza di coda (tail latency); campionare a una frequenza maggiore per i percorsi lenti.
- SLO non allineati (es. troppo restrittivi) generano affaticamento da alert (alert fatigue); iterare con dati di traffico reali.
- I controlli di uptime possono avere esito positivo mentre le dipendenze interne falliscono; utilizzare SLO consapevoli delle dipendenze.

Operazioni della Piattaforma, Runbook e Gestione degli Incidenti

Il rigore operativo riduce il tempo medio per rilevare, mitigare e apprendere.

Runbook e escalation: Ogni allarme deve essere collegato a un runbook deterministico con

Automazione, inventario delle risorse, policy e drift

Automatizzare le attività ripetibili con il principio del privilegio minimo (least privilege) e l’idempotenza.

Strumenti: Utilizzare Cloud Shell per un’amministrazione sicura ed effimera con $HOME persistente; posizionare i binari di supporto in ~/bin per la persistenza del PATH. Automatizzare con gcloud, API REST e librerie client. Utilizzare i service account e la workload identity per eliminare le chiavi a lunga durata.
Scheduler e orchestratori: Utilizzare Cloud Scheduler per attivare job HTTP e Pub/Sub tramite pianificazioni cron. Usare Workflows per orchestrare l’automazione multi-servizio con tentativi (retry), backoff, compensazione e timeout. Garantire l’idempotenza e aggiungere ID di correlazione ai log.
Esempi di automazione di routine:
- Esportazione giornaliera degli asset su GCS e BigQuery per report di inventario e di drift.
- Calcolo automatizzato del burn-rate degli SLO con pubblicazione su una dashboard.
- Valutazione periodica delle policy rispetto alle policy dell’organizzazione e alle anomalie IAM.
Inventario delle risorse e valutazione delle policy: Cloud Asset Inventory fornisce feed di modifiche point-in-time e in tempo reale di risorse, binding IAM e policy dell’organizzazione. Esportare su BigQuery per analisi storiche e rilevamento del drift; sottoscrivere a Pub/Sub per il triage quasi in tempo reale delle violazioni delle policy. Utilizzare Policy Analyzer e Recommender per rilevare permessi IAM troppo ampi e non utilizzati. Applicare i vincoli con Organization Policy e validare le configurazioni prima del deploy con la policy-as-code.
Drift di configurazione: Prevenire il drift con IaC dichiarativa e validazione continua. Al rilevamento, riconciliare automaticamente o mettere in quarantena le risorse. Taggare le risorse con la loro provenienza (es. deployment_id) per distinguere quelle gestite da quelle ad hoc.
Architettura di osservabilità per sicurezza, affidabilità e costi:
- Sicurezza: Indirizzare i log di audit verso bucket protetti da CMEK e con accesso limitato; esportare su un progetto dedicato alla sicurezza. Integrare il SIEM tramite Pub/Sub.
- Affidabilità: Basare dashboard e avvisi su SLI e trace; esercitare l’automazione degli incidenti con i workflow.
- Costi: Controllare la cardinalità delle metriche, regolare la conservazione dei log per ogni bucket, partizionare gli export di BigQuery e usare Profiler per ottimizzare i percorsi critici (hot path).

Esempio: pianificare un’esportazione giornaliera degli asset ed eseguire un workflow.

gcloud asset export –content-type=resource –output-path=gs://ORG-SEC-BUCKET/daily/resources-$(date +%F).json
gcloud scheduler jobs create http run-asset-scan –schedule=“0 3 * * *” –uri=“WORKFLOW_EXECUTIONS_API_ENDPOINT” –http-method=POST –oauth-service-account-email=scheduler-sa@PROJECT.iam.gserviceaccount.com

Scenario di un problema pratico

Contoso Commerce sta lanciando una piattaforma di checkout multi-region basata su GKE. Requisiti: amministrazione verificabile (auditable), avvisi basati su SLO con rumore minimo, tracciamento end-to-end delle richieste, inventario di conformità notturno automatizzato e controlli dei costi rigorosi.

Approccio:

Stabilire le basi per il logging e l’audit

Creare bucket di log regionali con CMEK per i log di applicazione, sicurezza e analisi; impostare una conservazione di 30 giorni per i log dell’app e 400+ giorni per quelli di sicurezza, come richiesto. Indirizzare i log di Admin Activity, System Event e Policy Denied al bucket di sicurezza; abilitare i log di Data Access solo per i servizi di pagamento.
Motivazione: La segregazione per livello di sensibilità riduce il blast radius e i costi; CMEK soddisfa i requisiti di conformità; limitare l’ambito dei log di Data Access evita picchi di volume.

Implementare la raccolta e il logging strutturato delle applicazioni

Distribuire l’Ops Agent sui nodi GKE e collettori sidecar/daemonset per inviare i log dell’applicazione come JSON strutturato con ID di correlazione (trace_id, span_id) e label di utente/sessione sanificate per rimuovere le PII.
Motivazione: I log strutturati consentono query precise, metriche basate sui log e join con i trace; gli ID di correlazione supportano la diagnostica distribuita.

Implementare il tracciamento distribuito, l’aggregazione degli errori e il profiling

Strumentare i microservizi con gli SDK di OpenTelemetry che esportano verso Cloud Trace; impostare un campionamento (sampling) più elevato per i percorsi di checkout e pagamento. Abilitare Error Reporting per tutti i runtime e Profiler per i servizi critici in termini di CPU/memoria.
Motivazione: I trace localizzano la latenza per ogni hop tra servizi; Error Reporting raggruppa gli stack trace per accelerare il triage; Profiler riduce i costi di calcolo e la latenza di coda (tail latency).

Definire SLI/SLO e configurare avvisi e dashboard

Definire gli SLI: latenza p90 e p99 del checkout, disponibilità dell’API di checkout e tasso di successo dei pagamenti. Impostare gli SLO (es. disponibilità del 99,9%, latenza p99 inferiore a 800 ms). Configurare avvisi sul burn-rate (2% su 1 ora e 1% su 6 ore) con link ai runbook e canale PagerDuty; creare dashboard che mostrino i golden signal e l’andamento dell’error budget.
Motivazione: Gli avvisi basati sull’error budget sono legati all’impatto sul cliente e riducono il rumore; le dashboard forniscono una consapevolezza della situazione operativa (situational awareness).

Aggiungere health check esterni e interni

Configurare uptime check multi-regione per gli endpoint di checkout con validazione del contenuto; aggiungere controlli di transazioni sintetiche per il flusso dal carrello al pagamento. Integrare le readiness probe di GCLB e GKE.
Motivazione: Gli uptime check verificano la disponibilità percepita dal cliente; i flussi sintetici rilevano le interruzioni delle dipendenze.

Automatizzare l’inventario, il monitoraggio delle policy e il rilevamento del drift

Creare un progetto di Sicurezza per ricevere gli export di Cloud Asset Inventory su GCS e BigQuery; abilitare i feed Pub/Sub in tempo reale per le modifiche a IAM e alle policy dell’organizzazione. Eseguire Workflows ogni notte per confrontare i manifest dello stato desiderato con gli asset correnti; aprire ticket o riconciliare automaticamente il drift a basso rischio.
Motivazione: Un inventario centralizzato supporta gli audit; la valutazione continua delle policy previene il ‘privilege creep’ (aumento incontrollato dei privilegi); l’automazione limita il drift.

Gestire quote e capacità

Monitorare le quote di calcolo, di load balancer e delle API con avvisi al 70% e 85% di utilizzo. Richiedere in anticipo quote più elevate per il carico previsto; allineare i limiti dell’autoscaler del cluster GKE e dell’HPA con le quote. Abilitare l’autoscaling predittivo per i servizi basati su MIG dove l’avvio è lento.
Motivazione: Il raggiungimento dei limiti di quota può apparire come un’interruzione del servizio (outage); aggiustamenti proattivi e un autoscaling allineato prevengono il throttling durante i picchi di carico.

Ottimizzare i costi dell’osservabilità

Limitare la conservazione dei log per bucket, escludere i log di debug verbosi in produzione tramite i filtri del Log Router ed esportare solo i campi necessari su BigQuery con scadenza delle partizioni. Limitare la cardinalità delle label delle metriche; utilizzare i risultati di Profiler per ridimensionare (downsize) i servizi più utilizzati (hot services).
Motivazione: L’osservabilità deve essere efficiente in termini di costi; una conservazione e un’esportazione mirate prevengono una spesa incontrollata (runaway spend).