Повний пробний іспит CNPE

Напрямок CNPE: Складність [СКЛАДНИЙ]
Час на проходження: 90-120 хв
Передумови: Стратегія та середовище іспиту CNPE, Лабораторна робота з GitOps та доставки, Лабораторна робота з платформними API та самообслуговуванням, Лабораторна робота зі спостережуваності, безпеки та операцій

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

Після цього модуля ви зможете:

Діагностувати дрейф GitOps-доставки, порівнюючи намір у репозиторії, статус контролера та живі об’єкти Kubernetes 1.35+.
Оцінювати запити самообслуговування платформних API, читаючи контракти CRD, умови статусу та докази узгодження.
Налагоджувати збої спостережуваності чи безпеки, не послаблюючи захисні бар’єри політик і не втрачаючи операційних доказів.
Спроєктувати робочий процес розподілу часу на іспиті, який відкладає застряглу роботу, перевіряє кожне завдання та зберігає час на фінальний огляд.
Запровадити розбір польотів у стилі екзаменатора, який перетворює промахи на конкретні зміни в практиці.

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

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

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

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

Читання іспиту як платформний оператор

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

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

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

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

Пробний іспит побудований навколо чотирьох типів завдань: GitOps-доставка, самообслуговування платформних API, реагування на інциденти спостережуваності чи безпеки та операційний супровід. Ця послідовність досі працює як кістяк пробного іспиту, але глибший урок полягає в тому, що кожне завдання має інше визначення успіху. Виправлення доставки не завершене лише тому, що маніфест відредаговано; воно завершене, коли потрібне середовище збіглося. Виправлення платформного API не завершене лише тому, що запит прийнято; воно завершене, коли контракт валідний, статус осмислений, а узгодження досягає очікуваного стану.

У реалістичній репетиції текст завдання може навмисно містити спокусливі деталі. Ім’я простору імен, збійний под чи розлючена подія — корисний доказ, але це не автоматично корінна причина. Хороша іспитова робота перетворює кожну зачіпку на запитання: яка система породила цю зачіпку, чим ця система володіє і що змінилося б, якби моя гіпотеза була істинною? Ця звичка убезпечує вас від плутання шуму реалізації з наміром платформи, особливо коли завдання охоплює GitOps, API та поведінку під час виконання.

Проходження пробного іспиту під реальним тиском

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

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

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

Сценарій вправи: у вас 90-хвилинне вікно практики й чотири завдання. Завдання з доставки виглядає прямолінійним, завдання з платформного API має незнайомі поля CRD, інцидентне завдання породжує шумні події, а операційне завдання просить покращити runbook. Сильний хід — зазвичай зібрати бали за доставку й операції рано, обмежити час на дослідження незнайомого контракту й лишити недоторканим час на фінальний огляд. Слабкий хід — поставитися до найзаплутанішого завдання як до особистого виклику і дати йому поглинути всю сесію.

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

Аналогія генеральної репетиції перед виступом — корисна ментальна модель тут. Справжній сценічний виступ не перевіряє, чи можете ви бездоганно запам’ятати партитуру; він перевіряє, чи можете ви тримати темп під вогнями, відновлюватися після дрібних помилок і завершувати твір упевнено й чисто. CNPE працює за точно такою самою логікою. Найкращий результат репетиції — це зовсім не ідеальний перший прогін без жодної помилки, а радше повторюваний і надійний цикл «читай-дій-перевіряй», який переживає будь-яке відволікання й лишає по собі достатньо чітких доказів, щоб сторонній екзаменатор міг легко прослідкувати за ходом вашої думки.

Опрацювання кожного домену, не втрачаючи нитки

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

Домен	Вага
Платформна архітектура та інфраструктура	15%
GitOps та неперервна доставка	25%
Платформні API та можливості самообслуговування	25%
Спостережуваність та операції	20%
Безпека та забезпечення політик	15%

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

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

Завдання з самообслуговування платформних API починаються з контракту. Запит (claim), складений ресурс, CRD чи специфічна для платформи абстракція — це не просто ще один YAML-об’єкт; це обіцянка між платформною командою та її користувачами. Учневі доводиться читати обов’язкові поля, поведінку валідації, припущення про значення за замовчуванням, умови статусу та володіння з боку контролера. Коли контракт неясний, користувачі вгадують. Коли статус розмитий, оператори вгадують. Пробний іспит винагороджує звичку робити обидві сторони спостережуваними.

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

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

Зразковий перебіг іспиту лишається практичною мапою: завдання перше — GitOps-доставка: огляньте намір репозиторію, відремонтуйте специфічну для середовища зміну, відновіть синхронізацію чи виправте розгортання та перевірте, що живий стан відповідає бажаному. Завдання друге — самообслуговування платформних API: прочитайте CRD або запит, визначте поля контракту, відремонтуйте проблеми з валідацією, статусом чи узгодженням і підтвердьте, що об’єкт досягає очікуваного здорового стану. Завдання третє — спостережуваність або безпека: звузьте причину за допомогою метрик, логів, трейсів чи подій, застосуйте найменше безпечне виправлення, збережіть бар’єри й перевірте, що симптом зник. Завдання четверте — операційний супровід: підтвердьте, що існує правильне сповіщення чи сигнал runbook, задокументуйте операційну зачіпку й тримайте платформу пояснюваною.

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

Рубрику оцінювання нижче варто зберегти, бо вона віддзеркалює платформні рівні, які ви маєте інтегрувати під час репетиції.

Сфера	Повний залік	Частковий залік
Доставка	Синхронізація чи розгортання збігається з коректними межами середовища	Зміна працює, але просування чи перевірка слабкі
Платформний API	Контракт зрозумілий, і ресурс узгоджується	Ресурс створено, але міркування про статус чи контракт неясне
Операції	Корінну причину виявлено й виправлено безпечно	Симптом покращено, але докази неповні
Безпека	Бар’єри лишаються цілими, поки проблему виправлено	Виправлення працює, але без потреби послаблює контроль
Управління часом	Завдання впорядковані, а застрягла робота відкладена	Одне завдання поглинає надто багато сесії

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

Перевірка як контрольний цикл іспиту

Перевірка — це контрольний цикл іспиту, бо вона перетворює дію на доказ. Без перевірки завдання може здаватися завершеним лише тому, що ви відредагували правдоподібний файл, перезапустили правдоподібне робоче навантаження чи побачили, що одна команда повернула заспокійливий рядок. Цього недостатньо на платформному іспиті. Екзаменатор не питає, чи виконали ви активність; екзаменатор питає, чи досягла система запитаного стану з правильної причини.

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

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

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

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

Розбір польотів як екзаменатор

Розбір польотів — це місце, де пробний іспит стає тренуванням, а не просто стресовою годиною. Поганий розбір каже: «Мені треба стати швидшим», що надто розпливчасто, щоб спрямувати практику. Корисний розбір називає завдання, точку рішення, докази, які ви пропустили, та наступну поведінку, яку ви відпрацюєте. Мета — зробити наступний прогін вимірювано іншим, а не емоційно задовільним.

Почніть із реконструкції хронології зі свого чернеткового аркуша. Яке завдання ви відкрили першим, коли перемкнулися, де відклали роботу й скільки часу лишилося на огляд? Тоді розгляньте вибори рівня. Чи пропатчили ви деталь реалізації, коли намір був хибним? Чи поставилися до відмови політики як до збою робочого навантаження? Чи продовжували копати після того, як доказів уже було досить? Ці запитання незручні саме так, як має бути хороша практика.

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

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

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

Побудова повторюваного набору практики

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

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

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

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

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

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

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

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

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

Стратегія оцінювання та якість доказів

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

Високоякісні докази достатньо конкретні, щоб інший оператор міг повторити перевірку. Для завдання з доставки «застосунок виправлено» — слабко, тоді як «оверлей репозиторію тепер відповідає staging, контролер GitOps повідомляє synced і healthy, а Deployment у просторі імен має очікуваний образ» — сильно. Для завдання платформного API «запит працює» — слабко, тоді як «запит показує умову ready, складений ресурс існує, а в подіях не лишилося помилок узгодження» — сильно. Конкретний доказ зменшує неоднозначність під час фінального проходу огляду.

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

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

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

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

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

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

Патерни та антипатерни

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

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

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

Кілька поширених патернів збою варто назвати, бо вони описують звички, а не специфічні для інструментів помилки.

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

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

Рамка прийняття рішень

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

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

Рішення	Обирайте це, коли	Компроміс
Виправити намір GitOps першим	Бажаний стан репозиторію суперечить запитаному середовищу	Швидка збіжність, якщо контролер здоровий, але слабко, якщо справжня причина — живий дрейф
Виправити контракт платформного API першим	Поля запиту, валідація чи умови статусу пояснюють збій	Дає тривку поведінку самообслуговування, але вимагає уважного читання під тиском часу
Виправити симптом виконання першим	Докази доводять, що стан навантаження чи простору імен — безпосередній блокер	Може швидко відновити сервіс, але не повинно обходити володіння GitOps чи політикою
Відкласти й повернутися	Ви повторюєте перевірки без нових доказів	Захищає бали між доменами, але вимагає чіткої нотатки, щоб контекст можна було відновити
Витратити час фінального огляду	Ви завершили завдання з вузькими доказами перевірки	Ловить дрібні помилки, але працює лише за умови стислих попередніх нотаток

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

Чи знали ви?

Розширення Kubernetes API через CustomResourceDefinitions стало стабільним в API apiextensions.k8s.io/v1, тому сучасні іспити з платформних API очікують, що ви читатимете схему й статус як першокласні операційні докази.
Argo CD ставиться до Git як до джерела бажаного стану і неперервно порівнює його з живим станом кластера, тож завдання з доставки не завершене, поки ви не можете пояснити обидва сигнали — синхронізацію та здоров’я.
Prometheus випустився з CNCF у 2018 році, і його модель запитів досі є центральною для хмарної інцидентної роботи, бо платформним операторам потрібні докази часових рядів, а не ізольовані знімки.
Kubernetes 1.35 покращує помилки валідації kube-apiserver для кастомних ресурсів із правилами валідації CEL, показуючи значення, яке не пройшло валідацію, що робить налагодження контрактів CRD доречнішим для іспиту.

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

Помилка	Чому це стається	Як це виправити
Ставитися до пробного іспиту як до ще одного завдання на читання	Учень очікує, що модуль дасть комфорт замість тиску	Проведіть репетицію зі справжнім таймером, коротким чернетковим аркушем і без пауз
Редагувати живі об’єкти, перш ніж перевірити намір GitOps	Видимий симптом — у кластері, тож репозиторій відчувається непрямим	Порівняйте намір репозиторію, статус контролера та живі об’єкти, перш ніж обрати рівень
Ремонтувати платформний запит, не прочитавши контракт CRD	Ресурси самообслуговування під стресом виглядають як звичайний YAML	Огляньте обов’язкові поля, значення за замовчуванням, умови статусу та володіння узгодженням, перш ніж змінювати значення
Послаблювати політику, щоб усунути симптом безпеки	Відмова може виглядати як перешкода, а не як корисний доказ	Збережіть бар’єри й визначте дозволену зміну, що задовольняє вимогу робочого навантаження
Дати одному складному завданню поглинути сесію	Учень хоче завершеності й гониться ще за однією зачіпкою	Відкладіть завдання з названою умовою повернення та зберіть перевірені бали деінде
Лишати перевірку на фінальні хвилини	Перевірка відчувається повільнішою за внесення більшої кількості змін	Перевіряйте після кожного завдання, щоб фінальний огляд підтверджував роботу, а не виявляв базові збої
Писати нотатки розбору, надто розпливчасті для практики	«Стати швидшим» здається істинним, але не називає поведінки	Перетворіть кожен промах на конкретну ціль наступної репетиції зі спостережуваним сигналом успіху

Тест

Питання 1

Гіпотетичний сценарій: керований через GitOps застосунок став нездоровим після недавньої зміни в репозиторії. Завдання просить вас відновити середовище, не обходячи процес доставки. Який найкращий перший хід?

A. Відредагувати живий Deployment напряму, бо под — видимий збій.
B. Порівняти намір репозиторію, статус контролера та живі об’єкти Kubernetes, щоб локалізувати межу дрейфу.
C. Видалити простір імен, щоб контролер GitOps відтворив усе з нуля.
D. Вимкнути автоматичну синхронізацію до кінця іспиту, щоб робоче навантаження перестало змінюватися.

Відповідь

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

Питання 2

Сценарій вправи: запит бази даних для самообслуговування прийнято API-сервером, але він ніколи не досягає умови ready. Який шлях розслідування найкраще оцінює контракт платформного API?

A. Прочитати запит, схему CRD, умови статусу, події та складені ресурси, перш ніж редагувати поля.
B. Замінити запит написаним вручну Secret, бо застосунку потрібні лише облікові дані.
C. Ігнорувати статус, бо успішне створення об’єкта доводить, що запит валідний.
D. Пропатчити тег образу деплойменту контролера, перш ніж перевірити контракт ресурсу.

Відповідь

A правильна, бо платформна робота з API залежить від контракту між введенням користувача, валідацією, узгодженням і доказами статусу. B хибна, бо обхід запиту ламає модель самообслуговування й може лишити контролер необізнаним про бажаний стан. C хибна, бо створення доводить лише допуск, а не успішне узгодження. D хибна, бо зміна контролера першою пропускає дешевші докази, доступні в запиті та CRD.

Питання 3

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

A. Видалити політику, бо відновлення сервісу завжди важливіше за бар’єри.
B. Скористатися подіями, конфігурацією робочого навантаження та вимогами політики, щоб знайти найменше сумісне виправлення.
C. Додати широкі привілеї сервісному акаунту й рухатися далі.
D. Ігнорувати відмову й перезапускати поди, поки один не стане готовим.

Відповідь

B правильна, бо збої безпеки треба налагоджувати з доказами, зберігаючи межу політики. A хибна, бо видалення політики послаблює платформу замість безпечного задоволення робочого навантаження. C хибна, бо широкі привілеї створюють уникну регресію безпеки й можуть не усувати фактичну відмову. D хибна, бо перезапуски не змінюють порушеної вимоги й марнують іспитовий час.

Питання 4

Сценарій вправи: ви витратили кілька хвилин на незнайомий CRD і повторюєте ті самі команди огляду без нових доказів. Лишаються незачепленими два легші завдання. Яке рішення щодо розподілу часу найкраще захищає загальний результат пробного іспиту?

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

Відповідь

B правильна, бо робочий процес розподілу часу на іспиті має захищати час між доменами, зберігаючи достатньо контексту для безпечного повернення. A хибна, бо зусилля на одному завданні можуть виснажити легшу перевірену роботу. C хибна, бо видалення ресурсу — ризикована дія, не пов’язана з проблемою розподілу часу. D хибна, бо чернетковий аркуш має бути стислим, а не відсутнім; він несе гіпотезу, потрібну для пізнішого повернення.

Питання 5

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

A. Написати довшу розповідь про все, що ви пробували, щоб жодна деталь не пропала.
B. Додати конкретний рядок перевірки до кожного завдання, що називає ресурс, простір імен, умову та очікуваний результат.
C. Наступного разу пропустити фінальний огляд, бо він лише створює тривогу.
D. Зосередитися лише на швидкості команд, бо документація не є частиною платформної роботи.

Відповідь

B правильна, бо розбір має перетворити промах на спостережувану зміну в практиці. A хибна, бо довші нотатки можуть стати другим проєктом, не довівши симптому. C хибна, бо фінальний огляд — це місце, де дрібні помилки ловлять до того, як спливе час. D хибна, бо платформна робота включає докази, за якими може прослідкувати інший оператор чи екзаменатор.

Питання 6

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

A. Почати з часового вікна метрики, diff розгортання та доступних логів, тоді вирішити, чи прогалини в трейсах є причинними, чи побічними.
B. Припустити, що трейсинг зламано, і витратити сесію на відбудову спостережуваності.
C. Вимкнути стратегію деплойменту, бо розгортання завжди є причиною затримки.
D. Поставитися до відсутніх відмов політики як до доказу, що сервіс здоровий.

Відповідь

A правильна, бо налагодження спостережуваності має поєднувати сигнали й дозволяти таймінгу спрямовувати наступну перевірку. B хибна, бо відбудова спостережуваності надто широка, якщо докази не показують, що інструментування є блокувальною проблемою. C хибна, бо розгортання — це гіпотеза, а не висновок. D хибна, бо відсутність відмов політики лише звужує один клас причин; вона не доводить здорової поведінки.

Питання 7

Гіпотетичний сценарій: ваше завдання операційного супроводу просить покращити runbook після того, як ви виправили проблему узгодження платформного API. Яке оновлення найкраще підтримує наступного оператора?

A. Додати точну умову статусу, ймовірну причину та сигнал перевірки, що вказують на неузгодженість контракту.
B. Додати загальне нагадування «перевірте Kubernetes», бо всі збої зрештою стосуються кластера.
C. Видалити розділ runbook, щоб оператори вчилися, розслідуючи з нуля.
D. Задокументувати лише фінальну команду, яку ви виконали, не пояснюючи доказів, які вона довела.

Відповідь

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

Практична вправа

Сценарій вправи: проведіть повну репетицію CNPE, використовуючи одне завдання з доставки, одне завдання з платформного API, одне завдання зі спостережуваності чи безпеки та одне завдання операційного супроводу з напрямку CNPE. Користуйтеся справжнім таймером, тримайте нотатки короткими й оцініть прогін за збереженою в цьому модулі рубрикою. Суть не в тому, щоб винайти ідеальний іспит; суть у тому, щоб створити повторюваний стрес-тест, який виявляє, як ви діагностуєте дрейф GitOps-доставки, оцінюєте запити платформних API, налагоджуєте захищені збої під час виконання, керуєте розподілом часу та запроваджуєте розбір.

Завдання перше — підготовка. Оберіть чотири завдання, напишіть однорядковий очікуваний результат для кожного та поставте таймер, який ви не зупинятимете. Наприклад, підказка платформного API може казати: «Запит бази даних у team-a прийнято, але він не готовий; відновіть готовність, виправивши запит чи контракт без обходу платформного API, тоді запишіть умову Ready і складений ресурс як доказ». Ваша підготовка завершена, коли ви можете вказати на точний доказ, який довів би завершення кожного завдання. Не починайте розв’язувати ще; перший практичний хід — визначити успіх до того, як тиск звузить вашу увагу.

Пропонований підхід до підготовки

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

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

Пропонований підхід до виконання

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

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

Пропонований підхід до огляду

Перегляньте кожне завдання щодо сигналу успіху, який ви написали на підготовці. Для GitOps-доставки перевірте намір, статус контролера та живий стан. Для завдання платформного API перевірте припущення про схему, умови статусу та докази узгодження. Для спостережуваності чи безпеки перевірте, що початковий симптом зник без послаблення політики. Для операційного супроводу перевірте, що наступний оператор знав би, який сигнал важливий.

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

Пропонований підхід до розбору

Уникайте розпливчастих висновків на кшталт потреби бути швидшим. Пишіть спостереження на зразок «Я витратив надто багато часу на CRD, не прочитавши умови статусу» чи «Я перевірив под, але не контролер GitOps». Тоді визначте наступний хід практики, як-от репетиція читання умов запиту чи додавання рядка перевірки перед кожним перемиканням завдання. Розбір успішний, коли наступний пробний іспит має поведінку, яку ви можете навмисно перевірити.

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

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

Перевірка:

git status --short
kubectl get events -A --sort-by=.lastTimestamp | tail -n 20
kubectl get all -n <namespace>

Джерела

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

Поверніться до хабу CNPE і проведіть ще одну повну репетицію з іншими завданнями, щоб робочий процес став повторюваним під тиском.