55+ AWS Pytania Rekrutacyjne 2026: EC2, S3, Lambda i VPC - Flipcards

55+ AWS Pytania Rekrutacyjne 2026: EC2, S3, Lambda i VPC

Sławomir Plamowski 20 min czytania
aws cloud devops ec2 pytania-rekrutacyjne s3 terraform

AWS dominuje na rynku cloud z ~32% udziałem. Na rozmowach DevOps, SRE i Cloud Engineer znajomość AWS jest praktycznie wymagana. Nawet jeśli firma używa Azure czy GCP, zrozumienie koncepcji AWS przenosi się na inne chmury.

Ten przewodnik zawiera 55+ pytań rekrutacyjnych z odpowiedziami - od podstawowych usług po zaawansowane tematy jak VPC, IAM i Infrastructure as Code.

Spis treści

  1. Podstawy AWS Pytania
  2. EC2 Compute Pytania
  3. S3 Storage Pytania
  4. VPC Networking Pytania
  5. IAM Security Pytania
  6. RDS i Bazy Danych Pytania
  7. Lambda i Serverless Pytania
  8. EKS i Kontenery Pytania
  9. Infrastructure as Code Pytania
  10. Monitoring i Logging Pytania
  11. Powiązane Artykuły
Fiszki Online - Wszystkie pakiety

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 AWS Pytania

Czym jest AWS i jakie są główne kategorie usług?

Odpowiedź w 30 sekund: AWS (Amazon Web Services) to platforma cloud computing oferująca 200+ usług. Główne kategorie: Compute (EC2, Lambda), Storage (S3, EBS), Database (RDS, DynamoDB), Networking (VPC, Route 53), Security (IAM, KMS).

Odpowiedź w 2 minuty:

AWS organizuje swoje usługi w logiczne kategorie, co ułatwia znalezienie odpowiedniego narzędzia do konkretnego zadania:

Kategoria Usługi Zastosowanie
Compute EC2, Lambda, ECS, EKS Uruchamianie aplikacji
Storage S3, EBS, EFS, Glacier Przechowywanie danych
Database RDS, DynamoDB, ElastiCache Bazy danych
Networking VPC, Route 53, CloudFront, ELB Sieć i DNS
Security IAM, KMS, Secrets Manager Bezpieczeństwo
Monitoring CloudWatch, CloudTrail, X-Ray Obserwabilność
Developer Tools CodePipeline, CodeBuild, CodeDeploy CI/CD

Regiony i Availability Zones:

Region (np. eu-west-1)
├── AZ-a (eu-west-1a) - osobne data center
├── AZ-b (eu-west-1b) - osobne data center
└── AZ-c (eu-west-1c) - osobne data center
  • Region - geograficzna lokalizacja (np. eu-west-1 = Irlandia)
  • Availability Zone (AZ) - izolowane data center w regionie
  • Multi-AZ - deployment w wielu AZ dla high availability

Czym różni się IaaS, PaaS i SaaS?

Odpowiedź w 30 sekund: IaaS (EC2) - dostajesz VM, zarządzasz wszystkim od OS w górę. PaaS (Elastic Beanstalk) - dostajesz platformę, wrzucasz kod. SaaS (Gmail) - gotowa aplikacja. Im wyżej, tym mniej zarządzasz.

Odpowiedź w 2 minuty:

Modele cloud computing różnią się poziomem odpowiedzialności za zarządzanie infrastrukturą:

Model Co zarządzasz Co AWS zarządza Przykłady AWS
IaaS OS, Runtime, App Hardware, Virtualization EC2, VPC, EBS
PaaS App, Data OS, Runtime, Hardware Elastic Beanstalk, App Runner
SaaS Tylko konfiguracja Wszystko WorkMail, Chime
FaaS Kod (funkcje) Wszystko inne Lambda 
┌─────────────────────────────────────────────────────────┐
│                    ODPOWIEDZIALNOŚĆ                     │
├──────────────┬──────────────┬──────────────┬───────────┤
│   On-Premise │     IaaS     │     PaaS     │   SaaS    │
├──────────────┼──────────────┼──────────────┼───────────┤
│ Applications │ Applications │ Applications │    ✓      │
│ Data         │ Data         │ Data         │    ✓      │
│ Runtime      │ Runtime      │      ✓       │    ✓      │
│ OS           │ OS           │      ✓       │    ✓      │
│ Virtualization│     ✓       │      ✓       │    ✓      │
│ Hardware     │     ✓        │      ✓       │    ✓      │
└──────────────┴──────────────┴──────────────┴───────────┘
   Ty zarządzasz                    AWS zarządza (✓)

EC2 Compute Pytania

Czym jest EC2 i jakie są typy instancji?

Odpowiedź w 30 sekund: EC2 (Elastic Compute Cloud) to wirtualne maszyny w AWS. Typy instancji: t3 (general purpose, burstable), m5 (general purpose), c5 (compute optimized), r5 (memory optimized), g4 (GPU). Wybór zależy od workloadu.

Odpowiedź w 2 minuty:

Typy instancji EC2 są podzielone na rodziny zoptymalizowane pod różne workloady:

Rodzina Prefix Optymalizacja Użycie
General Purpose t3, m5, m6i Balanced Web servers, dev
Compute Optimized c5, c6i CPU Batch processing, gaming
Memory Optimized r5, x2idn RAM Databases, caching
Storage Optimized i3, d2 I/O Data warehousing
GPU p4, g4dn GPU ML, rendering

Naming convention:

m5.xlarge
│ │  └── Size (nano, micro, small, medium, large, xlarge, 2xlarge...)
│ └──── Generation (newer = better)
└────── Family (m = general purpose)

Purchase options:

Opcja Oszczędności Commitment
On-Demand 0% Brak
Reserved (1yr) ~40% 1 rok
Reserved (3yr) ~60% 3 lata
Spot do 90% Może być przerwany
Savings Plans do 72% $/hr commitment

Co to jest AMI i jak działa?

Odpowiedź w 30 sekund: AMI (Amazon Machine Image) to szablon do uruchamiania EC2 - zawiera OS, oprogramowanie, konfigurację. Możesz używać gotowych AMI (Amazon Linux, Ubuntu) lub tworzyć własne. AMI jest region-specific, ale można kopiować między regionami.

Odpowiedź w 2 minuty:

AMI działa jak szablon zawierający wszystkie komponenty potrzebne do uruchomienia instancji. Oto przykład tworzenia własnego AMI:

# AMI zawiera:
# - Root volume (OS)
# - Launch permissions
# - Block device mapping (dodatkowe dyski)

# Tworzenie własnego AMI
aws ec2 create-image \
  --instance-id i-1234567890abcdef0 \
  --name "my-app-v1.0" \
  --description "My application with all dependencies"

# Kopiowanie AMI do innego regionu
aws ec2 copy-image \
  --source-image-id ami-123456 \
  --source-region us-east-1 \
  --region eu-west-1 \
  --name "my-app-eu"

Golden AMI pattern:

  1. Uruchom bazowy EC2
  2. Zainstaluj wszystkie dependencies
  3. Hardening security
  4. Utwórz AMI
  5. Używaj AMI w Auto Scaling Group

Czym jest Security Group?

Odpowiedź w 30 sekund: Security Group to wirtualny firewall dla EC2. Kontroluje inbound i outbound traffic. Domyślnie: deny all inbound, allow all outbound. Stateful - jeśli wpuścisz ruch, odpowiedź jest automatycznie dozwolona.

Odpowiedź w 2 minuty:

Security Group działa jako wirtualny firewall z regułami kontrolującymi ruch sieciowy. Przykład konfiguracji przez AWS CLI:

# Security Group rules
# Inbound (kto może się połączyć)
aws ec2 authorize-security-group-ingress \
  --group-id sg-123456 \
  --protocol tcp \
  --port 443 \
  --cidr 0.0.0.0/0

# Outbound (gdzie instancja może się połączyć)
aws ec2 authorize-security-group-egress \
  --group-id sg-123456 \
  --protocol tcp \
  --port 5432 \
  --source-group sg-789012  # Do innego SG

Security Group vs NACL:

Cecha Security Group NACL
Poziom Instance Subnet
State Stateful Stateless
Rules Allow only Allow & Deny
Evaluation All rules Order matters
Default Deny all inbound Allow all

Best practices:

  • Principle of least privilege
  • Używaj Security Groups zamiast IP gdzie możliwe
  • Oddzielne SG dla różnych tier (web, app, db)
  • Nie używaj 0.0.0.0/0 dla SSH/RDP

Co to jest Auto Scaling Group?

Odpowiedź w 30 sekund: Auto Scaling Group (ASG) automatycznie skaluje liczbę EC2 instancji. Definiujesz min/max/desired capacity. Skalowanie na podstawie metryk (CPU, custom metrics) lub schedule. Zapewnia high availability przez rozpięcie na wiele AZ.

Odpowiedź w 2 minuty:

Auto Scaling Group składa się z Launch Template (definicja instancji) oraz konfiguracji skalowania. Przykład kompletnej konfiguracji:

# Launch Template (co uruchomić)
LaunchTemplate:
  LaunchTemplateName: my-app-template
  LaunchTemplateData:
    ImageId: ami-123456
    InstanceType: t3.medium
    SecurityGroupIds:
      - sg-123456
    UserData: |
      #!/bin/bash
      yum update -y
      systemctl start myapp

# Auto Scaling Group
AutoScalingGroup:
  AutoScalingGroupName: my-app-asg
  LaunchTemplate:
    LaunchTemplateId: !Ref LaunchTemplate
  MinSize: 2
  MaxSize: 10
  DesiredCapacity: 2
  VPCZoneIdentifier:
    - subnet-1a  # AZ-a
    - subnet-1b  # AZ-b
  TargetGroupARNs:
    - !Ref ALBTargetGroup

Scaling Policies:

Policy Type Trigger Użycie
Target Tracking Utrzymuj CPU na 70% Najprostsza
Step Scaling Różne akcje przy różnych progach Zaawansowana
Scheduled O określonej godzinie Przewidywalny ruch
Predictive ML-based prediction Traffic patterns 
# Przykład Target Tracking
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name my-asg \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ASGAverageCPUUtilization"
    }
  }'

S3 Storage Pytania

Czym jest S3 i jakie są klasy storage?

Odpowiedź w 30 sekund: S3 (Simple Storage Service) to object storage - przechowuje pliki jako obiekty w bucketach. Klasy: Standard (hot), Intelligent-Tiering (auto), Glacier (cold archive). 11 nines durability (99.999999999%). Płacisz za storage, requests i transfer.

Odpowiedź w 2 minuty:

S3 oferuje różne klasy storage zoptymalizowane pod kątem kosztów i częstotliwości dostępu do danych:

Klasa Dostępność Retrieval Użycie
Standard 99.99% Instant Aktywne dane
Intelligent-Tiering 99.9% Instant Zmienny access pattern
Standard-IA 99.9% Instant Rzadki dostęp (30+ dni)
One Zone-IA 99.5% Instant Rzadki, reproductible
Glacier Instant 99.9% Milisekundy Archiwum z szybkim dostępem
Glacier Flexible 99.99% 1-12 godzin Archiwum
Glacier Deep Archive 99.99% 12-48 godzin Long-term archive 
# Lifecycle policy - automatyczna migracja
aws s3api put-bucket-lifecycle-configuration \
  --bucket my-bucket \
  --lifecycle-configuration '{
    "Rules": [{
      "ID": "Archive old logs",
      "Status": "Enabled",
      "Filter": {"Prefix": "logs/"},
      "Transitions": [
        {"Days": 30, "StorageClass": "STANDARD_IA"},
        {"Days": 90, "StorageClass": "GLACIER"}
      ],
      "Expiration": {"Days": 365}
    }]
  }'

Jak zabezpieczyć bucket S3?

Odpowiedź w 30 sekund: Domyślnie bucket jest prywatny. Block Public Access na poziomie account i bucket. Bucket Policy dla resource-based permissions. ACL (legacy). Encryption: SSE-S3 (default), SSE-KMS, SSE-C. Versioning dla ochrony przed usunięciem.

Odpowiedź w 2 minuty:

Zabezpieczenie S3 wymaga wielowarstwowego podejścia. Przykład Bucket Policy ograniczającej dostęp tylko z VPC:

// Bucket Policy - tylko z VPC
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::my-bucket",
      "arn:aws:s3:::my-bucket/*"
    ],
    "Condition": {
      "StringNotEquals": {
        "aws:sourceVpc": "vpc-123456"
      }
    }
  }]
}

Security checklist:

  • ✅ Block Public Access enabled
  • ✅ Bucket Policy restrykcyjna
  • ✅ Encryption enabled (SSE-S3 minimum)
  • ✅ Versioning enabled
  • ✅ MFA Delete dla critical buckets
  • ✅ Access logging enabled
  • ✅ VPC Endpoint dla private access
# Block Public Access
aws s3api put-public-access-block \
  --bucket my-bucket \
  --public-access-block-configuration \
    BlockPublicAcls=true,\
    IgnorePublicAcls=true,\
    BlockPublicPolicy=true,\
    RestrictPublicBuckets=true

VPC Networking Pytania

Co to jest VPC i jak go skonfigurować?

Odpowiedź w 30 sekund: VPC (Virtual Private Cloud) to izolowana sieć w AWS. Definiujesz CIDR block (np. 10.0.0.0/16), tworzysz subnety (public/private), konfigurujesz routing, Internet Gateway dla public access, NAT Gateway dla private subnets.

Odpowiedź w 2 minuty:

VPC tworzy izolowaną przestrzeń sieciową z publicznymi i prywatnymi podsieciami rozproszonymi w wielu AZ. Przykładowa architektura:

VPC (10.0.0.0/16)
├── Public Subnet (10.0.1.0/24) - AZ-a
│   ├── Route: 0.0.0.0/0 → Internet Gateway
│   └── Resources: ALB, Bastion
├── Private Subnet (10.0.2.0/24) - AZ-a
│   ├── Route: 0.0.0.0/0 → NAT Gateway
│   └── Resources: EC2, Containers
├── Public Subnet (10.0.3.0/24) - AZ-b
│   └── Route: 0.0.0.0/0 → Internet Gateway
└── Private Subnet (10.0.4.0/24) - AZ-b
    └── Route: 0.0.0.0/0 → NAT Gateway
# Terraform example
resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true
}

resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "eu-west-1a"
  map_public_ip_on_launch = true
}

resource "aws_internet_gateway" "main" {
  vpc_id = aws_vpc.main.id
}

resource "aws_nat_gateway" "main" {
  allocation_id = aws_eip.nat.id
  subnet_id     = aws_subnet.public.id
}

Czym różni się Internet Gateway od NAT Gateway?

Odpowiedź w 30 sekund: Internet Gateway pozwala zasobom z public IP komunikować się z internetem (inbound + outbound). NAT Gateway pozwala zasobom w private subnet wychodzić do internetu bez przyjmowania ruchu przychodzącego - bezpieczniejsze dla backendów.

Odpowiedź w 2 minuty:

Główna różnica polega na kierunku komunikacji i wymaganiach dotyczących publicznych adresów IP:

Cecha Internet Gateway NAT Gateway
Kierunek Bi-directional Outbound only
Public IP Wymagany na instancji Nie wymagany
High Availability Automatic Per-AZ (trzeba tworzyć w każdym AZ)
Koszt Free ~$0.045/hr + transfer
Użycie Public subnets Private subnets 
Internet
    │
    ▼
┌────────────────────────────────────────────────┐
│              Internet Gateway                   │
└────────────────────────────────────────────────┘
    │                              │
    ▼                              ▼
┌──────────────────┐      ┌──────────────────┐
│  Public Subnet   │      │  Public Subnet   │
│   (ALB, NAT)     │      │   (ALB, NAT)     │
│   10.0.1.0/24    │      │   10.0.3.0/24    │
└────────┬─────────┘      └────────┬─────────┘
         │                         │
    NAT Gateway               NAT Gateway
         │                         │
         ▼                         ▼
┌──────────────────┐      ┌──────────────────┐
│  Private Subnet  │      │  Private Subnet  │
│   (EC2, RDS)     │      │   (EC2, RDS)     │
│   10.0.2.0/24    │      │   10.0.4.0/24    │
└──────────────────┘      └──────────────────┘

Co to jest VPC Peering i Transit Gateway?

Odpowiedź w 30 sekund: VPC Peering łączy dwa VPC - ruch idzie prywatnie przez AWS backbone. Ograniczenie: nie przechodnie (A-B, B-C nie daje A-C). Transit Gateway to hub - łączy wiele VPC i on-premise, routing przechodni, centralne zarządzanie.

Odpowiedź w 2 minuty:

Obie technologie służą do łączenia VPC, ale różnią się skalowalnością i możliwościami routingu:

VPC Peering:

VPC-A ←──── Peering ────→ VPC-B
  │                          │
  └──── Peering ─────────────┘
             │
           VPC-C

# NIE ma połączenia A-C przez B!
# Trzeba osobny peering A-C

Transit Gateway:

                ┌─────────────────────┐
                │   Transit Gateway   │
                └─────────┬───────────┘
         ┌────────────────┼────────────────┐
         │                │                │
      VPC-A            VPC-B            VPC-C
                          │
                     On-Premise
                     (VPN/DX)
Cecha VPC Peering Transit Gateway
Topologia Point-to-point Hub-and-spoke
Transitive Nie Tak
Skalowalność Do ~125 peerings Tysiące attachments
Koszt Tylko data transfer Per attachment + data
Complexity Prosta (1:1) Centralne zarządzanie
Fiszki Online - Wszystkie pakiety

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ł →

IAM Security Pytania

Jak działa IAM w AWS?

Odpowiedź w 30 sekund: IAM kontroluje kto (Users, Roles) może co (Policies - Allow/Deny actions) na czym (Resources). Users dla ludzi z credentials. Roles dla usług (EC2, Lambda) - temporary credentials. Zasada least privilege - minimalne wymagane uprawnienia.

Odpowiedź w 2 minuty:

IAM Policy definiuje uprawnienia za pomocą JSON opisującego efekt, akcje, zasoby i warunki. Przykład struktury:

// IAM Policy structure
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",           // lub "Deny"
      "Action": [                  // Co można robić
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": [                // Na czym
        "arn:aws:s3:::my-bucket/*"
      ],
      "Condition": {               // Kiedy (opcjonalne)
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/8"
        }
      }
    }
  ]
}

IAM Entities:

Entity Użycie Credentials
User Ludzie, CI/CD Long-term (access key)
Group Grupowanie Users -
Role Usługi, Federation Temporary (STS)
Policy Uprawnienia - 
# Assume Role (np. EC2 instance profile)
# EC2 automatycznie dostaje temporary credentials

# Cross-account access
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::123456789012:root"},
    "Action": "sts:AssumeRole"
  }]
}

Czym różni się Identity-based od Resource-based policy?

Odpowiedź w 30 sekund: Identity-based policy jest attached do User/Role - mówi "ta tożsamość może X". Resource-based policy jest attached do zasobu (S3, SQS) - mówi "ten zasób może być accessed przez Y". Resource-based umożliwia cross-account access.

Odpowiedź w 2 minuty:

Identity-based policies są przypisane do tożsamości, podczas gdy resource-based policies są częścią samego zasobu:

Cecha Identity-based Resource-based
Attached do User, Group, Role Resource (S3, SQS, Lambda)
Principal Implicit (attached identity) Explicit w policy
Cross-account Wymaga assume role Bezpośrednio w policy
Przykład IAM Policy S3 Bucket Policy 
// Identity-based (attached do Role)
{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bucket/*"
}

// Resource-based (attached do S3 bucket)
{
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::OTHER-ACCOUNT:role/MyRole"},
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::bucket/*"
}

Policy Evaluation Logic:

  1. Explicit Deny → DENY
  2. Organization SCPs → jeśli Allow, kontynuuj
  3. Resource-based policy → jeśli Allow dla same-account, ALLOW
  4. Identity-based policy → jeśli Allow, ALLOW
  5. Permissions boundary → jeśli Allow, ALLOW
  6. Session policies → jeśli Allow, ALLOW
  7. Default → DENY

RDS i Bazy Danych Pytania

Czym jest RDS i kiedy go używać?

Odpowiedź w 30 sekund: RDS (Relational Database Service) to managed SQL databases - MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora. AWS zarządza backups, patching, replication. Używaj dla standardowych relacyjnych workloadów. Aurora dla najlepszej wydajności.

Odpowiedź w 2 minuty:

RDS wspiera wiele silników baz danych, każdy z własnymi zaletami i zastosowaniami:

Engine Użycie Cechy szczególne
Aurora Production, high-performance 5x faster than MySQL, auto-scaling storage
PostgreSQL Complex queries, extensions JSON, GIS
MySQL Web apps, WordPress Najpopularniejszy
MariaDB MySQL fork, open-source Community-driven
Oracle Enterprise, legacy Licensing
SQL Server .NET apps Windows ecosystem

RDS vs Aurora vs DynamoDB:

Cecha RDS Aurora DynamoDB
Typ SQL SQL NoSQL
Skalowanie Vertical Auto (storage), Read Replicas Horizontal (infinite)
Latency ms ms Single-digit ms
Schema Fixed Fixed Flexible
Cost Per-instance Per-instance Per-request/capacity 
# Multi-AZ deployment (HA)
aws rds create-db-instance \
  --db-instance-identifier mydb \
  --db-instance-class db.t3.medium \
  --engine postgres \
  --master-username admin \
  --master-user-password secret \
  --multi-az  # Automatic failover

# Read Replica (scaling reads)
aws rds create-db-instance-read-replica \
  --db-instance-identifier mydb-replica \
  --source-db-instance-identifier mydb

Jak zapewnić High Availability dla RDS?

Odpowiedź w 30 sekund: Multi-AZ deployment - synchronous standby replica w innym AZ, automatic failover (60-120s). Read Replicas dla skalowania read traffic (async, można promować). Aurora ma wbudowany Multi-AZ z szybszym failover (<30s).

Odpowiedź w 2 minuty:

Multi-AZ zapewnia wysoką dostępność przez synchroniczną replikację, podczas gdy Read Replicas służą do skalowania odczytów. Porównanie architektur:

Multi-AZ (HA)                     Read Replicas (Scaling)
┌─────────────┐                   ┌─────────────┐
│   Primary   │                   │   Primary   │
│   (AZ-a)    │                   │   (AZ-a)    │
└──────┬──────┘                   └──────┬──────┘
       │ Synchronous                     │ Asynchronous
       │ Replication                     │ Replication
       ▼                          ┌──────┼──────┐
┌─────────────┐                   ▼      ▼      ▼
│   Standby   │              Read    Read    Read
│   (AZ-b)    │              Rep-1   Rep-2   Rep-3
└─────────────┘              (AZ-a)  (AZ-b)  (AZ-c)

Comparison:

Cecha Multi-AZ Read Replica
Cel High Availability Read scaling
Replication Synchronous Asynchronous
Failover Automatic Manual (promote)
Można czytać? Nie (standby) Tak
Cross-region Nie Tak

Aurora HA:

  • 6 kopii danych w 3 AZ
  • Storage auto-scaling do 128 TB
  • Failover < 30 sekund
  • Global Database dla cross-region

Lambda i Serverless Pytania

Czym jest Lambda i kiedy jej używać?

Odpowiedź w 30 sekund: Lambda to serverless compute - uruchamiasz funkcje bez zarządzania serwerami. Płacisz za wykonanie (ms) i pamięć. Max 15 minut execution time, 10 GB RAM. Dla event-driven workloads, APIs, data processing. Nie dla long-running tasks.

Odpowiedź w 2 minuty:

Lambda uruchamia kod w odpowiedzi na triggery bez potrzeby zarządzania serwerami. Przykład prostej funkcji Lambda:

# Lambda function
import json

def handler(event, context):
    name = event.get('name', 'World')
    return {
        'statusCode': 200,
        'body': json.dumps(f'Hello, {name}!')
    }

Triggery Lambda:

Trigger Użycie
API Gateway REST/HTTP APIs
S3 File processing
SQS Queue processing
EventBridge Scheduled, events
DynamoDB Streams DB changes
Kinesis Real-time streaming
SNS Notifications

Lambda vs EC2:

Cecha Lambda EC2
Max duration 15 min Unlimited
Scaling Automatic (1000 concurrent) Manual/ASG
Cold start ~100ms-seconds N/A
Pricing Per request + duration Per hour
Management Zero OS, patching 
# Deploy with AWS CLI
aws lambda create-function \
  --function-name my-function \
  --runtime python3.11 \
  --handler index.handler \
  --role arn:aws:iam::123456:role/lambda-role \
  --zip-file fileb://function.zip

# Invoke
aws lambda invoke \
  --function-name my-function \
  --payload '{"name": "Jan"}' \
  response.json

Co to jest cold start i jak go zminimalizować?

Odpowiedź w 30 sekund: Cold start to czas inicjalizacji Lambda gdy nie ma "ciepłej" instancji - może trwać 100ms do kilku sekund (szczególnie VPC, Java). Minimalizacja: Provisioned Concurrency, mniejsze pakiety, lżejsze runtime (Python, Node vs Java), keep Lambda warm.

Odpowiedź w 2 minuty:

Cold start występuje gdy Lambda musi zainicjalizować nowy kontener wykonawczy. Proces składa się z kilku etapów:

Cold Start:
1. Download code
2. Start container
3. Initialize runtime
4. Run init code (outside handler)
5. Execute handler

Warm Start:
1. Execute handler (kontener już gotowy)

Optymalizacja:

Technika Efekt Koszt
Provisioned Concurrency Eliminuje cold starts $$$
Smaller package Szybszy download Free
Python/Node vs Java Szybszy runtime init Free
Init code optimization Szybszy init Free
SnapStart (Java) Checkpoint/restore Free 
# Provisioned Concurrency
ProvisionedConcurrencyConfig:
  FunctionName: my-function
  Qualifier: prod
  ProvisionedConcurrentExecutions: 10

# Lub auto-scaling provisioned
ApplicationAutoScaling:
  ScalableDimension: lambda:function:ProvisionedConcurrency
  MinCapacity: 5
  MaxCapacity: 100
# Optymalizacja - init poza handlerem
import boto3

# To wykonuje się RAZ (cold start)
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('my-table')

def handler(event, context):
    # To wykonuje się przy każdym wywołaniu
    return table.get_item(Key={'id': event['id']})

EKS i Kontenery Pytania

Czym różni się ECS od EKS?

Odpowiedź w 30 sekund: ECS (Elastic Container Service) to własny orchestrator AWS - prostszy, głęboka integracja z AWS. EKS (Elastic Kubernetes Service) to managed Kubernetes - dla teamów znających K8s, portability, bogaty ekosystem. Oba mogą używać Fargate (serverless) lub EC2.

Odpowiedź w 2 minuty:

ECS i EKS różnią się podejściem do orkiestracji kontenerów - pierwszy to własne rozwiązanie AWS, drugi to managed Kubernetes:

Cecha ECS EKS
Orchestrator Własny AWS Kubernetes
Learning curve Łatwiejszy Stroma (K8s knowledge)
Portability AWS only Multi-cloud
Ekosystem AWS native K8s ecosystem (Helm, etc.)
Pricing Free (płacisz za compute) $0.10/hr per cluster + compute
IAM integration Native IRSA (IAM Roles for Service Accounts) 
ECS Architecture:
┌─────────────────────────────────────┐
│             ECS Cluster             │
├─────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐   │
│  │   Service   │  │   Service   │   │
│  │  (3 tasks)  │  │  (2 tasks)  │   │
│  └─────────────┘  └─────────────┘   │
├─────────────────────────────────────┤
│    Fargate    │        EC2          │
│   (serverless)│    (self-managed)   │
└─────────────────────────────────────┘

EKS Architecture:
┌─────────────────────────────────────┐
│         EKS Control Plane           │
│   (managed by AWS - $0.10/hr)       │
├─────────────────────────────────────┤
│  ┌─────────────┐  ┌─────────────┐   │
│  │ Deployment  │  │ Deployment  │   │
│  │  (3 pods)   │  │  (2 pods)   │   │
│  └─────────────┘  └─────────────┘   │
├─────────────────────────────────────┤
│ Fargate Nodes │   EC2 Node Group    │
└─────────────────────────────────────┘

Kiedy co:

  • ECS - prostsze deployments, AWS-only, mniejszy team
  • EKS - K8s expertise, multi-cloud strategy, complex workloads

Infrastructure as Code Pytania

Czym jest Terraform i jak go używać z AWS?

Odpowiedź w 30 sekund: Terraform to IaC tool od HashiCorp - definiujesz infrastrukturę w HCL, Terraform tworzy/aktualizuje zasoby. State file śledzi co istnieje. Multi-cloud (AWS, Azure, GCP). CloudFormation to AWS-native alternative.

Odpowiedź w 2 minuty:

Terraform używa deklaratywnego języka HCL do definiowania infrastruktury. Przykład kompletnej konfiguracji z providerem AWS:

# provider.tf
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "eu-west-1"
  }
}

provider "aws" {
  region = "eu-west-1"
}

# main.tf
resource "aws_instance" "web" {
  ami           = "ami-123456"
  instance_type = "t3.medium"
  subnet_id     = aws_subnet.public.id

  tags = {
    Name = "web-server"
  }
}

resource "aws_security_group" "web" {
  vpc_id = aws_vpc.main.id

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

# outputs.tf
output "instance_ip" {
  value = aws_instance.web.public_ip
}
# Terraform workflow
terraform init      # Download providers, init backend
terraform plan      # Preview changes
terraform apply     # Apply changes
terraform destroy   # Remove everything

# State management
terraform state list
terraform state show aws_instance.web
terraform import aws_instance.web i-1234567890

Terraform vs CloudFormation

Odpowiedź w 30 sekund: Terraform: multi-cloud, HCL syntax, state management, rich ecosystem. CloudFormation: AWS-native, YAML/JSON, no state file (AWS manages), deep AWS integration (StackSets, drift detection). Terraform bardziej popularny, CloudFormation jeśli AWS-only.

Odpowiedź w 2 minuty:

Terraform i CloudFormation to dwa najpopularniejsze narzędzia IaC dla AWS, różniące się zakresem wsparcia i filozofią działania:

Cecha Terraform CloudFormation
Provider Multi-cloud AWS only
Language HCL YAML/JSON
State Local/Remote (S3) AWS managed
Modules Terraform Registry Nested Stacks, Modules
Drift detection terraform plan CloudFormation Drift
Rollback Manual Automatic
Learning curve Moderate Moderate 
# CloudFormation equivalent
AWSTemplateFormatVersion: '2010-09-09'
Resources:
  WebServer:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: ami-123456
      InstanceType: t3.medium
      SubnetId: !Ref PublicSubnet
      Tags:
        - Key: Name
          Value: web-server

Outputs:
  InstanceIP:
    Value: !GetAtt WebServer.PublicIp

Kiedy co:

  • Terraform - multi-cloud, existing Terraform expertise
  • CloudFormation - AWS-only, native integrations, CDK

Monitoring i Logging Pytania

Jak działa CloudWatch?

Odpowiedź w 30 sekund: CloudWatch to monitoring platform AWS - Metrics (CPU, Network), Logs (app logs), Alarms (notifications), Dashboards (visualization). Zbiera metryki z AWS services automatycznie. Custom metrics przez API. Alarms integrują z SNS, Lambda, Auto Scaling.

Odpowiedź w 2 minuty:

CloudWatch zbiera metryki, logi i konfiguruje alarmy dla wszystkich usług AWS. Przykłady użycia przez AWS CLI:

# Custom metric
aws cloudwatch put-metric-data \
  --namespace "MyApp" \
  --metric-name "RequestCount" \
  --value 1 \
  --dimensions Environment=prod,Service=api

# Alarm
aws cloudwatch put-metric-alarm \
  --alarm-name "High-CPU" \
  --metric-name CPUUtilization \
  --namespace AWS/EC2 \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:eu-west-1:123456:alerts

# Log group with retention
aws logs create-log-group --log-group-name /my-app/prod
aws logs put-retention-policy \
  --log-group-name /my-app/prod \
  --retention-in-days 30

CloudWatch components:

Component Funkcja Przykład
Metrics Dane numeryczne CPUUtilization, RequestCount
Logs Log data Application logs, VPC Flow Logs
Alarms Alerting High CPU → SNS → PagerDuty
Dashboards Visualization Custom dashboards
Events/EventBridge Event routing Scheduled tasks, event patterns
Insights Log analysis Query logs with SQL-like syntax 
-- CloudWatch Logs Insights
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

Powiązane Artykuły

Ten artykuł jest częścią serii przygotowującej do rozmów rekrutacyjnych na stanowisko DevOps Engineer i Cloud Engineer. Opanuj AWS i inne technologie cloud z naszymi fiszkami do nauki.

Autor

Autor

Zespół Flipcards

Ponad 15 lat doświadczenia w branży IT i setki przeprowadzonych rozmów technicznych w firmach takich jak BNY Mellon, UBS i wiodących fintechach.

Chcesz więcej pytań rekrutacyjnych?

To tylko jeden temat z naszego kompletnego przewodnika po rozmowach rekrutacyjnych. Uzyskaj dostęp do 800+ pytań z 13 technologii.

Kup pełny dostęp Zobacz bezpłatny podgląd
Powrót do blogu

Zostaw komentarz

Pamiętaj, że komentarze muszą zostać zatwierdzone przed ich opublikowaniem.