GCP - Pytania Rekrutacyjne dla DevOps i Cloud Engineera [2026]

Google Cloud Platform zdobywa coraz większą popularność, szczególnie wśród organizacji wykorzystujących analitykę danych, machine learning i Kubernetes. GCP ma ~11% rynku cloud, ale rośnie najszybciej z wielkiej trójki. Jeśli firma używa BigQuery, Kubernetes (GKE) lub ma silne powiązania z ekosystemem Google, możesz spodziewać się pytań o GCP.

Ten przewodnik zawiera 50+ pytań rekrutacyjnych z odpowiedziami - od podstaw organizacji zasobów, przez compute i networking, po BigQuery i GKE.

Spis treści

• Podstawy GCP
• Compute - VMs, Cloud Run, Functions
• Kontenery - GKE
• IAM i bezpieczeństwo
• Networking - VPC
• Storage i bazy danych
• BigQuery i analytics
• Zobacz też

Chcesz więcej pytań rekrutacyjnych?

Fiszki Online to ponad 800 pytań z 13 technologii - JavaScript, React, TypeScript, Node.js, SQL i więcej. Natychmiastowy dostęp na 30 dni, nauka na każdym urządzeniu.

Sprawdź za 49,99 zł →

Podstawy GCP

Jak GCP organizuje zasoby?

Odpowiedź w 30 sekund:

GCP ma hierarchię: Organization → Folders (opcjonalne) → Projects → Resources. Project to podstawowa jednostka organizacyjna - billing, APIs i IAM są zarządzane per project. Labels służą do organizacji zasobów i alokacji kosztów.

Odpowiedź w 2 minuty:

Hierarchia zasobów GCP różni się od AWS i Azure. Zrozumienie tej struktury jest fundamentalne:

Organization
└── Folders (opcjonalne)
    └── Projects
        └── Resources (VMs, buckets, etc.)

Project to podstawowa jednostka organizacyjna w GCP:

• Billing jest na poziomie projektu
• APIs są włączane per project
• IAM policies są przypisywane do projektów
• Każdy zasób należy do dokładnie jednego projektu

Folders grupują projekty dla polityk organizacyjnych - przydatne dla dużych firm z wieloma zespołami.

Labels to pary klucz-wartość dla organizacji zasobów i alokacji kosztów:

# Dodanie labels do instancji
gcloud compute instances add-labels my-vm \
    --labels=environment=production,team=backend,cost-center=engineering

Pytanie rekrutacyjne: "Jak hierarchia zasobów GCP różni się od AWS?"

W AWS konta są główną granicą. GCP używa projektów w ramach organizacji, z folderami dla dodatkowego grupowania. To sprawia, że multi-project architektury GCP są prostsze dla dużych organizacji - jedna organizacja może mieć tysiące projektów z centralnym IAM i billingiem.

Czym są Regiony i Zones w GCP?

Odpowiedź w 30 sekund:

Region to geograficzna lokalizacja (np. europe-west1 = Belgia, europe-central2 = Polska). Zone to izolowane data center w regionie (np. europe-west1-b). Kluczowa różnica od AWS: VPC w GCP jest globalne, subnety są regionalne.

Odpowiedź w 2 minuty:

GCP ma unikalną strukturę geograficzną, która różni się od konkurencji:

Kluczowa różnica od AWS/Azure:

W GCP VPC jest globalne - jeden VPC może mieć subnety w różnych regionach, a instancje mogą komunikować się bezpośrednio bez peeringu. W AWS/Azure VPC jest regionalne i wymaga peeringu między regionami.

Compute - VMs, Cloud Run, Functions

GCP oferuje różne opcje compute. Znajomość kiedy używać której jest kluczowa.

Czym jest Compute Engine i jakie są typy maszyn?

Odpowiedź w 30 sekund:

Compute Engine to VMs w GCP (odpowiednik EC2). Typy maszyn: e2 (cost-effective), n2 (general purpose), c2 (compute optimized), m2 (memory optimized), a2 (GPU). Preemptible/Spot VMs dają do 80% zniżki ale mogą być przerwane.

Odpowiedź w 2 minuty:

Compute Engine oferuje wirtualne maszyny z różnymi konfiguracjami zoptymalizowanymi pod konkretne workloady:

Preemptible vs Spot VMs:

# Utworzenie preemptible VM
gcloud compute instances create batch-worker \
    --machine-type=n2-standard-4 \
    --preemptible \
    --no-restart-on-failure \
    --maintenance-policy=terminate

# Utworzenie Spot VM
gcloud compute instances create spot-worker \
    --machine-type=n2-standard-4 \
    --provisioning-model=SPOT \
    --instance-termination-action=STOP

Live Migration - unikalna cecha GCP: VMs migrują podczas maintenance bez downtime. W AWS/Azure musisz planować maintenance windows.

Czym jest Cloud Run i kiedy go używać?

Odpowiedź w 30 sekund:

Cloud Run to fully managed serverless platform dla kontenerów. Skaluje do zera, płacisz tylko za czas obsługi requestów. Wspiera dowolny język/runtime (bo kontenery). Idealny dla HTTP API i web apps z nieprzewidywalnym ruchem.

Odpowiedź w 2 minuty:

Cloud Run to jeden z najpopularniejszych serwisów GCP - łączy prostotę serverless z elastycznością kontenerów:

Kluczowe cechy:

• Container-based - dowolny język, dowolny runtime
• Scale to zero - płacisz tylko gdy obsługujesz requesty
• Concurrency - jedna instancja obsługuje wiele requestów (konfigurowalne)
• Cold starts - pierwszy request może mieć latency
• Cloud Run Jobs - dla batch workloads bez incoming requests

# Konfiguracja serwisu Cloud Run
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: api-service
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: "1"  # Unikaj cold starts
        autoscaling.knative.dev/maxScale: "100"
    spec:
      containerConcurrency: 80  # Requestów na instancję
      containers:
        - image: gcr.io/my-project/api:latest
          resources:
            limits:
              cpu: "2"
              memory: "1Gi"

# Deploy do Cloud Run
gcloud run deploy my-api \
    --image=gcr.io/my-project/api:latest \
    --platform=managed \
    --region=europe-west1 \
    --allow-unauthenticated \
    --min-instances=1 \
    --max-instances=100

Czym są Cloud Functions i czym różnią się od Cloud Run?

Odpowiedź w 30 sekund:

Cloud Functions to FaaS (jak AWS Lambda) - event-driven, single-purpose funkcje. Triggery: HTTP, Pub/Sub, Cloud Storage, Firestore. Gen 2 jest zbudowany na Cloud Run i wspiera dłuższe timeouts. Cloud Run dla HTTP serwisów, Functions dla event processing.

Odpowiedź w 2 minuty:

Cloud Functions i Cloud Run to oba serverless, ale mają różne use cases:

Przykład Cloud Function (Gen 2) - przetwarzanie uploadowanych obrazów:

// Cloud Function triggered przez Cloud Storage
const sharp = require('sharp');
const { Storage } = require('@google-cloud/storage');

exports.processImage = async (event, context) => {
  const storage = new Storage();
  const bucket = storage.bucket(event.bucket);
  const file = bucket.file(event.name);

  // Pomiń jeśli już przetworzone
  if (event.name.startsWith('processed/')) return;

  const [buffer] = await file.download();

  const processed = await sharp(buffer)
    .resize(800, 600)
    .jpeg({ quality: 80 })
    .toBuffer();

  await bucket.file(`processed/${event.name}`).save(processed);
  console.log(`Processed: ${event.name}`);
};

# Deploy Cloud Function Gen 2
gcloud functions deploy process-image \
    --gen2 \
    --runtime=nodejs20 \
    --region=europe-west1 \
    --trigger-bucket=my-upload-bucket \
    --entry-point=processImage

Drzewo decyzyjne - który compute wybrać?

Kontenery - GKE

Google Kubernetes Engine (GKE) to managed Kubernetes. Google jest twórcą Kubernetes, więc GKE jest najbardziej dojrzałym managed K8s.

Czym różni się GKE Autopilot od Standard?

Odpowiedź w 30 sekund:

GKE Standard - ty zarządzasz nodes, pełna kontrola nad konfiguracją. GKE Autopilot - Google zarządza wszystkim, płacisz za pod resources nie za nodes. Autopilot dla prostoty i niższego overhead, Standard dla maksymalnej kontroli.

Odpowiedź w 2 minuty:

To jedno z najczęstszych pytań o GKE na rozmowach:

# Utworzenie Autopilot cluster
gcloud container clusters create-auto my-cluster \
    --region=europe-west1

# Utworzenie Standard cluster
gcloud container clusters create my-cluster \
    --region=europe-west1 \
    --num-nodes=3 \
    --machine-type=e2-standard-4 \
    --enable-autoscaling \
    --min-nodes=1 \
    --max-nodes=10

Autopilot jest rekomendowany dla nowych projektów, chyba że potrzebujesz specyficznej konfiguracji nodes (GPU, custom OS, Windows nodes).

Co to jest Workload Identity i dlaczego jest ważne?

Odpowiedź w 30 sekund:

Workload Identity pozwala GKE pods autentykować do GCP services przez Kubernetes service accounts mapowane na GCP service accounts. Eliminuje potrzebę key files - bezpieczniejsze i łatwiejsze w zarządzaniu. Rekomendowany sposób dostępu do GCP APIs z GKE.

Odpowiedź w 2 minuty:

Workload Identity rozwiązuje problem bezpiecznego dostępu do GCP services z podów Kubernetes:

Konfiguracja Workload Identity:

# Kubernetes ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  annotations:
    iam.gke.io/gcp-service-account: my-app@my-project.iam.gserviceaccount.com
---
# Pod używający ServiceAccount
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  serviceAccountName: my-app
  containers:
    - name: app
      image: gcr.io/my-project/my-app

# Bind Kubernetes SA do GCP SA
gcloud iam service-accounts add-iam-policy-binding \
    my-app@my-project.iam.gserviceaccount.com \
    --role=roles/iam.workloadIdentityUser \
    --member="serviceAccount:my-project.svc.id.goog[default/my-app]"

Dlaczego nie używać key files?

• Key files to credentials na dysku - ryzyko wycieku
• Trudne w rotacji
• Workload Identity nie wymaga żadnych credentials w kodzie

IAM i bezpieczeństwo

Jak działa IAM w GCP?

Odpowiedź w 30 sekund:

GCP IAM: Kto (principal) może robić Co (role) na Którym zasobie. Principals: users, service accounts, groups. Roles: basic (viewer/editor/owner), predefined (granularne), custom. Policies bindują principals do ról na zasobach. Zasada least privilege.

Odpowiedź w 2 minuty:

IAM w GCP opiera się na trzech elementach - Principal, Role, Resource:

Principals (Kto):

• Users (konta Google)
• Service accounts (dla aplikacji)
• Groups (grupy Google)
• Domains (cała domena)

Roles (Co może):

# Przypisanie roli predefined
gcloud projects add-iam-policy-binding my-project \
    --member="serviceAccount:my-app@my-project.iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"

# Przypisanie na poziomie zasobu (bardziej restrykcyjne)
gcloud storage buckets add-iam-policy-binding gs://my-bucket \
    --member="serviceAccount:my-app@my-project.iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"

Best practice: Unikaj basic roles (viewer/editor/owner) - są zbyt szerokie. Używaj predefined lub custom roles z minimalnym zestawem uprawnień.

Jak zarządzać Service Accounts?

Odpowiedź w 30 sekund:

Service accounts to tożsamości dla aplikacji, nie ludzi. User-managed tworzysz sam, default są tworzone automatycznie (często overprivileged). Unikaj key files - używaj Workload Identity dla GKE, metadata dla Compute Engine. Impersonation pozwala działać jako inny SA bez key files.

Odpowiedź w 2 minuty:

Service accounts są kluczowe dla bezpiecznej komunikacji między usługami:

Typy service accounts:

Best practices:

# Utwórz dedicated service account
gcloud iam service-accounts create my-app \
    --display-name="My Application"

# Nadaj minimalne uprawnienia
gcloud projects add-iam-policy-binding my-project \
    --member="serviceAccount:my-app@my-project.iam.gserviceaccount.com" \
    --role="roles/storage.objectViewer"

# Dla lokalnego developmentu - impersonation zamiast key file
gcloud auth application-default login \
    --impersonate-service-account=my-app@my-project.iam.gserviceaccount.com

Unikaj key files:

• Są credentials na dysku - ryzyko wycieku
• Trudne w rotacji
• Dla GKE używaj Workload Identity
• Dla Compute Engine używaj attached service account
• Dla lokalnego dev używaj impersonation

Chcesz więcej pytań rekrutacyjnych?

Fiszki Online to ponad 800 pytań z 13 technologii - JavaScript, React, TypeScript, Node.js, SQL i więcej. Natychmiastowy dostęp na 30 dni, nauka na każdym urządzeniu.

Sprawdź za 49,99 zł →

Networking - VPC

Jak działa VPC w GCP?

Odpowiedź w 30 sekund:

VPC w GCP jest globalne - jeden VPC może mieć subnety w różnych regionach. Auto mode VPC ma pre-created subnets, custom mode wymaga explicit tworzenia. Firewall rules są na poziomie VPC i używają network tags do targetowania. Private Google Access umożliwia dostęp do GCP APIs bez publicznych IP.

Odpowiedź w 2 minuty:

VPC w GCP ma fundamentalną różnicę od AWS/Azure - jest globalne:

# Utworzenie custom VPC
gcloud compute networks create my-vpc --subnet-mode=custom

# Utworzenie subnetów w różnych regionach
gcloud compute networks subnets create us-subnet \
    --network=my-vpc \
    --region=us-central1 \
    --range=10.0.1.0/24 \
    --enable-private-ip-google-access

gcloud compute networks subnets create eu-subnet \
    --network=my-vpc \
    --region=europe-west1 \
    --range=10.0.2.0/24 \
    --enable-private-ip-google-access

Korzyść globalnego VPC: Instancje w różnych regionach mogą komunikować się bezpośrednio w tym samym VPC - bez peeringu!

Auto vs Custom mode:

Custom mode jest rekomendowany dla produkcji - lepsza kontrola nad adresacją IP.

Jak działają Firewall Rules w GCP?

Odpowiedź w 30 sekund:

Firewall rules są na poziomie VPC (nie subnetu jak w Azure). Targetują przez network tags lub service accounts, nie IP. Priority: niższy numer = wyższy priorytet. Implied rules: deny all ingress, allow all egress domyślnie.

Odpowiedź w 2 minuty:

Firewall rules w GCP są unikalne - używają network tags zamiast IP do targetowania:

# Allow HTTP do instancji z tagiem 'web'
gcloud compute firewall-rules create allow-http \
    --network=my-vpc \
    --allow=tcp:80,tcp:443 \
    --target-tags=web \
    --source-ranges=0.0.0.0/0 \
    --priority=1000

# Allow komunikację wewnętrzną
gcloud compute firewall-rules create allow-internal \
    --network=my-vpc \
    --allow=tcp,udp,icmp \
    --source-ranges=10.0.0.0/8 \
    --priority=1000

# Targetowanie przez service account (bardziej bezpieczne)
gcloud compute firewall-rules create allow-db \
    --network=my-vpc \
    --allow=tcp:5432 \
    --target-service-accounts=db-server@my-project.iam.gserviceaccount.com \
    --source-service-accounts=app-server@my-project.iam.gserviceaccount.com

Network tags vs Service accounts:

• Tags - łatwiejsze, ale mutable (instancja może zmienić tag)
• Service accounts - bezpieczniejsze, immutable po przypisaniu

Jakie są opcje Load Balancing w GCP?

Odpowiedź w 30 sekund:

Global HTTP(S) LB - Layer 7, single anycast IP, SSL termination, Cloud CDN integration. Regional - Network LB dla TCP/UDP, Internal LB dla traffic wewnętrznego. Cloud Armor dla DDoS protection zintegrowany z Global LB.

Odpowiedź w 2 minuty:

GCP oferuje różne typy load balancerów:

Global HTTP(S) Load Balancer jest najpopularniejszy:

# Utworzenie backend service
gcloud compute backend-services create web-backend \
    --global \
    --protocol=HTTP \
    --health-checks=http-health-check

# Utworzenie URL map
gcloud compute url-maps create web-map \
    --default-service=web-backend

# Utworzenie HTTPS proxy
gcloud compute target-https-proxies create web-proxy \
    --url-map=web-map \
    --ssl-certificates=my-cert

# Utworzenie forwarding rule (faktyczny IP)
gcloud compute forwarding-rules create web-rule \
    --global \
    --target-https-proxy=web-proxy \
    --ports=443

Korzyści Global LB:

• Single anycast IP address
• Routes do nearest healthy backend
• SSL termination at edge
• Cloud CDN integration
• Cloud Armor dla DDoS

Storage i bazy danych

Jakie są klasy storage w Cloud Storage?

Odpowiedź w 30 sekund:

Standard dla często używanych danych (brak minimum duration). Nearline dla danych używanych rzadziej niż raz/miesiąc (30 dni min). Coldline dla kwartalnego dostępu (90 dni min). Archive dla rocznego dostępu (365 dni min). Niższa klasa = tańszy storage, droższy retrieval.

Odpowiedź w 2 minuty:

Cloud Storage (odpowiednik S3) ma cztery klasy storage:

Lifecycle policies automatycznie przenoszą obiekty między klasami:

# Utworzenie bucket
gcloud storage buckets create gs://my-bucket \
    --location=europe-west1 \
    --default-storage-class=standard

# Lifecycle policy (JSON)
cat > lifecycle.json << EOF
{
  "rule": [
    {
      "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
      "condition": {"age": 30}
    },
    {
      "action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
      "condition": {"age": 90}
    },
    {
      "action": {"type": "Delete"},
      "condition": {"age": 365}
    }
  ]
}
EOF

gcloud storage buckets update gs://my-bucket --lifecycle-file=lifecycle.json

Jakie bazy danych oferuje GCP?

Odpowiedź w 30 sekund:

Cloud SQL - managed MySQL, PostgreSQL, SQL Server. Cloud Spanner - globalnie dystrybuowana relacyjna DB (horizontally scalable SQL!). Firestore - serverless document DB. Bigtable - wide-column NoSQL dla big data. Cloud Memorystore - managed Redis/Memcached.

Odpowiedź w 2 minuty:

GCP oferuje szeroką gamę baz danych:

Cloud Spanner jest unikalny - to jedyna globalnie dystrybuowana baza danych z ACID transactions i horizontal scaling:

# Utworzenie instancji Spanner
gcloud spanner instances create my-instance \
    --config=regional-europe-west1 \
    --nodes=1 \
    --description="My Spanner Instance"

# Utworzenie bazy danych
gcloud spanner databases create my-database \
    --instance=my-instance

Cloud Spanner jest drogi, ale idealny dla aplikacji wymagających global consistency z horizontal scaling.

BigQuery i analytics

Co to jest BigQuery i jak działa pricing?

Odpowiedź w 30 sekund:

BigQuery to serverless data warehouse - brak infrastruktury do zarządzania, SQL queries na petabajtach danych. Dwa modele pricing: on-demand ($5/TB scanned, 1TB free/miesiąc) lub flat-rate (dedykowane slots). Optymalizuj przez partitioning i clustering.

Odpowiedź w 2 minuty:

BigQuery to flagowy serwis analytics GCP - często pytany na rozmowach:

Kluczowe cechy:

• Serverless - brak infrastruktury
• Columnar storage - optymalizowane dla analytics
• Standard SQL - ANSI-compliant
• Partitioning - dzielenie tabel po date lub integer
• Clustering - sortowanie danych w partycjach

Pricing:

Optymalizacja kosztów:

-- 1. Używaj partitioned tables
CREATE TABLE my_dataset.events
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_type
AS SELECT * FROM raw_events;

-- 2. Wybieraj tylko potrzebne kolumny (unikaj SELECT *)
SELECT user_id, event_type, COUNT(*)
FROM my_dataset.events
WHERE DATE(event_timestamp) = '2026-01-07'  -- Używa partition
GROUP BY user_id, event_type;

-- 3. Używaj approximate functions dla dużych datasetów
SELECT APPROX_COUNT_DISTINCT(user_id) as unique_users
FROM my_dataset.events;

-- 4. Sprawdź koszt przed wykonaniem
-- bq query --dry_run --use_legacy_sql=false "SELECT..."

Best practices:

• Partition tables by date
• Cluster by frequently filtered columns
• Używaj --dry_run do sprawdzenia bytes scanned
• Ustaw cost controls i quotas

Co to jest Pub/Sub?

Odpowiedź w 30 sekund:

Pub/Sub to messaging service dla asynchronicznej komunikacji. Topics to kanały publikacji, Subscriptions to delivery (pull lub push). At-least-once delivery - wiadomości mogą być dostarczone wielokrotnie. Dead letter topics dla failed messages.

Odpowiedź w 2 minuty:

Pub/Sub jest centralny dla event-driven architectures w GCP:

# Publisher
from google.cloud import pubsub_v1

publisher = pubsub_v1.PublisherClient()
topic_path = publisher.topic_path('my-project', 'my-topic')

data = '{"event": "user_signup", "user_id": "123"}'
future = publisher.publish(topic_path, data.encode('utf-8'))
print(f'Published message ID: {future.result()}')

# Subscriber
subscriber = pubsub_v1.SubscriberClient()
subscription_path = subscriber.subscription_path('my-project', 'my-sub')

def callback(message):
    print(f'Received: {message.data}')
    message.ack()  # Potwierdź przetworzenie

streaming_pull_future = subscriber.subscribe(subscription_path, callback=callback)

Porównanie GCP vs AWS vs Azure

Kluczowe różnice GCP:

• VPC jest globalne (nie regionalne)
• BigQuery jest serverless (nie cluster-based jak Redshift)
• GKE jest najbardziej dojrzałym managed K8s (Google stworzył K8s)

Na co rekruterzy naprawdę zwracają uwagę

Znajomość gcloud CLI - wiele firm używa CLI w codziennej pracy. Pokaż że potrafisz tworzyć zasoby z linii poleceń.

GKE depth - Google stworzył Kubernetes, więc oczekują głębszej wiedzy o GKE: Autopilot vs Standard, Workload Identity, node pools.

BigQuery - jeśli firma używa data analytics, oczekuj pytań o partitioning, clustering, optymalizację kosztów.

IAM bez key files - rekruterzy chcą wiedzieć, że rozumiesz Workload Identity i unikasz key files.

Global VPC - pokaż że rozumiesz różnicę od AWS/Azure i korzyści global networking.

Zadania praktyczne

1. Utwórz GKE cluster (Autopilot) i wdróż aplikację z Workload Identity do dostępu do Cloud Storage.
2. Skonfiguruj Cloud Run z autoskalowaniem i custom domain.
3. Utwórz BigQuery dataset z partitioned table i wykonaj query analizujące koszty.
4. Zaprojektuj VPC z subnetami w dwóch regionach i firewall rules używającymi service accounts.
5. Zaimplementuj event pipeline z Pub/Sub triggering Cloud Function.

Zobacz też

• AWS - Pytania Rekrutacyjne - porównanie z największym cloud provider
• Azure - Pytania Rekrutacyjne - Microsoft cloud
• Kubernetes - Pytania Rekrutacyjne - głębsze zanurzenie w K8s (podstawa GKE)
• Docker - Pytania Rekrutacyjne - podstawy konteneryzacji
• Kompletny Przewodnik - Rozmowa DevOps Engineer - pełna mapa przygotowania

Ten artykuł jest częścią serii przygotowującej do rozmów rekrutacyjnych na stanowiska DevOps i Cloud Engineer. Sprawdź nasze fiszki z pytaniami i odpowiedziami do nauki: Fiszki Online.