DevOpsQuest
0 XP

Desafios

12 desafios avaliados por critérios

Leia o briefing, entregue no seu repositório e confira cada critério de aceitação antes de marcar como concluído.

  • Runbook de plantão em 30 comandos

    Iniciante+250 XP

    Escreva o runbook que qualquer pessoa usaria nos primeiros cinco minutos de um incidente em um servidor Linux, com ordem de investigação e critério de escalada.

    Linuxsystemdjournalctl

    Critérios de aceitação

    • 30 comandos agrupados por objetivo, cada um com uma frase própria explicando o que responde
    • Seção 'primeiros 5 minutos' com ordem de execução justificada
    • Critério objetivo de escalada (quando envolver outra pessoa)
    • Arquivo versionado em docs/runbook-linux.md

  • Diagnóstico do 502 sem tocar no código

    Intermediário+250 XP

    Dado um Nginx retornando 502 intermitente, produza um relatório com evidências que prove a causa raiz sem alterar a aplicação.

    Nginxcurlssjournalctl

    Critérios de aceitação

    • Evidência do error.log do Nginx com a mensagem entre parênteses
    • Teste direto no upstream com curl e verificação de porta com ss
    • Correlação temporal entre reinícios do serviço e ocorrências de 502
    • Conclusão com causa raiz e correção proposta (com e sem alteração de código)

  • Automação de plantão em Bash

    Intermediário+250 XP

    Entregue dois scripts (health-check e backup com retenção) com tratamento de erro, códigos de saída distintos e agendamento por systemd timer.

    Bashsystemd timersShellCheck

    Critérios de aceitação

    • set -euo pipefail, trap de limpeza e log com timestamp em stderr
    • Códigos de saída diferentes por tipo de falha, documentados no cabeçalho
    • ShellCheck sem avisos
    • Timer ativo com Persistent=true e restauração de backup testada

  • Imagem enxuta e endurecida

    Intermediário+250 XP

    Reduza a imagem da API para menos de 200 MB, rodando como usuário não-root, com filesystem somente leitura e sem vulnerabilidade crítica corrigível.

    DockerTrivyBuildKit

    Critérios de aceitação

    • Tamanho antes e depois documentado, com as três mudanças que produziram o ganho
    • Multi-stage com .dockerignore e dependências de produção apenas
    • Container roda com --read-only, --cap-drop ALL e usuário não-root
    • Trivy sem HIGH/CRITICAL corrigíveis

  • Stack completo com um comando

    Intermediário+250 XP

    Entregue um docker compose up que sobe frontend, API e banco com healthchecks, persistência e nenhum segredo em texto no repositório.

    Docker ComposePostgreSQL

    Critérios de aceitação

    • Healthcheck no banco e depends_on com condition: service_healthy
    • Volume nomeado com persistência comprovada após down/up
    • Rede interna para o banco, sem porta publicada no host
    • Segredos por arquivo ou secret, com .gitignore correspondente

  • Pipeline que protege a main

    Intermediário+250 XP

    Configure CI obrigatório com lint, testes unitários e de integração, cache eficiente e duração total abaixo de cinco minutos.

    GitHub ActionsBranch protection

    Critérios de aceitação

    • Merge bloqueado quando o check falha
    • Testes de integração com service container e migrações aplicadas
    • Cache com chave baseada no lockfile, com ganho medido
    • Duração do pipeline documentada antes e depois das otimizações

  • Deploy com rollback automático

    Avançado+250 XP

    Implemente publicação de imagem com tag imutável e deploy que reverte automaticamente quando a verificação de saúde falha. Meça o RTO.

    GitHub ActionsGHCRBash

    Critérios de aceitação

    • Imagem publicada com versão semântica, tag por SHA e digest registrado
    • Verificação de saúde pós-deploy com retry e backoff
    • Rollback automático em falha, com evidência de execução
    • RTO medido e publicado no README

  • Ambiente AWS seguro e auditável

    Avançado+250 XP

    Entregue um ambiente com banco privado, aplicação em subnet privada, IAM sem chaves estáticas, orçamento configurado e checklist de destruição executado.

    AWSIAMVPCRDS

    Critérios de aceitação

    • Nenhuma chave de acesso de longa duração em uso (OIDC ou instance profile)
    • Auditoria mostrando zero regras 0.0.0.0/0 em portas administrativas ou de banco
    • Budget ativo e todos os recursos com tags de projeto/ambiente/dono
    • Evidência de que a conta ficou sem recursos remanescentes ao final

  • Dois ambientes idênticos por IaC

    Avançado+250 XP

    Provisione dev e staging com o mesmo módulo, state remoto com lock, e configure os hosts com playbook idempotente.

    TerraformAnsible

    Critérios de aceitação

    • State em backend remoto com versionamento, lock e criptografia
    • Módulo reutilizado; diferenças apenas em tfvars
    • terraform plan com exit code 0 após apply em ambos os ambientes
    • Playbook com changed=0 na segunda execução

  • Kubernetes com rollback comprovado

    Avançado+250 XP

    Rode o CloudShop no cluster com Ingress, probes corretas, limites dimensionados por medição e rollback executado com tempo registrado.

    KubernetesHelm

    Critérios de aceitação

    • Probes separando liveness (sem dependências) de readiness (com dependências)
    • requests/limits justificados por kubectl top, não por chute
    • Chart Helm com values por ambiente e image.tag obrigatório
    • Evidência de rollback com tempo medido

  • GitOps de ponta a ponta

    Ninja+250 XP

    Coloque staging e produção sob ArgoCD, com promoção por PR, segredos fora do Git e rollback por revert comprovado.

    ArgoCDKustomizeExternal Secrets

    Critérios de aceitação

    • Applications Synced/Healthy com selfHeal ativo em staging
    • Promoção para produção por PR com a versão validada em staging
    • Nenhum valor sensível no repositório GitOps (verificado por scanner)
    • Rollback por git revert com tempo registrado

  • SLO, incidente e postmortem

    Ninja+250 XP

    Defina os SLOs do CloudShop, conduza um incidente controlado e publique o postmortem sem culpa com ações, donos e prazos.

    PrometheusGrafanaOpenTelemetry

    Critérios de aceitação

    • Dois SLIs com consulta PromQL e metas justificadas
    • Alertas por sintoma e por burn rate, com runbook vinculado
    • Linha do tempo do incidente com impacto medido em minutos e em error budget
    • Postmortem com causas contribuintes, o que funcionou e ações com prazo