Google PCNE: Automatyzacja sieci, zarządzanie i operacje kosztowe — Przewodnik do nauki

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

Część Google Professional Cloud Network Engineer — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Google, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Automatyzacja sieci, ład i operacje kosztowe w Google Cloud to nierozerwalnie połączone dyscypliny, które decydują o tym, jak niezawodnie, bezpiecznie i ekonomicznie działają Twoje sieci na dużą skalę. Efektywna praktyka łączy dobrze zorganizowaną hierarchię zasobów i zasadę najmniejszych uprawnień IAM z infrastrukturą jako kodem (IaC) i przepływami pracy sterowanymi zdarzeniami, a wszystko to wsparte jest przez przejrzyste budżety, limity (quotas) i możliwość audytu. Stanem docelowym jest przewidywalne provisionowanie, minimalna liczba ręcznych zmian, możliwe do obrony dowody zgodności oraz przejrzysta ekonomia jednostkowa dla sieci.

Ład i kontrola dostępu

• Hierarchia zasobów

  • Organizacja → Foldery → Projekty to płaszczyzna sterowania dla dziedziczenia uprawnień i barier ochronnych w postaci polityk. Umieść środowiska produkcyjne i nieprodukcyjne w osobnych folderach, aby odizolować polityki i limity. Używaj etykiet na VPC, podsieciach, routerach, regułach przekierowania i instancjach do alokacji kosztów i targetowania zasobów.
  • Shared VPC konsoliduje routing i łączność w projekcie hosta, delegując jednocześnie zasoby obliczeniowe do projektów usługowych. Udostępniaj tylko te podsieci, których potrzebuje dany projekt usługowy, aby przestrzegać zasady jawnego eksponowania sieci i ograniczyć niezamierzoną ekspozycję tras.

• IAM i zasada najmniejszych uprawnień

  • Oddziel administrację siecią od administracji bezpieczeństwem. Rola Compute Network Admin przyznaje pełną kontrolę nad konstrukcjami sieciowymi i dostęp tylko do odczytu do reguł zapory sieciowej, podczas gdy Security Admin zarządza regułami zapory i certyfikatami SSL. Ten podział pozwala uniknąć operatorów z nadmiernymi uprawnieniami i jest zgodny z kontrolą zmian.
  • Nadawaj precyzyjnie określone role:
    • Aby modyfikować reguły zapory, użyj roli Security Admin w projekcie Shared VPC.
    • Do zarządzania VLAN attachments i innymi kluczowymi zasobami sieciowymi odpowiednia jest rola Compute Network Admin.
    • Dla automatyzacji działającej na konkretnych zasobach, w miarę możliwości nadawaj uprawnienia na poziomie zasobu zamiast ról na poziomie projektu, lub utwórz rolę niestandardową ograniczoną do wymaganych uprawnień.
  • Preferuj podszywanie się pod konta usług (impersonation) i tokeny krótkotrwałe zamiast stałych kluczy. W miarę możliwości zablokuj tworzenie kluczy kont usług za pomocą polityki organizacji. Użyj Workload Identity Federation, aby całkowicie wyeliminować klucze w automatyzacji on-premise lub multi-cloud.
  • Stosuj zasadę najmniejszych uprawnień dla zadań w płaszczyźnie danych. Na przykład, zadanie odczytujące dane z Cloud Storage potrzebuje tylko roli storage object viewer na docelowym buckecie, a nie szerokiej roli edytora na poziomie projektu.

• Polityki organizacji

  • Wymuszaj domyślnie brak zewnętrznego adresu IP dla maszyn wirtualnych; użyj Private Google Access i Cloud NAT, aby uzyskać dostęp do Google APIs bez publicznych adresów.
  • Ogranicz peering i udostępnianie na zewnątrz do zatwierdzonych wzorców (np. ogranicz konfiguracje VPC peering, aby uniknąć niekontrolowanego rozrostu).
  • Ogranicz tworzenie kluczy kont usług i ich użycie, aby ograniczyć rozprzestrzenianie się poświadczeń.
  • Scenariusze awarii i kompromisy:
    • Zbyt szerokie, dziedziczone role na poziomie folderu mogą po cichu przyznać dostęp do zapisu w wielu projektach. Przeglądaj powiązania ról za pomocą analizy efektywnych uprawnień.
    • Zablokowanie maszynom wirtualnym możliwości posiadania zewnętrznych adresów IP bez zaplanowania Private Google Access i NAT prowadzi do przerw w działaniu podczas wywoływania usług Google.
    • Konwersja VPC z trybu automatycznego na niestandardowy bez refaktoryzacji szablonów, które zakładały automatyczne podsieci, psuje wdrożenia; od tego momentu należy jawnie odwoływać się do podsieci niestandardowych.

Automatyzacja, IaC i operacje sterowane zdarzeniami

• Infrastruktura jako kod z Terraform

  • Stosuj projekt modułowy: jeden moduł na prymityw (VPC, podsieć, zapora sieciowa, Cloud Router, Cloud NAT, interconnect attachment), a następnie komponuj z nich stosy środowiskowe. Wersjonuj moduły i przypinaj ich wersje w stosach, które z nich korzystają, aby kontrolować wdrożenia.
  • Przechowuj stan zdalnie z blokowaniem (np. w Cloud Storage z blokowaniem w stylu Dynamo za pomocą wzorca backendu), aby zapobiec jednoczesnym zmianom. Szyfruj stan i twórz jego kopie zapasowe; traktuj stan jako dane wrażliwe.
  • Zarządzanie dryfem konfiguracji:
    • Wymuszaj zmiany poprzez pull requesty i terraform plan w CI, aby ujawnić różnice między stanem zamierzonym a rzeczywistym. Uruchamiaj zaplanowane wykrywanie dryfu (plan -detailed-exitcode) i emituj alerty, gdy dryf się pojawi.
    • Unikaj doraźnych zmian za pomocą gcloud na produkcji; jeśli konieczne są poprawki awaryjne, zapisz je i natychmiast uzgodnij z kodem.
  • Idempotentność i bariery ochronne: Zawsze planuj, przeglądaj i wdrażaj. Używaj apply na konkretnych zasobach (targeted apply), aby zminimalizować promień rażenia. Używaj walidacji zmiennych i polityk jako kodu (np. Sentinel lub OPA), aby blokować antywzorce, takie jak nakładające się zakresy CIDR lub otwarte zapory sieciowe.

• gcloud, API i przepływy pracy

  • Używaj gcloud i REST do zadań operacyjnych o niskim opóźnieniu, ale opakowuj je w powtarzalne skrypty. Obsługuj spójność ostateczną (eventual consistency) i limity zapytań API za pomocą ponownych prób i wykładniczego backoffu.
  • Operacje sterowane zdarzeniami:
    • Użyj Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions do automatyzacji rutynowych zadań, takich jak sprawdzanie limitów, audyty wykorzystania NAT czy próbkowanie logów zapory sieciowej.
    • Przesyłaj strumieniowo logi Admin Activity i Data Access do Pub/Sub, aby wyzwalać przepływy pracy z barierami ochronnymi (np. automatyczne wycofanie nieautoryzowanej zmiany w regule zapory).
  • Przykładowe fragmenty kodu
    • Nadaj rolę:
      • gcloud projects add-iam-policy-binding PROJECT –member=user:alice@example.com –role=roles/compute.networkAdmin
    • Utwórz trasę dla Google APIs, aby ominąć domyślną trasę do NGFW:
      • gcloud compute routes create google-apis-egress –network=NET –destination-range=199.36.153.8/30 –next-hop-gateway=default-internet-gateway –priority=800

• Pułapki operacyjne

  • Warunki wyścigu (race conditions), gdy wiele potoków (pipelines) zarządza współdzielonymi zasobami (np. zaporami sieciowymi we wspólnej sieci VPC), powodują niestabilne zmiany (flapping). Stosuj konwencje własności i potoki o zakresie folderu.
  • Niestabilność API przy wysokim zrównolegleniu wyzwala błędy limitów; ograniczaj i grupuj operacje według regionu i typu zasobu.

Zarządzanie kosztami, limitami i pojemnością

• Limity (quotas) i ograniczenia API

  • Śledź limity per projekt i per region (adresy, reguły przekierowania, reguły zapory sieciowej, załączniki interconnect, routery). Automatyzuj monitorowanie limitów i wnioskuj o ich zwiększenie, zanim wdrożone zostaną nowe środowiska. Wbuduj wstępne sprawdzanie limitów w proces CI, aby szybko wykrywać błędy.
  • Udostępniaj zasoby na dużą skalę za pomocą:
    • Shardingu regionalnego (tworzenie zasobów w każdym regionie, aby uniknąć rywalizacji o limity regionalne).
    • Prealokacji (rezerwowanie adresów i konfigurowanie routerów przed okresami szczytowego obciążenia).
    • Wdrożeń etapowych (tworzenie, walidacja, a następnie dołączanie backendów).

• Koszty ruchu wychodzącego (egress) i ekonomia topologii

  • Ruch międzyregionalny wewnątrz VPC generuje koszty ruchu wychodzącego (egress) między regionami. Umieszczaj komunikujące się ze sobą obciążenia w tym samym regionie lub replikuj dane regionalnie, gdy opóźnienia i koszty mają znaczenie.
  • Dla użytkowników w pobliżu us-east1 i europe-west1, pojedyncza sieć VPC z podsieciami regionalnymi umożliwia prywatną komunikację w standardzie RFC1918, minimalizując narzut związany z NAT i peeringiem, jednocześnie pozwalając na proste zasady i routing.
  • Używaj VPC Network Peering do zapewnienia łączności o niskim narzucie między projektami lub działami, bez NAT i bez routingu przechodniego (transitive routing); utrzymuj niepokrywające się zakresy CIDR. Używaj oddzielnych sieci VPC do izolowania działów, które nie powinny się ze sobą komunikować.
  • Cloud CDN redukuje ruch wychodzący (egress) i poprawia opóźnienia dla ruchu HTTP(S); globalny load balancer HTTP(S) jest płaszczyzną sterowania dla CDN. Sieciowy load balancer (network load balancer) nie poprawi globalnych opóźnień dla aplikacji webowych, ponieważ nie posiada dystrybucji brzegowej (edge) i buforowania (caching).
  • Wybieraj połączenie interconnect z rozwagą: Dedicated Interconnect z załącznikami VLAN w projekcie hosta centralizuje administrację i redukuje koszty per projekt dla dużej, współdzielonej łączności on-premise. Cloud VPN z Cloud Router jest odpowiedni do szybkiej, szyfrowanej łączności między organizacjami, z możliwością późniejszej ewolucji w kierunku interconnect.

• Alokacja kosztów, budżety i prognozowanie

  • Oznaczaj wszystkie zasoby sieciowe etykietami dla działu, środowiska i centrum kosztów. Eksportuj dane bilingowe do BigQuery i wyliczaj koszty jednostkowe (na przykład, $/GB ruchu wychodzącego na usługę).
  • Twórz budżety na poziomie projektu, folderu lub etykiety. Wysyłaj alerty do Pub/Sub i podłączaj je do systemów ChatOps lub responderów w Cloud Run. Automatyzuj działania w przypadku przekroczenia budżetu (na przykład zmniejszenie próbkowania logów lub skalowanie w dół niekrytycznych środowisk testowych).
  • Optymalizuj ruch wychodzący (egress):
    • Preferuj użycie Private Google Access i Cloud NAT zamiast zewnętrznych adresów IP, aby kontrolować ścieżki ruchu wychodzącego i centralizować rozliczenia.
    • Dla topologii z wymuszonym tunelowaniem (forced-tunnel), dodaj niestandardowe trasy dla Google APIs do domyślnej bramy internetowej lub skonfiguruj Private Google Access dla środowiska on-premise, aby uniknąć tzw. hairpinningu przez zapory sieciowe firm trzecich.
    • Prognozuj pojemność, analizując VPC Flow Logs i logi load balancerów; koreluj wyniki z sezonowością. Dopasuj rozmiar bram NAT i pojemność połączeń interconnect z wyprzedzeniem przed okresami szczytowymi.

Audytowalność i doskonałość operacyjna

• Logowanie i dowody

  • Cloud Audit Logs:
    • Logi Admin Activity rejestrują zmiany w płaszczyźnie sterowania dotyczące VPC, tras, zapór sieciowych, routerów i load balancerów; są zawsze włączone. Przechowuj je centralnie i kieruj do projektu bezpieczeństwa z CMEK, jeśli jest to wymagane.
    • Logi Data Access dla sieciowych API mogą mieć dużą objętość; włączaj je selektywnie i stosuj próbkowanie lub ujścia (sinks).
  • VPC Flow Logs i Firewall Rules Logging dostarczają dowodów z płaszczyzny danych na potrzeby reagowania na incydenty i zapewnienia zgodności. Przechowuj je przez wymagany horyzont retencji i indeksuj za pomocą BigQuery na potrzeby dochodzeń.
  • Rejestry zmian: Wymagaj, aby każda zmiana w sieci pochodziła z IaC z niezmiennym artefaktem planu i odniesieniem do ticketu. W przypadku wyjątkowych zmian ręcznych, rejestruj polecenie gcloud, operatora, znacznik czasu i uzasadnienie w centralnym rejestrze.

• Bezpieczne poświadczenia i kontrola ryzyka automatyzacji

  • Wyeliminuj długoterminowe klucze kont usług. Używaj warunków IAM (IAM Conditions) do ograniczania zakresu automatyzacji według zasobu, czasu lub adresu IP. Zabezpieczaj uprawnienia wysokiego ryzyka (np. compute.firewalls.update, compute.routers.updateBgpPeer) za pomocą przepływów zatwierdzania.
  • Stosuj zasadę najmniejszych uprawnień w CI/CD, używaj kont usług per środowisko i często rotuj tokeny. Używaj VPC Service Controls do ochrony perymetru usług tam, gdzie istnieje ryzyko eksfiltracji danych.

• Runbooki, cykl życia i ciągłe doskonalenie

  • Utrzymuj runbooki dla rutynowych operacji: wdrażanie projektu do Shared VPC, tworzenie VPC peering, ustanawianie Cloud VPN z IKEv2, promowanie reguł Cloud Armor z trybu podglądu (preview) do trybu egzekwowania (enforce).
  • Zdefiniuj polityki cyklu życia:
    • Promocja Sandbox → Staging → Production z identycznymi modułami Terraform i zmiennymi specyficznymi dla regionu.
    • Playbooki do bezpiecznego wycofywania (decommission) peeringu, NAT i tras.
  • Ciągłe doskonalenie:
    • Przeglądy poincydentalne powinny wpływać na modyfikację modułów (np. dodawanie domyślnej reguły blokującej ruch wychodzący (deny egress) z jawnymi listami dozwolonych, lub domyślne włączanie logowania NAT).
    • Regularnie przeglądaj polityki organizacyjne, etykiety i budżety pod kątem odchyleń od zamierzonego stanu.

Praktyczny scenariusz problemowy

Firma Contoso Retail działa w Ameryce Północnej i Europie. Użytkownicy i usługi działają głównie w regionach us-east1 i europe-west1. Dział bezpieczeństwa wymaga domyślnej trasy do zewnętrznego urządzenia NGFW, braku zewnętrznych adresów IP na maszynach wirtualnych oraz scentralizowanej łączności on-premise. Firma potrzebuje również przejrzystej alokacji kosztów według działów i zautomatyzowanych mechanizmów zabezpieczających (guardrails).

1. Ustanów ład korporacyjny i topologię

• Utwórz projekt hosta Shared VPC z jedną siecią VPC i dwiema podsieciami regionalnymi w us-east1 i europe-west1. Uzasadnienie: Jedna sieć VPC z podsieciami regionalnymi pozwala na bezpośrednią komunikację RFC1918 między regionami przy prostym routingu i politykach, minimalizując narzut na każdy projekt.
• Udostępnij tylko niezbędne podsieci trzem projektom usługowym (Marketing, Supply, Finance). Uzasadnienie: Udostępnianie na poziomie podsieci ogranicza ekspozycję tras i zapór sieciowych, zachowując jednocześnie scentralizowaną kontrolę.
• Utwórz oddzielną sieć VPC dla starszego systemu finansowego (Finance), który musi być odizolowany; połącz peeringiem tylko z Marketing i Supply tam, gdzie jest to potrzebne. Uzasadnienie: VPC peering zapewnia prywatną łączność o niskim opóźnieniu dla dwóch działów, zachowując jednocześnie izolację od działu Finance.

2. Skonfiguruj bezpieczny dostęp do usług Google bez publicznych adresów IP

• Włącz Private Google Access we wszystkich współdzielonych podsieciach. Uzasadnienie: Instancje bez zewnętrznych adresów IP mogą uzyskiwać dostęp do interfejsów API Google prywatnie.
• Ponieważ domyślna trasa prowadzi do NGFW, dodaj niestandardową trasę statyczną dla 199.36.153.8/30 do domyślnej bramy internetowej. Uzasadnienie: Zapewnia to, że wywołania do interfejsów API Google nie będą zawracane przez zaporę sieciową (hairpinning), co zmniejsza opóźnienia i pozwala uniknąć pojedynczego punktu zatoru.

3. Scentralizuj łączność on-premise

• Wdróż Dedicated Interconnect i załączniki VLAN w projekcie hosta Shared VPC, podłączając je do Cloud Router w każdym regionie. Uzasadnienie: Scentralizowany interconnect zmniejsza koszty i duplikację operacyjną; Cloud Router zapewnia dynamiczny routing na potrzeby przyszłego rozwoju.
• Nadaj uprawnienia Compute Network Admin operatorom sieci, a Security Admin zespołowi bezpieczeństwa. Uzasadnienie: Wymusza to zasadę najmniejszych uprawnień i rozdział obowiązków; administratorzy sieci nie mogą zmieniać zapór sieciowych bez zgody zespołu bezpieczeństwa.

4. Zautomatyzuj provisioning i mechanizmy zabezpieczające (guardrails)

• Zaimplementuj moduły Terraform dla VPC, podsieci, routerów, NAT, peeringu i polityk zapory sieciowej. Przechowuj stan zdalnie z blokowaniem; wymuszaj przeglądy pull-request z terraform plan w CI. Uzasadnienie: Powtarzalne, wersjonowane zmiany z kontrolą odchyleń (drift control) minimalizują przestoje.
• Dodaj politykę OPA blokującą nakładające się zakresy CIDR i otwarty ruch przychodzący z 0.0.0.0/0 do wewnętrznych podsieci. Uzasadnienie: Zapobiega to częstym błędom konfiguracyjnym na etapie przeglądu.
• Użyj Cloud Scheduler do publikowania codziennych kontroli limitów (quota) do Pub/Sub; usługa Cloud Run wywołuje Service Usage API, aby zweryfikować dostępną rezerwę dla adresów, reguł przekierowania i załączników interconnect. Uzasadnienie: Pozwala to uniknąć niepowodzeń wdrożeń z powodu wyczerpania limitów.

5. Optymalizuj koszty i dokładnie je alokuj

• Zastosuj etykiety env, dept i service do wszystkich zasobów sieciowych za pomocą Terraform. Eksportuj dane rozliczeniowe do BigQuery i zdefiniuj budżety dla każdego działu z alertami do Pub/Sub. Uzasadnienie: Przejrzysta alokacja kosztów i wczesne ostrzeżenia o skokach wydatków umożliwiają proaktywne działanie.
• Obsłuż publiczne usługi internetowe za pomocą globalnego load balancera HTTP(S) i włącz Cloud CDN. Uzasadnienie: Poprawia to opóźnienia dla użytkowników na całym świecie i zmniejsza koszty ruchu wychodzącego (egress) poprzez serwowanie buforowanej zawartości z krawędzi sieci.

6. Wzmocnij audytowalność i reagowanie na incydenty

• Przekieruj logi Admin Activity i Firewall Rules Logging do centralnego projektu logowania z CMEK. Uzasadnienie: Odporne na manipulacje rejestry zmian i dowody z płaszczyzny danych spełniają wymagania zgodności.
• W przypadku podejrzanych, nadużywających zasobów klientów, wdróż regułę Cloud Armor w trybie podglądu (preview mode) na load balancerze HTTP(S) i przejrzyj logi przed jej włączeniem. Uzasadnienie: Minimalizuje to zakłócenia dla użytkowników podczas walidacji środka zaradczego.

7. Dokumentuj i iteruj

• Opublikuj runbooki dotyczące onboardingu projektu do Shared VPC, tworzenia VPC peering między Marketing i Supply oraz budowania opartego na politykach Cloud VPN dla partnerów, którzy nie obsługują BGP. Uzasadnienie: Standaryzowane wykonanie zmniejsza MTTR i zmienność.
• Po każdym oknie zmian zbieraj metryki (czas wdrożenia, błędy, koszt egress $/GB, współczynnik trafień w cache) i wprowadzaj ulepszenia z powrotem do modułów i polityk. Uzasadnienie: Ciągłe doskonalenie wbudowuje niezawodność i kontrolę kosztów w codzienne operacje.

← Obserwowalność sieci · Wszystkie domeny

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Google →