50+ GCP Pytania Rekrutacyjne 2026: GKE, BigQuery i Cloud Run

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

1. Podstawy GCP Pytania
2. Compute VMs Cloud Run Functions Pytania
3. Kontenery GKE Pytania
4. IAM i Bezpieczeństwo Pytania
5. Networking VPC Pytania
6. Storage i Bazy Danych Pytania
7. BigQuery i Analytics Pytania
8. Zadania Praktyczne
9. Powiązane Artykuły

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 Pytania

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 Pytania

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 Pytania

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 Pytania

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 Pytania

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 Pytania

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 Pytania

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 Pytania

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 Zwracają Uwagę Pytania

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.

Powiązane Artykuły

• 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.