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

Azure to druga największa platforma chmurowa na świecie i domyślny wybór dla wielu przedsiębiorstw, szczególnie tych z inwestycjami w ekosystem Microsoft. Jeśli aplikujesz do firmy używającej .NET, Office 365 lub dowolnego stacku Microsoft, możesz spodziewać się pytań o Azure.

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

Spis treści

• Podstawy Azure
• Compute - VMs, App Service, Functions
• Identity - Azure AD (Entra ID)
• Networking - VNet
• Storage i bazy danych
• Kontenery - AKS
• Infrastructure as Code
• Monitoring i observability
• 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 Azure

Jak Azure organizuje zasoby?

Odpowiedź w 30 sekund:

Azure ma hierarchiczną strukturę: Tenant (Azure AD) → Management Groups → Subscriptions → Resource Groups → Resources. Subscription to granica billingowa i dostępu, Resource Group to logiczny kontener dla zasobów o wspólnym cyklu życia.

Odpowiedź w 2 minuty:

Zrozumienie hierarchii zasobów Azure jest fundamentalne - rekruterzy często zaczynają od tego pytania, żeby sprawdzić czy rozumiesz podstawy organizacji chmury Microsoft:

Tenant (Azure AD / Entra ID)
└── Management Groups (opcjonalne)
    └── Subscriptions
        └── Resource Groups
            └── Resources

Tenant to instancja Azure AD twojej organizacji. Jeden tenant może mieć wiele subscriptions.

Management Groups to opcjonalne kontenery do organizacji subscriptions. Pozwalają stosować polityki i RBAC na dużą skalę.

Subscription to granica billingowa i dostępu. Zasoby w różnych subscriptions są domyślnie izolowane.

Resource Group to logiczny kontener dla zasobów, które mają wspólny cykl życia. Każdy zasób musi należeć do dokładnie jednej Resource Group.

Klasyczne pytanie rekrutacyjne: "Co się stanie gdy usuniesz Resource Group?"

Wszystkie zasoby w grupie zostaną usunięte. Resource Groups są kontenerami cyklu życia - mają zawierać zasoby, które powinny być tworzone i usuwane razem. Ostrożnie z produkcyjnymi Resource Groups.

Czym są Regiony i Availability Zones?

Odpowiedź w 30 sekund:

Region to geograficzna lokalizacja z jednym lub więcej data centers (np. West Europe, Poland Central). Availability Zone to fizycznie oddzielne data center w regionie z niezależnym zasilaniem i siecią. Nie wszystkie regiony mają AZ.

Odpowiedź w 2 minuty:

Azure, podobnie jak AWS, dzieli swoją infrastrukturę na regiony i strefy dostępności, ale z kilkoma istotnymi różnicami:

Paired Regions - to koncept specyficzny dla Azure. Niektóre usługi automatycznie replikują do sparowanego regionu:

Pytanie rekrutacyjne: "Jak zapewnić high availability w Azure?"

Wdrażaj w wielu Availability Zones w ramach regionu dla HA. Dla disaster recovery replikuj do sparowanego regionu. Używaj usług zone-redundant gdzie dostępne (Zone-Redundant Storage, zone-redundant AKS).

Co to jest Azure Resource Manager (ARM)?

Odpowiedź w 30 sekund:

ARM to warstwa deploymentu i zarządzania Azure. Każda operacja Azure przechodzi przez ARM - Portal, CLI, PowerShell, SDK. ARM autentykuje przez Azure AD, autoryzuje przez RBAC i wykonuje operacje. Umożliwia też Infrastructure as Code przez ARM templates lub Bicep.

Odpowiedź w 2 minuty:

ARM jest centralnym punktem sterowania dla wszystkich zasobów Azure. Zrozumienie jak działa jest kluczowe dla każdego DevOps engineera:

ARM Templates to Infrastructure as Code w formacie JSON:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [{
    "type": "Microsoft.Storage/storageAccounts",
    "apiVersion": "2021-02-01",
    "name": "mystorageaccount",
    "location": "[resourceGroup().location]",
    "sku": {"name": "Standard_LRS"},
    "kind": "StorageV2"
  }]
}

Bicep to nowszy, czystszy DSL który kompiluje się do ARM templates:

resource storage 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name: 'mystorageaccount'
  location: resourceGroup().location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

Bicep jest rekomendowany przez Microsoft dla nowych projektów IaC - jest znacznie czytelniejszy niż surowy JSON ARM templates.

Compute - VMs, App Service, Functions

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

Jakie są typy Virtual Machines w Azure?

Odpowiedź w 30 sekund:

Azure VMs mają serie zoptymalizowane pod różne workloady: B (burstable), D (general purpose), E (memory optimized), F (compute optimized), N (GPU). Nazwa jak Standard_D4s_v3 oznacza serię, rozmiar i generację.

Odpowiedź w 2 minuty:

Typy VM w Azure są podzielone na serie, podobnie jak w AWS, ale z inną konwencją nazewnictwa:

Konwencja nazewnictwa:

Standard_D4s_v3
│       │││  └── Wersja (generacja)
│       ││└──── v = Premium storage
│       │└───── s = Premium storage capable
│       └────── Rozmiar (liczba vCPU)
└────────────── Seria

Opcje dostępności:

Pytanie rekrutacyjne: "Kiedy użyć Availability Set vs Availability Zones?"

Availability Zones zapewniają wyższą dostępność (oddzielne data centers), ale nie wszystkie regiony je wspierają. Availability Sets działają we wszystkich regionach i chronią przed awariami na poziomie rack. Używaj Zones dla produkcji gdy dostępne, Sets jako fallback.

Czym jest App Service i kiedy go używać?

Odpowiedź w 30 sekund:

App Service to w pełni zarządzana platforma PaaS dla aplikacji webowych, API i mobile backends. Deployment slots dla zero-downtime deployments, autoskalowanie, custom domains, managed identity. Idealne gdy nie potrzebujesz kontroli nad OS.

Odpowiedź w 2 minuty:

App Service to najpopularniejsza opcja hostowania aplikacji webowych w Azure. Oferuje balans między prostotą a funkcjonalnością:

App Service Plans - zasoby compute na których działają aplikacje:

Kluczowe funkcje:

• Deployment slots - staging environments z możliwością swap
• Auto-scaling - skalowanie na podstawie metryk lub harmonogramu
• Custom domains i SSL - wbudowane zarządzanie certyfikatami
• Managed Identity - bezpieczny dostęp do usług Azure

Klasyczne pytanie rekrutacyjne: "Jak osiągnąć zero-downtime deployment w App Service?"

Używaj deployment slots. Deploy do staging slot, rozgrzej aplikację, następnie swap z produkcją. Swap jest natychmiastowy (tylko zmiana DNS/routing). Jeśli pojawią się problemy, swap z powrotem natychmiast.

# Deploy do staging
az webapp deployment source config-zip \
  --resource-group myRG \
  --name myApp \
  --slot staging \
  --src app.zip

# Swap staging z produkcją
az webapp deployment slot swap \
  --resource-group myRG \
  --name myApp \
  --slot staging \
  --target-slot production

Czym są Azure Functions i kiedy ich używać?

Odpowiedź w 30 sekund:

Azure Functions to serverless compute - event-driven, płatność za wykonanie. Triggery: HTTP, Timer, Blob, Queue, Event Hub, Cosmos DB. Hosting plans: Consumption (auto-scale do 0), Premium (pre-warmed, VNet), Dedicated (App Service Plan).

Odpowiedź w 2 minuty:

Functions to odpowiednik AWS Lambda w Azure. Idealne dla krótkich, event-driven zadań:

Hosting plans:

Triggery i Bindings:

Triggery definiują co uruchamia funkcję, bindings to deklaratywne połączenia z źródłami danych:

[FunctionName("ProcessOrder")]
public static void Run(
    [QueueTrigger("orders")] Order order,           // Trigger: wiadomość z kolejki
    [CosmosDB("db", "processed")] out dynamic doc)   // Output binding: zapis do Cosmos
{
    doc = new { id = order.Id, processed = DateTime.UtcNow };
}

Drzewo decyzyjne - który compute wybrać?

Rekruterzy często pytają o wybór między różnymi opcjami compute. Ten diagram pomoże ci szybko odpowiedzieć:

Identity - Azure AD (Entra ID)

Identity jest centralnym elementem Azure. Praktycznie wszystko autentykuje przez Azure AD.

Czym różni się Azure AD od tradycyjnego Active Directory?

Odpowiedź w 30 sekund:

To zupełnie inne usługi. Tradycyjny AD to on-premises directory service używający LDAP i Kerberos dla domen Windows. Azure AD (teraz Entra ID) to chmurowa platforma tożsamości używająca REST API, OAuth 2.0, SAML, OpenID Connect dla aplikacji chmurowych i SaaS.

Odpowiedź w 2 minuty:

To jedno z najczęstszych pytań na rozmowach Azure. Kandydaci często mylą te dwie usługi:

Azure AD NIE jest AD w chmurze - to inna usługa zaprojektowana dla nowoczesnych wzorców autentykacji. Możesz synchronizować on-premises AD do Azure AD używając Azure AD Connect, ale to nadal dwie oddzielne usługi.

Co to jest Managed Identity i jak jej używać?

Odpowiedź w 30 sekund:

Managed Identity to automatycznie zarządzana tożsamość dla usług Azure w Azure AD. Brak credentials w kodzie - Azure obsługuje rotację. System-assigned jest powiązana z jednym zasobem i usuwana razem z nim. User-assigned jest niezależna i może być współdzielona.

Odpowiedź w 2 minuty:

Managed Identity rozwiązuje klasyczny problem "jak bezpiecznie przechowywać credentials" - po prostu ich nie ma:

Klasyczne pytanie rekrutacyjne: "Jak Azure Function powinien bezpiecznie dostać się do Key Vault?"

Użyj Managed Identity. Włącz system-assigned identity na Function, nadaj jej dostęp do Key Vault secrets przez RBAC lub access policy. Brak credentials w kodzie - tylko referencja do Key Vault w konfiguracji:

// Brak credentials - używa Managed Identity
var client = new SecretClient(
    new Uri("https://myvault.vault.azure.net/"),
    new DefaultAzureCredential());  // Automatycznie wykrywa Managed Identity

var secret = await client.GetSecretAsync("my-secret");

# Włączenie Managed Identity na Function App
az functionapp identity assign \
  --resource-group myRG \
  --name myFunctionApp

# Nadanie dostępu do Key Vault
az keyvault set-policy \
  --name myKeyVault \
  --object-id <identity-principal-id> \
  --secret-permissions get list

Jak działa RBAC w Azure?

Odpowiedź w 30 sekund:

Azure RBAC kontroluje kto może co robić na jakich zasobach. Komponenty: Security Principal (kto - user, group, service principal), Role Definition (co może - Reader, Contributor, Owner), Scope (gdzie - management group, subscription, resource group, resource).

Odpowiedź w 2 minuty:

RBAC w Azure działa na trzech elementach, które razem tworzą Role Assignment:

Wbudowane role:

Pytanie rekrutacyjne: "Developer potrzebuje deployować do App Service ale nie powinien mieć dostępu do produkcyjnej bazy danych. Jak to zrobić?"

Utwórz custom role lub użyj wbudowanej "Website Contributor" role scoped do Resource Group z App Service. Nie nadawaj dostępu na poziomie subscription. Zasada least privilege.

# Przypisanie roli na poziomie Resource Group
az role assignment create \
  --assignee developer@company.com \
  --role "Website Contributor" \
  --resource-group app-service-rg

Networking - VNet

Virtual Networks (VNet) to fundament networkingu Azure. Każdy VM, App Service (isolated tier) i AKS cluster działa wewnątrz VNet.

Jakie są komponenty VNet?

Odpowiedź w 30 sekund:

VNet to izolowana sieć w Azure z zdefiniowaną przestrzenią adresową (CIDR). Subnet to zakres w VNet gdzie deployujesz zasoby. NSG (Network Security Group) to stanowy firewall na poziomie subnetu lub NIC z regułami allow/deny.

Odpowiedź w 2 minuty:

Podstawowa architektura VNet wygląda następująco - to klasyczny trójwarstwowy model z izolacją przez NSG:

VNet: 10.0.0.0/16
├── Subnet: web-tier (10.0.1.0/24)
│   └── NSG: allow 80, 443 from internet
├── Subnet: app-tier (10.0.2.0/24)
│   └── NSG: allow from web-tier only
└── Subnet: data-tier (10.0.3.0/24)
    └── NSG: allow from app-tier only

NSG Rules mają priorytet (niższy = ważniejszy) i składają się z:

• Source/Destination (IP, CIDR, Service Tag, ASG)
• Protocol (TCP, UDP, *)
• Port range
• Action (Allow/Deny)

# Utworzenie NSG z regułą
az network nsg create --name web-nsg --resource-group myRG

az network nsg rule create \
  --nsg-name web-nsg \
  --resource-group myRG \
  --name allow-https \
  --priority 100 \
  --source-address-prefixes Internet \
  --destination-port-ranges 443 \
  --protocol Tcp \
  --access Allow

Czym różni się NSG od Azure Firewall?

Odpowiedź w 30 sekund:

NSG to darmowy, stanowy filtr pakietów L3/L4 na poziomie subnetu lub NIC - podstawowe reguły allow/deny. Azure Firewall to płatna, zarządzana usługa z filtrowaniem L7, threat intelligence, FQDN filtering i centralnym logowaniem. NSG dla microsegmentacji, Azure Firewall dla enterprise security.

Odpowiedź w 2 minuty:

To pytanie pojawia się prawie na każdej rozmowie dotyczącej networkingu Azure:

Pytanie rekrutacyjne: "Kiedy użyjesz Azure Firewall zamiast NSG?"

Gdy potrzebujesz centralnego logowania, filtrowania FQDN (allow *.microsoft.com), threat intelligence lub inspekcji na poziomie aplikacji. NSG wystarczą dla podstawowej segmentacji sieci; Azure Firewall dodaje funkcje enterprise security.

Jakie są opcje łączności w Azure?

Odpowiedź w 30 sekund:

VNet Peering łączy VNets (same lub różne regiony/subscriptions). VPN Gateway to szyfrowane połączenie przez internet do on-premises. ExpressRoute to prywatne, dedykowane połączenie do on-premises. Private Endpoint daje prywatny IP dla usług PaaS w twoim VNet.

Odpowiedź w 2 minuty:

Azure oferuje różne metody łączności w zależności od scenariusza:

Private Endpoints vs Service Endpoints - to częste pytanie:

Service Endpoints włączają bezpośrednią trasę z VNet do usług Azure. Ruch zostaje w backbone Azure, ale usługa nadal ma publiczny endpoint.

Private Endpoints tworzą prywatny IP w twoim VNet dla usługi Azure. Usługa jest dostępna tylko przez ten prywatny IP. Bezpieczniejsze ale bardziej złożone.

Pytanie rekrutacyjne: "Jak zapewnić, że ruch do Azure SQL nigdy nie przechodzi przez publiczny internet?"

Użyj Private Endpoint. Tworzy prywatny IP w twoim VNet dla SQL server. Wyłącz publiczny dostęp na SQL server. Ruch między VNet a SQL zostaje całkowicie w sieci Azure.

# Utworzenie Private Endpoint dla Azure SQL
az network private-endpoint create \
  --name sql-private-endpoint \
  --resource-group myRG \
  --vnet-name myVNet \
  --subnet data-subnet \
  --private-connection-resource-id <sql-server-id> \
  --group-id sqlServer \
  --connection-name sql-connection

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

Storage i bazy danych

Azure oferuje różne opcje storage i baz danych. Znajomość kiedy używać której jest kluczowa.

Jakie są typy Azure Storage?

Odpowiedź w 30 sekund:

Storage Account zapewnia dostęp do: Blob Storage (object storage dla nieustrukturyzowanych danych), File Storage (SMB file shares), Queue Storage (kolejki wiadomości), Table Storage (NoSQL key-value). Blob ma tiery: Hot, Cool, Archive z różnym kosztem storage vs access.

Odpowiedź w 2 minuty:

Storage Account to kontener dla różnych usług storage:

Blob Access Tiers:

Redundancy Options:

Czym jest Cosmos DB i jakie ma consistency levels?

Odpowiedź w 30 sekund:

Cosmos DB to globalnie dystrybuowana, multi-model baza NoSQL. Wspiera API: SQL, MongoDB, Cassandra, Gremlin, Table. Kluczowa cecha: 5 tuneable consistency levels od Strong (najsilniejsza) przez Session (domyślna) do Eventual (najsłabsza). Silniejsza consistency = wyższe latency.

Odpowiedź w 2 minuty:

Cosmos DB wyróżnia się możliwością wyboru poziomu consistency - to unikalna cecha często pytana na rozmowach:

Consistency Levels (od najsilniejszego do najsłabszego):

Pytanie rekrutacyjne: "Kiedy wybrałbyś Strong consistency w Cosmos DB?"

Gdy absolutnie nie możesz odczytać stale data - transakcje finansowe, systemy inventory gdzie overselling jest kosztowny. Strong consistency ogranicza do single-region writes i dodaje latency. Większość aplikacji działa dobrze z Session consistency (domyślne).

Partitioning - wybierz partition key który równomiernie dystrybuuje dane i pasuje do wzorców zapytań. Zły partition key = hot partitions = throttling.

Kiedy Azure SQL vs Cosmos DB?

Odpowiedź w 30 sekund:

Azure SQL dla relacyjnych danych z ACID, złożonymi query i joinami, pionowym skalowaniem. Cosmos DB dla dokumentów/key-value z flexible schema, globalną dystrybucją, poziomym skalowaniem. SQL gdy potrzebujesz transakcji i complex queries, Cosmos gdy potrzebujesz scale i global reach.

Odpowiedź w 2 minuty:

To częste pytanie porównawcze - rekruterzy chcą sprawdzić czy rozumiesz trade-offs:

Azure SQL opcje:

Pytanie rekrutacyjne: "Kiedy użyjesz SQL Managed Instance zamiast Azure SQL Database?"

Gdy potrzebujesz funkcji pełnego SQL Server: cross-database queries, SQL Agent, CLR, Service Broker. Managed Instance zapewnia prawie pełną kompatybilność z SQL Server dla migracji lift-and-shift.

Kontenery - AKS

Azure Kubernetes Service (AKS) to managed Kubernetes. Azure zarządza control plane, ty zarządzasz worker nodes.

Co Azure zarządza w AKS, a co ty?

Odpowiedź w 30 sekund:

Azure zarządza control plane: API server, etcd, scheduler, controller manager. Ty zarządzasz: worker nodes (VM scale sets), deployments aplikacji, konfiguracja node pools. Azure oferuje też integrację z Azure AD, networking i monitoring.

Odpowiedź w 2 minuty:

Podział odpowiedzialności w AKS jest kluczowy dla zrozumienia co musisz monitorować i zarządzać:

Co Azure zarządza:

• Control plane (API server, etcd, scheduler, controller manager)
• Upgrades i patching (opcjonalnie dla nodes)
• Integracja z Azure AD, networking, monitoring

Co ty zarządzasz:

• Worker nodes (VM scale sets)
• Deployments aplikacji
• Konfiguracja node pools

Node Pools - grupy nodes o tej samej konfiguracji:

AKS Cluster
├── System Node Pool (Linux, system pods)
├── User Node Pool 1 (Linux, general workloads)
└── User Node Pool 2 (Windows, .NET apps)

Jakie są opcje networkingu w AKS?

Odpowiedź w 30 sekund:

Kubenet: prosty networking, nodes dostają Azure VNet IPs, pods dostają IPs z innego range z NAT. Azure CNI: pods dostają IPs bezpośrednio z Azure VNet subnet. CNI wymagane dla Windows nodes i pełnej VNet integration.

Odpowiedź w 2 minuty:

Wybór modelu networkingu w AKS ma istotne implikacje:

Pytanie rekrutacyjne: "Jak bezpiecznie pullować images z ACR do AKS?"

Podłącz ACR do AKS używając managed identity. Uruchom az aks update --attach-acr <acr-name>. AKS dostaje rolę AcrPull automatycznie. Brak potrzeby image pull secrets.

# Podłączenie ACR do AKS
az aks update \
  --resource-group myRG \
  --name myAKS \
  --attach-acr myACR

Infrastructure as Code

IaC jest standardem w DevOps. Azure wspiera ARM templates, Bicep i Terraform.

ARM Templates vs Bicep vs Terraform - co wybrać?

Odpowiedź w 30 sekund:

ARM Templates to natywny format Azure (JSON) - verbose ale pełna kompatybilność. Bicep to DSL Microsoft który kompiluje do ARM - czystszy, rekomendowany dla nowych projektów Azure-only. Terraform to multi-cloud tool od HashiCorp - najlepszy dla środowisk hybrid/multi-cloud.

Odpowiedź w 2 minuty:

Wybór IaC tool zależy od kontekstu - rekruterzy często pytają o trade-offs:

Bicep - rekomendowany dla nowych projektów Azure:

// Znacznie czystszy niż ARM JSON
param location string = resourceGroup().location
param storageAccountName string

resource storage 'Microsoft.Storage/storageAccounts@2021-02-01' = {
  name: storageAccountName
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
}

output storageId string = storage.id

Terraform - dla multi-cloud lub gdy zespół już go zna:

provider "azurerm" {
  features {}
}

resource "azurerm_resource_group" "main" {
  name     = "my-rg"
  location = "West Europe"
}

resource "azurerm_storage_account" "main" {
  name                     = "mystorageaccount"
  resource_group_name      = azurerm_resource_group.main.name
  location                 = azurerm_resource_group.main.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

Monitoring i observability

Jakie są główne narzędzia monitoring w Azure?

Odpowiedź w 30 sekund:

Azure Monitor to centralna platforma - zbiera metrics i logs z wszystkich zasobów Azure. Application Insights to APM dla aplikacji (traces, dependencies, exceptions). Log Analytics to workspace dla logów z KQL query language. Azure Alerts dla powiadomień na podstawie metryk lub logów.

Odpowiedź w 2 minuty:

Azure ma zintegrowany stack monitoring - ważne jest zrozumienie jak komponenty współpracują:

Application Insights kluczowe funkcje:

• Distributed tracing (end-to-end request tracking)
• Dependency tracking (SQL, HTTP, Redis)
• Live metrics stream
• Smart detection (anomaly detection)
• Failure analysis

KQL (Kusto Query Language) - język zapytań dla Log Analytics:

// Błędy w ostatniej godzinie
requests
| where timestamp > ago(1h)
| where success == false
| summarize count() by resultCode, bin(timestamp, 5m)
| render timechart

// Wolne requesty
requests
| where duration > 1000
| project timestamp, name, duration, resultCode
| order by duration desc
| take 20

Porównanie Azure vs AWS

Jeśli masz doświadczenie z AWS, ta tabela pomoże ci szybko mapować usługi:

Scenariusze architektoniczne

Rekruterzy często pytają o design scenariuszy. Oto typowe pytania:

Zaprojektuj highly available web application na Azure

Rozwiązanie:

• App Service w wielu regionach lub VMs w Availability Zones
• Azure Front Door lub Traffic Manager dla global load balancing
• Azure SQL z geo-replication lub Cosmos DB dla bazy danych
• Blob Storage dla static assets, CDN dla caching
• Azure AD dla autentykacji
• Key Vault dla secrets, Managed Identity dla dostępu
• Application Insights dla monitoringu

Jak migrować on-premises .NET app do Azure?

Kroki:

1. Assess: Azure Migrate do discovery dependencies
2. Wybór target: App Service (najłatwiej), AKS (kontenery), VMs (lift-and-shift)
3. Database: SQL Managed Instance dla kompatybilności lub Azure SQL Database
4. Identity: Azure AD Connect do sync on-premises AD
5. Networking: VPN lub ExpressRoute dla hybrid connectivity
6. Migracja: Azure Site Recovery dla VMs lub deploy bezpośrednio dla App Service

Na co rekruterzy naprawdę zwracają uwagę

Zrozumienie hierarchii zasobów - Tenant, Subscription, Resource Group. Kandydaci którzy nie rozumieją podstaw organizacji Azure często mają problemy z bardziej zaawansowanymi tematami.

Identity jako fundament - Azure AD/Entra ID jest centralny dla wszystkiego. Managed Identity, RBAC, Conditional Access. Rekruterzy chcą wiedzieć, że rozumiesz jak bezpiecznie łączyć usługi.

Networking - VNet, subnety, NSG, Private Endpoints. Umiejętność projektowania bezpiecznej architektury sieciowej jest kluczowa dla DevOps/Cloud Engineer.

IaC - Znajomość przynajmniej jednego narzędzia (Bicep, Terraform). Rekruterzy cenią umiejętność automatyzacji infrastruktury.

Porównanie z AWS - Jeśli masz doświadczenie z AWS, pokaż że rozumiesz różnice i podobieństwa. To pokazuje dojrzałość i umiejętność adaptacji.

Zadania praktyczne

1. Utwórz VNet z trzema subnetami (web, app, data) i skonfiguruj NSG dla każdego z odpowiednimi regułami.
2. Wdróż App Service z deployment slots i przeprowadź blue-green deployment.
3. Skonfiguruj Managed Identity na Azure Function do bezpiecznego dostępu do Key Vault.
4. Napisz Bicep template który tworzy Storage Account z Private Endpoint.
5. Zaprojektuj architekturę dla e-commerce aplikacji z HA i DR wymaganiami.

Zobacz też

• AWS - Pytania Rekrutacyjne - porównanie z największym cloud provider
• Kubernetes - Pytania Rekrutacyjne - głębsze zanurzenie w AKS i K8s
• Docker - Pytania Rekrutacyjne - podstawy konteneryzacji
• CI/CD - Pytania Rekrutacyjne - Azure DevOps i GitHub Actions
• 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.