Las tres lecciones anteriores han cubierto qué entra en cada certificación. Esta cubre cómo se aprueba. Es la lección de técnica, y es común al CKA, al CKAD y al CKS, porque los tres comparten el mismo formato: un terminal en el navegador, un supervisor remoto mirando, unas quince tareas y un reloj que corre.

Hay gente que sabe Kubernetes de sobra y suspende. Las causas son casi siempre las mismas y ninguna es técnica: no cambiar de contexto, escribir YAML a mano, atascarse quince minutos en una tarea de cuatro puntos, no verificar lo hecho, o llegar al examen con una webcam que no funciona. Todo eso se previene, y prevenirlo es exactamente el objeto de esta lección.

Aviso. Los requisitos del entorno de supervisión, la política de reintentos, la duración de la validez y el procedimiento de identificación cambian con el tiempo. Lo que sigue es orientativo. Consulta siempre el Candidate Handbook y las condiciones vigentes en la web de la Linux Foundation / CNCF antes de reservar tu examen.

1. Antes del examen: entorno, identificación y reserva de fecha
2. Los primeros 60 segundos: preparación del terminal
3. Uso eficaz de la documentación permitida
4. Gestión del tiempo durante el examen
5. Los errores que más puntos cuestan
6. El hábito de verificar cada tarea
7. Preparación mental y física
8. Si algo va mal durante la prueba
9. Después del examen: resultado, repaso, renovación y cómo demostrarla

El examen se hace desde tu propio ordenador, con un supervisor humano observando por webcam durante toda la prueba. Los requisitos son estrictos y se comprueban antes de empezar. Si algo falla, el examen no arranca y puedes perder la sesión.

El proveedor de supervisión ofrece una comprobación del sistema (system check) que se puede ejecutar en cualquier momento. Es gratuita y detecta problemas de cámara, micrófono, ancho de banda y bloqueos del navegador.

Hazla dos veces:

1. El día que reserves la fecha, para tener margen si algo falla.
2. El día antes del examen, en el mismo sitio, con el mismo equipo y a la misma hora del día que tendrás la prueba (la red de casa no se comporta igual a las 9:00 que a las 22:00).

Problemas frecuentes y su arreglo:

Reserva 30 minutos antes de la hora oficial. El proceso de admisión suele consumir 10-15 minutos y el reloj del examen no empieza hasta que el supervisor te da paso, pero llegar con prisas es la peor forma de empezar.

Secuencia típica:

1. Entras en la sala virtual desde tu cuenta de la Linux Foundation.
2. Muestras el documento de identidad a la cámara.
3. Muestras la sala con la webcam: mesa, suelo bajo la mesa, paredes, techo.
4. Muestras tus muñecas y orejas (no se permiten relojes inteligentes ni auriculares).
5. Cierras todas las aplicaciones salvo el navegador del examen.
6. El supervisor te da acceso al terminal y empieza el tiempo.

La matrícula suele incluir un segundo intento gratuito (free retake) si suspendes el primero. Verifica las condiciones vigentes: puede haber plazos y limitaciones.

Por qué conviene reservar la fecha antes de sentirte listo:

Este es probablemente el consejo más útil de toda la lección. La razón no es psicológica sino estructural:

• Sin fecha, no hay plan. El estudio sin fecha se dilata indefinidamente. Con fecha, el plan de seis semanas de la lección 12-01 se convierte en un calendario real.
• La sensación de "estar listo" no llega nunca. El examen es práctico y siempre habrá un procedimiento que no dominas del todo. Si esperas a la certeza, no te presentas nunca.
• Existe el segundo intento. El coste de fallar el primero es tiempo, no dinero. Y un primer intento fallido es la mejor sesión de estudio posible: sales sabiendo exactamente qué te falta.
• La fecha se puede mover. Normalmente se puede reprogramar con antelación suficiente (revisa el plazo exacto, suele rondar las 24 horas). Reservar no es un compromiso irreversible.

Estrategia recomendada: reserva la fecha para seis a ocho semanas vista el día que empieces a estudiar en serio. Y si a mitad de camino ves que no llegas, la mueves.

Hora del día: elige una franja en la que estés despierto y la casa esté tranquila. Dos horas de concentración continua sin descansos no son triviales. Evita justo después de comer.

Nada más ver el terminal, antes de leer la primera tarea, teclea este bloque. Son unos 40 segundos que te devuelven entre 15 y 25 minutos a lo largo del examen.

Qué hace cada línea:

Nota importante: en el CKA y el CKS puedes acabar trabajando en varios nodos por ssh. El alias no viaja con la sesión ssh. Cuando entres en un nodo, o repites el bloque, o simplemente escribes kubectl completo. Ten presente que el $do tampoco existe allí.

Si esto sale bien, el arsenal está listo.

Segundo bloque, igual de rentable. Escríbelo antes de abrir el primer YAML:

Alternativa rápida sin fichero: si prefieres no crear ~/.vimrc, dentro de vim puedes teclear:

Pero hacerlo una vez en ~/.vimrc es más seguro que acordarte en cada fichero.

Practica esto la semana antes del examen. El día de la prueba no es momento de recordar cómo se borran cinco líneas.

Dos estrategias válidas. Elige una y sé consistente:

La A ahorra tiempo pero exige cambiarlo al empezar cada tarea nueva. La B es imposible de olvidar pero cuesta segundos. Muchos candidatos usan la A y, en la revisión final, comprueban cada objeto con su -n explícito.

La interfaz del examen incluye un bloc de notas. Úsalo desde el minuto uno para llevar la lista de tareas:

Sin esta lista, en el minuto 100 no recordarás qué dejaste pendiente ni cuál valía más.

Prohibido en todos: buscadores generales, foros, GitHub, notas propias, otras webs, herramientas de IA, cualquier fichero local que no sea del clúster. Se permite una sola pestaña adicional además de la del examen.

Verifica la lista exacta de dominios permitidos en el handbook oficial: ha cambiado entre revisiones del programa.

El buscador propio del sitio es lento y a menudo devuelve resultados poco útiles. Dos técnicas mejores:

Técnica 1 — URL directa. Muchas páginas tienen rutas predecibles:

Técnica 2 — Ctrl+F dentro de la página. Una vez en la página correcta, busca la palabra del campo que necesitas (fsGroup, startingDeadlineSeconds, emptyDir) en vez de leerla entera.

Esta es tu chuleta mental. Memoriza la palabra de búsqueda, no la URL.

Compara los dos caminos para una NetworkPolicy:

Camino A — escribirla a mano:

Camino B — copiar y adaptar:

Tres veces más rápido y con una fracción del riesgo. Y el corrector no distingue si lo escribiste o lo copiaste: solo mira el estado del clúster.

Los objetos que más se benefician de este enfoque (los que no tienen generador imperativo):

• PersistentVolume y PersistentVolumeClaim
• NetworkPolicy
• StorageClass
• securityContext completo
• Sondas con todos sus campos
• Política de auditoría
• EncryptionConfiguration
• RuntimeClass
• Perfiles seccomp

Para dudas puntuales de un campo, esto es más rápido que ir al navegador:

Y para recordar la versión de API correcta:

k api-resources es la respuesta a "¿cuál era el apiVersion de esto?" en dos segundos.

Dedica los primeros 4-5 minutos a leer TODAS las tareas sin resolver ninguna. Parece contraintuitivo, pero es la inversión más rentable del examen.

Mientras lees, anota en el bloc de notas para cada tarea:

Resultado típico:

Ahora tienes un mapa. Sin él, vas a ciegas.

Fase 1 (minutos 5-40): las baratas. Todas las F, en el orden en que aparecen. Son puntos rápidos y garantizados, y te ponen en ritmo. Psicológicamente, empezar acumulando aciertos cambia el examen entero.

Fase 2 (minutos 40-95): el bloque central. Las M y las D, priorizando por peso. Aquí es donde se decide el aprobado. Las de mayor peso van en este bloque porque necesitas tiempo y cabeza fresca, pero no tan al final que te pille el reloj.

Fase 3 (minutos 95-110): las pendientes. Vuelves a las saltadas y a las medio hechas. Con lo aprendido en las otras tareas, a menudo la solución es evidente ahora.

Fase 4 (minutos 110-120): revisión. Ni una tarea nueva. Solo comprobar.

Regla dura: si una tarea supera su tiempo objetivo en más de un 50 %, la marcas y la dejas.

Por qué esto funciona: una tarea del 4 % en la que llevas 12 minutos te ha costado el equivalente a dos tareas del 5 % que habrías resuelto. La aritmética es implacable: el examen no premia la perseverancia, premia el rendimiento por minuto.

Cómo saltar bien:

1. Deja hecho lo que hayas conseguido (puntuación parcial).
2. Anótalo en el bloc con una nota de dónde te atascaste.
3. Pasa a la siguiente sin darle vueltas.

Volver más tarde con la cabeza despejada resuelve la mitad de los atascos.

Prohibido empezar una tarea nueva. Ese tiempo es para:

Comprobaciones concretas de la revisión:

Encontrar un solo objeto en el namespace equivocado en esta revisión ya paga los diez minutos.

Por orden de daño causado.

El error número uno, y el más caro: puntuación cero en una tarea resuelta perfectamente.

Cada tarea empieza con su comando de contexto. Cópialo y ejecútalo siempre, aunque creas que es el mismo de la tarea anterior.

Hábito a entrenar: el use-context es el primer comando, antes incluso de terminar de leer el enunciado. Que sea automático.

El segundo error más caro, y por la misma razón: el objeto se crea en default y el corrector no lo encuentra.

O -n en todos los comandos. Pero una de las dos, siempre.

Caso especial: los objetos de ámbito de clúster (PersistentVolume, StorageClass, ClusterRole, ClusterRoleBinding, Namespace, RuntimeClass, PriorityClass, IngressClass) no llevan namespace. Ponerles uno no da error, simplemente se ignora, pero saber cuáles son evita confusión.

Situación típica: creas el Deployment, te distraes con el Service, y el Deployment queda con la imagen equivocada. O aplicas un YAML con un error y no miras el resultado.

Si hubiera salido error validating data: ValidationError..., la tarea no está hecha. Lee la salida de cada comando.

Que un objeto exista no significa que funcione. Los casos que más puntos cuestan:

La regla: una comprobación por tarea, siempre.

Ya está tratado en el apartado 3.4, pero conviene repetirlo porque es el error que más silenciosamente arruina exámenes. No suspendes por él directamente: suspendes porque te faltaron tres tareas por hacer.

La jerarquía de velocidad, de más rápido a más lento:

Cada tarea debe seguir esta secuencia, sin excepción:

El paso 3 no es opcional. Cuesta 5-10 segundos y detecta la mitad de los errores antes de que sea tarde.

Además de verificar tú, hay tareas que piden explícitamente guardar un resultado en un fichero. Esas son puntuación directa y se fallan por descuido:

Error clásico: el comando falla, el fichero se crea vacío por la redirección, y tú no lo miras. Un cat de un segundo lo evita.

No estudies contenido nuevo las últimas 48 horas. No se consolida y aumenta la ansiedad. Lo que ya sabes es lo que llevarás.

Los simulacros solo sirven si son realistas:

• Dos horas seguidas, sin pausas, sin móvil, sin levantarte.
• Solo la documentación permitida abierta. Nada de buscar en Google "cómo se hacía esto".
• En el mismo sitio, con el mismo equipo que usarás el día del examen.
• Corrigiendo al final, no sobre la marcha.

La lección 12-05 de este curso es exactamente eso: un simulacro completo con quince tareas cronometradas y su solucionario.

Qué medir en cada simulacro:

Detalles que parecen menores y no lo son:

• El mismo teclado. Si practicas en un teclado y examinas en otro, pierdes velocidad y cometes erratas.
• La misma disposición de teclado (español, inglés). Los caracteres |, \, {, }, " y - aparecen constantemente en YAML y comandos.
• El mismo navegador y la misma resolución.
• Practica copiar y pegar en un terminal web. Los atajos (Ctrl+Shift+C/Ctrl+Shift+V) son distintos de los del terminal nativo, y el día del examen no es momento de descubrirlo.
• Practica con la pantalla partida: terminal a la izquierda, documentación a la derecha. Es como trabajarás.

• Los primeros minutos son los peores. Es normal. La pasada de lectura inicial ayuda precisamente aquí: te da control antes de teclear.
• Si una tarea te bloquea, sáltala. No es un fracaso, es la estrategia correcta.
• No calcules tu nota mentalmente durante la prueba. Distrae y casi siempre es pesimista.
• Respira antes de tocar algo crítico. Sobre todo antes de editar el apiserver en el CKS.
• Acepta la imperfección. Con un umbral en torno al 66 %, puedes fallar un tercio del examen y aprobar.

Importante: si algo falla por causa de la plataforma, avisa al supervisor en el momento, no al terminar. Deja constancia. Reclamar después de acabar, sin registro durante la sesión, tiene pocas opciones.

Durante todo el examen hay un chat en la interfaz. Es el canal oficial.

Escribe en inglés y sé concreto: número de tarea y síntoma. El supervisor no puede darte pistas sobre el contenido, pero sí resolver problemas de plataforma.

También puedes usar el chat para:

• Pedir permiso para beber agua (según normas).
• Avisar de un ruido inevitable en tu entorno.
• Comunicar cualquier interrupción externa.

Nunca: preguntes nada sobre el contenido de las tareas. La respuesta será negativa y consume tu tiempo.

Faltas que pueden invalidar el examen y que la gente comete sin mala intención:

• Hablar en voz alta o leer los enunciados murmurando. El micrófono lo capta.
• Mirar fuera de la pantalla repetidamente.
• Levantarse sin autorización.
• Que entre alguien en la sala.
• Tener el móvil a la vista, aunque esté apagado.
• Llevar auriculares o reloj inteligente.
• Tomar notas en papel.

Avisa a quien conviva contigo, cierra la puerta y deja el móvil en otra habitación.

• El resultado llega por correo, normalmente en un plazo de hasta 24 horas (orientativo; verifica el plazo vigente).
• Recibes la puntuación global y, si suspendes, un desglose por dominio con tu rendimiento en cada uno.
• Si apruebas, recibes el certificado en PDF y un badge digital verificable.

No es un drama y es más común de lo que parece. La matrícula suele incluir un segundo intento gratuito.

Plan de acción:

1. El mismo día, escribe lo que recuerdes. Qué tipos de tarea aparecieron, cuáles te bloquearon, dónde perdiste tiempo. Esa información se evapora en 48 horas y es oro puro.
2. Lee el desglose por dominio. Te dice exactamente dónde fallaste.
3. Diagnostica la causa real, que casi siempre es una de estas tres:

4. Reserva el segundo intento a 3-4 semanas vista. Ni antes (no da tiempo a corregir) ni mucho después (pierdes el estado de forma).
5. Trabaja solo lo que falló. No repitas el temario entero.

Consejo de calendario: apunta la fecha de caducidad el mismo día que apruebas, con un recordatorio a cuatro meses antes. Te da margen para preparar la renovación sin agobios.

Y ten en cuenta que la renovación no es solo burocracia: Kubernetes cambia rápido, y el temario del examen se actualiza con las versiones. Renovar es una forma de mantenerte al día.

Consejo práctico: incluye siempre el enlace de verificación. Distingue una certificación real de una afirmación, y los reclutadores técnicos lo agradecen.

Aprobar no es el final del recorrido:

• Aplícalo. Una certificación sin práctica se oxida en meses. Sigue operando clústeres.
• Encadena. Si tienes el CKAD, el CKA está a un paso. Si tienes el CKA, el CKS es la especialización natural.
• Amplía al ecosistema. El CNCF ofrece otras certificaciones (Prometheus, Istio, Argo, GitOps, y las de nivel introductorio como KCNA y KCSA). Repasa el módulo 10 para ver dónde encaja cada herramienta.
• Mantén un clúster propio. Un kind o un minikube en tu portátil es suficiente para no perder los reflejos.

1. Reserva la fecha antes de sentirte listo. Sin fecha no hay plan.
2. Los primeros 60 segundos valen 20 minutos: alias, $do, autocompletado, .vimrc.
3. Lee todas las tareas antes de resolver ninguna. Cinco minutos que ordenan las dos horas.
4. Copiar de la documentación es la estrategia correcta, no un atajo vergonzoso.
5. El ciclo es contexto → resolver → verificar. Siempre los tres pasos.
6. Saltar es una decisión estratégica, no una rendición.
7. Los últimos 10 minutos son para revisar, nunca para una tarea nueva.
8. Simula el examen entero al menos dos veces antes del día real.
9. Si suspendes, escribe lo que recuerdes el mismo día y usa el segundo intento en 3-4 semanas.
10. Apunta la caducidad el día que apruebas.

En un terminal limpio (contenedor, VM o sesión nueva), y con cronómetro:

1. Teclea de memoria el bloque completo de alias, variables y autocompletado.
2. Crea el ~/.vimrc con los siete ajustes.
3. Demuestra que funciona: genera con $do el YAML de un pod, ábrelo en vim, pega dentro un bloque de securityContext copiado de la documentación, guárdalo y aplícalo.

Objetivo: menos de 3 minutos en total, sin consultar nada.

Repítelo cinco días seguidos hasta que salga sin pensar.

Te dan este listado de tareas de un examen imaginario. Sin resolverlas, elabora tu plan de ataque: orden, tiempo asignado a cada una y en qué fase la abordarías.

Construye tu propia tabla de "necesito X → busco Y en kubernetes.io", con al menos 20 entradas, ordenada por frecuencia esperada en tu examen (CKA, CKAD o CKS).

Después, verifica cada entrada: abre kubernetes.io, busca el término que anotaste y comprueba que el primer o segundo resultado es la página que necesitas. Corrige los términos que no funcionen.

Solución al Ejercicio 1

Dentro de vim, pegando el bloque copiado de la documentación:

Autoevaluación: si has tardado más de 3 minutos, identifica dónde. Lo habitual es dudar en la línea de complete -o default o pelearse con vim. Ambas cosas se arreglan repitiendo.

La trampa del ejercicio: si al pegar en vim el YAML queda en escalera, es que set paste no estaba activo. Comprueba con :set paste? dentro de vim.

Solución al Ejercicio 2

Total: 100 %, 15 tareas, 120 minutos.

Clasificación por dificultad típica y tiempo objetivo:

Reparto temporal:

Análisis del plan:

• La fase 1 asegura 23 puntos en 22 minutos, algo más de un punto por minuto. Es el mejor rendimiento del examen y por eso va primero.
• Las cuatro tareas de mayor peso (2, 5, 9, 14) suman 35 puntos y unos 44 minutos. Son las que deciden. Van en el bloque central, no al final.
• Con 23 (fase 1) + 35 (las cuatro grandes) = 58 puntos, aún no apruebas. Necesitas también las medias: 7, 12, 15, 11 y 4 suman 32 puntos más. Ese es el margen real.
• Si las tareas 5 (etcd) y 14 (upgrade) se atascan, el límite duro de 15 minutos evita que se lleven 40 minutos entre las dos.

El error que este ejercicio previene: empezar por la tarea 1 y seguir en orden. Llegarías a la tarea 5 (10 %) sobre el minuto 30 con la cabeza fresca —eso está bien—, pero la tarea 9 (9 %) y la 14 (8 %) caerían al final, con prisa y cansancio. Y las fáciles del final (10, 13) podrían quedarse sin hacer, regalando 7 puntos que costaban 7 minutos.

Solución al Ejercicio 3

Extracto de una chuleta para el CKA, ordenada por frecuencia esperada:

El valor del ejercicio está en el paso de verificación. Términos que parecen obvios a menudo no llevan a la página correcta: buscar "backup etcd" da resultados dispersos, mientras que "operating etcd clusters" lleva directo. Descubrir eso ahora vale minutos el día del examen.

Consejo adicional: para el CKS, añade una segunda tabla con falco.org/docs (sintaxis de reglas, lista de campos %evt.* y %container.*) y aquasecurity.github.io/trivy (flags de severidad y formatos de salida).

El conocimiento técnico es condición necesaria para aprobar el CKA, el CKAD o el CKS, pero no suficiente. El formato del examen —práctico, cronometrado, con varios clústeres y supervisión remota— añade una capa de dificultad que se prepara aparte, y que es exactamente lo que has trabajado en esta lección.

Lo que debes llevarte:

• Antes: comprueba el sistema dos veces, prepara la sala y el documento de identidad, y reserva la fecha antes de sentirte listo —sin fecha no hay plan, y existe el segundo intento.
• Los primeros 60 segundos: alias k, $do, $now, autocompletado y ~/.vimrc con set paste. Cuarenta segundos que devuelven veinte minutos.
• La documentación permitida es una herramienta, no una muleta: copiar un ejemplo y adaptarlo es tres veces más rápido y mucho más seguro que escribir un manifiesto desde cero.
• El tiempo se gestiona en cuatro fases: leer todo, resolver lo barato, atacar el bloque central por peso, y revisar. Con límite duro por tarea y sin remordimientos al saltar.
• Los errores más caros no son técnicos: no cambiar de contexto, no fijar el namespace, dejar objetos a medias, no comprobar que funcionan y escribir YAML a mano.
• El ciclo de cada tarea es siempre el mismo: contexto → resolver → verificar. Los tres pasos, sin excepción.
• Prepárate también física y mentalmente: simulacros realistas, entorno idéntico, descanso, y nada de temas nuevos las últimas 48 horas.
• Si algo va mal, avisa al supervisor en el momento, por el chat y en inglés.
• Después: lee el desglose por dominio si suspendes, diagnostica si el problema fue conocimiento, velocidad o proceso, y apunta la fecha de caducidad el mismo día que apruebas.
• Consulta siempre el Candidate Handbook y las condiciones vigentes antes de reservar: requisitos, plazos y políticas cambian.

Solo queda una cosa: ponerlo todo a prueba. La siguiente y última lección del curso es el simulacro final: quince tareas cronometradas sobre la plataforma Rutas Norte, con su puntuación, su solucionario completo y una tabla de autoevaluación que te dirá si estás listo para reservar la fecha o qué módulos conviene repasar antes. Prepara el cronómetro y un clúster limpio.