Saber levantar un contenedor es solo el principio. Entregar un cambio con pruebas, trazabilidad y un camino de recuperación exige conectar varias herramientas. La certificación LPI DevOps Tools Engineer puede ayudar a organizar ese aprendizaje; en esta guía encontrarás el examen adecuado, un plan de estudio y un laboratorio que crea los archivos antes de ejecutar los comandos.
Revisado el 12 de septiembre de 2026. Los ejercicios y la secuencia de estudio son propuestas de LinuxPro, no preguntas reales del examen ni garantía de aprobado.
Atención a la versión: estudia para el 701-200
La versión actual es 2.0, examen 701-200. LPI informa que la versión 1.0, examen 701-100, estuvo disponible hasta el 30 de junio de 2026. Comprueba el código en la descripción del curso y en la reserva: un manual antiguo puede enseñar herramientas útiles sin cubrir el temario actual.
Es un examen con 60 preguntas de opción múltiple y rellenar huecos, en 90 minutos. La validez indicada es de 5 años. No hay certificación previa obligatoria; LPI recomienda una certificación adicional en administración, como LPIC-1, o en desarrollo. Por tanto, no es necesario completar LPIC-2 o LPIC-3 antes.
En la consulta, la página oficial lista inglés para la versión actual en los centros VUE. Confirma idioma, modalidad y precio para tu país antes de pagar; no des por sentado que el examen esté disponible en portugués.
Qué incluye el temario actual
Usa los objetivos oficiales como checklist. Este mapa es un resumen, no sustituye los subapartados:
- 701 — Ingeniería de software: arquitectura, servicios, Git, CI/CD, GitOps, licencias y composición de software.
- 702 — Contenedores: Docker y Podman, redes, volúmenes, Compose, construcción y distribución de imágenes OCI.
- 703 — Kubernetes: arquitectura, recursos, operaciones, Helm y nociones de Kustomize.
- 704 — Seguridad y observabilidad: protección de aplicaciones e infraestructura, Prometheus, logs y tracing con OpenTelemetry.
Los pesos indican importancia relativa, no una promesa de cantidad exacta de preguntas. Operaciones básicas de Kubernetes tienen peso 7; Git y monitorización con Prometheus tienen peso 6 cada uno. Ansible, Vagrant y Packer no aparecen como objetivos específicos en esta versión: no organices el estudio actual en torno al antiguo bloque de despliegue y configuración de máquinas.
Plan de estudio en 6 etapas
Avanza por entregas, no por vídeos vistos. Repite el paso cuando consigas copiar la solución pero aún no sepas explicar el resultado. Ajusta el ritmo a tu experiencia; esta secuencia no establece un plazo universal.
- 1. Base y Git: navega por la terminal, entiende permisos y procesos, crea un repositorio, haz un cambio en una rama y resuelve un conflicto en una copia de entrenamiento. Entrega: historial legible y explicación de lo que se modificó.
- 2. Contenedores: construye una imagen, ejecútala sin usuario root dentro del contenedor y compara un archivo incorporado a la imagen con un dato en un volumen. Entrega: servicio accesible solo en la dirección esperada y explicación de la persistencia.
- 3. Entrega: convierte la verificación local en un job de CI. Provoca que un test falle a propósito y observa cómo se bloquea. Entrega: saber distinguir entre test, build, artefacto y despliegue, en lugar de llamar pipeline completo a cualquier script.
- 4. Kubernetes: en un clúster desechable, publica una aplicación, inspecciona los eventos, actualiza la imagen y observa las réplicas. Después instala un chart de estudio y modifica sus valores. Entrega: explicar qué se declaró y qué ejecutó el clúster.
- 5. Observabilidad y seguridad: provoca un fallo controlado, localiza el error y elige una señal para detectarlo. Revisa permisos, secretos y el origen de las dependencias. Entrega: diagnóstico con evidencias, sin desactivar protecciones para esconder el problema.
- 6. Revisión: vuelve a los objetivos, marca las lagunas y rehaz tareas sin consultar la receta. Entrega: un pequeño repositorio de laboratorio con instrucciones, tests, limitaciones y procedimiento de recuperación.
Laboratorio: de Git a un servicio probado en contenedor
Usa una máquina de estudio Linux con Bash, Git, Python 3, curl actualizado, Docker Engine actualizado (28.0.0 o posterior) y el plugin Docker Compose instalados. El usuario debe poder ejecutar Docker. Hazlo todo en una carpeta nueva, nunca dentro de un proyecto real. La primera construcción descarga una imagen de internet.
Este servicio publica solo una página estática para entrenamiento. El servidor HTTP de Python no es apto para producción; no utilices este ejemplo para alojar clientes ni exponer archivos personales.
1. Crea la página y una prueba mínima
El directorio temporal se encuentra en tu carpeta personal y el comando imprime su ruta. La identidad Git indicada abajo solo es válida para ese repositorio de entrenamiento.
LAB_DIR=$(mktemp -d "$HOME/lpi-devops-lab.XXXXXX")
cd "$LAB_DIR"
printf '%s\n' "$LAB_DIR"
git init -b main
git config user.name "LPI Lab"
git config user.email "lab@example.invalid"
mkdir site
printf '%s\n' '<!doctype html><html lang="en"><title>DevOps lab</title><h1>DevOps lab OK</h1></html>' > site/index.html
printf '%s\n' '__pycache__/' > .gitignore
cat > test_site.py <<'EOF'
from pathlib import Path
import unittest
class SiteTest(unittest.TestCase):
def test_homepage(self):
page = Path("site/index.html").read_text()
self.assertIn("<h1>DevOps lab OK</h1>", page)
if __name__ == "__main__":
unittest.main()
EOF
python3 -m unittest -v
El resultado esperado es una prueba aprobada. Verifica solo el contenido del archivo; todavía no prueba red, contenedor ni disponibilidad.
2. Describe la imagen y la ejecución
cat > Dockerfile <<'EOF'
FROM python:3.13-slim
WORKDIR /app
COPY site/ /app/site/
RUN chmod 755 /app/site && chmod 644 /app/site/index.html
USER 10001:10001
EXPOSE 8080
CMD ["python", "-m", "http.server", "8080", "--bind", "0.0.0.0", "--directory", "/app/site"]
EOF
cat > .dockerignore <<'EOF'
*
!Dockerfile
!site/
!site/**
EOF
cat > compose.yaml <<'EOF'
services:
web:
build: .
image: lpi-devops-lab:local
ports:
- "127.0.0.1:18080:8080"
read_only: true
cap_drop:
- ALL
security_opt:
- no-new-privileges:true
EOF
docker compose config
git add .gitignore site/index.html test_site.py Dockerfile .dockerignore compose.yaml
git commit -m "Add tested container lab"
La imagen usa un identificador numérico no root. La aplicación escucha en la interfaz del contenedor, pero la publicación en el host está limitada al loopback. EXPOSE documenta el puerto; no publica el servicio por sí solo. Si el puerto local está ocupado, elige otro en Compose y ajusta la siguiente comprobación.
La etiqueta de la imagen base es mutable: reconstrucciones futuras pueden descargar contenido diferente. Para un proyecto que requiera reproducción exacta, registra y fija el digest verificado de la imagen, con un proceso separado para actualizaciones de seguridad.
3. Construye, valida y consulta los registros
docker compose up -d --build
docker compose ps
curl --fail --silent --show-error --max-time 5 --retry 10 --retry-all-errors --retry-delay 1 http://127.0.0.1:18080/ | grep -F 'DevOps lab OK'
docker compose exec -T web id
docker compose logs --tail=20 web
Comprueba la página esperada, el proceso sin root y la petición en los registros. Una respuesta HTTP correcta es una comprobación básica, no prueba de seguridad ni prueba completa. Si falla, lee el mensaje y comprueba estado, dirección y puerto antes de reconstruir todo.
4. Añade CI sin fingir que ya hay despliegue
Si usas GitLab, guarda este archivo en el repositorio. Necesita un runner con un ejecutor que admita la imagen declarada, como Docker o Kubernetes, disponible para el proyecto. El job ejecuta solo la prueba de la página: no construye la imagen ni publica nada.
stages:
- test
test_site:
stage: test
image: python:3.13-slim
script:
- python -m unittest -v
Nombre del archivo: .gitlab-ci.yml. Haz commit de él y envíalo a un repositorio de GitLab tuyo, con el runner configurado. No pongas tokens en el archivo. Para evolucionar hasta entrega continua, aún faltan política de artefactos, credenciales protegidas, entorno de destino y validación tras el despliegue.
5. Entrena el fallo, la recuperación y la limpieza
Cambia solo el mensaje de la página y ejecuta la prueba: debe fallar. Revierte la edición y confirma que vuelve a pasar. Después haz un cambio en un commit aparte y practica revertirlo con Git; evita comandos destructivos que borren trabajo no guardado. Reconstruye el servicio y repite la comprobación HTTP.
Al terminar, ejecute en la carpeta del laboratorio:
docker compose down
Esto elimina los contenedores y la red del proyecto. El directorio de trabajo, la imagen construida y la caché de compilación siguen disponibles. No use una limpieza global de Docker: puede afectar a otros laboratorios o servicios.
Después del laboratorio: Kubernetes, métricas y tracing
El ejemplo anterior no cubre toda la certificación. Para Kubernetes, use el tutorial oficial en un entorno desechable: verifique el contexto antes de modificar recursos, cree un namespace de entrenamiento y practique Deployment, Service, escalado y actualización. Registre el resultado observado, incluidos los eventos cuando algo no se inicia.
Con Helm, compare los valores por defecto de un chart con una configuración propia. Antes de instalar, lea los recursos y permisos que crea. El objetivo es entender el cambio, no solo copiar un comando que apunta a un repositorio desconocido.
En Prometheus, siga el ejercicio oficial de monitorizar el propio servidor y consulte la métrica up. Después detenga un objetivo de prueba y observe lo que cambia. Una recogida exitosa no garantiza que la operación de negocio del usuario haya funcionado; elija también la señal que representa esa operación.
No trate métricas, logs y traces como sinónimos. Las métricas ayudan a seguir medidas a lo largo del tiempo; los logs registran eventos; los traces muestran el camino de una operación entre componentes. Use OpenTelemetry para estudiar las señales y la propagación de contexto, sin confundir la instrumentación con el sistema que almacena y consulta los datos.
Consejos para estudiar mejor y evitar atajos malos
- Mantenga un cuaderno de errores: síntoma, hipótesis, comando usado, evidencia y corrección. Revise los problemas que realmente encontró, no solo una lista de flags.
- Use revisión activa: cierre la documentación, explique la tarea en voz alta e intente reproducirla. Después consulte la referencia para corregir detalles de sintaxis.
- Practica la lectura de términos técnicos en inglés. Monta tarjetas con conceptos que confundes, como imagen y container, autenticación y autorización, entrega e implantación.
- Separa las evidencias: test aprobado, imagen construida y servicio respondiendo son resultados diferentes. Guarda versiones y salidas relevantes sin conservar claves ni datos de clientes.
- Utiliza simulacros legítimos como diagnóstico, no como predicción del examen. Evita dumps y promesas de aprobación. Antes de la cita, revisa las instrucciones actuales del proveedor y la identificación exigida.
Lecturas de LinuxPro para continuar
Refuerza los fundamentos y conecta el laboratorio a problemas reales. Ansible sigue siendo útil en el trabajo, aunque no sea el centro del guion actual de esta prueba. Los textos históricos ayudan a entender el contexto, pero no sustituyen la documentación vigente de las herramientas.
- LPIC-1: base de administración Linux
- Curso Linux do Toca do Tux
- Git simple y rápido: introducción del acervo
- A história do Docker
- A história do Kubernetes
- Primeros pasos con Ansible
- OpenObserve: logs, métricas y traces
La mejor entrega del estudio no es un repositorio lleno de comandos copiados: es conseguir explicar por qué el servicio funciona, detectar cuándo falla y recuperar con seguridad. Usa la certificación para organizar ese camino, sin confundir la credencial con experiencia en producción.