Quiz

Clique em "Resposta" para revelar a resposta correta e a explicação.

Integração contínua

Q1. Por que o CatalogApiTest usa Testcontainers em vez de um banco em memória como o H2?

• A. O Testcontainers é mais rápido que o H2
• B. O teste roda o PostgreSQL 17 real (e o Redis): as migrações do Flyway, o dialeto SQL, as constraints e o cache se comportam exatamente como em produção, então um teste que passa diz algo sobre produção
• C. O H2 não pode ser usado com o Spring Boot 4
• D. O GitHub Actions proíbe bancos em memória

Q2. O workflow tem permissions: contents: read no topo, e o job image acrescenta packages: write, id-token: write, attestations: write e security-events: write. Por que não dar write-all ao workflow inteiro?

• A. write-all não é YAML válido
• B. Privilégio mínimo: um step comprometido (por exemplo, uma dependência maliciosa num teste) só pode fazer o que o token do seu job permite; os jobs de teste não conseguem fazer push de imagens nem reescrever o repositório
• C. Isso deixa o workflow mais rápido
• D. O GitHub cobra por permissões de escrita

Q3. Por que toda action é fixada num SHA de commit (aquasecurity/trivy-action@ed142fd…, actions/checkout@3d3c42e…) em vez de numa tag?

• A. Tags não são suportadas para actions de terceiros
• B. Uma tag pode ser movida por quem controla o repositório da action; um SHA completo sempre se refere ao mesmo código, então uma tag sequestrada não consegue injetar código no seu pipeline
• C. SHAs fazem o workflow rodar mais rápido
• D. O Dependabot só funciona com SHAs

Cadeia de suprimentos

Q4. O job image faz o build com load: true, escaneia e só então faz o push. Qual é a vantagem sobre fazer o push primeiro e escanear a imagem no registry?

• A. Escanear imagens locais é mais preciso
• B. Uma imagem vulnerável nunca é publicada: se o portão falha, nada chega ao registry, de onde um cluster poderia puxá-la
• C. Só economiza custo de armazenamento no registry
• D. O Trivy não consegue escanear imagens no registry

Q5. Por que o portão do Trivy só falha em vulnerabilidades CRITICAL com correção (ignore-unfixed), enquanto o relatório completo lista tudo?

• A. O Trivy não consegue detectar vulnerabilidades sem correção
• B. Um portão precisa ser acionável: bloquear toda mudança por vulnerabilidades que ninguém consegue corrigir hoje deixa o portão permanentemente vermelho, e os times aprendem a contorná-lo; o relatório mantém o resto visível para priorização
• C. Vulnerabilidades HIGH nunca são exploráveis
• D. O GitHub limita os envios de SARIF a achados críticos

Q6. O que a atestação de proveniência do build permite verificar com gh attestation verify?

• A. Que a imagem não tem vulnerabilidades
• B. Que este digest exato de imagem foi construído pelo workflow do seu repositório, a partir de um commit específico, nos runners do GitHub — e não foi modificado desde então
• C. Que o SBOM está completo
• D. Que a imagem foi escaneada pelo Trivy

Portão de desempenho

Q7. O teste de orçamento tem um cenário warmup de 20 s que não é coberto pelos thresholds. Por quê?

• A. Para economizar minutos de CI
• B. Uma JVM recém-iniciada é mais lenta (compilação JIT, pools e cache vazios): medi-la faria o portão falhar por ruído em vez de por regressões
• C. O k6 precisa de tempo para iniciar os seus usuários virtuais
• D. Thresholds não podem se aplicar ao teste inteiro

Q8. O orçamento é p95 < 300 ms, e a execução normal mede p95 ≈ 7 ms. Um threshold tão folgado não é inútil?

• A. Sim, deveria ser 8 ms
• B. Não: runners compartilhados de CI são ruidosos, então um threshold apertado falharia aleatoriamente; o portão está lá para pegar regressões grandes (o sleep proposital de 400 ms, uma query N+1), enquanto a tendência dos números ao longo de muitas execuções revela as pequenas
• C. Sim, thresholds sempre devem ser iguais ao valor medido
• D. Não, porque o k6 arredonda as latências

GitOps e canary

Q9. Neste lab, o CI nunca roda kubectl apply contra o cluster. Como uma nova versão chega ao deploy?

• A. O Argo CD consulta o GHCR em busca de novas imagens
• B. O workflow Deploy faz commit da nova tag da imagem em k8s/overlays/gitops; o Argo CD, rodando dentro do cluster, vê o commit e aplica o overlay
• C. O Kubernetes puxa a tag main a cada minuto
• D. O desenvolvedor roda kubectl apply depois do CI

Q10. Alguém roda kubectl -n boxoffice scale deployment redis --replicas=0. O que acontece com selfHeal: true?

• A. O Redis fica com 0 réplicas até o próximo deploy
• B. O Argo CD detecta que o cluster difere do Git (OutOfSync) e restaura 1 réplica em segundos
• C. O Argo CD apaga o Deployment do Redis
• D. O HPA escala o Redis de volta

Q11. A release ruim (30% de erros) foi abortada com as medições [], 0.068, 0.285 e failureLimit: 1. Por que a primeira medição, vazia, não reprovou a análise?

• A. O Argo Rollouts ignora a primeira medição
• B. A condição de sucesso len(result) == 0 || isNaN(result[0]) || result[0] < 0.01 trata "ainda sem tráfego no canary" como sucesso; o abort veio com a segunda falha (0,068 e 0,285 > 1%), ultrapassando failureLimit: 1
• C. O Prometheus estava fora do ar
• D. O canary não tinha pods

Q12. Durante um canary, a versão antiga e a nova do catalog rodam contra o mesmo banco. Qual mudança de schema é segura de entregar na nova versão?

• A. Renomear uma coluna que a versão antiga lê
• B. Remover uma coluna que a nova versão não usa mais
• C. Adicionar uma nova coluna nullable (expand), com o novo código tolerando a sua ausência
• D. Mudar o tipo de uma coluna no lugar

Voltar ao lab