Saber subir um container é um começo. Entregar uma mudança com teste, rastreabilidade e um caminho de recuperação exige conectar várias ferramentas. A LPI DevOps Tools Engineer pode ajudar a organizar esse aprendizado; neste guia, você encontra o exame correto, um plano de estudo e um laboratório que cria os arquivos antes de executar os comandos.
Revisado em 12 de setembro de 2026. Os exercícios e a sequência de estudo são propostas do LinuxPro, não questões reais do exame nem garantia de aprovação.
Atenção à versão: estude para o 701-200
A versão atual é a 2.0, exame 701-200. O LPI informa que a versão 1.0, exame 701-100, ficou disponível até 30 de junho de 2026. Confira o código na descrição do curso e no agendamento: uma apostila antiga pode ensinar ferramentas úteis sem cobrir o roteiro atual.
É uma prova com 60 questões de múltipla escolha e preenchimento de lacunas, em 90 minutos. A validade informada é de 5 anos. Não há certificação prévia obrigatória; o LPI recomenda uma certificação adicional em administração, como LPIC-1, ou em desenvolvimento. Portanto, não é necessário completar LPIC-2 ou LPIC-3 antes dela.
Na consulta, a página oficial lista inglês para a versão atual nos centros VUE. Confirme idioma, modalidade e preço para o seu país antes de pagar; não presuma que a prova esteja disponível em português.
O que entra no roteiro atual
Use os objetivos oficiais como checklist. Este mapa é um resumo, não substitui os subitens:
- 701 — Engenharia de software: arquitetura, serviços, Git, CI/CD, GitOps, licenças e composição de software.
- 702 — Containers: Docker e Podman, redes, volumes, Compose, construção e distribuição de imagens OCI.
- 703 — Kubernetes: arquitetura, recursos, operações, Helm e noções de Kustomize.
- 704 — Segurança e observabilidade: proteção de aplicações e infraestrutura, Prometheus, logs e tracing com OpenTelemetry.
Os pesos indicam importância relativa, não uma promessa de quantidade exata de questões. Operações básicas de Kubernetes têm peso 7; Git e monitoramento com Prometheus têm peso 6 cada. Ansible, Vagrant e Packer não aparecem como objetivos específicos nessa versão: não organize o estudo atual em torno do antigo bloco de implantação e configuração de máquinas.
Plano de estudo em 6 etapas
Avance por entregas, não por vídeos assistidos. Repita a etapa quando conseguir copiar a solução, mas ainda não conseguir explicar o resultado. Ajuste o ritmo à sua experiência; esta sequência não estabelece um prazo universal.
- 1. Base e Git: navegue pelo terminal, entenda permissões e processos, crie um repositório, faça uma alteração em branch e resolva um conflito em uma cópia de treino. Entrega: histórico legível e explicação do que foi alterado.
- 2. Containers: construa uma imagem, execute sem usuário root dentro do container e compare arquivo incorporado à imagem com dado em volume. Entrega: serviço acessível apenas no endereço esperado e explicação da persistência.
- 3. Entrega: transforme a verificação local em um job de CI. Faça um teste falhar de propósito e acompanhe o bloqueio. Entrega: saber distinguir teste, build, artefato e implantação, em vez de chamar qualquer script de pipeline completo.
- 4. Kubernetes: em cluster descartável, publique uma aplicação, inspecione eventos, atualize a imagem e observe as réplicas. Depois instale um chart de estudo e altere seus valores. Entrega: explicar o que foi declarado e o que o cluster executou.
- 5. Observabilidade e segurança: provoque uma falha controlada, localize o erro e escolha um sinal para detectá-la. Revise permissões, segredos e origem das dependências. Entrega: diagnóstico com evidências, sem desabilitar proteções para esconder o problema.
- 6. Revisão: volte aos objetivos, marque as lacunas e refaça tarefas sem consultar a receita. Entrega: um pequeno repositório de laboratório com instruções, testes, limitações e procedimento de recuperação.
Laboratório: do Git a um serviço testado em container
Use uma máquina de estudo Linux com Bash, Git, Python 3, curl atualizado, Docker Engine atualizado (28.0.0 ou posterior) e o plugin Docker Compose instalados. O usuário precisa conseguir executar Docker. Faça tudo em uma pasta nova, nunca dentro de um projeto real. A primeira construção baixa uma imagem da internet.
Este serviço publica apenas uma página estática para treinamento. O servidor HTTP do Python não é indicado para produção; não use este exemplo para hospedar clientes ou expor arquivos pessoais.
1. Crie a página e um teste mínimo
O diretório temporário fica na sua pasta pessoal e o comando imprime seu caminho. A identidade Git abaixo vale apenas para esse repositório de treino.
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
O resultado esperado é um teste aprovado. Ele verifica somente o conteúdo do arquivo; ainda não testa rede, container nem disponibilidade.
2. Descreva a imagem e a execução
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"
A imagem usa um identificador numérico não root. A aplicação escuta na interface do container, mas a publicação no host está limitada ao loopback. EXPOSE documenta a porta; não publica o serviço sozinho. Se a porta local estiver ocupada, escolha outra no Compose e ajuste a verificação seguinte.
A tag da imagem base é mutável: reconstruições futuras podem baixar conteúdo diferente. Para um projeto que exija reprodução exata, registre e fixe o digest verificado da imagem, com um processo separado para atualizações de segurança.
3. Construa, valide e consulte os logs
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
Confira a página esperada, o processo sem root e a requisição nos logs. Uma resposta HTTP bem-sucedida é uma verificação básica, não prova de segurança ou teste completo. Se falhar, leia a mensagem e confira estado, endereço e porta antes de reconstruir tudo.
4. Acrescente CI sem fingir que já existe deploy
Se você usar GitLab, salve este arquivo no repositório. Ele exige um runner com executor que suporte a imagem declarada, como Docker ou Kubernetes, disponível para o projeto. O job executa apenas o teste da página: não constrói a imagem e não publica nada.
stages:
- test
test_site:
stage: test
image: python:3.13-slim
script:
- python -m unittest -v
Nome do arquivo: .gitlab-ci.yml. Faça commit dele e envie para um repositório GitLab seu, com o runner configurado. Não coloque tokens no arquivo. Para evoluir até entrega contínua, ainda faltam política de artefatos, credenciais protegidas, ambiente de destino e validação após a implantação.
5. Treine a falha, a recuperação e a limpeza
Altere somente a mensagem da página e rode o teste: ele deve falhar. Reverta a edição e confirme que passa novamente. Depois faça uma mudança em um commit separado e pratique revertê-la com Git; evite comandos destrutivos que apagam trabalho não salvo. Reconstrua o serviço e repita a verificação HTTP.
Ao terminar, execute na pasta do laboratório:
docker compose down
Isso remove os containers e a rede do projeto. O diretório de trabalho, a imagem construída e o cache de build continuam disponíveis. Não use uma limpeza global do Docker: ela pode atingir outros laboratórios ou serviços.
Depois do laboratório: Kubernetes, métricas e tracing
O exemplo anterior não cobre toda a certificação. Para Kubernetes, use o tutorial oficial em um ambiente descartável: confira o contexto antes de modificar recursos, crie um namespace de treino e pratique Deployment, Service, escala e atualização. Registre o resultado observado, inclusive eventos quando algo não inicia.
Com Helm, compare os valores padrão de um chart com uma configuração sua. Antes de instalar, leia os recursos e permissões que ele cria. O objetivo é entender a mudança, não apenas copiar um comando que aponta para um repositório desconhecido.
Em Prometheus, siga o exercício oficial de monitorar o próprio servidor e consulte a métrica up. Depois interrompa um alvo de teste e observe o que muda. Uma coleta bem-sucedida não garante que a operação de negócio do usuário funcionou; escolha também o sinal que representa essa operação.
Não trate métricas, logs e traces como sinônimos. Métricas ajudam a acompanhar medidas ao longo do tempo; logs registram eventos; traces mostram o caminho de uma operação entre componentes. Use OpenTelemetry para estudar os sinais e a propagação de contexto, sem confundir instrumentação com o sistema que armazena e consulta os dados.
Dicas para estudar melhor e evitar atalhos ruins
- Mantenha um caderno de erros: sintoma, hipótese, comando usado, evidência e correção. Revise os problemas que você realmente encontrou, não apenas uma lista de flags.
- Use revisão ativa: feche a documentação, explique a tarefa em voz alta e tente reproduzi-la. Depois confira a referência para corrigir detalhes de sintaxe.
- Pratique a leitura de termos técnicos em inglês. Monte cartões com conceitos que você confunde, como imagem e container, autenticação e autorização, entrega e implantação.
- Separe evidências: teste aprovado, imagem construída e serviço respondendo são resultados diferentes. Salve versões e saídas relevantes sem guardar chaves ou dados de clientes.
- Use simulados legítimos como diagnóstico, não como previsão da prova. Evite dumps e promessas de aprovação. Antes do agendamento, revise as instruções atuais do provedor e a identificação exigida.
Leituras do LinuxPro para continuar
Fortaleça os fundamentos e conecte o laboratório a problemas reais. Ansible continua útil no trabalho, mesmo não sendo o centro do roteiro atual desta prova. Os textos históricos ajudam a entender o contexto, mas não substituem a documentação vigente das ferramentas.
- LPIC-1: base de administração Linux
- Curso Linux do Toca do Tux
- Git simples e rápido: introdução do acervo
- A história do Docker
- A história do Kubernetes
- Primeiros passos com Ansible
- OpenObserve: logs, métricas e traces
A melhor entrega do estudo não é um repositório cheio de comandos copiados: é conseguir explicar por que o serviço funciona, detectar quando falha e recuperar com segurança. Use a certificação para organizar esse caminho, sem confundir a credencial com experiência de produção.