Google PCNE: Automazione della rete, governance e gestione dei costi — Guida allo studio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

Panoramica

L’automazione della rete, la governance e le operazioni sui costi su Google Cloud sono discipline inseparabili che determinano l’affidabilità, la sicurezza e l’economicità con cui le vostre reti operano su larga scala. Una pratica efficace unisce una gerarchia delle risorse ben strutturata e un approccio IAM basato sul principio del privilegio minimo con l’infrastructure as code e flussi di lavoro basati su eventi, il tutto supportato da budget, quote e auditability chiari. Lo stato finale è un provisioning prevedibile, modifiche manuali minime, prove di conformità difendibili ed economie unitarie trasparenti per il networking.

Governance e Controllo degli Accessi

Gerarchia delle risorse
- Organization → Folders → Projects è il piano di controllo per l’ereditarietà delle autorizzazioni e le policy di protezione (guardrail). Collocare gli ambienti di produzione e non-produzione in cartelle separate per isolare policy e quote. Utilizzare le etichette su VPC, subnet, router, regole di forwarding e istanze per l’allocazione dei costi e il targeting delle risorse.
- La Shared VPC consolida il routing e la connettività in un progetto host, delegando il calcolo (compute) ai progetti di servizio. Condividere solo le subnet di cui ogni progetto di servizio ha bisogno per seguire il principio di esporre le reti in modo esplicito e ridurre l’esposizione involontaria delle route.
IAM e principio del privilegio minimo
- Separare l’amministrazione della rete dall’amministrazione della sicurezza. Il ruolo Compute Network Admin concede il pieno controllo sui costrutti di rete e l’accesso in sola lettura alle regole del firewall, mentre il ruolo Security Admin gestisce le regole del firewall e i certificati SSL. Questa separazione evita di avere operatori con privilegi eccessivi e si allinea con il controllo delle modifiche (change control).
- Concedere ruoli mirati:
  - Per modificare le regole del firewall, utilizzare il ruolo Security Admin sulla Shared VPC.
  - Per gestire gli allegati VLAN e altre risorse di rete principali, il ruolo Compute Network Admin è appropriato.
  - Per l’automazione su risorse specifiche, concedere autorizzazioni a livello di risorsa anziché ruoli a livello di progetto quando possibile, o creare un ruolo personalizzato limitato alle autorizzazioni necessarie.
- Preferire l’impersonificazione dei service account e i token di breve durata rispetto alle chiavi persistenti. Disabilitare la creazione di chiavi per i service account tramite una policy dell’organizzazione, dove possibile. Utilizzare Workload Identity Federation per eliminare completamente le chiavi per l’automazione on-premise o multi-cloud.
- Seguire il principio del privilegio minimo per le attività del data plane. Ad esempio, un job che legge da Cloud Storage necessita solo del ruolo storage object viewer sul bucket di destinazione, non del ruolo editor a livello di progetto.
Policy dell’organizzazione
- Applicare di default la policy “nessun IP esterno” per le VM; utilizzare Private Google Access e Cloud NAT per raggiungere le API di Google senza indirizzi pubblici.
- Limitare il peering e la condivisione esterna a modelli approvati (ad esempio, limitare le configurazioni di VPC peering per evitarne la proliferazione incontrollata).
- Limitare la creazione di chiavi e l’uso dei service account per limitare la proliferazione delle credenziali.
- Modalità di fallimento e compromessi:
  - Ruoli ereditati troppo ampi a livello di cartella possono concedere silenziosamente l’accesso in scrittura a molti progetti. Rivedere i collegamenti dei ruoli (role bindings) con l’analisi delle autorizzazioni effettive.
  - Bloccare gli IP esterni delle VM senza pianificare l’uso di Private Google Access e NAT porta a interruzioni del servizio quando si chiamano i servizi Google.
  - Convertire una VPC dalla modalità automatica a quella personalizzata senza rifattorizzare i template che presupponevano subnet automatiche rompe le implementazioni (deployment); fare riferimento esplicito alle subnet personalizzate da quel momento in poi.

Automazione, IaC e Operazioni Basate su Eventi

Infrastructure as Code con Terraform
- Utilizzare un design modulare: un modulo per ogni primitiva (VPC, subnet, firewall, Cloud Router, Cloud NAT, interconnect attachment), quindi comporre gli stack degli ambienti. Versionare i moduli e fissare (pin) le versioni negli stack che li utilizzano per controllare i rollout.
- Archiviare lo stato (state) in remoto con un meccanismo di blocco (locking) (ad esempio, Cloud Storage con blocco in stile Dynamo tramite un pattern di back-end) per prevenire modifiche concorrenti. Crittografare ed eseguire il backup dello stato; trattare lo stato come dato sensibile.
- Gestione del drift (deriva):
  - Imporre le modifiche tramite pull request e terraform plan in CI per rivelare la differenza tra lo stato desiderato e quello attuale. Eseguire rilevamenti di drift pianificati (plan -detailed-exitcode) ed emettere avvisi quando appare un drift.
  - Evitare modifiche ad-hoc con gcloud in produzione; se sono necessarie correzioni di emergenza, registrarle e riconciliarle immediatamente nel codice.
- Idempotenza e policy di protezione (guardrail): Pianificare, revisionare e applicare sempre. Utilizzare apply mirati per minimizzare il raggio d’impatto (blast radius). Utilizzare la validazione delle variabili e la policy-as-code (ad esempio, Sentinel o OPA) per bloccare gli anti-pattern come CIDR sovrapposti o firewall aperti.
gcloud, API e flussi di lavoro
- Utilizzare gcloud e REST per attività operative a bassa latenza, ma incapsularli in script ripetibili. Gestire la consistenza finale (eventual consistency) e i limiti di velocità (rate limit) delle API con tentativi (retry) e backoff esponenziale.
- Operazioni basate su eventi:
  - Utilizzare Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions per automatizzare attività di routine come controlli delle quote, audit sull’utilizzo di NAT o campionamento dei log del firewall.
  - Inviare in streaming i log di Admin Activity e Data Access a Pub/Sub per attivare flussi di lavoro di protezione (guardrail) (ad esempio, ripristinare automaticamente una modifica non autorizzata a una regola del firewall).
- Esempi di snippet
  - Concedere un ruolo:

undefined

- Creare una route per le API di Google per bypassare una route di default verso un NGFW:
  -

undefined

Insidie operative
- Le race condition, quando più pipeline gestiscono risorse condivise (ad esempio, i firewall in una VPC comune), causano instabilità (flapping). Utilizzare convenzioni di proprietà (ownership) e pipeline con ambito a livello di cartella.
- L’instabilità delle API in condizioni di parallelismo elevato scatena errori di quota; limitare (throttle) e raggruppare (batch) le operazioni per regione e tipo di risorsa.

Gestione dei costi, delle quote e della capacità

Quote e limiti delle API
- Monitorare le quote per progetto e per regione (indirizzi, regole di forwarding, regole firewall, collegamenti di interconnessione, router). Automatizzare il monitoraggio delle quote e richiedere aumenti prima dell’implementazione di nuovi ambienti. Integrare controlli preliminari delle quote nella CI per un fallimento rapido (fail fast).
- Provisioning su larga scala con:
  - Sharding regionale (creare risorse per regione per evitare la contesa delle quote regionali).
  - Preallocazione (riservare indirizzi e configurare router prima degli eventi di picco).
  - Rollout graduali (creare, convalidare e quindi collegare i backend).
Costi di egress e aspetti economici della topologia
- Il traffico tra regioni all’interno di un VPC comporta costi di egress interregionali. Collocare i carichi di lavoro che comunicano nella stessa regione o replicare i dati a livello regionale quando la latenza e i costi sono importanti.
- Per gli utenti vicini a us-east1 e europe-west1, un singolo VPC con sottoreti regionali abilita la comunicazione privata RFC1918, minimizzando l’overhead di NAT e peering e consentendo al contempo policy e routing semplici.
- Utilizzare VPC Network Peering per una connettività a basso overhead tra progetti o dipartimenti senza NAT e senza routing transitivo; mantenere CIDR non sovrapposti. Utilizzare VPC separati per isolare i dipartimenti che non devono comunicare.
- Cloud CDN riduce l’egress e migliora la latenza per il traffico HTTP(S); un bilanciatore di carico HTTP(S) globale è il control plane per la CDN. Un bilanciatore di carico di rete non migliorerà la latenza globale per le app web perché manca di distribuzione edge e caching.
- Scegliere l’interconnessione con saggezza: Dedicated Interconnect con collegamenti VLAN (VLAN attachment) in un progetto host centralizza l’amministrazione e riduce i costi per progetto per connessioni on-premise condivise e di grandi dimensioni. Cloud VPN con Cloud Router è adatto per una connettività rapida e crittografata tra organizzazioni, con la possibilità di evolvere successivamente verso un’interconnessione.
Allocazione dei costi, budget e previsioni
- Assegnare tag a tutte le risorse di rete con etichette per dipartimento, ambiente e centro di costo. Esportare i dati di fatturazione in BigQuery e derivare i costi unitari (ad esempio, $/GB di egress per servizio).
- Creare budget a livello di progetto, cartella o etichetta. Inviare avvisi a Pub/Sub e collegarli a ChatOps o a responder Cloud Run. Automatizzare le azioni in caso di superamento del budget (ad esempio, ridurre il campionamento dei log o ridurre la scalabilità degli ambienti di test non critici).
- Ottimizzare l’egress:
  - Preferire Private Google Access e Cloud NAT invece di IP esterni per controllare i percorsi di egress e centralizzare la fatturazione.
  - Per le topologie a tunnel forzato (forced-tunnel), aggiungere route personalizzate per le API di Google al gateway Internet predefinito o configurare Private Google Access per l’ambiente on-premise per evitare l’hairpinning attraverso firewall di terze parti.
  - Prevedere la capacità analizzando i VPC Flow Logs e i log dei bilanciatori di carico; correlare con la stagionalità. Dimensionare correttamente (right-size) i gateway NAT e la capacità di interconnessione in anticipo rispetto ai picchi.

Verificabilità ed Eccellenza Operativa

Registrazione e prove (evidence)
- Cloud Audit Logs:
  - I log delle attività di amministrazione (Admin Activity logs) acquisiscono le modifiche al piano di controllo su VPC, rotte, firewall, router e load balancer; sono sempre attivi. Conservarli centralmente e instradarli a un progetto di sicurezza con CMEK, se necessario.
  - I log di accesso ai dati (Data Access logs) per le API di networking possono avere un volume elevato; abilitarli selettivamente e applicare campionamento o sink.
- I VPC Flow Logs e il Firewall Rules Logging forniscono prove a livello di piano dati per la risposta agli incidenti e la conformità. Archiviarli per l’orizzonte di conservazione richiesto e indicizzarli con BigQuery per le indagini.
- Registri delle modifiche: Richiedere che ogni modifica alla rete provenga da IaC con un artefatto del piano immutabile e un riferimento a un ticket. Per modifiche manuali eccezionali, acquisire il comando gcloud, l’operatore, il timestamp e la giustificazione in un registro centrale.
Credenziali sicure e controllo del rischio dell’automazione
- Eliminare le chiavi degli account di servizio a lunga durata. Usare le IAM Conditions per limitare l’ambito dell’automazione per risorsa, tempo o IP. Proteggere le autorizzazioni ad alto rischio (ad esempio, compute.firewalls.update, compute.routers.updateBgpPeer) con flussi di lavoro di approvazione.
- Applicare il principio del privilegio minimo alla CI/CD, usare account di servizio per ogni ambiente e ruotare frequentemente i token. Usare i VPC Service Controls per la protezione del perimetro di servizio dove esistono rischi di esfiltrazione di dati.
Runbook, ciclo di vita e miglioramento continuo
- Mantenere runbook per le operazioni di routine: onboarding di un progetto su Shared VPC, creazione di un peering VPC, instaurazione di una Cloud VPN con IKEv2, promozione delle regole di Cloud Armor da “preview” a “enforce”.
- Definire policy del ciclo di vita:
  - Promozione Sandbox → Staging → Produzione con moduli Terraform identici e variabili specifiche per regione.
  - Playbook di smantellamento (decommissioning) per rimuovere in sicurezza peering, NAT e rotte.
- Miglioramento continuo:
  - Le revisioni post-incidente dovrebbero essere recepite nei moduli (ad esempio, aggiungendo una regola di “deny” predefinita in uscita (egress) con allowlist esplicite, o il logging del NAT per impostazione predefinita).
  - Rivedere regolarmente le policy dell’organizzazione, le etichette e i budget per verificare deviazioni (drift) dalla configurazione (posture) prevista.

Scenario di un Problema Pratico

Contoso Retail opera in Nord America e in Europa. Utenti e servizi sono eseguiti principalmente in us-east1 e europe-west1. La sicurezza richiede una rotta predefinita verso un NGFW di terze parti, nessun IP esterno sulle VM e una connettività on-premise centralizzata. L’azienda necessita anche di una chiara allocazione dei costi per dipartimento e di guardrail automatizzati.

Stabilire governance e topologia

Creare un progetto host Shared VPC con un singolo VPC e due subnet regionali in us-east1 e europe-west1. Motivazione: Un unico VPC con subnet regionali permette una comunicazione diretta RFC1918 tra le regioni con routing e policy semplici, minimizzando l’overhead per progetto.
Condividere solo le subnet necessarie con tre progetti di servizio (Marketing, Supply, Finance). Motivazione: La condivisione a livello di subnet limita l’esposizione di rotte e firewall, mantenendo il controllo centralizzato.
Creare un VPC separato per un sistema legacy del reparto Finance che deve essere isolato; eseguire il peering solo con Marketing e Supply dove necessario. Motivazione: Il VPC peering fornisce connettività privata a bassa latenza per i due dipartimenti, mantenendo l’isolamento da Finance.

Configurare l’accesso sicuro ai servizi Google senza IP pubblici

Abilitare il Private Google Access su tutte le subnet condivise. Motivazione: Le istanze senza IP esterni possono raggiungere le API di Google in modo privato.
Poiché la rotta predefinita va a un NGFW, aggiungere una rotta statica personalizzata per 199.36.153.8/30 verso il gateway internet predefinito. Motivazione: Assicura che le chiamate alle API di Google non effettuino un “hairpin” attraverso il firewall, riducendo la latenza ed evitando un singolo punto di congestione (choke point).

Centralizzare la connettività on-premise

Distribuire Dedicated Interconnect e VLAN attachment nel progetto host Shared VPC, collegandoli a un Cloud Router per regione. Motivazione: L’interconnessione centralizzata riduce i costi e la duplicazione operativa; il Cloud Router fornisce routing dinamico per la crescita.
Concedere il ruolo Compute Network Admin agli operatori di rete e Security Admin al team di sicurezza. Motivazione: Applica il principio del privilegio minimo e la separazione dei compiti; gli amministratori di rete non possono modificare i firewall senza l’approvazione della sicurezza.

Automatizzare il provisioning e i guardrail

Implementare moduli Terraform per VPC, subnet, router, NAT, peering e policy di firewall. Archiviare lo stato in remoto con meccanismi di locking; imporre revisioni delle pull request con terraform plan nella CI. Motivazione: Modifiche ripetibili e versionate con controllo delle deviazioni (drift) minimizzano le interruzioni di servizio.
Aggiungere una policy OPA per bloccare CIDR sovrapposti e traffico in ingresso (ingress) da 0.0.0.0/0 verso le subnet interne. Motivazione: Previene errori di configurazione comuni in fase di revisione.
Usare Cloud Scheduler per pubblicare controlli giornalieri delle quote su Pub/Sub; un servizio Cloud Run chiama la Service Usage API per verificare il margine disponibile (headroom) per indirizzi, regole di forwarding e interconnect attachment. Motivazione: Evita fallimenti di deployment dovuti all’esaurimento delle quote.

Ottimizzare i costi e allocarli accuratamente

Applicare le etichette env, dept e service a tutte le risorse di rete tramite Terraform. Esportare la fatturazione in BigQuery e definire budget per dipartimento con avvisi su Pub/Sub. Motivazione: L’allocazione trasparente dei costi e gli avvisi precoci sui picchi consentono un’azione proattiva.
Posizionare davanti alle proprietà web pubbliche un load balancer HTTP(S) globale e abilitare Cloud CDN. Motivazione: Migliora la latenza per gli utenti globali e riduce l’egress servendo contenuti memorizzati nella cache dall’edge.

Rafforzare la verificabilità e la risposta agli incidenti

Instradare i log delle attività di amministrazione (Admin Activity) e delle regole di firewall (Firewall Rules Logging) a un progetto di logging centrale con CMEK. Motivazione: Registri delle modifiche a prova di manomissione e prove a livello di piano dati soddisfano la conformità.
Per client sospetti di abusi, distribuire una regola Cloud Armor in modalità “preview” sul load balancer HTTP(S) e rivedere i log prima di applicarla (enforcing). Motivazione: Minimizza l’interruzione per l’utente durante la convalida della mitigazione.

Documentare e iterare

Pubblicare runbook per l’onboarding di un progetto su Shared VPC, la creazione di un VPC peering tra Marketing e Supply e la costruzione di una Cloud VPN basata su policy per i partner che non dispongono di BGP. Motivazione: L’esecuzione standardizzata riduce l’MTTR e la variabilità.
Dopo ogni finestra di modifica, acquisire metriche (tempo di deployment, errori, $/GB di egress, rapporto di cache hit) e reintrodurre i miglioramenti nei moduli e nelle policy. Motivazione: Il miglioramento continuo integra l’affidabilità e il controllo dei costi nelle operazioni quotidiane.

← Osservabilità della rete · Tutti i domini

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →