Jaké otázky na Terraform mohu u pohovoru očekávat?

Většina pohovorů o Terraformu začíná pracovním postupem a rychle přechází k tomu, co se děje pod povrchem. Buďte připraveni bez poznámek popsat celý životní cyklus: terraform init stáhne poskytovatele a nakonfiguruje backend; terraform plan porovná požadovanou konfiguraci se souborem stavu a skutečnými prostředky a poté vypíše akce, které by provedl; terraform apply tento plán vykoná; terraform destroy odstraní vše, co konfigurace spravuje. První doplňující otázka se téměř vždy týká toho, proč jsou plan a apply oddělené kroky. Odpovědí je kontrola a bezpečnost: plán lze před jakoukoli změnou zkontrolovat, schválit a uložit.

• Poskytovatelé. Pluginy komunikující s API, například AWS, Azure, Google Cloud nebo Kubernetes. Doplňující otázka: proč pevně nastavit verze poskytovatelů?
• Prostředky a datové zdroje. Prostředky jsou objekty, které Terraform vytváří a spravuje; datové zdroje načítají existující objekty, jež nespravuje.
• Proměnné, lokální hodnoty a výstupy. Vstupy, vypočtené hodnoty a exportované hodnoty. Doplňující otázka: jak zabráníte zobrazení tajného údaje ve výstupu plánu?
• Graf závislostí. Terraform určuje pořadí operací podle odkazů mezi prostředky; depends_on slouží pro závislosti, které graf nedokáže rozpoznat.

V odpovědi uveďte, co každý příkaz čte a zapisuje. Kandidáti, kteří řeknou, že plan pouze čte, zatímco apply mění infrastrukturu i stav, již prokázali, že modelu rozumějí.

Víte, že stav je důležitý, a tušíte, že se hodnotitel pokusí najít hranice vašich znalostí. To je pochopitelné, proto tato část probírá otázky, které k této hranici míří, i to, co má úplná odpověď obsahovat.

• Kde je stav uložen a proč ne lokálně? Vzdálený backend, například kontejner objektového úložiště, Terraform Cloud nebo databáze, poskytuje sdílený zdroj pravdy. Doplňující otázka se týká zamykání: kdyby apply spustili současně dva lidé, mohli by stav poškodit, takže backendy podporující zámky druhé spuštění odmítnou.
• Co obsahuje soubor stavu? Atributy prostředků včetně hodnot, které můžete považovat za citlivé. Uveďte, že se stavem je nutné zacházet jako s tajným materiálem, šifrovat jej v klidovém stavu a řídit k němu přístup.
• Moduly. Modul je opakovaně použitelná sada prostředků s vlastními vstupy a výstupy. Hodnotitelé se ptají, jak verzujete moduly, jak se vyhnete modulu, který se snaží dělat vše, a jak kořenový modul skládá podřízené moduly.
• Pracovní prostory versus samostatné konfigurace. Pracovní prostory poskytují jedné konfiguraci několik souborů stavu. Chybnou odpovědí je považovat je za úplné řešení prostředí; produkce si obvykle zaslouží vlastní konfiguraci, backend a přihlašovací údaje, nikoli pouhé přepnutí pracovního prostoru.
• Refaktorizace bez zničení. Po přejmenování prostředku ho chce Terraform zničit a znovu vytvořit. Měli byste vědět, že existují bloky moved a příkaz terraform state mv, a znát účel každého z nich.

Dobrou zásadou pro každou odpověď v této části je pojmenovat selhání, kterému daný postup předchází. Zamykání zabraňuje poškození souběžnými změnami, vzdálený stav zabraňuje rozdílům mezi notebooky a pevně nastavené verze zabraňují nečekané aktualizaci během běžného apply.

U pohovorů na seniorní pozice nahrazují definice konkrétní situace. Typický příklad: platformní inženýr při pohovoru na pozici v oblasti infrastruktury ve fintech společnosti dostane informaci, že někdo ručně změnil bezpečnostní skupinu v cloudové konzoli, následující plán ukazuje rozdíl, který nikdo neočekával, a tým se obává spustit apply. Silná odpověď označí situaci jako odchylku, vysvětlí, že ji plán již odhalil obnovením skutečného stavu, rozhodne, zda má být ruční změna zachována, nebo vrácena, a buď upraví konfiguraci podle reality, nebo pomocí apply obnoví deklarovaný stav. Hodnotitel poslouchá vaše rozhodnutí, nikoli příkaz.

Další opakující se scénáře: apply, které selhalo v polovině, a následná podoba stavu; prostředky vytvořené před zavedením Terraformu a jejich převzetí pod správu pomocí terraform import; tým několika inženýrů a uspořádání repozitářů, backendů a CI tak, aby se plány spouštěly pro pull requesty a apply proběhlo jen jednou; tajné údaje v proměnných a vhodnější zdroj těchto údajů; aktualizace poskytovatele, která mění chování prostředku. V každém případě popište omezení, zvolte mechanismus a uveďte jeho náklady.

Dobře se na tyto otázky odpovídá snáze, pokud jste si odpovědi předem řekli nahlas. Režim simulovaného pohovoru nabízí scénářové otázky s doplňujícími dotazy a další sady otázek podle rolí a nástrojů najdete v části otázky k pohovoru podle role a tématu.

U konverzačních částí ano, ale s omezeními, která je vhodné jasně uvést. Nativní desktopová aplikace SubcueAI pro macOS a Windows zachycuje systémový zvuk i váš mikrofon a zobrazuje stručné návrhy v místním překryvném okně. Když se tedy hodnotitel zeptá, čemu zamykání stavu brání, máte mechanismus před sebou a můžete jej vysvětlit. Postranní panel rozšíření prohlížeče dělá totéž pro hovory na kartě prohlížeče v Chrome nebo Edge a zachycuje pouze zvuk karty se schůzkou. K hovoru se nepřipojuje žádný bot a do stránky schůzky se nic nevkládá; postup nastavení najdete na stránce s návodem.

Kdy nepomůže: při hlídaném testu, nahrávání obrazovky, na notebooku spravovaném společností nebo při praktickém úkolu, během něhož pod dohledem píšete HCL. Aaron Cao, zakladatel SubcueAI, popisuje cíl návrhu jako nápovědu k tomu, co už znáte, nikoli jako náhradu znalostí. Asistent proto vychází z vašeho životopisu a vašeho vlastního způsobu vyjadřování. Jasné hranice použití popisuje soubor témat o zjistitelnosti.