La RHCSA (Red Hat Certified System Administrator) valida habilidades prácticas de administración de Red Hat Enterprise Linux. Tiene sentido para quienes trabajan con RHEL o quieren demostrar que saben configurar, diagnosticar y recuperar un sistema — no solo reconocer comandos en un manual. Esta guía reúne una ruta de estudio, ejercicios propios y una rutina de validación para el EX200.
Revisión de 12 de septiembre de 2026: comprueba la versión y las condiciones de tu inscripción antes de comprar material o agendar. El plan de estudio que sigue es una sugerencia editorial, no una promesa de aprobación ni una reproducción de tareas reales del examen.
Cómo funciona la RHCSA y qué RHEL estudiar
La página actual del EX200 indica RHEL 10. El examen es práctico, sin internet ni material personal; la documentación instalada puede estar disponible. Las configuraciones deben persistir tras el reinicio. Usa la lista oficial como referencia principal, en lugar de mezclar guiones de versiones diferentes.
La trayectoria oficial de aprendizaje publicada en 2022 lista 3 horas para el EX200. Confirme duración, idioma, modalidad y precio en su reserva; no use un precio convertido de otro país como presupuesto definitivo.
Red Hat considera las certificaciones vigentes durante 3 años. Después, la credencial puede quedar no actualizada; esto es distinto de borrar el historial de la certificación. Consulte las opciones oficiales de renovación, incluida la repetición del examen.
Lista de temas: atención a RHEL 10
Organice el estudio en herramientas y shell, software, procesos y arranque, almacenamiento, sistemas de archivos, servicios, red, usuarios y seguridad. La lista actual incluye RPM y Flatpak, GPT/LVM, VFAT/ext4/XFS, NFS/autofs, timers systemd, IPv4/IPv6, firewalld y SELinux. Los contenedores no aparecen como objetivo específico en esa lista consultada; no asuma que un curso antiguo de Podman represente el temario actual.
Convierta cada tema en una entrega observable: ¿un usuario consigue acceder al directorio? ¿El volumen se monta solo? ¿El servicio responde desde otra máquina? Marque como dominado solo lo que consigue rehacer, explicar y probar sin seguir una receta preparada.
Monta un laboratorio desechable
Para estudiar, propongo dos máquinas virtuales: servidor y cliente, con red privada entre ellas, acceso a internet para instalar paquetes y snapshot limpio. Añada discos virtuales vacíos dedicados a ejercicios de almacenamiento. No ejecute tareas de particionado, arranque, firewall o SELinux en el servidor de producción.
La suscripción Red Hat Developer Subscription for Individuals ofrece RHEL sin coste, con autosoporte y hasta 16 nodos físicos o virtuales, según sus términos. Use una cuenta individual elegible y verifique las condiciones del programa; esto no equivale a contratar soporte de producción.
Antes de cada ejercicio, confirme la máquina y los discos. El nombre de un dispositivo puede cambiar entre máquinas virtuales; identificar por tamaño y por propósito es más seguro que copiar un comando destructivo con un nombre fijo.
hostnamectl
cat /etc/redhat-release
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
ip -br address
Un plan de estudio en seis pasos
Use las etapas como secuencia, no como plazo obligatorio. Quien empieza desde cero puede necesitar repetirlas varias veces. Para cada sesión, reserve tiempo para montar el escenario, equivocarse, consultar la documentación y rehacer sin mirar las notas.
- Etapa 1 — terminal: archivos, permisos, enlaces, redireccionamientos,
grep, archivos comprimidos y scripts pequeños con argumentos. - Etapa 2 — operación: usuarios, grupos, privilegios, procesos, logs, servicios y recuperación de arranque en la consola de la VM.
- Etapa 3 — almacenamiento: discos vacíos, volúmenes lógicos, sistemas de archivos, swap y montaje persistente.
- Etapa 4 — integración: conectividad entre VMs, resolución de nombres, firewall, SSH, NFS y autofs.
- Etapa 5 — mantenimiento y seguridad: repositorios, programaciones, SELinux y diagnóstico sin desactivar los controles de seguridad.
- Etapa 6 — simulacro propio: combine tareas anteriores, cronometre y valide todo después de reiniciar.
Ejercicio integrado: servicio web que vuelve tras el reinicio
Este es un laboratorio de autoría propia para combinar paquetes, servicios, permisos, firewall y pruebas; no es una pregunta oficial ni una previsión del examen. Use una VM RHEL desechable, repositorios funcionales y un usuario con sudo. Mantenga el acceso a la consola de la VM antes de activar el firewall, en caso de que la conexión SSH quede bloqueada. El ejemplo utiliza el puerto HTTP estándar para no confundir la configuración del servicio con la autorización de un puerto alternativo.
sudo dnf install -y httpd firewalld
printf "RHCSA lab OK\n" | sudo tee /var/www/html/index.html
sudo chmod 0644 /var/www/html/index.html
sudo restorecon -v /var/www/html/index.html
sudo systemctl enable --now firewalld
sudo systemctl enable --now httpd
sudo firewall-cmd --get-active-zones
Observe la zona asociada a la interfaz utilizada por el cliente. Si es public, use los comandos siguientes; si es otra, sustituya public por el nombre correcto. Abrir HTTP en la zona equivocada no libera la interfaz deseada.
sudo firewall-cmd --zone=public --add-service=http
sudo firewall-cmd --permanent --zone=public --add-service=http
sudo firewall-cmd --zone=public --query-service=http
sudo firewall-cmd --permanent --zone=public --query-service=http
curl --fail http://127.0.0.1/
La regla sin --permanent actúa en el estado en ejecución; la permanente queda guardada para los siguientes arranques. Aquí configuramos ambas explícitamente. Desde el cliente, acceda a la IP privada real del servidor con curl. A continuación, reinicie únicamente la VM del servidor y repita la prueba remota.
sudo reboot
Tras reconectarse al servidor, compruebe el estado, el inicio automático, el puerto y el contexto. Un servicio activo por sí solo no prueba la conectividad externa; la prueba de la segunda VM sigue siendo necesaria.
systemctl is-active httpd
systemctl is-enabled httpd
sudo ss -ltnp
sudo firewall-cmd --zone=public --query-service=http
getenforce
ls -lZ /var/www/html/index.html
curl --fail http://127.0.0.1/
SELinux: corrige la causa, no desactives la protección
En el entrenamiento, separe el permiso Unix, el contexto SELinux, el puerto en escucha y el firewall. Son capas diferentes. Un chmod permisivo no corrige un contexto incorrecto, y abrir un puerto en el firewall no hace que el servicio empiece a escucharlo.
Para entrenar el etiquetado persistente en una nueva carpeta de laboratorio, registre el contexto y luego aplíquelo. El ejemplo no cambia el DocumentRoot de Apache: solo demuestra la parte de SELinux. Si la regla ya existe, inspecciónela antes de intentar añadirla de nuevo.
sudo dnf install -y policycoreutils-python-utils
sudo mkdir -p /srv/rhcsa-web
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/rhcsa-web(/.*)?"
sudo restorecon -Rv /srv/rhcsa-web
ls -Zd /srv/rhcsa-web
Almacenamiento: valida antes de reiniciar
Proponga otro escenario: crear un volumen lógico en un disco virtual vacío, montarlo en /dados, persistirlo por UUID y aumentar la capacidad sin perder un archivo de prueba. El criterio de éxito es que el archivo siga siendo legible, que la capacidad aumente y que el montaje vuelva tras el reinicio. No confunda ampliar el volumen lógico con ampliar el sistema de archivos.
Después de editar /etc/fstab en el laboratorio, use findmnt para comprobar la configuración. La opción --verify verifica su consistencia; no es un montaje ni garantiza que un servidor NFS remoto esté disponible. Pruebe también el montaje y el acceso al archivo.
sudo findmnt --verify --verbose
lsblk -f
findmnt /dados
df -hT /dados
Trucos de estudio que no dependen de memorizar
- Use un cuaderno de errores: síntoma, hipótesis, comando de diagnóstico, corrección y prueba final. Registre por qué se equivocó, no solo el comando que funcionó.
- Repita el mismo escenario con otros nombres, directorios y tamaños. Esto revela si entendió la tarea o solo memorizó la secuencia.
- Entrene la consulta local: man, la búsqueda con / dentro del manual,
--helpe/usr/share/doc. Saber encontrar una opción es más útil que memorizar todas. - Separe configurar de validar. Escriba la prueba esperada antes de la solución: salida de un comando, acceso de otro usuario o respuesta de otra VM.
- Rompa una cosa a la vez en una copia desechable: servicio deshabilitado, permiso incorrecto o regla ausente. Diagnostique sin abrir la receta y restaure la instantánea al terminar.
- Use el tiempo para priorizar, no para adivinar. Si se atasca en un ejercicio, anote el punto exacto, avance en el simulacro y vuelva con una hipótesis comprobable.
Fuentes y preparación para el día del examen
La ruta oficial ofrece RH124 y RH134 para construir la base, y RH199 para quien ya tiene experiencia en administración Linux. Use la evaluación de habilidades para localizar lagunas. Los vídeos y cursos ayudan, pero el laboratorio debe ocupar espacio real en su estudio.
Si eliges examen remoto, lee la guía de preparación vigente y realiza las pruebas de compatibilidad con antelación. Verifica identificación, entorno, cámara, audio, red e instrucciones de tu cita. No dejes la preparación del equipo para el momento del examen ni busques dumps de preguntas.
Próximos pasos
Comienza con la base de Linux y compara la RHCSA con otras rutas antes de invertir. En el laboratorio, el objetivo siempre es el mismo: ejecutar, verificar, reiniciar y verificar de nuevo. La aprobación no se garantiza por calendario; la preparación mejora cuando consigues explicar y reproducir el resultado.