Модуль 0.1: Огляд іспиту KCNA

Складність: [ШВИДКИЙ] — базова орієнтація.

Час на проходження: 35–50 хвилин.

Передумови: немає — це ваша відправна точка!

Результати навчання

Після завершення цього модуля ви зможете пов’язати огляд іспиту з конкретними рішеннями щодо навчання, а не сприймати KCNA як розпливчастий значок для початківців:

Оцінити, чи є KCNA правильною сертифікаційною ціллю для вашої поточної ролі, навчального бюджету та досвіду роботи з Kubernetes.
Порівняти формат іспиту KCNA з CKA, CKAD, CKS та KCSA, щоб обрати відповідну тактику підготовки.
Спроєктувати зважений навчальний план, який зіставляє основи Kubernetes, оркестрацію, архітектуру, спостережуваність та теми доставки з вашими власними прогалинами у знаннях.
Діагностувати хибні поради щодо підготовки до KCNA, відокремлюючи концептуальну готовність до іспиту від навичок адміністрування виробничих систем.
Впровадити особистий робочий процес відстеження, який використовує офіційну програму іспиту, ландшафт CNCF та модулі KubeDojo без надмірної прив’язки до застарілих матеріалів.

Чому цей модуль важливий

Гіпотетичний сценарій: Команда завершує поспішну міграцію на Kubernetes і очікує, що наступний аудит буде рутинним. У платформенної команди є компетентні оператори кластера, але менеджери продукту, координатори релізів та провідні розробники застосунків ніколи не виробляли спільного словника для Подів, Сервісів, Деплойментів, просторів імен, спостережуваності чи GitOps. Звичайне заморожування релізу перетворюється на шестигодинний координаційний інцидент, тому що одна команда називає Сервіс «сервером», інша має на увазі «застосунок», а третя припускає, що перезапуск Деплойменту збереже кожну сесію в пам’яті. Втрачене вікно релізу, понаднормова робота підрядників та ескалація до служби підтримки клієнтів складаються в дорогий інцидент, хоча жоден окремий інженер не припускається драматичної технічної помилки.

Саме такий інцидент і є причиною існування KCNA. Він не покликаний довести, що ви можете врятувати виробничу площину управління опівночі, і не є заміною глибокої адміністраторської практики. Він підтверджує, чи можете ви міркувати про хмарну систему як про систему: чому існує Kubernetes, як пов’язані його основні ресурси, чому оркестрація змінює операційні звички та де вписуються інструменти екосистеми, такі як Prometheus, Helm, Fluentd, сервісні сітки (service mesh) та GitOps-контролери. Команди використовують цей фундамент, щоб зменшити вартість «перекладу» між собою, перш ніж інвестувати у вищі за ставками сертифікації чи виробничі обов’язки.

Цей модуль дає вам чітку карту, перш ніж ви почнете йти. Ви побачите, що вимірює KCNA, чого він не вимірює, чим іспит відрізняється від сертифікацій Kubernetes на основі практичних завдань, та як побудувати навчальний план, який поважає і офіційні матеріали, і структуру навчальної програми KubeDojo. Модуль використовує чинний офіційний поділ на п’ять доменів (чинний з листопада 2025 року), оскільки решта цього напрямку використовує його для побудови, водночас нагадуючи вам перевіряти офіційні сторінки Linux Foundation та CNCF перед записом на іспит, адже деталі сертифікації можуть змінюватися.

Що насправді перевіряє KCNA

KCNA розшифровується як Kubernetes and Cloud Native Associate, і важливе слово тут — Associate (асоційований фахівець). На цьому рівні іспит перевіряє, чи можете ви застосовувати основоположні ідеї до реалістичних ситуацій, а не чи можете ви виконати кожну операцію з кластером з пам’яті. Хороший кандидат на KCNA може пояснити, чому Деплоймент є кращою абстракцією, ніж «голий» Под для реплікованого вебзастосунку, чому Сервіс дає клієнтам стабільну ціль, тоді як Поди з’являються і зникають, і чому спостережуваність стає обов’язковою, коли запит проходить через кілька незалежно розгорнутих компонентів. Такому кандидату все ще може знадобитися інструкція (runbook), щоб налаштувати виробничий контроль допуску, і це прийнятно для цього посвідчення.

Початковий модуль подавав KCNA як вхідну точку на шляху сертифікації Kubernetes, і це формулювання залишається корисним. Наведена нижче діаграма збережена з попереднього уроку, оскільки вона відображає зв’язок між KCNA, професійними практичними іспитами та шляхом асоційованого фахівця з безпеки. Сприймайте її як карту сертифікацій, а не як гарантію того, що кожен іспит назавжди матиме однаковий стиль, період поновлення чи перелік доменів. Сертифікаційні програми змінюються, і офіційна сторінка іспиту завжди має пріоритет, коли ви ухвалюєте рішення про запис.

┌─────────────────────────────────────────────────────────────┐
│              KUBERNETES CERTIFICATION PATH                  │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  ENTRY LEVEL (Multiple Choice)                             │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  KCNA - Kubernetes and Cloud Native Associate       │   │
│  │  • Concepts and fundamentals                        │   │
│  │  • No hands-on required                             │   │
│  │  • Great starting point                             │   │
│  └─────────────────────────────────────────────────────┘   │
│                         │                                   │
│                         ▼                                   │
│  PROFESSIONAL LEVEL (Hands-On)                             │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐        │
│  │    CKA      │  │    CKAD     │  │    CKS      │        │
│  │ Administrator│  │  Developer  │  │  Security   │        │
│  └─────────────┘  └─────────────┘  └─────────────┘        │
│                                                             │
│  ALSO ENTRY LEVEL                                          │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  KCSA - Kubernetes and Cloud Native Security Assoc  │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Практичний наслідок полягає в тому, що підготовка до KCNA має відчуватися радше як вивчення карти, ніж як заучування клавіатурної послідовності. Ви маєте вміти оглянути сценарій і обрати концепцію Kubernetes, яка розв’язує заявлену проблему. Якщо команді потрібне стабільне внутрішнє виявлення сервісів, ви маєте подумати про Сервіс перш ніж про Інгрес. Якщо контейнер аварійно завершує роботу, а бізнес-вимога каже, що він повинен автоматично повертатися з кількома репліками, ви маєте подумати про Деплоймент, а не про окремий Под. Якщо менеджер запитує, чому важливий GitOps, ви маєте пов’язати декларативний бажаний стан, історію аудиту та відтворюване постачання, а не цитувати назву продукту.

Ця відмінність важлива, тому що багато тих, хто навчається, приходять з інших сертифікаційних культур. Деякі ІТ-іспити винагороджують ізольоване пригадування визначень, тоді як професійні іспити Kubernetes винагороджують швидке виконання команд на «живому» кластері. KCNA розташований між цими звичками. Це тест із вибором відповіді, але кращі запитання все одно вимагають прикладного міркування, виключення варіантів і розпізнавання компромісів. Склавши його, ви не доведете виробничих повноважень, проте можете використати його, щоб напрацювати словник, який робить подальше виробниче навчання набагато швидшим.

Інсайт від практика: В корпоративних середовищах KCNA виконує стратегічну операційну функцію. Команди платформенної інженерії часто використовують навчальну програму KCNA як обов’язкову базу для адаптації нетехнічних ролей (менеджерів продукту, технічних письменників, Agile-коучів). Коли міжфункціональні команди мають спільний словник, «податок на переклад» під час розборів інцидентів (post-mortem) та планування спринтів суттєво знижується.

Найбезпечніша ментальна модель — сприймати KCNA як контрольну точку готовності до розмов про хмарні технології. Він підтверджує, що ви можете обговорювати форму системи Kubernetes, не плутаючи межі кожного компонента. Він не підтверджує, що ви можете адмініструвати відновлення etcd, спроєктувати аварійне відновлення для кількох кластерів або налагодити несправний CNI-плагін під «живим» тиском. Це цінні навички, але вони належать до пізнішого етапу шляху, після того як основоположний словник перестане конкурувати за вашу увагу.

Формат іспиту та сертифікаційний контекст

Наведена нижче збережена таблиця підсумовує формат, яким зазвичай керуються ті, хто навчається, плануючи підготовку до KCNA. Оскільки програми іспитів еволюціонують, перевіряйте поточні деталі на офіційній сторінці Linux Foundation або CNCF перед купівлею чи записом. Для проєктування навчання сталі сигнали важливіші за точні адміністративні деталі: іспит онлайн, з наглядом, із вибором відповіді, орієнтований на початківців і зосереджений на концептуальній грамотності в хмарних технологіях, а не на «живому» виконанні команд.

Аспект	Деталі
Тривалість	90 хвилин
Запитання	~60 із вибором відповіді
Прохідний бал	75% (~45 правильних відповідей)
Формат	Онлайн з наглядом
Передумови	Немає
Термін дії	2 роки (3 роки, якщо здобуто до 1 квітня 2024 року)

Онлайн-формат із вибором відповіді змінює те, як ви готуєтеся. Вам потрібна достатня точність, щоб розрізняти схожі ресурси Kubernetes, але вам не потрібна швидкість реакції, якої вимагає практичний термінальний іспит. Питання KCNA може описувати робоче навантаження, яке має пережити перезапуски контейнерів і масштабуватися горизонтально, а потім запитати, який ресурс підходить. Вас перевіряють на те, чи можете ви зіставити вимогу з абстракцією Kubernetes. Вас не перевіряють на те, чи пам’ятаєте ви кожне поле в маніфесті Деплойменту apps/v1.

Наступне збережене порівняння — найважливіша таблиця в модулі для вибору тактики підготовки. KCNA винагороджує концептуальне розпізнавання та прикладний словник, тоді як CKA, CKAD і CKS винагороджують швидкість роботи з командами, редагування ресурсів та усунення несправностей під тиском часу. Якщо ви готуєтеся до KCNA, відточуючи лише термінальні вправи, ви здобудете корисні навички Kubernetes, але можете недостатньо підготуватися до широти екосистеми. Якщо ви готуєтеся до CKA, читаючи лише концептуальні нотатки, ви розпізнаватимете ідеї, але не зможете виконувати завдання достатньо швидко у «живому» середовищі.

Аспект	KCNA	CKA/CKAD/CKS
Формат	Вибір відповіді	Практичний CLI
Фокус	Концепції	Реалізація
Перевіряються навички	Розуміння	Виконання
Тиск часу	Помірний	Високий
Документація	Заборонена	Дозволена

Це також місце, де звичка до kubectl потребує нюансу. У пізніших модулях Kubernetes від KubeDojo ми вводимо скорочення для оболонки alias k=kubectl і використовуємо приклади на кшталт k get pods, тому що це віддзеркалює професійний іспит та поширену практику операторів. Для KCNA вам усе одно слід знати, для чого використовуються базові команди, але вашим першочерговим пріоритетом є розуміння моделі ресурсів, яку ці команди оглядають. Побачивши k get pods, ви маєте подумати «перелічити найменші розгортувані об’єкти робочого навантаження», а не лише за м’язовою пам’яттю набирати команду.

Зупиніться й передбачте: якщо практичне запитання описує команду, якій потрібна стабільна мережева ідентичність для змінного набору Подів, які два варіанти відповіді є найспокусливішими і яка деталь дозволила б вам виключити неправильний? Саме такий тип міркування винагороджує KCNA. Ви не намагаєтеся пригадати гасло. Ви шукаєте вимогу, приховану всередині сценарію, і зіставляєте її з ресурсом, який володіє цією відповідальністю.

Сертифікаційний контекст також впливає на те, як ви пояснюєте KCNA іншим. Менеджер з найму не повинен сприймати KCNA як доказ того, що людина може самотужки керувати виробничим кластером Kubernetes. Керівник платформи може сприймати його як свідчення того, що кандидат розуміє базову мову роботи з хмарними технологіями. Розробник може використати його як трамплін до CKAD. Той, хто вивчає безпеку, може порівняти його з KCSA й вирішити, що для нього актуальніше як наступний крок — широка грамотність в екосистемі чи специфічні для безпеки основи.

Щодо версіонування Kubernetes, цей напрямок орієнтується на Kubernetes 1.35 і новіші версії. Це не означає, що кожне запитання KCNA стосується функції, доступної лише в Kubernetes 1.35. Це означає, що приклади, термінологія та ментальні моделі мають узгоджуватися із сучасним Kubernetes, а не зі старими припущеннями епохи dockershim. Коли ви бачите, що сучасна документація говорить про Поди, Деплойменти, Сервіси, декларативні API, планування та робочі навантаження, ці концепції достатньо стабільні, щоб сформувати кістяк вашого навчального плану.

Домени, ваги та навчальна стратегія

Іспит KCNA використовує структуру з п’яти доменів, яка полегшує побудову навчального шляху: Kubernetes Fundamentals (основи Kubernetes), Container Orchestration (оркестрація контейнерів), Cloud Native Architecture (хмарна архітектура), Cloud Native Observability (хмарна спостережуваність) та Application Delivery (доставка застосунків). Оновлення навчальної програми набуло чинності 24 листопада 2025 року; наведена нижче діаграма ваг доменів відображає чинний офіційний план із вагами 46%, 22%, 16%, 8% та 8%. Використовуйте діаграму як допоміжний засіб планування KubeDojo і звіряйте її з офіційною програмою іспиту, коли записуєтеся на нього.

┌─────────────────────────────────────────────────────────────┐
│              KCNA DOMAIN WEIGHTS                            │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Kubernetes Fundamentals       ██████████████████████ 46%  │
│  Pods, Deployments, Services, Architecture                  │
│                                                             │
│  Container Orchestration       ██████████░░░░░░░░░░░ 22%   │
│  Scheduling, scaling, service discovery                     │
│                                                             │
│  Cloud Native Architecture     ████████░░░░░░░░░░░░░ 16%   │
│  Principles, CNCF, serverless                               │
│                                                             │
│  Cloud Native Observability    ████░░░░░░░░░░░░░░░░░ 8%    │
│  Monitoring, logging, Prometheus                            │
│                                                             │
│  Application Delivery          ████░░░░░░░░░░░░░░░░░ 8%    │
│  CI/CD, GitOps, Helm                                        │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Урок, що стоїть за старими вагами, залишається чинним навіть тоді, коли офіційний перелік доменів змінюється: основи та оркестрація домінують у вашій підготовці. Kubernetes — це багатошарова система, і верхні шари не мають сенсу, якщо ви не можете пояснити нижні. Запитання про спостережуваність, доставку, serverless та сервісні сітки часто припускають, що ви вже розумієте Поди, Сервіси, бажаний стан, планування та площину управління. Якщо ці терміни розмиті, ваші подальші відповіді перетворюються на здогадки.

У чинному офіційному поділі на п’ять доменів (чинному з листопада 2025 року) 68% іспиту припадає на два домени, тому раціональний навчальний план починається саме з них, перш ніж поширюватися на менші ділянки екосистеми:

Kubernetes Fundamentals (46%)
Container Orchestration (22%)

Опануйте їх — і ви пройдете більшу частину шляху, за умови, що ви все ж зарезервуєте достатньо часу, щоб зрозуміти, чому хмарна архітектура, спостережуваність та доставка з’являються в одній сертифікації.

Цей простий розрахунок має формувати ваш навчальний план, але не повинен робити його вузьким. Той, хто навчається і витрачає кожну годину на Поди та Деплойменти, може добре скласти основи, але все одно пропустити запитання про Prometheus, GitOps, Helm, хмарну архітектуру та ролі в екосистемі. Краща стратегія — зважена широта: витрачайте найбільше часу на основи та оркестрацію, а потім свідомо резервуйте час для менших доменів, щоб вони не перетворилися на безкоштовні втрати. Малі домени важливі, тому що прохідний бал залишає обмежений простір для необачних промахів.

Перш ніж запускати цей навчальний план, який результат ви очікуєте від власних оцінок упевненості? Якщо ви вже працюєте з CI/CD, але ніколи не пояснювали планування в Kubernetes, ваги можуть підказати вам вивчати оркестрацію перед доставкою. Якщо ви розробник, який розгортає на керованій платформі, але ніколи не бачить внутрішніх механізмів спостережуваності, менший домен спостережуваності може заслуговувати на більше уваги, ніж підказує його сирий відсоток. Правильний план поєднує вагу іспиту з особистими слабкими місцями, а не сприймає всіх, хто навчається, як однакових.

Чинні офіційні матеріали особливо важливі, тому що програма KCNA пройшла через оновлення. Оновлення навчальної програми в листопаді 2025 року встановило чинну структуру з п’яти доменів та ваги, відображені в цьому модулі. Сторонні навчальні посібники, опубліковані до цього оновлення, все ще можуть навчати корисних концепцій, але можуть використовувати застарілі назви доменів чи ваги, тож класифікуйте їх обережно. Використовуйте офіційну програму, щоб визначити покриття іспиту, використовуйте модулі KubeDojo, щоб будувати пояснення, та використовуйте практичні запитання, щоб перевірити, чи можете ви застосувати ці концепції під тиском сценарію.

Корисний цикл навчання має три проходи. По-перше, перегляньте офіційну програму й позначте кожен термін як знайомий, розпливчастий чи новий. По-друге, використовуйте модулі KubeDojo, щоб перетворити розпливчасті й нові терміни на робочі пояснення. По-третє, відповідайте на сценарні запитання й записуйте, чому неправильні відповіді є неправильними. Цей останній крок важливий, тому що успіх у тестах із вибором відповіді часто походить від виключення варіантів. Ви не просто обираєте Деплоймент; ви відкидаєте Под, бо йому бракує поведінки контролера, відкидаєте Сервіс, бо він розв’язує мережеві питання, і відкидаєте Інгрес, бо він керує зовнішньою маршрутизацією HTTP, а не життєвим циклом реплік.

Є ще одна причина вчитися через зв’язки, а не через ізольовані визначення: запитання KCNA часто стискають кілька шарів в один короткий сценарій. Запитання про невдалий реліз може включати ідентичність робочого навантаження, поведінку розгортання, виявлення сервісів та сигнали спостережуваності в одному абзаці. Якщо ви вивчили кожну тему як відірвану картку для запам’ятовування, ви можете розпізнати кожне слово й усе одно пропустити визначальну вимогу. Якщо ви вивчили зв’язки, ви можете запитати, яка частина системи володіє проблемою, а потім виключити відповіді поза цією межею володіння.

Наприклад, припустімо, сценарій каже, що команда може розгортати нові Поди, але клієнти іноді потрапляють на старі Поди, а іноді на нові під час розгортання. Це запитання, ймовірно, перевіряє ваше розуміння Сервісів, міток (labels), селекторів та механіки розгортання, а не вимагає сирої команди. Корисний навчальний хід — намалювати маршрут від клієнта до Сервісу до обраних Подів, а потім запитати, який об’єкт змінюється, коли Деплоймент створює новий ReplicaSet. Навіть якщо іспит ніколи не попросить вас намалювати цей маршрут, малювання тренує те саме міркування, яке вам потрібне, щоб обрати правильну відповідь.

Ви також маєте відокремлювати готовність до іспиту від готовності до роботи у вашому плані. Готовність до іспиту означає, що ви можете відповідати на запитання в межах офіційної програми з достатньою точністю та послідовністю, щоб скласти його. Готовність до роботи означає, що ви можете виконувати завдання в реальному середовищі, де вимоги неповні, кластери мають історію, дозволи мають значення, а збої рідко повідомляють, до якого домену вони належать. KCNA може сприяти готовності до роботи, даючи вам словник та ментальні моделі, але це лише перший шар. Здоровий план називає цю межу, а не вдає, що один сертифікат розв’язує кожну операційну проблему.

Галузі знань за запитаннями

Початковий модуль згрупував знання KCNA у концепції, зв’язки, призначення та екосистему. Це групування досі є одним із найчистіших способів навчання, бо воно змушує вас вийти за межі визначень. Визначення каже вам, що Под — це найменший розгортуваний обчислювальний об’єкт у Kubernetes. Зв’язок каже вам, що Деплоймент керує ReplicaSet’ами, які створюють Поди, щоб відповідати бажаному стану. Твердження про призначення каже вам, чому команда зазвичай має уникати запуску некерованого Поду для виробничого вебсервісу. Погляд з боку екосистеми каже вам, як інструменти спостережуваності та доставки роблять робочу систему керованою.

┌─────────────────────────────────────────────────────────────┐
│              KCNA KNOWLEDGE AREAS                           │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  CONCEPTS (What is it?)                                    │
│  ├── What is a Pod?                                        │
│  ├── What is a Deployment?                                 │
│  ├── What does the control plane do?                       │
│  └── What is cloud native?                                 │
│                                                             │
│  RELATIONSHIPS (How do things connect?)                    │
│  ├── How do Services find Pods?                            │
│  ├── How does scheduling work?                             │
│  └── How do containers relate to Pods?                     │
│                                                             │
│  PURPOSE (Why use it?)                                     │
│  ├── Why use Kubernetes over VMs?                          │
│  ├── Why use Deployments over Pods?                        │
│  └── Why is observability important?                       │
│                                                             │
│  ECOSYSTEM (What tools exist?)                             │
│  ├── What is Prometheus for?                               │
│  ├── What is Helm?                                         │
│  └── What projects are in CNCF?                            │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Концептуальні запитання найлегше розпізнати, але не завжди найлегше відповісти під тиском. Іспит може запитати про Поди, ноди, кластери, простори імен, компоненти площини управління, образи контейнерів, Деплойменти, Сервіси, ConfigMap’и чи декларативні API. Якщо ви запам’ятовуєте однорядкові визначення без прикладів, схожі варіанти зливатимуться між собою. Сервіс, kube-proxy та Інгрес — усі вони пов’язані з мережевим трафіком, але вони володіють різними частинами шляху. Под, ReplicaSet та Деплоймент — усі вони пов’язані з виконанням робочого навантаження, але вони представляють різні рівні контролю.

Запитання про зв’язки виявляють, чи має ваша ментальна модель рухомі частини, чи лише ярлики. Kubernetes побудований навколо бажаного стану: ви оголошуєте, що має існувати, контролери порівнюють цей бажаний стан зі спостережуваним станом, і система продовжує узгодження. Цей патерн пояснює, чому Деплоймент потужніший за «голий» Под і чому видалення одного Поду з керованого набору зазвичай призводить до заміни. Він також пояснює, чому Сервіс може залишатися стабільним, тоді як окремі кінцеві Поди за ним змінюються через розгортання, збої чи події масштабування.

Запитання про призначення запитують, чому хмарні системи взагалі використовують ці абстракції. Контейнери пакують код застосунку із залежностями, але вони не розв’язують автоматично планування, виявлення, розгортання, масштабування чи відновлення після збоїв у межах кластера. Kubernetes додає оркестрацію, щоб команди могли описати бажану поведінку, не розміщуючи вручну кожен процес на кожній машині. Компроміс — складність. Ви отримуєте автоматизацію та узгодженість, але мусите вивчити модель ресурсів, словник налагодження та практики екосистеми, які непотрібні для єдиного процесу на єдиному хості.

Запитання про екосистему розширюють рамку за межі самого Kubernetes. Prometheus з’являється, тому що метрики мають значення, коли застосунки масштабуються й переміщуються. Fluentd та подібні інструменти логування з’являються, тому що логи контейнерів потребують збирання й маршрутизації. Helm з’являється, тому що пакувати й встановлювати пов’язані об’єкти Kubernetes вручну стає виснажливо. GitOps з’являється, тому що команди хочуть зберігати бажаний стан у системі контролю версій та узгоджувати його автоматично. Ландшафт CNCF з’являється, тому що робота з хмарними технологіями — це сукупність взаємодійних проєктів, а не один продукт від постачальника.

Саме тут цінним є опрацьований приклад виключення варіантів. Уявіть сценарій: вебзастосунок працює на кількох Подах, окремі Поди замінюються під час розгортання, а іншим внутрішнім робочим навантаженням потрібна стабільна адреса, щоб дістатися до нього. Под неправильний, бо Поди — тимчасові кінцеві точки. Інгрес спокусливий, якщо ви думаєте «трафік», але Інгрес призначений насамперед для зовнішньої маршрутизації HTTP до Сервісів. kube-proxy бере участь у реалізації, але це не той об’єкт, який команда застосунку створює для стабільної ідентичності. Сервіс правильний, тому що він забезпечує стабільне виявлення та балансування навантаження між змінним набором Подів.

Зупиніться й передбачте: якщо запитання каже, що застосунок працює повільно, а команді потрібно простежити один запит через кілька мікросервісів, про яку категорію екосистеми ви маєте подумати, перш ніж думати про дашборди? Метрики можуть показати, що затримка зросла, а логи можуть показати локальні події, але розподілене трасування (distributed tracing) з’єднує відрізки (spans) між сервісами, щоб команда могла визначити, де витрачається час. KCNA не вимагає, щоб ви керували кожним бекендом трасування, але він очікує, що ви знаєте, чому ця категорія існує.

Теми, які вам не потрібно опановувати, так само важливі. Вам не потрібно писати ідеальний YAML з пам’яті для KCNA. Вам не потрібно усувати несправності зламаного виробничого кластера за допомогою «живої» оболонки. Вам не потрібно знати кожен прапорець кожної команди. Вам усе ж слід вільно читати базові приклади й розпізнавати поширені ресурси, тому що концептуальні запитання часто використовують реалістичні терміни. Іспит очікує усвідомленого розпізнавання, а не пригадування кожної деталі реалізації з чистого аркуша.

Підхід до навчання та опрацьований план підготовки

Оскільки KCNA є концептуальним, ваш підхід до навчання має відрізнятися від плану сертифікації з «живим» терміналом. Почніть з офіційної програми, бо саме вона визначає контракт. Потім використовуйте модулі KubeDojo, щоб побудувати пояснення для кожного терміна в цьому контракті. Нарешті, використовуйте практичні сценарії, щоб перевірити, чи можете ви обирати серед схожих концепцій. Такий порядок запобігає двом поширеним невдачам: вивченню випадкових дрібниць про Kubernetes, яких немає на іспиті, та надто швидкому проходженню програми, коли ви розпізнаєте заголовки, але не вмієте про них міркувати.

Перший прохід через програму має бути діагностичним, а не показовим. Створіть п’ять стовпців, що відповідають чинному офіційному поділу на п’ять доменів (чинному з листопада 2025 року). Під кожним стовпцем перелічіть теми з офіційної навчальної програми й позначте їх зеленим, жовтим чи червоним залежно від того, чи можете ви пояснити їх іншій людині. Червоний означає, що ви не можете дати визначення. Жовтий означає, що ви можете дати визначення, але не можете застосувати його до сценарію. Зелений означає, що ви можете пояснити це, навести приклад і виключити принаймні один оманливий варіант.

Ваш другий прохід має пов’язати концепції з прикладами. Для Kubernetes Fundamentals поясніть Поди, Деплойменти, Сервіси, простори імен, API-сервер, контролери та бажаний стан, використовуючи одну історію застосунку. Для Container Orchestration поясніть планування, масштабування, середовище виконання, мережу, сховище, виявлення сервісів та безпеку в термінах того, що має робити платформа після того, як образ контейнера вже існує. Для Cloud Native Architecture поясніть, чому мікросервіси, декларативні API, стійкість, портативність та відкриті стандарти змінюють поведінку команди. Для Observability та Delivery поясніть, як команди бачать і змінюють систему після її запуску.

Третій прохід має керуватися оцінюванням. Коли ви пропускаєте практичне запитання, не записуйте лише правильну літеру. Запишіть вимогу, яка зробила відповідь правильною, та припущення, яке зробило кожен неправильний варіант спокусливим. Наприклад, якщо ви обираєте Інгрес, коли правильна відповідь — Сервіс, зазначте, що ви відреагували на «трафік», але пропустили «внутрішня стабільна IP-адреса». Ця нотатка корисніша за копіювання визначення, бо вона тренує саме ту навичку розрізнення, якої вимагають сценарні запитання з вибором відповіді.

Ось реалістичний двотижневий план для того, хто навчається й має обмежений досвід роботи з Kubernetes. Витратьте перші чотири навчальні сесії на Kubernetes Fundamentals, приділяючи особливу увагу Подам, Деплойментам, Сервісам, площині управління, просторам імен та декларативній моделі. Витратьте наступні дві-три сесії на теми оркестрації, такі як планування, масштабування, середовище виконання, мережа, сховище та виявлення сервісів. Зарезервуйте наступні сесії для хмарної архітектури, спостережуваності та доставки, а потім завершіть змішаними практичними запитаннями та журналом помилок. Деталі змінюватимуться залежно від вашого досвіду, але принцип зважування має залишатися.

Навчальний план має включати легку практичну взаємодію, навіть попри те, що KCNA не є практичним. Запуск локального кластера чи читання простих маніфестів допомагає вам прив’язати концепції до видимих об’єктів, а це робить сценарні запитання менш абстрактними. Небезпека — у надмірному коригуванні. Якщо ви витратите цілий тиждень на відточування швидкості команд чи запам’ятовування полів маніфесту, ви можете покращити майбутню готовність до CKA, нехтуючи широтою KCNA. Правильна кількість практики — достатня, щоб зробити концепції конкретними, не перетворюючи підготовку на інший іспит.

Зупиніться й подумайте: KCNA — це тест із вибором відповіді, тоді як CKA, CKAD і CKS — практичні. Як це змінює те, що вам потрібно вивчати? Якщо ви можете розпізнати правильну відповідь, але не можете пригадати її з пам’яті, цього може бути достатньо для KCNA, але недостатньо для «живого» командного іспиту. І навпаки, якщо ви можете швидко набрати команду, але не можете пояснити, чому ресурс існує, ви все одно можете мати труднощі зі сценарними формулюваннями KCNA.

Одна практична звичка — вести реєстр концепцій. Для кожного важливого терміна запишіть чотири короткі поля: визначення, призначення, пов’язані ресурси та поширена плутанина. Запис про Сервіс може казати, що він забезпечує стабільне виявлення для набору Подів, існує тому, що Поди ефемерні, пов’язаний із селекторами та кінцевими точками, і його зазвичай плутають з Інгресом чи kube-proxy. Запис про Деплоймент може казати, що він керує розгортанням та бажаним станом реплік, існує тому, що «голі» Поди надто крихкі для застосунків, пов’язаний із ReplicaSet’ами та Подами, і його зазвичай плутають зі StatefulSet’ами чи Job’ами.

Ваші практичні матеріали слід звіряти з офіційними джерелами. Нотатки спільноти, дописи в блогах та відео можуть бути чудовими, але вони старіють нерівномірно. Сторінки Linux Foundation та CNCF визначають чинну сертифікаційну програму, документація Kubernetes визначає поточні концепції Kubernetes, а документація проєктів визначає інструменти екосистеми. Використовуйте неофіційні матеріали для пояснення та повторення, але сприймайте їх як коментар. Коли два матеріали суперечать один одному, звіряйтеся з офіційною сторінкою та оновлюйте свої нотатки із зазначенням дати перевірки.

Корисний останній прохід — пояснити одну тему вголос. Оберіть сценарій на кшталт «вебзастосунку потрібні три репліки, стабільний внутрішній доступ та метрики для затримки», а потім поясніть, які ресурси Kubernetes та інструменти екосистеми ви очікували б побачити. Якщо ви затинаєтеся, зазначте точно, де пояснення ламається. Можливо, ви розумієте Деплойменти, але не Сервіси, чи Сервіси, але не спостережуваність, чи спостережуваність, але не те, чому GitOps змінює доставку. Викладання виявляє слабкі ланки, які приховує мовчазне перечитування, і перетворює підготовку до KCNA на практику комунікації.

Не ігноруйте й адміністративну готовність. Онлайн-іспити з наглядом вводять обмеження, окремі від знань Kubernetes: правила ідентифікації, дозволена робоча зона, перевірки браузера, вимоги до камери, вікна запису, політика перескладання та правила скасування. Ці деталі належать офіційному довіднику кандидата, а не пам’яті чи чуткам. Прочитайте їх достатньо рано, щоб запобіжна логістична проблема не з’їла увагу, яку ви мали намір витратити на концепції Kubernetes. Той, хто знає матеріал, але пропускає деталь політики, створив собі режим невдачі, якого можна було уникнути.

Коли це не застосовне

KCNA не є найкращою негайною ціллю, коли вашою основною перешкодою є усунення несправностей у виробничому середовищі. Якщо ви вже відповідаєте за «живий» кластер і не можете налагодити збої планування, зламані Сервіси, помилки завантаження образів, тиск на ноди чи невдалі розгортання, вам потрібна практична операційна робота з Kubernetes поряд з будь-яким навчанням KCNA. KCNA може впорядкувати ваш словник, але він не дасть м’язової пам’яті та діагностичного повторення, потрібних для відновлення сервісу під час інциденту. У такій ситуації поєднайте цей напрямок із практичними лабораторними роботами й розгляньте CKA, щойно основи стануть стабільними.

KCNA також не є єдиним варіантом асоційованого рівня. Якщо ваша роль значною мірою орієнтована на безпеку, а ви вже розумієте базову архітектуру Kubernetes, KCSA може краще відповідати вашим негайним цілям. Якщо ваша організація стандартизується на конкретній технології екосистеми, такій як Prometheus, Istio, Cilium, Argo чи Backstage, сфокусована асоційована сертифікація може бути доречнішою після того, як ви закладете базову грамотність у Kubernetes. Суть не в тому, щоб збирати значки по черзі; суть у тому, щоб обрати посвідчення, яке змінює вашу наступну корисну розмову чи відповідальність.

Найнадійніший патерн — підготовка з урахуванням ролі. Розробникам слід наголошувати на Деплойментах, Сервісах, доставці застосунків, базовій спостережуваності та на тому, як Kubernetes змінює поведінку релізів. Менеджерам слід наголошувати на словнику, компромісах, межах доменів та на тому, що посвідчення доводить, а чого не доводить. Початківцям у платформах слід наголошувати на основах, оркестрації та містку від KCNA до практичної роботи. Тим, хто орієнтований на безпеку, слід пов’язувати теми KCNA з ізоляцією, просторами імен, політикою, основами ланцюга постачання та подальшим шляхом асоційованого фахівця з безпеки.

Найсильніший антипатерн — сертифікаційний театр. Команди іноді вимагають посвідчення, святкують значок, а потім ніколи не змінюють те, як вони спілкуються про системи. Це марнує найкращу частину KCNA. Краща альтернатива — перетворити навчальні артефакти на спільну мову: глосарій для розборів інцидентів, карту доменів для адаптації, журнал помилок практичних запитань для сесій lunch-and-learn та чітке твердження, що KCNA означає основоположну грамотність, а не виробничі повноваження.

Інший антипатерн — вивчення лише найбільшого домену. Зважування — це орієнтир, а не дозвіл ігнорувати решту системи. Спостережуваність та доставка — менші частки в чинному офіційному поділі на п’ять доменів (чинному з листопада 2025 року), але вони представляють реальність роботи застосунків після розгортання. Кандидат, який може описати Поди, але не може пояснити, чому важливі метрики, логи, трасування, CI/CD чи GitOps, має неповну хмарну картину. KCNA очікує широкого фундаменту, бо Kubernetes рідко працює наодинці.

Коли використовувати це проти альтернатив

Використовуйте KCNA, коли вам потрібна структурована вхідна точка в концепції Kubernetes та хмарних технологій. Він особливо доречний для студентів, розробників, які рухаються до платформенної роботи, технічних менеджерів, яким потрібно брати участь в архітектурних обговореннях, інженерів підтримки, які обробляють заявки, пов’язані з Kubernetes, та для ролей у продукті чи документації, які мають розуміти мову команд, що працюють із хмарними технологіями. Цінність не в тому, що іспит — найскладніший на шляху. Цінність у тому, що він змушує зробити широкий прохід по словнику, перш ніж глибша спеціалізація звузить вашу увагу.

Використовуйте CKA, коли вам потрібно довести здатність до адміністрування кластера. Цей іспит ґрунтується на виконанні завдань, тому підготовка має включати багаторазову практику команд, редагування ресурсів, усунення несправностей та впевнену роботу з документацією під тиском часу. Використовуйте CKAD, коли ваша основна відповідальність — створення, налаштування та розгортання застосунків на Kubernetes. Використовуйте CKS, коли ви вже маєте необхідну адміністраторську базу й вам потрібно продемонструвати специфічні для безпеки операційні навички. Ці іспити стоять пізніше, бо вони припускають концептуальну карту, якої навчає KCNA.

Використовуйте KCSA, коли вашою найближчою ціллю є основи безпеки хмарних технологій, а не широка орієнтація в екосистемі Kubernetes. KCNA та KCSA можуть доповнювати один одного, але їхні акценти різняться. KCNA допомагає вам говорити про основи Kubernetes, оркестрацію, архітектуру, спостережуваність та доставку. KCSA націлений на призму безпеки в хмарних системах. Якщо ви обираєте між ними, запитайте, до якої розмови вам потрібно приєднатися в найближчі дев’яносто днів: широкий платформенний словник чи специфічні для безпеки засоби контролю та ризики.

Не використовуйте жодної сертифікації, коли посвідчення не змінює роботу. Якщо ви намагаєтеся випустити функцію наступного тижня, полагодити зламаний конвеєр розгортання чи налагодити збій кластера, сфокусована лабораторна робота чи виробнича інструкція можуть бути правильним інструментом. Сертифікації корисні, коли вони створюють підзвітність, структуру та спільні очікування. Вони менш корисні, коли стають відволіканням від конкретної операційної проблеми, яка потребує безпосередньої практики.

Рамка прийняття рішення проста. Якщо ви новачок у Kubernetes, почніть з KCNA чи еквівалентних структурованих основ. Якщо ви знаєте словник, але не можете оперувати ресурсами, рухайтеся до лабораторних робіт CKA чи CKAD. Якщо ви оперуєте ресурсами й вам потрібна глибина в безпеці, рухайтеся до CKS чи KCSA залежно від передумов та ролі. Якщо ви вже знаєте зміст іспиту й вам потрібен лише доказ для роботодавця, запишіться на іспит після короткого перегляду офіційної програми та кількох змішаних практичних наборів.

Чи знали ви?

KCNA запущено у 2021 році як першу сертифікацію Kubernetes початкового рівня. До цього єдиними сертифікаціями Kubernetes були практичні професійні іспити (CKA, CKAD, CKS).
Вимога прохідного балу 75% означає, що ви можете пропустити приблизно 15 із 60 запитань. Зверніть увагу, що планка в 75% насправді вища за 66% у CKA — KCNA концептуально легший, але його прохідний поріг не поблажливий.
Відсутність практики означає відсутність kubectl — ви не наберете жодної команди під час іспиту. Це все читання та вибір відповідей.
Іспит змінюється — оновлення навчальної програми набуло чинності 24 листопада 2025 року; ці п’ять доменів та ваги відображають чинний офіційний план. Стежте за оголошеннями CNCF та перевіряйте офіційну сторінку сертифікації перед записом.

Типові помилки

Помилка	Чому це стається	Як це виправити
Надмірна технічна підготовка	Ті, хто навчається, копіюють звички CKA й витрачають більшість навчального часу на швидкість команд замість концепцій.	Підтримуйте легку практичну роботу, але надавайте пріоритет міркуванню над сценаріями, словнику та офіційному покриттю доменів KCNA.
Ігнорування екосистеми CNCF	Kubernetes здається достатньо великим сам по собі, тож інструменти поза основним API виглядають необов’язковими.	Використовуйте CNCF Landscape, щоб виявити основні проєкти спостережуваності, доставки, мережі, середовища виконання та управління.
Сприйняття ваг доменів до 2025 року як чинного закону	Багато сторонніх навчальних посібників було опубліковано до оновлення в листопаді 2025 року, а ті, хто навчається, рідко перевіряють повідомлення про зміни в програмі.	Звіряйтеся з офіційною навчальною програмою Linux Foundation чи CNCF перед записом, а потім зіставте будь-які старіші нотатки з чинним планом на п’ять доменів.
Брак практики виключення варіантів	Ті, хто звик до практики, знають інструмент, але не практикувалися обирати між схожими концептуальними відповідями.	Для кожного пропущеного запитання запишіть, чому правильна відповідь підходить і чому кожна спокуслива відповідь — ні.
Поспіх із формулюванням сценарію	Стовбур запитання часто приховує справжню вимогу в словах на кшталт стабільний, внутрішній, реплікований, спостережуваний чи декларативний.	Підкресліть вимогу, перш ніж обирати варіант, а потім зіставте її з ресурсом чи категорією екосистеми.
Запам’ятовування YAML-файлів	Приклади Kubernetes роблять YAML видимим, тож початківці припускають, що синтаксис є ціллю іспиту.	Спочатку вивчіть призначення об’єктів та зв’язки; читайте YAML лише достатньо, щоб розпізнати вид ресурсу, метадані, специфікацію та намір.
Нехтування спостережуваністю та доставкою застосунків	Менші домени відчуваються менш терміновими, ніж основи, особливо за стислого графіку.	Зарезервуйте явні навчальні блоки для метрик, логів, трасування, Prometheus, GitOps, CI/CD та концепцій Helm.
Припущення, що KCNA доводить виробниче адміністрування	Посвідчення звучить специфічним для Kubernetes, тож менеджери можуть переоцінити те, що воно підтверджує.	Поясніть, що KCNA доводить основоположну хмарну грамотність, тоді як CKA та реальна операційна практика доводять здатність до адміністрування.

Тест

Запитання 1: Колега, який щойно склав CKA, радить вам витратити більшість навчального часу для KCNA на відточування швидкості команд у лабораторному кластері. Чи це хороша порада для вашої першої спроби KCNA?

Це неповна порада. CKA — це практичний іспит, де мають значення швидкість команд та редагування ресурсів, тоді як KCNA — це концептуальний іспит із вибором відповіді. Невелика лабораторна взаємодія може зробити концепції конкретними, але більшість навчального часу для KCNA має йти на словник, зв’язки, покриття доменів та виключення сценаріїв. Якщо ви витратите більшість часу на термінальні вправи, ви можете покращити майбутню готовність до CKA, пропускаючи теми екосистеми, яких очікує KCNA.

Запитання 2: У вас рівно два тижні на підготовку, а ваш досвід — фронтенд-розробка без досвіду роботи з Kubernetes. Як вам розподілити навчальний час між основами, оркестрацією, архітектурою, спостережуваністю та доставкою?

Почніть зі зваженого плану, а потім скоригуйте його під ваші слабкі місця. Kubernetes Fundamentals та Container Orchestration заслуговують на найбільшу частку, бо вони пояснюють модель ресурсів та поведінку системи, яку припускають пізніші теми. Усе ж зарезервуйте явний час для архітектури, спостережуваності та доставки, бо ці теми можуть вирішити близькі результати й представляють ширшу екосистему хмарних технологій. Розумний план витратив би першу половину на основи, кілька сесій на оркестрацію, а решту сесій — на архітектуру, спостережуваність, доставку та змішані практичні запитання.

Запитання 3: Ваш менеджер запитує, чи доводить KCNA, що новий працівник може самотужки адмініструвати виробничий кластер Kubernetes. Що вам слід пояснити?

KCNA доводить основоположні концептуальні знання, а не повноваження виробничого адміністрування. Сертифікований кандидат має розуміти ресурси Kubernetes, принципи хмарних технологій, основи оркестрації та словник екосистеми, але іспит не вимагає «живого» усунення несправностей під тиском. Виробниче адміністрування потребує практичної роботи й краще представлене CKA плюс реальним операційним досвідом. KCNA цінний як база спільної мови, а не як гарантія того, що хтось може полагодити несправний кластер.

Запитання 4: Член команди отримує бал трохи нижче цільового на пробному тесті й хоче відкласти іспит на місяць. Що йому слід перевірити, перш ніж змінювати дату іспиту?

Йому слід оглянути результати на рівні доменів, перш ніж ухвалювати рішення про запис. Якщо промахи зосереджені у важко зважених темах основ чи оркестрації, кілька сфокусованих сесій можуть покращити бал швидше, ніж довга загальна затримка. Якщо промахи розподілені по всіх доменах, відкладення може бути мудрим, бо проблема — у широкій готовності, а не в одній слабкій ділянці. Йому також слід переглянути, чи походили помилки від прогалин у знаннях, застарілих матеріалів чи поспішного читання формулювання сценарію.

Запитання 5: Команда міграції застарілих систем хоче розмістити вебсервер, логіку застосунку та базу даних в одному великому Поді, щоб імітувати віртуальну машину. Як ви діагностуєте проблему в термінах KCNA?

Це антипатерн, бо він ігнорує те, як Kubernetes розділяє життєвий цикл робочого навантаження, масштабування та межі збоїв. Под зазвичай має представляти тісно пов’язану одиницю, яка мусить спільно використовувати планування та життєвий цикл, а не цілу застарілу машину, втиснуту в один об’єкт. Вебрівень, рівень застосунку та база даних зазвичай мають різні потреби в масштабуванні, сховищі та оновленні, тож їх слід моделювати відповідними контролерами та сервісами. Релевантний для KCNA урок полягає в тому, що оркестрація працює найкраще, коли межі ресурсів відповідають операційній поведінці.

Запитання 6: Аудитор безпеки запитує, як оркестрація обмежує радіус ураження (blast radius) скомпрометованого контейнера. Які домени KCNA допомагають вам міркувати над відповіддю?

Застосовні і Container Orchestration, і Kubernetes Fundamentals. Контейнери покладаються на механізми ізоляції операційної системи та засоби контролю ресурсів, тоді як Kubernetes додає планування, межі робочих навантажень, простори імен, сервісні акаунти та інтеграції політик навколо цих контейнерів. KCNA не вимагає глибокого аналізу експлойтів, але він очікує, що ви розумієте: оркестрація — це не лише розміщення; вона також формує ізоляцію, мережу та керування життєвим циклом. Повна відповідь пов’язує ізоляцію контейнерів з абстракціями кластера, які керують робочими навантаженнями.

Запитання 7: Розробник каже, що Prometheus, логи та трасування — це відволікання, бо планування Kubernetes є справжньою темою. Як ви поясните, чому спостережуваність належить до підготовки до KCNA?

Планування розміщує робочі навантаження, але спостережуваність каже командам, чи здорові ці робочі навантаження після розміщення. У розподілених системах збої можуть проявлятися як затримка, частота помилок, відсутні логи чи насичення ресурсів у кількох сервісах, а не як один очевидний збій процесу. Prometheus та пов’язані інструменти спостережуваності дають операторам сигнали для діагностики та рішень про потужність. KCNA включає спостережуваність, бо хмарна грамотність неповна, якщо ви можете розгортати системи, але не можете пояснити, як команди їх бачать.

Запитання 8: Ваша команда впроваджує GitOps, але деякі учасники надають перевагу ручним змінам через `kubectl`, бо так їм здається швидше. Як GitOps покращує доставку та чому його перевіряють?

GitOps покращує доставку, роблячи систему контролю версій джерелом істини для бажаного стану й використовуючи автоматизацію для узгодження цього стану в кластері. Ручні зміни можуть здаватися швидшими тут і зараз, але їх важче переглядати, відтворювати, аудіювати та послідовно відкочувати. KCNA перевіряє GitOps у межах доставки застосунків, бо сучасна робота з Kubernetes включає те, як зміни потрапляють у кластер, а не лише те, які ресурси існують після прибуття. Найкраща відповідь пов’язує декларативний стан, автоматизацію, історію переглядів та зменшений дрейф конфігурації.

Практична вправа: складання вашої стратегії KCNA

Іспит KCNA не є практичним так само, як практичні CKA, CKAD чи CKS, але підготовка все одно вимагає активної роботи. У цій вправі ви побудуєте особисту навчальну карту, яка пов’язує офіційну програму, чинний офіційний поділ на п’ять доменів (чинний з листопада 2025 року), екосистему CNCF та ваш власний рівень упевненості. Результат — не декоративний навчальний календар. Це інструмент прийняття рішень, який каже вам, яку концепцію вивчати наступною й чому ця концепція має значення для іспиту.

Виконуйте цю вправу зі звичайним документом, таблицею, нотатником чи дошкою завдань. Формат менш важливий, ніж дисципліна записувати докази. Якщо ви позначаєте «Сервіси» зеленим, ви маєте вміти пояснити стабільне виявлення, селектори, зміни кінцевих точок та чому Інгрес — це не те саме. Якщо ви позначаєте «GitOps» жовтим, ви маєте знати загальну ідею, але визнати, що вам ще потрібна практика в поясненні узгодження та можливості аудиту. Чесні позначки корисніші за оптимістичні.

Крок 1: Дослідіть ландшафт CNCF

Відкрийте вебпереглядач і перейдіть до інтерактивного CNCF Cloud Native Landscape.
Знайдіть розділ «Orchestration & Management» та визначте, де розташований Kubernetes.
Знайдіть принаймні три інші проєкти-випускники (graduated) у ландшафті (наприклад, Prometheus для спостережуваності, Helm для доставки застосунків).

Орієнтири для розв'язку

Kubernetes має з’явитися як центральний проєкт оркестрації, але корисне навчання походить від його сусідів. Запишіть принаймні один проєкт, який допомагає спостерігати системи, один, який допомагає доставляти застосунки, та один, який допомагає з мережею, середовищем виконання чи політикою. Суть у тому, щоб побачити Kubernetes як частину екосистеми, а не як єдиний ізольований інструмент.

Крок 2: Проаналізуйте програму іспиту

Завантажте найновішу офіційну програму іспиту KCNA з вебсайту Linux Foundation.
Перегляньте детальні пункти під кожним з п’яти основних доменів.
Виділіть будь-які концепції чи інструменти, з якими ви ніколи раніше не стикалися.

Орієнтири для розв'язку

Використовуйте офіційну програму як контракт для іспиту, який ви плануєте складати. Напрямок KubeDojo дотримується чинного офіційного поділу на п’ять доменів (чинного з листопада 2025 року); якщо «жива» сторінка сертифікації колись зміниться знову, додайте нотатку, яка зіставляє кожен розділ KubeDojo з оновленим офіційним доменом. Це не дасть застарілому сторонньому матеріалу скеровувати ваше рішення про запис, водночас зберігаючи узгоджений шлях через модулі.

Крок 3: Складіть ваш навчальний план

Створіть простий документ чи таблицю з п’ятьма доменами іспиту.
На основі вашого перегляду програми призначте оцінку впевненості (1–5) кожному домену.
Розподіліть доступні навчальні години пропорційно, надаючи найбільше часу доменам з найнижчим балом, які мають найвищу вагу на іспиті (як-от Kubernetes Fundamentals).

Орієнтири для розв'язку

Поєднуйте вагу та впевненість замість того, щоб використовувати лише вагу. Тема з високою вагою та низькою впевненістю має переміститися на початок вашого плану. Тема з низькою вагою та дуже низькою впевненістю все одно має отримати визначений навчальний блок, бо невирішені малі домени можуть вирішити близькі результати. Завершіть план змішаними практичними запитаннями, щоб ви тренувалися перемикатися між доменами.

Крок 4: Побудуйте журнал помилок

Дайте відповіді на один невеликий набір практичних запитань у стилі сценаріїв після вашого першого навчального проходу.
Для кожного промаху запишіть вимогу, яку ви проґавили, та спокусливу неправильну відповідь, яку ви обрали.
Поверніться до тієї самої теми в офіційній документації чи у відповідному модулі KubeDojo.

Орієнтири для розв'язку

Журнал помилок має фіксувати дефекти міркування, а не лише факти. «Обрав Інгрес, бо в запитанні згадувався трафік, але вимогою було внутрішнє стабільне виявлення» корисніше за «Сервіс дорівнює стабільній IP». Перша нотатка змінює майбутню поведінку читання, тоді як друга нотатка все одно може підвести, коли формулювання зміниться.

Крок 5: Узгодьте з вашою наступною сертифікацією

Вирішіть, чи є вашим наступним імовірним кроком CKA, CKAD, CKS, KCSA чи жодна сертифікація.
Позначте, які теми KCNA стають передумовами для цього наступного кроку.
Додайте одну практичну лабораторну звичку, яка підтримує наступний крок, не перебираючи на себе підготовку до KCNA.

Орієнтири для розв'язку

Якщо наступним є CKA, додайте легку практику команд з alias k=kubectl після кожного блоку вивчення концепцій. Якщо наступним є CKAD, пов’яжіть теми робочих навантажень та доставки з маніфестами застосунків та поведінкою розгортання. Якщо наступним є KCSA чи CKS, позначте кожну тему, що стосується ізоляції, ідентичності, політики та ланцюга постачання. Мета — дати KCNA набрати імпульс, не перетворюючи цей модуль на неправильний іспит.

Критерії успіху

Я успішно зорієнтувався у CNCF Landscape та визначив категорію Kubernetes.
Я знайшов три проєкти-випускники CNCF, релевантні доменам KCNA (наприклад, спостережуваність, доставка застосунків).
Я переглянув офіційну програму KCNA та визначив свої конкретні прогалини в знаннях.
Я склав навчальний план, який надає пріоритет важко зваженим доменам (основам та оркестрації).
Я написав принаймні три записи в журналі помилок, які пояснюють, чому спокусливі неправильні відповіді були неправильними.

Структура навчальної програми

Ця навчальна програма дотримується доменів іспиту як навчальної послідовності, що означає: ця таблиця є одночасно організатором навчання й нагадуванням про те, що KubeDojo навчає концепцій у вибудуваному порядку:

Частина	Домен	Вага	Модулі
0	Вступ	—	Огляд іспиту, навчальна стратегія
1	Kubernetes Fundamentals	46%	Основні концепції, архітектура
2	Container Orchestration	22%	Планування, масштабування, сервіси
3	Cloud Native Architecture	16%	Принципи, CNCF, serverless
4	Cloud Native Observability	8%	Моніторинг, логування
5	Application Delivery	8%	CI/CD, GitOps, Helm

Таблиця збережена, тому що вона пояснює, як організований цей напрямок KubeDojo, та узгоджується з чинним офіційним поділом на п’ять доменів (чинним з листопада 2025 року). Якщо офіційний план іспиту зміниться в майбутньому оновленні, не панікуйте. Модулі все одно навчають базових концепцій; вам лише потрібно зіставити локальні позначки навчальної програми з тогочасними позначками іспиту. Завжди перевіряйте офіційну сторінку сертифікації перед записом.

Підсумок модуля простий: KCNA — це ваша вхідна точка до сертифікації Kubernetes, але це концептуальна вхідна точка. Формат іспиту — вибір відповіді, фокус — концепції понад команди, а найбільша навчальна інвестиція має йти в основи Kubernetes та оркестрацію. Сертифікація відрізняється від CKA, CKAD і CKS, бо тут немає термінала, немає вимоги «живого» написання YAML і немає симуляції усунення несправностей у виробництві. Ця відмінність має формувати кожне навчальне рішення, яке ви ухвалюєте.

Використовуйте наступний модуль, щоб перетворити цей огляд на розклад. Сильний розклад не просто розподіляє години. Він обирає навчальні дії на основі того, що перевіряє іспит, що ви вже знаєте та до якої пізнішої сертифікації чи робочої відповідальності ви готуєтеся. Якщо ви триматимете ці три вхідні дані на видноті, підготовка до KCNA стане структурованим фундаментом, а не купою розрізнених нотаток.

Джерела

Наступний модуль

Модуль 0.2: Навчальна стратегія — як ефективно підготуватися до іспиту Kubernetes із вибором відповіді, перетворивши огляд, офіційну програму та вашу карту впевненості на реалістичний тижневий план.