Модуль 0.4: Стратегія складання іспиту CKS

Складність: [QUICK] — критично для успіху на іспиті

Час на проходження: 20–25 хвилин

Передумови: сертифікація CKA, модулі 0.1–0.3

Що ви зможете зробити

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

Застосувати стратегію трьох проходів, адаптовану до специфічних для безпеки завдань CKS
Оцінити складність завдання, щоб за перші 30 секунд вирішити «пропустити чи розв’язувати»
Спроєктувати бюджет часу, який максимізує бали в усіх доменах CKS
Створити особистий чек-лист на день іспиту, що охоплює налаштування середовища та скорочення для kubectl

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

Гіпотетичний сценарій: ви починаєте іспит CKS упевнено, бо вже відпрацювали NetworkPolicy, RBAC, контексти безпеки, Trivy, Falco, kube-bench, seccomp, AppArmor і Pod Security Admission. Перше завдання просить написати власне правило Falco, синтаксис виглядає майже знайомим, і ви витрачаєте наступні 18 хвилин, ганяючись за умовою, яка все одно не спрацьовує. У ту мить нічого нового про безпеку Kubernetes концептуально немає, але іспит перетворився з технічних знань на управління портфелем, де кожну хвилину доводиться вкладати туди, де вона ще здатна принести бали.

Іспит CKS дає вам 2 години на практичний набір приблизно з 15–20 завдань, а прохідний бал становить 67%. Ця форма має значення, бо означає, що переможна стратегія — це не досконалість, а контрольоване виконання багатьох незалежних можливостей набрати бали. Кандидат, який розв’язує кожне знайоме швидке завдання, перевіряє кожен результат і залишає одне складне розслідування незавершеним, часто опиняється у кращому становищі, ніж кандидат, який доводить глибокий фах на одному складному завданні, але залишає кілька простіших завдань непобаченими.

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

Спроєктуйте бюджет часу з балів і ризику

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

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

Прохідний поріг у 67% має знижувати ваш стрес, а не ваші стандарти. Якщо на іспиті 17 завдань нерівної цінності, вам не потрібно завершувати кожне завдання; вам потрібно уникнути обміну шести швидких завершень на одне героїчне часткове. Завдання з безпеки особливо спокушають вас на такий обмін, бо вони часто пов’язані з цікавими інструментами та реалістичними режимами відмов. Умови Falco, виправлення kube-bench, шляхи до профілів seccomp і селектори NetworkPolicy — кожне з цього може поглинути час, не показуючи очевидного прогресу, якщо ви беретеся за них «з холодного старту».

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

┌─────────────────────────────────────────────────────────────┐
│              120 MINUTE TIME BUDGET                         │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  0:00  ─────── Pass 1 Start ───────                        │
│  │                                                          │
│  │     Quick wins: RBAC, basic NetworkPolicy,              │
│  │     securityContext, AppArmor profiles                  │
│  │                                                          │
│  0:50  ─────── Pass 2 Start ───────                        │
│  │                                                          │
│  │     Tool tasks: seccomp, PSA, kube-bench fixes,        │
│  │     complex NetworkPolicies, ServiceAccount hardening   │
│  │                                                          │
│  1:40  ─────── Pass 3 Start ───────                        │
│  │                                                          │
│  │     Complex: Falco rules, incident investigation,       │
│  │     multi-step hardening                                │
│  │                                                          │
│  2:00  ─────── Exam End ───────                            │
│                                                             │
│  Reserve 5 min at end for verification!                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

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

Зробіть паузу й спрогнозуйте: ви завершили Прохід 1 за 45 хвилин і набрали приблизно 35%. У вас залишилося 75 хвилин. Перш ніж читати далі, вирішіть, чи це на шляху до проходження, чи варто хвилюватися, і поясніть свої міркування у термінах балів, які ще доступні, а не завдань, що залишилися.

Ця ситуація зазвичай здорова, бо найшвидшу третину балів захоплено, а більше половини часу ще залишається. Небезпека не в 35%; небезпека — стати надто розслабленим і витратити наступні півгодини на один складний пункт. У цей момент ваш план має змінитися з широкого сканування на цілеспрямоване виконання Проходу 2, обираючи завдання середнього рівня з передбачуваною механікою та чіткими командами перевірки.

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

Стратегія трьох проходів для безпеки

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

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

┌─────────────────────────────────────────────────────────────┐
│              CKS THREE-PASS STRATEGY                        │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  PASS 1: Quick Security Wins (40-50 min)                   │
│  Target: 1-3 min per task                                  │
│  ─────────────────────────────────────────────────────────  │
│  ✓ Create/modify NetworkPolicy                             │
│  ✓ Fix RBAC permission issue                               │
│  ✓ Apply existing AppArmor profile                         │
│  ✓ Set securityContext fields                              │
│  ✓ Enable audit logging                                    │
│  ✓ Run Trivy scan, identify vulnerabilities                │
│                                                             │
│  PASS 2: Tool-Based Tasks (40-50 min)                      │
│  Target: 4-6 min per task                                  │
│  ─────────────────────────────────────────────────────────  │
│  ✓ Create seccomp profile from scratch                     │
│  ✓ Configure Pod Security Admission                         │
│  ✓ Run kube-bench, fix specific findings                   │
│  ✓ Create NetworkPolicy with egress rules                  │
│  ✓ Set up ServiceAccount with minimal permissions          │
│                                                             │
│  PASS 3: Complex Scenarios (20-30 min)                     │
│  Target: 7+ min per task                                   │
│  ─────────────────────────────────────────────────────────  │
│  ✓ Write custom Falco rule                                 │
│  ✓ Investigate and respond to runtime incident             │
│  ✓ Multi-step cluster hardening                            │
│  ✓ Complex NetworkPolicy (multiple pods, namespaces)       │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Прохід 1 — це той етап, де ви захоплюєте завдання, які виглядають майже механічними одразу, щойно ви зрозуміли поставлену вимогу. Сама по собі робота все ще може бути важливою роботою з безпеки, але шлях її виконання короткий і прямий: відредагувати securityContext, створити Role і RoleBinding, позначити простір імен міткою для Pod Security Admission, застосувати наявний профіль AppArmor або просто запустити сканер і повідомити прямий висновок. Ключова перевірка тут одна — чи можете ви назвати точну команду перевірки ще до того, як почнете набирати сам розв’язок.

Прохід 2 — для завдань, які передбачувані, але мають більше рухомих частин. Створити профіль seccomp з нуля концептуально не складно, якщо ви це відпрацьовували, але воно включає написання JSON, розміщення його там, де очікує kubelet, коректне посилання на нього й підтвердження, що Pod справді його використовує. Завдання kube-bench може бути простим, коли вивід називає перевірку, що провалилася, але виправлення може вимагати редагування маніфесту й очікування перезапуску статичного Pod. Ці завдання заслуговують на час, але вони не повинні переривати перше прочісування.

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

Зупиніться й подумайте: ви відкриваєте іспит CKS, і перше завдання просить написати власне правило Falco для виявлення майнінгу криптовалюти. Воно коштує 7% від загального балу. Беретеся за нього одразу чи пропускаєте, і які докази змінили б це рішення після вашого першого сканування?

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

Стратегія трьох проходів також захищає вашу увагу. На іспиті CKS перемикання контексту коштує дорого, бо кожна тема використовує іншу лексику: дієслова й суб’єкти RBAC, селектори NetworkPolicy, рівні серйозності вразливостей образів, профілі системних викликів, етапи аудиту й поля подій під час виконання. Якщо ви дозволите порядку іспиту диктувати ваш ментальний порядок, ви платите цю вартість перемикання раз за разом. Групування роботи за складністю дає вам спокійніший ритм: спершу швидкі редагування, потім механіка інструментів, наприкінці розслідування.

Класифікуйте та оцінюйте складність завдань

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

Швидкі завдання часто використовують знайомі дієслова й вузькі області. «Встановіть runAsNonRoot» каже вам родину полів, об’єкт і очікуваний стан. «Надайте дозвіл переглядати pod’и» каже вам дієслово й ресурс RBAC. «Створіть NetworkPolicy, щоб дозволити трафік від застосунку A до застосунку B» все ще може потребувати обережності, але якщо обидва робочі навантаження в одному просторі імен, а мітки видно, ви можете швидко реалізувати й перевірити. Це ті завдання, які ви маєте бути голодні знайти рано.

Патерн	Приклад	Час
«Встановіть runAsNonRoot»	Додати поле до securityContext	1–2 хв
«Створіть NetworkPolicy, щоб дозволити…»	Одне правило ingress/egress	2–3 хв
«Надайте дозвіл на…»	Створити Role/RoleBinding	2–3 хв
«Застосуйте профіль AppArmor»	Встановити `appArmorProfile` у securityContext	1–2 хв
«Проскануйте образ за допомогою Trivy»	Запустити команду, повідомити висновки	2–3 хв

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

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

Патерн	Приклад	Час
«Створіть профіль seccomp»	Написати JSON, послатися в pod	4–5 хв
«Виправте всі провали kube-bench»	Кілька змін конфігурації	5–6 хв
«Налаштуйте PSA для простору імен»	Мітки + тестові pod’и	4–5 хв
«Обмежте ServiceAccount»	RBAC + налаштування automount	4–5 хв
«NetworkPolicy з кількома правилами»	Ingress + egress	5–6 хв

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

Складні завдання містять невизначеність, яку не можна усунути запам’ятовуванням однієї форми YAML. Розслідування під час виконання може вимагати читання подій, логів контейнерів, логів аудиту й слідів процесів, перш ніж ви дізнаєтеся, що виправляти. Власне правило Falco може провалитися через назви полів, макроси, пріоритет умов або саму тестову подію. Завдання ізоляції між кількома просторами імен може виглядати як вправа з NetworkPolicy, але вимагати ретельних міркувань про DNS, поведінку default deny й селектори простору імен.

Патерн	Приклад	Час
«Напишіть правило Falco для виявлення…»	Власна умова + вивід	7–10 хв
«Розслідуйте інцидент»	Прочитати логи, визначити причину, виправити	8–12 хв
«Посильте кластер на основі…»	Кілька компонентів	10–15 хв
«Ізолюйте скомпрометований pod»	NetworkPolicy + аналіз	8–10 хв

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

Практична нотатка з класифікації має бути достатньо короткою, щоб записати її, не перериваючи плину. Використовуйте функцію позначення прапорцем в інтерфейсі іспиту, коли вона доступна, і ведіть чорновий список на кшталт «Q3 seccomp, Q8 Falco, Q11 multi-ns netpol». Списку не потрібні повні речення. Його робота — допомогти вам повернутися до правильних завдань у правильній фазі, не перечитуючи кожне завдання з нуля.

Використовуйте документацію та шаблони інструментів, не втрачаючи плину

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

Початковий модуль перелічив цілі для закладок, які найбільше важать для цієї стратегії. Збережіть їх у своїй особистій рутині браузера й потренуйтеся переходити до відповідного підрозділу, а не просто впізнавати сторінку верхнього рівня. Для Kubernetes 1.35 і новіших версій звертайте особливу увагу на поточну форму Pod Security Standards, посилань на seccomp, документації AppArmor і семантики NetworkPolicy, бо старі нотатки можуть містити застарілі анотації або припущення.

# Bookmark these in exam browser:

# NetworkPolicy examples
kubernetes.io/docs/concepts/services-networking/network-policies/

# Pod Security Standards
kubernetes.io/docs/concepts/security/pod-security-standards/

# seccomp profiles
kubernetes.io/docs/tutorials/security/seccomp/

# AppArmor
kubernetes.io/docs/tutorials/security/apparmor/

# Trivy
aquasecurity.github.io/trivy/

# Falco
falco.org/docs/

Самі лише закладки не створюють швидкості. Швидкість походить від знання, навіщо ви відкрили сторінку, ще до її завантаження. Якщо ви відкриваєте документацію NetworkPolicy, ви маєте вже знати, чи потрібен вам приклад podSelector, приклад namespaceSelector, приклад egress чи нагадування про поведінку default deny. Якщо ви відкриваєте посібник seccomp, ви маєте вже знати, чи відсутньою частиною є розміщення профілю, чи посилання у специфікації Pod.

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

# Trivy scan
trivy image --severity HIGH,CRITICAL <image>

# kube-bench
./kube-bench run --targets=master

# Check AppArmor profiles
cat /sys/kernel/security/apparmor/profiles

# Check seccomp support
grep SECCOMP /boot/config-$(uname -r)

# Audit logs location
/var/log/kubernetes/audit.log

Шаблонні команди корисні, бо вони не дають вам марнувати час на правопис і пригадування опцій. Вони не є заміною читанню завдання. Якщо завдання просить лише критичні вразливості, фільтр серйозності Trivy має значення. Якщо воно просить висновок kube-bench на робочих нодах, ціль площини управління — це хибна ціль. Скопійована команда, яка відповідає на трохи інше питання, все одно хибна.

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

# Memorize this pattern
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

Цей патерн навмисно консервативний, але він не є універсально безпечним. Скидання всіх можливостей (capabilities) може зламати програмне забезпечення, якому потрібна конкретна можливість, а readOnlyRootFilesystem може зламати образи, які пишуть у шляхи без змонтованих томів. Завдання іспиту зазвичай каже вам, яка поведінка має значення, тож використовуйте шаблон як відправну точку, а потім адаптуйте його під точну вимогу. Відповідь, що виглядає як від сеньйора, але ігнорує обмеження застосунку, може втратити ті самі бали, що й відсутнє поле.

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

# Default deny all ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

# Allow specific pod
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api
    ports:
    - port: 80

Який підхід ви обрали б тут і чому: написати NetworkPolicy з пам’яті спершу чи оглянути живі мітки Pod перед чернеткою? Безпечніша відповідь — спершу оглянути мітки, бо політику оцінюють за тим, що вона вибирає, а не за тим, чи виглядає YAML як знайомий приклад. Якщо у вас уже запам’ятований шаблон, огляд міток — це невелика попередня витрата, яка запобігає тихому нулю.

Створіть чек-лист дня іспиту та цикл перевірки

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

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

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

Інструмент	Розташування на іспиті
Trivy	Попередньо встановлено або надано
Falco	Працює в кластері або встановлюється
kube-bench	Завантаження або маніфест Job
kubesec	Може потребувати завантаження

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

Файл	Шлях
Маніфест API-сервера	`/etc/kubernetes/manifests/kube-apiserver.yaml`
Конфігурація kubelet	`/var/lib/kubelet/config.yaml`
Політика аудиту	`/etc/kubernetes/audit-policy.yaml`
Профілі seccomp	`/var/lib/kubelet/seccomp/`
Профілі AppArmor	`/etc/apparmor.d/`

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

Зупиніться й подумайте: ви витрачаєте 20 хвилин на складне завдання з правилом Falco під час Проходу 1, доводите його до часткової роботи, але тепер маєте лише 55 хвилин на решту 12 завдань. Обчисліть ваш імовірний фінальний бал проти прохідного порогу 67%, перш ніж вирішувати, чи продовжувати.

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

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

# For pods/deployments
kubectl get pods -n <namespace>  # Running?

# For NetworkPolicy
kubectl describe networkpolicy <name>  # Applied?

# For RBAC
kubectl auth can-i <verb> <resource> --as=<user>  # Works?

# For security context
kubectl get pod <name> -o yaml | grep -A 10 securityContext

# For Trivy
trivy image <image>  # Scans correctly?

Найкращі команди перевірки — швидкі й конкретні. Для RBAC kubectl auth can-i краще, ніж перечитування Role, бо вона запитує рівень авторизації про те, що насправді важить для завдання. Для securityContext відображена специфікація Pod краща, ніж буфер вашого редактора, бо допуск і значення за замовчуванням можуть змінити те, що насправді існує. Для NetworkPolicy команда describe — це початок, але реальний тест зв’язності сильніший, коли дозволяє час.

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

Виконайте опрацьований приклад першого сканування

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

Сканування починається із завдання A — завдання RBAC, що просить ServiceAccount переглядати Pod’и в одному просторі імен. Ви можете назвати ймовірні об’єкти, перевірку простору імен і команду перевірки ще до відкриття редактора, тож це Прохід 1. Завдання B просить runAsNonRoot і числового користувача на наявному шаблоні Pod, що теж є Проходом 1, якщо обмеження образу зрозуміле. Завдання C просить власне правило Falco з умовою, яку ви нещодавно не відпрацьовували, тож воно стає Проходом 3, навіть якщо цінність у балах виглядає привабливою.

Завдання	Сигнал першого сканування	Прохід	Ідея перевірки
A	Один ServiceAccount, одне дієслово, один ресурс	Прохід 1	`kubectl auth can-i`
B	Два поля securityContext на одному робочому навантаженні	Прохід 1	Відрендерена специфікація Pod і стан running
C	Власна умова Falco з незнайомим полем	Прохід 3	Подія-тригер і вивід Falco
D	Сканування образу Trivy з вимогою серйозності	Прохід 1	Вивід сканера містить запитану серйозність
E	Профіль seccomp з нуля	Прохід 2	Pod посилається на профіль і запускається
F	Перевірка kube-bench з редагуванням статичного Pod	Прохід 2	Висновок зникає після перезапуску компонента
G	NetworkPolicy між кількома просторами імен із DNS egress	Прохід 3	Позитивний і негативний тести зв’язності
H	Мітка Pod Security Admission і тестове навантаження	Прохід 2	Мітки простору імен і поведінка допуску

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

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

Завдання F має інший вид невизначеності. Вивід kube-bench може бути дуже прямим, але виправлення може торкатися маніфесту статичного Pod або конфігурації kubelet і вимагати очікування, доки компонент стабілізується. Цей час очікування належить до оцінки. Кандидат, який швидко редагує, але забуває про вартість перезапуску й перевірки, раз за разом недооцінюватиме завдання бенчмарка, що створює тиск пізніше, коли годинник уже поглинув приховану вартість.

Завдання G класифіковане як складне, бо робота з NetworkPolicy між кількома просторами імен має кілька тихих режимів відмов. namespaceSelector може збігтися з хибним простором імен, podSelector може не збігтися з жодним Pod, правило egress може заблокувати DNS, а політика default deny може змінити несумісний трафік, якщо селектор надто широкий. Жодна з цих помилок не обов’язково створює синтаксичну помилку. Завдання все ще може бути вартим розв’язання, але воно заслуговує на пізніший слот, де ви зможете протестувати і дозволені, і заборонені шляхи.

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

Після цього сканування розумна чорнова нотатка могла б звучати так: «A RBAC, B context, D Trivy спершу; H PSA, E seccomp, F bench другими; C Falco, G netpol наприкінці». Ця нотатка коротка, але містить достатньо структури, щоб порядок іспиту не захопив керування. Вона також дає вам план відновлення, якщо швидке завдання несподівано застрягне: зупиніться після однієї невдалої перевірки, позначте завдання прапорцем і беріть наступний швидкий пункт, замість того щоб перетворювати перший прохід на сеанс налагодження.

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

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

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

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

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

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

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

Тип	Поведінка	Коли це допомагає	Ризик, якщо знехтувати
Патерн	Класифікувати перед розв’язанням	Перше сканування і після будь-якого довгого завдання	Складні завдання поглинають легкі бали першими
Патерн	Перевіряти стан, видимий системі оцінювання	Перед тим, як залишити кожне завершене завдання	Правильний на вигляд YAML може нічого не вибрати
Патерн	Використовувати документацію для синтаксису, а не для навчання	Коли знайомий патерн потребує точних полів	Пошук у документації стає головним завданням
Антипатерн	Сприймати порядок завдань як порядок пріоритетів	Щоразу, коли перше завдання складне	Послідовність іспиту керує вашою стратегією балів
Антипатерн	Продовжувати через безповоротні витрати	Після десяти хвилин без перевіреного стану	Одне часткове завдання блокує кілька завершених
Антипатерн	Застосовувати шаблони, не оглянувши мітки	Завдання NetworkPolicy і RBAC	Об’єкт існує, але впливає на хибну ціль

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

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

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

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

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

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

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

Чи знали ви?

Прохідний бал 67% означає, що досконалість не обов’язкова. Ваш план має максимізувати перевірені бали, а не емоційне задоволення від розв’язання кожного складного завдання.
Тривалість іспиту CKS — 2 години. Десятихвилинне відхилення може поглинути той самий час, що й кілька швидких завдань RBAC, securityContext чи сканування.
Доступ до відкритих матеріалів змінює навичку, яку перевіряють. Іспит винагороджує швидку навігацію до точної документації виробника, а не повільне навчання з нуля.
Завдання безпеки часто мають кілька правильних реалізацій. Фінальна поведінка кластера важить більше, ніж збіг із запам’ятованою послідовністю команд.

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

Помилка	Чому це трапляється	Як це виправити
Починати зі складних завдань	Перше завдання відчувається як обов’язковий пріоритет	Спершу скануйте, позначайте складні завдання прапорцями й захищайте швидкі виграші перед глибокою роботою
Не дочитувати завдання повністю	Знайомі ключові слова роблять розв’язок очевидним надто рано	Переформулюйте фінальний стан, простір імен і команду перевірки перед набором
Забувати про простір імен	Тренувальні кластери часто використовують значення за замовчуванням, а завдання іспиту рідко	Вставляйте `-n namespace` у кожну доречну команду й перевіряйте розташування об’єкта
Не перевіряти	Застосування YAML дає хибне відчуття завершеності	Перевіряйте поведінку, видиму системі оцінювання, перед переходом до наступного завдання
Надмірна інженерія	Інстинкти безпеки штовхають до найсильнішого контролю, а не запитаного	Відповідайте завданню точно, потім додавайте лише те, що потрібно для заявленого результату
Використовувати документацію як підручник	Доступ до відкритих матеріалів відчувається як страховка	Відпрацьовуйте поширені патерни, доки документація потрібна лише для підтвердження синтаксису
Дозволяти аліасам проникати у скрипти	Інтерактивні скорочення відчуваються швидшими під час тренування	Використовуйте повний `kubectl` у виконуваних сніпетах, збережених нотатках і скриптах іспиту

Тест

Питання 1: Ви рівно 30 хвилин на іспиті CKS і завершили шість завдань: два виправлення RBAC, дві базові NetworkPolicy, одну зміну securityContext і одне сканування Trivy. Наступне завдання просить створити власний профіль seccomp з нуля й застосувати його до deployment. Як вам застосувати стратегію трьох проходів у цей момент?

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

Питання 2: Таймер іспиту показує 30 хвилин, що залишилися. Ви завершили 12 із 17 завдань, залишивши власне правило Falco, розслідування інциденту під час виконання, NetworkPolicy між кількома просторами імен, виправлення kube-bench і налаштування Pod Security Admission. Як вам оцінити складність завдань і розставити пріоритети на фінальному відрізку?

Розставте пріоритети спершу для Pod Security Admission і виправлення kube-bench, якщо ви відпрацьовували обидва патерни, бо вони передбачуваніші за правило Falco чи відкрите розслідування інциденту. NetworkPolicy між кількома просторами імен може бути вартою, якщо мітки й вимоги зрозумілі, але її варто обмежити часовим вікном, бо помилки селекторів можуть бути тихими. Falco й реагування на інцидент мають почекати, доки передбачувані завдання не будуть завершені або явно заблоковані. Мета — не уникнути важкої роботи; вона в тому, щоб обрати найкращу віддачу балів за хвилину з часом, що залишився.

Питання 3: Ви застосовуєте NetworkPolicy для завдання, що коштує 6% від загального балу, припускаєте, що вона працює, бо YAML застосувався без синтаксичних помилок, і одразу йдете далі. Під час фінального огляду ви виявляєте, що мітку селектора pod написано з помилкою. Якою була вартість пропуску перевірки?

Імовірна вартість — повна цінність цього завдання, бо NetworkPolicy, яка не вибирає жодного призначеного pod, не забезпечує запитану поведінку. Парсер YAML підтвердив лише синтаксис, а не ефект безпеки. Швидка команда перевірки на кшталт kubectl describe networkpolicy плюс перевірка мітки викрила б невідповідність, перш ніж ви пішли далі. Саме тому час на перевірку має бути включений у бюджет завдання, а не сприйматися як необов’язковий огляд.

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

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

Питання 5: Вам потрібно створити особистий чек-лист дня іспиту перед фінальним пробним іспитом. Які пункти мають бути в ньому, а які мають залишитися поза ним?

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

Питання 6: Завдання просить обмежити робоче навантаження за допомогою securityContext, і ви пам'ятаєте посилений шаблон, який скидає всі можливості й встановлює readOnlyRootFilesystem. Завдання просить лише runAsNonRoot і конкретний runAsUser. Що вам робити?

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

Питання 7: Під час тренування виправлення kube-bench займає у вас 13 хвилин, хоча ви класифікували його як середнє завдання Проходу 2. Як вам скоригувати стратегію перед справжнім іспитом?

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

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

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

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

Класифікуйте кожен пункт дриля як Прохід 1, Прохід 2 чи Прохід 3 перед запуском команди.
Завершіть щонайменше чотири з п’яти хронометражних завдань за 15 хвилин.
Перевірте кожне завершене завдання командою, яка перевіряє фінальний стан кластера.
Запишіть будь-яке завдання, що перевищило вашу оцінку більш ніж на 2 хвилини.
Створіть особистий чек-лист дня іспиту, що охоплює налаштування середовища та скорочення для kubectl.
Спроєктуйте бюджет часу для вашого наступного повного тренувального проходу на основі результатів хронометражу.

Запропонований підхід до розв'язання для хронометражного дриля

Сприймайте завдання 1, 2 і 3 як роботу Проходу 1, бо це вузькі редагування об’єктів із прямою перевіркою. Сприймайте завдання 4 як Прохід 1, лише якщо Trivy встановлений і знайомий; інакше позначте його як висновок про доступність інструмента й продовжуйте. Сприймайте завдання 5 як Прохід 1, якщо профіль AppArmor уже доступний, а завдання просить лише поле appArmorProfile, але перемістіть його до Проходу 2 в середовищі, де потрібне завантаження профілю чи огляд ноди.

# Simulate exam conditions:
# Set a 15-minute timer for these 5 tasks
# START YOUR TIMER NOW!

# Task 1 (2 min): Create NetworkPolicy
kubectl create namespace secure

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: secure
spec:
  podSelector: {}
  policyTypes:
  - Ingress
EOF

# Verify:
kubectl get networkpolicy -n secure

# Task 2 (2 min): Fix security context
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: insecure-pod
  namespace: secure
spec:
  containers:
  - name: app
    image: busybox
    command: ["sleep", "3600"]
    securityContext:
      runAsUser: 1000
      runAsNonRoot: true
EOF

# Verify:
kubectl get pod insecure-pod -n secure -o jsonpath='{.spec.containers[0].securityContext}'
echo ""

# Task 3 (3 min): RBAC
kubectl create serviceaccount app-sa -n secure

cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: secure
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: secure
subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: secure
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
EOF

# Verify:
kubectl auth can-i list pods -n secure --as=system:serviceaccount:secure:app-sa

# Task 4 (4 min): Trivy scan
# (Requires Trivy installed - skip if not available)
trivy image --severity CRITICAL nginx:1.20 2>/dev/null || echo "Trivy not installed - would scan for CVEs"

# Task 5 (4 min): AppArmor (Kubernetes 1.35+ GA field)
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: secure
spec:
  containers:
  - name: web
    image: nginx:alpine
    securityContext:
      runAsNonRoot: false  # nginx needs root initially
      appArmorProfile:
        type: RuntimeDefault
EOF

# Verify the GA field is set (not the legacy annotation API):
kubectl get pod web -n secure -o jsonpath='{.spec.containers[0].securityContext.appArmorProfile}'
echo ""

# Verify confinement is active (should not show "unconfined"):
kubectl exec web -n secure -- cat /proc/1/attr/current

# Verify enforcement: RuntimeDefault blocks mounting new filesystems
kubectl exec web -n secure -- sh -c 'mount -t tmpfs tmpfs /mnt 2>&1' | grep -Ei 'permission denied|operation not permitted|not permitted'
echo ""

# STOP TIMER - How did you do?
echo "=== Task Summary ==="
kubectl get networkpolicy,pods,role,rolebinding,sa -n secure

# Cleanup
kubectl delete namespace secure

Як інтерпретувати ваш результат

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

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

Перевірка засвоєння

Корисна ментальна модель — це радше табло, ніж чек-лист. Чек-лист запитує: «Чи зробив я наступний пункт?» Табло запитує: «Скільки балів я захистив, скільки часу залишилося і яке завдання має найкращу віддачу зараз?»

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

Джерела

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

Модуль 1.1: Мережеві політики — почніть Частину 1, перетворивши стратегію іспиту на конкретні навички мережевої ізоляції.