Canonical Academy: cómo se construye la certificación Ubuntu

septiembre 10, 2026 Alfonso Moreno | Sysadmin Senior 47 Visitas 13 min de lectura

Canonical publicó a comienzos de septiembre de 2026 un artículo interno explicando cómo construye los exámenes de Canonical Academy, su plataforma de certificación lanzada en octubre de 2025. No es un anuncio de producto: es un desglose del proceso de diseño. Y ahí está lo interesante, porque explica por qué esta certificación se parece más a un turno de guardia que a un cuestionario.

Si trabajas como sysadmin en Latinoamérica y llevas años peleando con la pregunta de si vale la pena pagar por una certificación Linux, este artículo te va a servir. No para venderte el examen, sino para que entiendas qué mide realmente y decidas con datos.

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos para instalación, 1-2 horas para upgrade in-place.
Requisitos: Backup de /home, conexión a internet, 20+ GB libres.
Resultado: Sistema actualizado con soporte extendido, drivers funcionando.
Troubleshooting: dnf distro-sync, akmods para NVIDIA, journalctl -p err.

Qué es Canonical Academy y qué no es

Canonical Academy es la plataforma de certificación de la empresa detrás de Ubuntu. Se anunció el 23 de octubre de 2025 durante el Ubuntu Summit 25.10 y arrancó con un solo track: System Administrator. Ese track se compone de cuatro exámenes modulares:

Using Linux Terminal — disponible al público desde el lanzamiento.
Using Ubuntu Desktop — arrancó en beta comunitaria.
Using Ubuntu Server — arrancó en beta comunitaria.
Using DevOps Principles — el más nuevo, todavía en fase de test beta a septiembre de 2026.

Cada examen aprobado da un badge digital independiente. Si completas los cuatro, desbloqueas la calificación de track completo: Canonical Academy SysAdmin. Es un modelo modular, no un examen monolítico de cuatro horas.

Lo que no es: no es un curso. Canonical no vende (todavía) un programa de formación asociado. Vende el examen y el badge. La preparación corre por tu cuenta, con la documentación oficial de Ubuntu, las man pages y tu propio laboratorio. Para alguien acostumbrado al modelo de Red Hat —donde el curso RH124/RH134 viene empaquetado con el RHCSA— esto se siente incompleto. Para alguien autodidacta, es exactamente lo que quiere.

El proceso ADDIE: por qué importa cómo se fabrica un examen

La parte técnicamente relevante del artículo de Canonical es que documentan el ciclo de construcción de cada examen siguiendo el modelo ADDIE (Analysis, Design, Development, Implementation, Evaluation), adaptado a seis fases:

Fase	Nivel	Qué produce
Analysis	Track	Job Task Analysis (JTA): encuesta a expertos para aislar las tareas de alta frecuencia del rol real
Design	Examen	Blueprint con objetivos de evaluación y objetivos de aprendizaje
Item development	Ítem	Prototipos de ejercicios en laboratorio real, con code review interno
Form development	Variaciones	Múltiples variantes por pregunta y scripts de scoring automatizado
Implementation	Examen	Alpha privado y Beta público para calibrar tiempos y cut scores psicométricos
Evaluation	Continuo	Encuestas de salida y feedback post-lanzamiento

Los dos puntos que valen la pena subrayar son el form development y el cut score psicométrico. El primero significa que tu examen no es idéntico al de la persona de al lado: hay variables inyectadas en los ítems. El segundo significa que la nota de corte no es un 70% inventado, sino un número calculado sobre datos de testers reales durante la beta.

Esto ataca directamente el problema que hizo que muchas certificaciones perdieran credibilidad: los braindumps. Si el ítem tiene variables y el scoring es un script que verifica el estado final del sistema, memorizar la respuesta de un foro no te sirve de nada.

Cómo es el entorno de examen

Canonical es explícito: los candidatos trabajan dentro de instancias sandbox corriendo sobre la misma infraestructura de producción que verían en el trabajo. Durante el examen puedes levantar contenedores, modificar el stack de red o escribir scripts en Bash o Python. Tienes acceso completo a la documentación del producto y a las man pages, igual que en tu día laboral.

Ese detalle del acceso a documentación es el que más gente malinterpreta. No es que el examen sea fácil: es que evaluar tu memoria de flags es absurdo cuando man está a un comando de distancia. Lo que se evalúa es si sabes qué hacer y en qué orden.

Un ejemplo del tipo de tarea que cae en Using Linux Terminal: reconstruir particiones y filesystems. El examen no te pregunta “¿qué hace parted?”; te da un disco roto y te pide dejarlo montable.

sudo parted -s /dev/sdb mklabel gpt
sudo parted -s /dev/sdb mkpart primary ext4 1MiB 100%
sudo mkfs.ext4 -L datos /dev/sdb1
sudo blkid /dev/sdb1

Ese bloque crea una tabla de particiones GPT nueva, una partición que ocupa el disco entero y un filesystem ext4 etiquetado. El blkid final te devuelve el UUID, que es lo que realmente necesitas para el /etc/fstab. Importa porque montar por /dev/sdb1 es una bomba de tiempo: el orden de detección de discos cambia entre arranques.

Si parted falla con “Partition(s) on /dev/sdb are being used”, tienes algo montado o un volumen LVM activo encima. Verifica con lsblk -f y desmonta antes de tocar la tabla. En un examen cronometrado, ese diagnóstico son treinta segundos que no puedes perder buscando en Google.

Los cuatro exámenes, tema por tema

Canonical publica el contenido de cada examen en su página de exam content. Vale la pena revisarlo antes de pagar, porque el reparto de temas no es obvio.

Using Linux Terminal cubre navegación y manipulación de archivos con expresiones regulares, pipes y redirección; gestión de recursos del sistema (logs, rotación, particiones, crontab); y seguridad de acceso al filesystem: claves SSH, políticas de contraseña, interpretación de configuración de sudo, gestión de usuarios y grupos, ownership y permisos.

La parte de logs es la que más gente subestima. No basta con saber dónde está /var/log: hay que interpretar el log durante un troubleshooting.

journalctl -u ssh.service --since "2026-09-01" --no-pager
journalctl -p err -b -1
journalctl --disk-usage
sudo journalctl --vacuum-time=7d

La primera línea filtra el journal de un servicio concreto desde una fecha. La segunda muestra solo errores del arranque anterior, que es lo que quieres cuando el server se reinició solo y no sabes por qué. Las dos últimas revisan y podan el tamaño del journal, algo que en un VPS de 20 GB deja de ser opcional rápido.

Si journalctl devuelve “No journal files were found” como usuario normal, tu cuenta no está en el grupo systemd-journal ni en adm. Es un error frecuente en imágenes cloud minimalistas.

Using Ubuntu Desktop se enfoca en configuración de red, principios de capa 2 (MAC, resolución ARP, comportamiento broadcast/multicast), participación en la comunidad open source (ciclos LTS, convenciones de versionado, gobernanza de Ubuntu, interpretación de licencias), instalación (reparar GRUB2 e initramfs, upgrades LTS, USB booteable, drivers propietarios de GPU y Wi-Fi, LVM y snapshots), gestión de paquetes deb vs snap, y seguridad de escritorio (PKI, unirse a un realm Active Directory, ACLs).

La parte de LVM con snapshots es la que separa a quien “usa Ubuntu” de quien lo administra:

sudo lvcreate -L 2G -s -n home_snap /dev/vg0/home
sudo lvs -o lv_name,lv_size,data_percent,origin
sudo lvconvert --merge /dev/vg0/home_snap

La primera línea crea un snapshot de 2 GB del volumen lógico home. La segunda muestra cuánto se ha llenado el snapshot: cuando data_percent llega a 100, el snapshot se invalida y pierdes la capacidad de revertir. La tercera hace merge de vuelta al origen, que es tu rollback.

El error clásico: dimensionar el snapshot demasiado pequeño antes de un do-release-upgrade. Si el upgrade reescribe más datos que el tamaño del snapshot, el rollback deja de existir justo cuando lo necesitas.

Using Ubuntu Server cubre control de servicios vía systemd, contraste entre usuarios regulares y de sistema, firewall con iptables o ufw, y gestión de procesos y units.

systemctl list-units --type=service --state=running
systemctl list-unit-files --state=disabled
sudo ufw status verbose
sudo ufw allow from 192.168.1.0/24 to any port 22 proto tcp

Las dos primeras líneas responden a preguntas distintas: qué está corriendo ahora versus qué está instalado pero deshabilitado. Es una distinción que cae en el examen y que en producción evita el clásico “el servicio arrancó a mano y no sobrevive al reboot”. Las dos últimas revisan el firewall y abren SSH solo desde la LAN, que es infinitamente mejor que ufw allow 22.

Ojo con el orden: si activas ufw antes de crear la regla de SSH y estás conectado remotamente, te quedas fuera. Siempre la regla primero, el ufw enable después.

Using DevOps Principles es el más ambicioso: scripts de automatización en Bash o Python con control de versiones Git, herramientas de workflow como cloud-init y Ansible, parches vía Landscape / Ubuntu Pro / Livepatch / ESM, gestión de aplicaciones containerizadas con Docker o LXD, provisión de entornos virtualizados con virsh, virt-manager o LXD, y troubleshooting con tcpdump, dig, ss e iproute2.

ss -tulpn | grep LISTEN
dig +short A soylinux.com @1.1.1.1
sudo tcpdump -i any -n port 443 -c 20
ip -br addr show

Este set es literalmente el que usas cuando algo “no conecta”. ss te dice qué proceso está escuchando en qué puerto; dig contra un resolver externo descarta problemas de DNS local; tcpdump con -c 20 captura veinte paquetes y sale, sin llenarte la terminal; ip -br da un resumen legible de interfaces.

Si tcpdump devuelve “You don’t have permission to capture on that device”, falta sudo o el usuario no está en el grupo con CAP_NET_RAW. En contenedores necesitas --cap-add=NET_ADMIN, algo que en el examen de DevOps es plausible que aparezca.

Cómo prepararte sin pagar un curso

Como Canonical no vende formación asociada, la preparación es tuya. La forma honesta de hacerlo es montar un laboratorio y romper cosas. Con LXD o Multipass tienes máquinas Ubuntu desechables en segundos:

sudo snap install lxd
sudo lxd init --minimal
lxc launch ubuntu:24.04 lab-server
lxc exec lab-server -- bash

Eso te deja dentro de un contenedor Ubuntu 24.04 limpio donde puedes destrozar /etc/fstab, borrar reglas de firewall o corromper permisos sin consecuencias. Cuando lo arruines, lxc delete lab-server --force y vuelves a empezar.

Si lxd init falla por permisos, tu usuario no está en el grupo lxd. Añádelo con sudo usermod -aG lxd $USER y vuelve a iniciar sesión — el cambio de grupo no aplica a la shell actual.

Un patrón de estudio que funciona: escribe un script que rompa el sistema de una forma concreta, ejecútalo en el contenedor y practica el diagnóstico a ciegas. Es exactamente el formato del examen.

lxc exec lab-server -- bash -c 'chmod 000 /etc/ssh/sshd_config; systemctl restart ssh'
lxc exec lab-server -- systemctl status ssh --no-pager
lxc exec lab-server -- journalctl -u ssh -n 20 --no-pager

Ese ejercicio rompe SSH cambiando permisos, y luego te obliga a llegar a la causa leyendo el status y el journal, no adivinando. Es el músculo que el examen mide.

Canonical Academy frente a las alternativas

Aquí es donde hay que ser honesto: Canonical Academy es la certificación más nueva del mercado y todavía no tiene reconocimiento comparable a las establecidas.

Certificación	Enfoque	Formato	Reconocimiento
Canonical Academy SysAdmin	Ubuntu específico	Práctico, modular, 4 badges	Nuevo (desde oct. 2025)
LFCS (Linux Foundation)	Neutral entre distros	Práctico, examen único	Alto, vendor-neutral
RHCSA (Red Hat)	RHEL específico	Práctico, examen único	El estándar de facto en enterprise
LPIC-1	Neutral entre distros	Opción múltiple, dos exámenes	Medio, teórico

El LFCS cuesta 445 USD en su modalidad de examen solo, incluye doce meses para agendarlo, dos intentos y acceso a dos simulacros. Es el punto de comparación más justo para Canonical Academy porque ambos son prácticos y ambos apuntan al rol de sysadmin.

Canonical no publica una lista de precios abierta: hay que entrar a la tienda con una cuenta Ubuntu One para verlos. Esa fricción es una decisión de producto discutible, y a septiembre de 2026 sigue igual.

Mi opinión: para quién sí y para quién no

Voy a ser directo, porque el marketing de certificaciones vive de la ambigüedad.

Tiene sentido si trabajas en un entorno mayoritariamente Ubuntu —que en Latinoamérica es enorme, entre VPS baratos, startups y universidades—, si eres autodidacta y necesitas un papel que valide lo que ya sabes hacer, o si quieres un badge por examen en lugar de jugártelo todo a una prueba de cuatro horas. El formato modular es genuinamente más amable con quien estudia después del trabajo.

No tiene sentido si tu objetivo es entrar a una empresa grande con infraestructura Red Hat: ahí el RHCSA sigue siendo la llave. Tampoco si buscas la credencial de mayor reconocimiento posible en el menor tiempo: el LFCS lleva años acumulando reputación y es neutral entre distros. Y si tu currículum ya tiene experiencia demostrable, una certificación nueva aporta poco.

El punto que sí me parece un acierto real de Canonical es la estrategia contra la memorización. Que el scoring sea un script que verifica el estado final del sistema, con variables inyectadas por ítem, hace que el braindump no funcione. En un mercado donde los reclutadores desconfían —con razón— de los certificados de opción múltiple, eso es una ventaja concreta.

Lo que no me convence: la falta de transparencia en precios y la ausencia de material de estudio oficial. Si vas a competir con Red Hat, que te vende el curso junto con el examen, dejar al candidato solo frente a la documentación es una barrera de entrada real para quien está empezando.

Si quieres participar en el proceso

Un detalle que casi nadie menciona: Canonical está reclutando activamente Subject Matter Experts externos para diseñar los próximos tracks —arquitectura cloud, virtualización de seguridad y DevOps—. Buscan practicantes activos: ingenieros de nivel medio a senior, SREs y administradores de sistemas con experiencia práctica vigente.

La participación es flexible: workshops de desarrollo de contenido o revisiones de código asíncronas sobre prototipos de preguntas en GitHub. También hay un programa de testers pre-lanzamiento que da acceso anticipado a los exámenes en desarrollo y tarifas con descuento.

Para un sysadmin latinoamericano que quiere visibilidad internacional sin mudarse, es una puerta poco explotada. Los canales oficiales son el registro de SME y el de tester en el sitio de Canonical Academy, además de su canal público de Matrix.

Resumen

Canonical Academy es una certificación práctica, modular y específica de Ubuntu, construida con un proceso de diseño que se toma en serio la validez psicométrica. Su fortaleza es que mide ejecución real en un entorno sandbox sobre infraestructura de producción, con scoring automatizado y variantes por ítem que hacen inútil la memorización.

Su debilidad es el reconocimiento: lleva menos de un año en el mercado y compite contra credenciales con una década de reputación. Si trabajas en Ubuntu y necesitas validar habilidades reales, entra. Si buscas la credencial de mayor peso en el CV, mira primero el LFCS o el RHCSA.

El siguiente paso concreto, si te interesa: revisa el contenido publicado de Using Linux Terminal, monta un contenedor LXD, y haz una pasada honesta por los objetivos. Si más de la mitad te resultan cómodos, el examen es viable. Si no, ya sabes exactamente qué estudiar — y eso solo vale la pena por sí mismo.

Preguntas frecuentes

¿Por qué Canonical Academy: cómo se construye la certificación Ubuntu es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Canonical Academy: cómo se construye?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Canonical Academy: cómo se construye?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Canonical Academy: cómo se construye y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Canonical Academy: cómo se construye?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.