Pular para conteúdo

DevOps e Cloud – Fundamentos Práticos 🚀

Domine a integração entre desenvolvimento (Dev) e operações (Ops), aplicando práticas modernas de automação, containers, pipelines de CI/CD e serviços em nuvem.

Foco do Curso

Metodologia: Aprendizado prático e direto ao ponto, focado em ferramentas reais do mercado (Docker, GitHub Actions, AWS, Terraform) para acelerar a entrega de software com qualidade.

🎯 O Que Você Vai Aprender

  • Cultura DevOps --- Entenda a colaboração entre times, metodologias ágeis e como o DevOps resolve gargalos tradicionais de software. Ir para Módulo 1

  • CI/CD e Automação --- Aprenda a criar pipelines automatizados que testam, buildam e entregam o seu código de forma contínua e segura. Ver Automação

  • Containers (Docker) --- Domine a arte de empacotar aplicações em containers, garantindo que o software funcione em qualquer ambiente. Ver Containers

  • Cloud & IaC --- Entenda os principais provedores (AWS, Azure) e aprenda a gerenciar infraestrutura via código com Terraform. Ver Cloud

📚 Jornada de Aprendizado (16 Aulas)

O curso é estruturado em quatro módulos essenciais.

🧱 Módulo 1: Fundamentos de DevOps (Aulas 01-04)

⚙️ Módulo 2: Integração e Automação (Aulas 05-08)

☁️ Módulo 3: Cloud Computing (Aulas 09-12)

🛡️ Módulo 4: Operações e Segurança (Aulas 13-16)

Começar Minha Jornada DevOps

Plano de Ensino 🧭

Curso: DevOps e Cloud – Fundamentos Práticos
Público-alvo: Estudantes de ADS, Ciência da Computação e Desenvolvedores de Software
Carga Horária: 20 Aulas (80 Horas Teórico-Práticas)

🎯 1. Objetivos do Curso

  • Compreender os fundamentos conceituais e arquiteturais de DevOps e Cloud – Fundamentos Práticos.
  • Aplicar padrões de projeto, sintaxe moderna e boas práticas da indústria.
  • Desenvolver soluções completas através de exercícios práticos e desafios de projeto.

📚 2. Cronograma de Aulas (Matriz de 20 Semanas)

Aula Tema Central Atividades e Entregas
01 Introdução ao DevOps e Cultura ️ Teoria, Prática Guiada, Quiz e Exercícios
02 Cultura Ágil e DevOps ‍️ Teoria, Prática Guiada, Quiz e Exercícios
03 Controle de Versão com Git Teoria, Prática Guiada, Quiz e Exercícios
04 Repositórios Remotos e GitHub Teoria, Prática Guiada, Quiz e Exercícios
05 Integração Contínua (CI) ️ Teoria, Prática Guiada, Quiz e Exercícios
06 Entrega Contínua (CD) Teoria, Prática Guiada, Quiz e Exercícios
07 Containers e Virtualização Teoria, Prática Guiada, Quiz e Exercícios
08 Docker na Prática Teoria, Prática Guiada, Quiz e Exercícios
09 Fundamentos de Cloud Computing ️ Teoria, Prática Guiada, Quiz e Exercícios
10 Principais Provedores de Cloud (AWS, Azure, GCP) Teoria, Prática Guiada, Quiz e Exercícios
11 Deploy em Cloud (Simulação e Prática) Teoria, Prática Guiada, Quiz e Exercícios
12 Infraestrutura como Código (IaC) Teoria, Prática Guiada, Quiz e Exercícios
13 Monitoramento e Observabilidade Teoria, Prática Guiada, Quiz e Exercícios
14 Segurança em Cloud e DevSecOps ️ Teoria, Prática Guiada, Quiz e Exercícios
15 Projeto Prático Integrador ️ Teoria, Prática Guiada, Quiz e Exercícios
16 Mercado, Carreira e Próximos Passos ‍️ Teoria, Prática Guiada, Quiz e Exercícios
17 Infrastructure as Code (IaC) com Terraform e Ansible Teoria, Prática Guiada, Quiz e Exercícios
18 Orquestração de Contêineres com Kubernetes (K8s) Teoria, Prática Guiada, Quiz e Exercícios
19 Monitoramento e Observabilidade com Prometheus e Grafana Teoria, Prática Guiada, Quiz e Exercícios
20 Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma Teoria, Prática Guiada, Quiz e Exercícios

🧠 3. Metodologia de Ensino

  • Teoria Fundamentada: Aulas com conceitos detalhados, diagramas arquiteturais e sintaxe de referência.
  • Ciclo Teoria ⇄ Prática: Cada aula conta com Quiz Interativo (10 questões) para validação imediata, Lista de Exercícios Sanfonados (com Gabarito Explicado) e Desafio de Projeto Prático.
  • Laboratório Contínuo: Ambientes configurados passo a passo na seção de Setups da plataforma.

💼 4. Competências e Perfil Desenvolvido

  • Dominar as ferramentas e fluxos de desenvolvimento de DevOps e Cloud – Fundamentos Práticos.
  • Resolver problemas técnicos de alta complexidade com código limpo e performático.
  • Construir portfólio prático com 20 projetos aplicados.

📊 5. Critérios de Avaliação

  • 20 Listas de Exercícios: Resolução individual dividida em Básico, Intermediário e Desafio.
  • 20 Quizzes Interativos: Validação formativa com feedback imediato via JavaScript.
  • 20 Desafios de Projetos: Aplicações práticas consolidando o aprendizado de cada unidade.

Aulas

Módulo 1 - Fundamentos

Aula 01 - Introdução ao DevOps e Cultura ♾️

Objetivo

Objetivo: Compreender o que é o movimento DevOps, sua origem cultural e como ele resolve os conflitos históricos entre times de Desenvolvimento (Dev) e Operações (Ops).

1. O que é DevOps? 🤔

DevOps não é apenas um cargo ou uma ferramenta. É uma cultura e uma série de práticas que unem o Desenvolvimento de Software (Dev) e as Operações de TI (Ops).

O objetivo principal é encurtar o ciclo de vida de desenvolvimento do sistema e fornecer entrega contínua com alta qualidade de software.

🏢 O Modelo Tradicional (Silos)

Antigamente, os times trabalhavam de forma isolada (em "silos"): - Desenvolvimento: Focado em criar novas funcionalidades rapidamente. - Operações: Focado em manter a estabilidade do sistema e evitar mudanças que pudessem causar erros.

Isso gerava o famoso "Muro da Confusão", onde o Dev "jogava" o código por cima do muro e o Ops tinha que se virar para fazê-lo rodar.

2. O Muro da Confusão 🧱

graph LR
    Dev["Desenvolvimento"] -- "Joga o Código" --> Muro(["Muro da Confusão"])
    Muro --> Ops["Operações"]

    style Muro fill:#f66,stroke:#333,stroke-width:4px

Problemas do modelo tradicional:

  • Lentidão: Deploy demorado e burocrático.
  • Conflitos: Acusações mútuas quando algo quebra ("Na minha máquina funciona!").
  • Baixa Qualidade: Bugs descobertos apenas em produção.

3. Os 3 Pilares do DevOps 🏗️

O DevOps se sustenta em três pilares fundamentais:

  1. Cultura: Colaboração, confiança e responsabilidade compartilhada.
  2. Processos: Automação de tarefas repetitivas e feedback rápido.
  3. Ferramentas: Tecnologias que facilitam a integração e o monitoramento.

O Ciclo de Vida DevOps (O Infinito)

graph LR
    subgraph "Dev"
        Plan(["Planejar"]) --> Code(["Codar"])
        Code(["Codar"]) --> Build(["Buildar"])
        Build(["Buildar"]) --> Test(["Testar"])
    end
    subgraph "Ops"
        Release(["Release"]) --> Deploy(["Deploy"])
        Deploy(["Deploy"]) --> Operate(["Operar"])
        Operate(["Operar"]) --> Monitor(["Monitorar"])
    end
    Test --> Release
    Monitor --> Plan

4. Benefícios Práticos 🚀

  • Velocidade: Entregas mais frequentes.
  • Confiabilidade: Menos erros em produção devido à automação.
  • Escalabilidade: Capacidade de gerenciar sistemas complexos com menos esforço.
  • Colaboração: Times trabalham juntos por um objetivo comum: o valor para o cliente.

5. Visão Geral de Ferramentas 🛠️

Embora o DevOps seja cultura, as ferramentas são o que "lubrificam" as engrenagens:

  • Versionamento: Git, GitHub, GitLab.
  • CI/CD: GitHub Actions, Jenkins, CircleCI.
  • Containers: Docker, Kubernetes.
  • Cloud: AWS, Azure, Google Cloud.
  • Monitoramento: Prometheus, Grafana.

Exemplo de Fluxo (Termynal) 💻

git push origin main Build in pipeline... OK Deploy to Cloud... OK Systems Online! 🚀

6. Prática Inicial 💻

Antes de começarmos a codar, precisamos entender o ambiente:

  1. Terminal: Sua maior ferramenta de agora em diante.
  2. Conta no GitHub: Onde seu código viverá e será automatizado.
  3. Mentalidade: Esteja pronto para aprender que "software pronto" é "software rodando bem para o usuário".

7. Exercício de Reflexão 🧠

Pense sobre um site ou app que você usa e que "caiu" ou parou de funcionar recentemente.

  1. Como essa falha poderia ter sido evitada com melhor comunicação entre quem cria e quem mantém o app?
  2. Em sua opinião, qual o maior desafio para dois times diferentes trabalharem juntos?

Próxima Aula: Vamos explorar as metodologias que deram origem ao DevOps na aula de Cultura Ágil! 🏗️

Aula 02 - Cultura Ágil e DevOps 🏃‍♂️

Objetivo

Objetivo: Entender a relação intrínseca entre o DevOps e as metodologias ágeis, explorando como o Scrum e o Manifesto Ágil pavimentaram o caminho para a entrega contínua.

1. Por que Ágil? 🌪️

Antes do Manifesto Ágil (2001), o software era desenvolvido no modelo Cascata (Waterfall): 1. Requisitos (meses) 2. Design (meses) 3. Desenvolvimento (meses) 4. Testes (meses) 5. Entrega (após 1 ano ou mais)

O Problema: Quando o software chegava ao cliente, o mundo já tinha mudado ou as necessidades eram outras.

2. O Manifesto Ágil 📜

O Agile não é um conjunto de regras, mas 4 valores fundamentais:

  • Indivíduos e interações mais que processos e ferramentas.
  • Software em funcionamento mais que documentação abrangente.
  • Colaboração com o cliente mais que negociação de contratos.
  • Responder a mudanças mais que seguir um plano.

Introdução ao Agile Alliance

A Agile Alliance é uma organização sem fins lucrativos que promove esses valores globalmente. No DevOps, bebemos dessa fonte para garantir que a automação sirva às pessoas, e não o contrário.

3. DevOps e Scrum 🔄

O Scrum é o framework ágil mais utilizado. O DevOps estende os benefícios do Scrum para além do desenvolvimento.

Scrum (Foco no Dev) DevOps (Foco no Ciclo Todo)
Sprints (Iterações) Deploy Contínuo
Daily Meetings Feedback em Tempo Real
Product Backlog Infraestrutura como Código
Incremento de Software Software Rodando em Produção

Scrum.org e DevOps

A Scrum.org oferece capacitação que integra as práticas de desenvolvimento com a entrega de software. O DevOps é o "braço técnico" que permite ao Scrum entregar valor em cada Sprint.

4. Conceito de Entrega Contínua (Continuous Delivery) 🏗️

A entrega contínua é a capacidade de colocar alterações de qualquer tipo (novas funcionalidades, configurações, correções de bugs) em produção de forma segura, rápida e sustentável.

Os 3 pilares da Entrega Contínua:

  1. Baixo Risco: Deploys pequenos e frequentes são menos perigosos que um grande deploy anual.
  2. Automação: Se você faz algo mais de duas vezes, automatize!
  3. Qualidade: O software deve estar sempre em um estado "implantável" (deployable).

5. Visualizando o Fluxo Ágil-DevOps 🌊

graph LR
    subgraph "Ágil (Planejamento)"
        Backlog(["Backlog"]) --> Sprint(["Sprint"])
        Sprint(["Sprint"]) --> Feature(["Funcionalidade"])
    end
    subgraph "DevOps (Entrega)"
        Feature --> Build(["Build"])
        Build --> Test(["Teste"])
        Test --> Deploy(["Deploy"])
    end
    Deploy --> Feedback(["Feedback"])
    Feedback --> Backlog

Automação Ágil (Termynal) 💻

npm run sprint-check Verificando Backlog... OK Validando incrementos... OK Status: Pronto para Deploy! 🚀

6. Prática Inicial 🛠️

Para ser ágil, você precisa de visibilidade. No mundo DevOps, usamos ferramentas de gestão como: * GitHub Projects: Para organizar tarefas (To Do, Doing, Done). * Trello / Jira: Para fluxos mais complexos.

Sua tarefa: Pense em um projeto simples (ex: criar um site pessoal). Divida ele em 3 tarefas pequenas que possam ser feitas em 1 hora cada. Isso é desconstruir em partes ágeis!

7. Exercício de Fixação 🧠

  1. Explique com suas palavras a diferença entre o modelo Cascata e o Ágil.
  2. Como a prática de DevOps ajuda um time a ser verdadeiramente ágil?
  3. O que significa dizer que um software deve estar sempre em estado "deploiável"?

Próxima Aula: Vamos aprender a ferramenta base de qualquer DevOps: o Git Essencial! 📡

Aula 03 - Controle de Versão com Git 📜

Objetivo

Objetivo: Compreender o conceito de versionamento de código, aprender os comandos fundamentais do Git e entender como ele permite que múltiplos desenvolvedores trabalhem no mesmo projeto sem caos.

1. O que é Versionamento? 🕰️

Imagine que você está escrevendo um TCC. Você salva como TCC_final.docx, depois TCC_final_v2.docx, depois TCC_final_agora_vai.docx.

O Controle de Versão (VCS) resolve isso de forma profissional, permitindo que você: * Mantenha um histórico de todas as alterações. * Volte no tempo se algo quebrar. * Trabalhe em equipe sem sobrescrever o trabalho do colega.

O Git é o sistema de controle de versão distribuído mais popular do mundo.

2. A Estrutura do Git (Os 3 Estados) 🏗️

O Git trabalha com três áreas principais:

  1. Working Directory: Onde você edita seus arquivos.
  2. Staging Area (Index): Onde você marca os arquivos que quer salvar no próximo "print" (commit).
  3. Repository (.git): Onde o Git guarda permanentemente as fotos (snapshots) do seu código.
graph LR
    WD(["Working Directory"]) -- "git add" --> SA(["Staging Area"])
    SA -- "git commit" --> RP(["Local Repository"])
    RP -- "git push" --> Remote(["Remote Repository"])

3. Comandos Básicos (Mão na Massa) 🛠️

Abra seu terminal e prepare-se para usar os comandos sagrados:

Comandos de Fluxo (Termynal) 💻

git init Initialized empty Git repository... git add . git commit -m "Meu primeiro commit" [main (root-commit) 1a2b3c4] Meu primeiro commit git status nothing to commit, working tree clean

4. Branches: Linhas do Tempo 🌿

Uma Branch é uma ramificação do seu projeto. Você pode criar uma branch para testar uma funcionalidade nova sem estragar a versão principal (main).

  • git branch: Lista as branches.
  • git checkout -b nova-feature: Cria e muda para uma nova branch.
  • git merge nova-feature: Junta as alterações da branch na main.

5. Boas Práticas de Commits 📝

Um bom desenvolvedor DevOps escreve mensagens de commit que fazem sentido: * ❌ git commit -m "ajuste" * ❌ git commit -m "foi" * ✅ git commit -m "Adiciona validação de e-mail no formulário de login"

Dica: Use o presente e seja descritivo: "Adiciona X", "Corrige Y", "Remove Z".

6. Prática Sugerida 💻

  1. Crie uma pasta chamada meu-primeiro-git.
  2. Inicie o git nela (git init).
  3. Crie um arquivo index.html.
  4. Adicione e commite (git add . e git commit).
  5. Crie uma branch chamada ajuste-texto, mude o arquivo e faça o merge.

7. Exercício de Fixação 🧠

  1. Qual a diferença entre a Staging Area e o Repositório Local?
  2. Para que serve o comando git merge?
  3. Por que é importante usar uma branch diferente para cada nova funcionalidade?

Próxima Aula: Vamos levar nosso código para o mundo com o GitHub Colaborativo! 👥

Aula 04 - Repositórios Remotos e GitHub 👥

Objetivo

Objetivo: Entender o papel do GitHub como plataforma de colaboração, aprender a trabalhar com repositórios remotos, dominar o fluxo de Pull Requests e o Git Flow simplificado.

1. O que é o GitHub? ☁️

Enquanto o Git é o software que controla as versões na sua máquina, o GitHub é um serviço de nuvem que hospeda esses repositórios. Pense nele como uma "Rede Social para Programadores", mas com ferramentas poderosas de automação.

Por que usar?

  • Backup: Seu código está seguro na nuvem.
  • Colaboração: Muitos desenvolvedores podem contribuir no mesmo projeto.
  • Portfólio: Uma vitrine para empresas verem o que você sabe fazer.
  • Automação (DevOps): Onde os pipelines de CI/CD (GitHub Actions) acontecem.

2. Trabalhando com Remotos 📡

Para conectar seu Git local ao GitHub, usamos os comandos de "sincronização":

  • git remote add origin [URL]: Conecta sua pasta local a um repositório no GitHub.
  • git push -u origin main: Envia seus commits locais para o GitHub.
  • git pull: Traz as novidades que seus colegas enviaram para o GitHub.
  • git clone [URL]: Baixa um projeto inteiro para sua máquina.

3. Fluxo de Trabalho: Pull Requests (PR) 📥

No DevOps, nunca enviamos código diretamente para a branch prinicipal (main) sem revisão. Usamos o fluxo de Pull Request:

  1. Você cria uma Branch para sua tarefa (feature-login).
  2. Faz os commits e o Push.
  3. No GitHub, você abre um Pull Request.
  4. Seus colegas revisam seu código, fazem comentários e sugerem mudanças.
  5. Quando tudo estiver OK, o código é "mergeado" na main.

4. Git Flow Simplificado 🌊

O Git Flow é uma estratégia de organização de branches. Para iniciantes, usamos este modelo simples:

  • main: Código estável que está rodando para o usuário (em "produção").
  • develop: Onde as funcionalidades novas são integradas antes de irem para a main.
  • features/: Branches temporárias para criar algo novo (ex: feature/ajuste-fonte).
graph LR
    Main(["main"]) --- Develop(["develop"])
    Develop --- F1(["feature/A"])
    Develop --- F2(["feature/B"])
    F1 -- "PR" --> Develop
    Develop -- "Release" --> Main

Comandos de Sincronização (Termynal) 💻

git remote add origin https://github.com/usuario/repo.git git push -u origin main Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Writing objects: 100% (5/5), 450 bytes | 450.00 KiB/s, done. To https://github.com/usuario/repo.git * [new branch] main -> main branch 'main' set up to track 'origin/main'.

5. Colaboração Profissional 🤝

  • Issues: Para relatar bugs ou pedir novas funcionalidades.
  • Code Review: O ato de ler o código do colega para garantir qualidade e aprender.
  • README.md: O arquivo mais importante! Explica o que o projeto faz e como rodar.

6. Prática Sugerida 🚀

  1. Crie um repositório público no seu GitHub chamado lab-devops-01.
  2. Suba os arquivos que criamos na aula anterior (git push).
  3. Crie um arquivo chamado README.md direto pelo site do GitHub.
  4. Dê um git pull na sua máquina para ver o arquivo aparecer lá.
  5. Crie uma branch, mude algo e abra seu primeiro Pull Request para você mesmo.

7. Exercício de Fixação 🧠

  1. Diferencie Git de GitHub.
  2. O que é um Pull Request e por que ele é vital para a cultura DevOps?
  3. Qual o comando para baixar um repositório existente do GitHub pela primeira vez?

Fim do Módulo 1! Você agora entende a cultura e a base técnica. No próximo módulo, iniciaremos a Integração Contínua e Automação! ⚙️

Módulo 2 - CI/CD e Automação

Aula 05 - Integração Contínua (CI) ⚙️

Objetivo

Objetivo: Entender o conceito de Integração Contínua (CI), por que ela é fundamental para o DevOps e como as ferramentas automatizam o processo de build e teste cada vez que um commit é feito.

1. O que é Integração Contínua (CI)? 🔄

A Integração Contínua é a prática de integrar o código de todos os desenvolvedores em um repositório compartilhado várias vezes ao dia.

Cada integração é verificada por um Build Automatizado e por Testes Automatizados, permitindo que as equipes detectem problemas rapidamente.

O Problema do "Integration Hell" 😵‍💫

Antes do CI, os desenvolvedores trabalhavam isolados por semanas. Na hora de juntar tudo (merge), o sistema quebrava de tantas formas que levava dias para consertar. O CI resolve isso ao integrar pequenas mudanças constantemente.

2. O Pipeline de CI 🏗️

Um pipeline de CI geralmente segue este fluxo:

graph LR
    Code(["Código"]) --> Commit(["Commit/Push"])
    Commit --> Build(["Build/Compilação"])
    Build --> Unit(["Testes Unitários"])
    Unit --> Static(["Análise Estática"])
    Static --> Artifact(["Artefato Gerado"])

Automação de CI (Termynal) 💻

git push origin develop Iniciando Pipeline... Rodando Pytest... [PASSED] Análise de Lint... [SUCCESS] Geração de Imagem: v1.0.5 Status: Pipeline Completo! ✅

  1. Commit/Push: O gatilho que inicia o processo.
  2. Build: O servidor baixa as dependências e o código é transformado em algo executável (se necessário).
  3. Testes Unitários: Scripts que testam as menores partes do código (funções e classes).
  4. Análise Estática (Lint): Verifica se o código segue boas práticas e padrões de estilo.
  5. Artefato: O resultado final (um arquivo .bin, uma imagem Docker, etc) pronto para ser testado mais a fundo.

3. Benefícios do CI 💎

  • Feedback Rápido: O desenvolvedor sabe em minutos se quebrou algo.
  • Qualidade do Código: Erros não chegam a branches estáveis.
  • Confiança: O time sabe que o código no repositório está "saudável".
  • Documentação Viva: Os testes automatizados explicam como o sistema deveria funcionar.

4. Ferramentas Populares de CI 🛠️

Existem muitas ferramentas no mercado. As mais usadas hoje são:

  • GitHub Actions: Integrado diretamente no GitHub (vamos focar nele!).
  • Jenkins: O "vovô" do CI, muito poderoso e customizável.
  • GitLab CI: Integrado ao GitLab.
  • CircleCI / Travis CI: Soluções de mercado focadas em facilidade de uso.

5. Prática Sugerida: O Primeiro Pipeline 🚀

Imagine que você tem um projeto Python. Um arquivo de workflow do GitHub Actions (.github/workflows/main.yml) seria assim:

name: CI Pipeline
on: [push] # Gatilho
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Instalar Dependências
        run: pip install -r requirements.txt
      - name: Rodar Testes
        run: pytest

6. Exercício de Fixação 🧠

  1. Qual a diferença entre um Build Manual e um Build de CI?
  2. O que acontece se um teste falhar durante o pipeline de CI?
  3. Por que o feedback rápido é considerado a maior vantagem do CI?

Próxima Aula: Agora que o código está integrado e testado, como levamos ele para o usuário? Vamos falar de Entrega Contínua (CD)! 🚚

Aula 06 - Entrega Contínua (CD) 🚚

Objetivo

Objetivo: Compreender a diferença entre Entrega Contínua (Continuous Delivery) e Implantação Contínua (Continuous Deployment), e entender como o código sai do repositório e chega ao ambiente de produção.

1. O que é Entrega Contínua (CD)? 📦

Se o CI é sobre integrar código, o CD é sobre entregar esse código.

Existem duas variações do CD:

  • Continuous Delivery (Entrega Contínua): O pipeline automatiza todo o processo de deploy, mas a decisão final de "apertar o botão" e colocar no ar é humana. É o modelo mais comum em empresas grandes.
  • Continuous Deployment (Implantação Contínua): Todo commit que passa nos testes de CI vai automaticamente para produção, sem intervenção humana. Exige altíssima confiança nos testes.

2. O Pipeline de CD 🏗️

O CD começa onde o CI termina. Após a geração do artefato:

graph LR
    Artifact(["Artefato"]) --> Staging(["Ambiente de Homologação"])
    Staging --> Manual(["Aprovação Humana"])
    Manual --> Prod(["Ambiente de Produção"])

Automação de CD (Termynal) 💻

git push origin main Build... OK Testes... OK Aguardando aprovação para Produção... approve-deploy --env prod Deploying to AWS... Status: Site Online! 🚀

  1. Staging (Homologação): Um ambiente idêntico ao real onde o time testa a nova versão.
  2. Testes de Aceitação: Testes automatizados (end-to-end) que simulam o usuário final.
  3. Deploy em Produção: A atualização final do sistema para os usuários reais.

3. Estratégias de Deploy 🛡️

Para evitar que o sistema fique fora do ar durante a atualização, usamos estratégias como:

  • Blue-Green Deployment: Você tem dois ambientes idênticos. O "Green" está no ar. Você sobe a versão nova no "Blue". Se tudo estiver ok, você vira a chave do roteador para o "Blue".
  • Canary Release: Você libera a versão nova para apenas 5% dos usuários. Se não houver erros, libera para o restante.
  • Rolling Update: Atualiza um servidor por vez, gradualmente, até que todos estejam na versão nova.

4. O papel da Infraestrutura como Código (IaC) 💻

No CD moderno, não configuramos servidores clicando em janelas. Usamos código para descrever a infraestrutura. Isso garante que o ambiente de teste seja exatamente igual ao de produção.

5. Prática Sugerida: Deploy no GitHub Pages 🚀

Um exemplo simples de CD é o que estamos fazendo neste curso! Sempre que fazemos um push para a branch main, o GitHub Actions: 1. Gera o site (MkDocs). 2. Publica automaticamente na internet (GitHub Pages).

Este é um exemplo de Continuous Deployment.

6. Exercício de Fixação 🧠

  1. Explique a diferença entre Continuous Delivery e Continuous Deployment.
  2. O que é um ambiente de "Staging" e por que ele é crucial?
  3. Qual a vantagem da estratégia "Canary" em comparação com atualizar todos os servidores de uma vez?

Próxima Aula: Como garantimos que o código rode exatamente igual na minha máquina e no servidor? Vamos entrar no mundo dos Containers e Virtualização! 🐳

Aula 07 - Containers e Virtualização 🐳

Objetivo

Objetivo: Entender o que são containers, como eles se diferenciam das Máquinas Virtuais (VMs) tradicionais e por que eles se tornaram o padrão da indústria para Deploy de aplicações.

1. O Problema: "Na minha máquina funciona!" 🤷‍♂️

Um dos maiores desafios do desenvolvimento é garantir que o software rode da mesma forma no computador do desenvolvedor e no servidor de produção. Diferenças de sistema operacional, bibliotecas e versões causam erros inesperados.

A Conteinerização resolve isso empacotando a aplicação com tudo o que ela precisa para rodar.

2. Containers vs Máquinas Virtuais (VMs) ⚔️

Antigamente, usávamos VMs para isolar aplicações. Mas as VMs são pesadas.

Característica Máquina Virtual (VM) Container (Docker)
Peso Pesada (Gigas) Leve (Megas)
Velocidade Minutos para ligar Segundos para ligar
Isolamento Completo (Hardware virtual) Processos isolados no SO
Sistema Operacional Possui um SO completo dentro Compartilha o Kernel do Host

Estrutura de Container vs VM

graph TD
    subgraph VM["Máquina Virtual (VM)"]
        APP1["App"] --> LIB1["Biliotecas"]
        LIB1 --> OS1["SO Convidado"]
        OS1 --> HYP["Hipervisor"]
    end
    subgraph CT["Container (Docker)"]
        APP2["App"] --> LIB2["Bibliotecas"]
        LIB2 --> DE["Docker Engine"]
        DE --> OS2["SO Host (Kernel)"]
    end

Rodando seu primeiro Container (Termynal) 💻

docker run hello-world Unable to find image 'hello-world:latest' locally latest: Pulling from library/hello-world Digest: sha256:d37adae... Status: Downloaded newer image for hello-world:latest Hello from Docker! 🐳

3. O que é um Container? 📦

Pense em um container como uma "caixa" que contém: * O código da sua aplicação. * O runtime (ex: Node.js, Python, Java). * As bibliotecas dependentes. * Variáveis de ambiente e arquivos de configuração.

Tudo o que está dentro da caixa é imutável e portável. Se rodar no seu PC, vai rodar igual em qualquer lugar que tenha Docker.

4. Como funciona o Docker? 🏗️

O Docker é a ferramenta que popularizou os containers. Ele trabalha com três conceitos básicos:

  1. Dockerfile: A "receita do bolo". Um arquivo de texto com as instruções para criar a imagem.
  2. Imagem: O "bolo pronto e congelado". É o arquivo que contém a aplicação pronta para rodar.
  3. Container: O "bolo sendo servido". É a imagem em execução (um processo vivo).

5. Benefícios para o DevOps 💎

  • Padronização: O ambiente é o mesmo em Dev, Teste e Prod.
  • Escalabilidade: Você pode subir 100 containers em segundos se o tráfego aumentar.
  • Eficiência: Mais aplicações rodando no mesmo hardware comparado a VMs.
  • Microserviços: Facilita a divisão de uma aplicação grande em partes menores e independentes.

6. Exercício de Fixação 🧠

  1. Por que os containers são considerados mais eficientes que as Máquinas Virtuais?
  2. O que significa dizer que um container é "portável"?
  3. Qual a função do Dockerfile no processo de criação de um container?

Próxima Aula: Vamos colocar a mão na massa e criar nosso primeiro container! Docker na Prática 🚀

Aula 08 - Docker na Prática 🚀

Objetivo

Objetivo: Aprender os comandos essenciais do Docker, construir sua primeira imagem personalizada e rodar um container conectando portas e volumes.

1. Instalando o Docker 🛠️

Para começar, você precisa do Docker Desktop (Acesse docker.com).

Após instalado, abra o terminal e digite: 

docker --version

2. Comandos Básicos do Dia a Dia ⌨️

  • docker images: Lista as imagens que você tem baixadas no PC.

Ciclo de Comandos Docker

graph LR
    DF(["Dockerfile"]) -- "docker build" --> IMG(["Imagem"])
    IMG -- "docker run" --> CT(["Container"])
    CT -- "docker stop" --> ST(["Parado"])
    ST -- "docker rm" --> RM(["Removido"])

Prática: Build e Run (Termynal) 💻

docker build -t meu-site . Sending build context... OK Step 1/3 : FROM nginx:alpine... Successfully tagged meu-site:latest docker run -d -p 8080:80 meu-site f1a2b3c4d5e6... Status: Container rodando em localhost:8080! 🚀

3. Criando sua Própria Imagem (Dockerfile) 📝

Imagine que temos um arquivo index.html. Queremos criar uma imagem que já venha com um servidor web e nossa página dentro.

Crie um arquivo chamado Dockerfile (sem extensão):

# 1. Definir a imagem base
FROM nginx:alpine

# 2. Copiar os arquivos do seu PC para dentro da imagem
COPY index.html /usr/share/nginx/html/index.html

# 3. Informar qual porta o container vai usar
EXPOSE 80

Para gerar a imagem, use: 

docker build -t meu-site-docker .

4. Portas e Mapeamento 🚪

Por padrão, um container é isolado. Para acessá-lo do seu navegador, você precisa mapear uma porta do seu PC para a porta dele.

docker run -d -p 8080:80 meu-site-docker
* -d: Roda em "background" (você continua usando o terminal). * -p 8080:80: Mapeia a porta 8080 do seu computador para a porta 80 do container.

Agora, acesse localhost:8080 no seu navegador! 🎉

5. Persistência de Dados (Volumes) 💾

Se você apagar um container de banco de dados, os dados somem. Os Volumes permitem que o container escreva dados diretamente em uma pasta do seu computador, garantindo que eles não se percam.

6. Exercício de Fixação 🧠

  1. Qual a diferença entre docker run e docker start?
  2. O que o comando docker build faz exatamente?
  3. Se mapearmos a porta -p 3000:80, qual endereço devemos digitar no navegador para acessar a aplicação?

Próxima Aula: Concluímos o Módulo 2! Agora vamos para as nuvens. Módulo 3: Fundamentos de Cloud Computing ☁️

Módulo 3 - Cloud Computing

Aula 09 - Fundamentos de Cloud Computing ☁️

Objetivo

Objetivo: Entender o que é Computação em Nuvem, quais são seus principais modelos (IaaS, PaaS, SaaS) e por que ela é a base de quase todos os sistemas modernos.

1. O que é "A Nuvem"? 🤔

Muitas pessoas pensam que a nuvem é algo abstrato, mas o ditado popular no TI diz: "A nuvem é apenas o computador de outra pessoa".

A Computação em Nuvem é a entrega de recursos de TI (processamento, armazenamento, bancos de dados) sob demanda, via internet, com pagamento por uso.

2. Benefícios da Nuvem 💎

  • Custo: Você não precisa comprar servidores caros. Você "aluga" e paga só pelo que usa.
  • Escalabilidade: Seu site cresceu? Em segundos você aumenta a capacidade.
  • Elasticidade: O tráfego diminuiu de madrugada? A nuvem reduz os recursos automaticamente para economizar.
  • Globalidade: Você pode colocar seu site para rodar em um servidor no Japão com apenas um clique.

3. Modelos de Serviço (O Triângulo da Cloud) 📐

A nuvem é dividida em três camadas principais:

  1. SaaS (Software como Serviço): Você usa o software pronto via navegador. Ex: Gmail, Google Drive, Netflix.

Modelo de Responsabilidade Compartilhada

graph TD
    subgraph SaaS["SaaS (Gmail/Netflix)"]
        S1["Provedor cuida de TUDO"]
    end
    subgraph PaaS["PaaS (Heroku/App engine)"]
        P1["Você cuida do APP"]
        P2["Provedor cuida do RESTO"]
    end
    subgraph IaaS["IaaS (AWS EC2/Azure VM)"]
        I1["Você cuida do APP e do SO"]
        I2["Provedor cuida do HARDWARE"]
    end

Explorando a Nuvem (Termynal) 💻

aws ec2 describe-instances --region us-east-1 Fetching instances... { "Instances": [ { "InstanceId": "i-0987654321", "State": "running" } ] } Status: 1 servidor rodando na Virgínia! ☁️

4. Modelos de Implantação 🏠

  • Nuvem Pública: Os recursos são compartilhados por várias empresas (AWS, Azure, GCP).
  • Nuvem Privada: Recursos dedicados exclusivamente a uma única organização.
  • Nuvem Híbrida: Uma mistura das duas (dados sensíveis na privada, site na pública).

5. Por que Cloud e DevOps andam juntos? 🤝

O DevOps prega a agilidade e a automação. A nuvem fornece as "peças" (APIs) para que possamos automatizar a criação de servidores, redes e bancos de dados via código. Sem a nuvem, o DevOps seria muito mais lento.

6. Exercício de Fixação 🧠

  1. Explique a diferença entre Escalabilidade e Elasticidade.
  2. Dê um exemplo de um serviço SaaS que você usa no dia a dia.
  3. Se você quer ter controle total sobre o Sistema Operacional do seu servidor na nuvem, qual modelo você escolheria: IaaS, PaaS ou SaaS?

Próxima Aula: Quem são os gigantes que dominam este mercado? Principais Provedores (AWS, Azure, GCP) 🏢

Aula 10 - Principais Provedores de Cloud (AWS, Azure, GCP) 🏢

Objetivo

Objetivo: Conhecer os três maiores provedores de computação em nuvem do mundo, entender seus principais serviços e aprender como escolher o melhor para cada projeto.

1. O Mercado de Cloud 📊

Embora existam dezenas de empresas de nuvem, o mercado é dominado pelo "Big Three": AWS, Microsoft Azure e Google Cloud.

pie title Market Share Cloud (Estimativa 2024)
    "AWS" : 31
    "Azure" : 25
    "Google Cloud" : 11
    "Outros" : 33

2. AWS (Amazon Web Services) 🟠

A pioneira e atual líder de mercado. É conhecida por ter a maior variedade de serviços. * Carro-chefe: EC2 (Servidores virtuais). * S3: Armazenamento de arquivos super barato e seguro. * Perfil: Ideal para empresas que precisam de ferramentas muito específicas e maduras.

3. Microsoft Azure 🔵

A favorita das grandes empresas que já usam Windows e Office. Integração total com o ecossistema Microsoft. * Carro-chefe: Azure App Service. * Active Directory: Gerenciamento de usuários e logins empresariais. * Perfil: Escolha padrão para o mundo corporativo e usuários de .NET.

4. Google Cloud Platform (GCP) 🔴

Conhecida pela sua excelência em ferramentas de Dados, Inteligência Artificial e Kubernetes. * Carro-chefe: GKE (Google Kubernetes Engine). * BigQuery: Banco de dados para análise de trilhões de linhas em segundos. * Perfil: Preferida por startups e empresas focadas em inovação e IA.

5. Comparação de Serviços (Nomes diferentes, mesma função) 🔄

Função AWS Azure GCP
Servidor CPU EC2 Virtual Machines Compute Engine
Containers ECS / EKS AKS GKE
Arquivos S3 Blob Storage Cloud Storage
Banco SQL RDS Azure SQL Cloud SQL
Sem Servidor Lambda Azure Functions Cloud Functions

6. Como escolher? 🤔

  1. Conhecimento Técnico: Sua equipe já conhece alguma? Comece por ela.
  2. Tecnologia: Usa .NET? Vá de Azure. Usa Docker/K8s pesado? Considere GCP. Precisa de tudo e mais um pouco? AWS.
  3. Localização: Onde estão seus usuários? Escolha o servidor mais próximo deles (Brasil tem regiões de todas as 3).

Verificando Latência (Termynal) 💻

ping sa-east-1.amazonaws.com 64 bytes from ... icmp_seq=1 ttl=245 time=15.2 ms 64 bytes from ... icmp_seq=2 ttl=245 time=14.8 ms Região: São Paulo (Baixa Latência) ✅

7. Exercício de Fixação 🧠

  1. Se uma empresa usa massivamente o ecossistema Microsoft (Office 365, Active Directory), qual nuvem ela provavelmente escolherá?
  2. Qual serviço da AWS você usaria para guardar as fotos dos usuários do seu app?
  3. O Google Cloud é muito respeitado por qual tipo de tecnologia específica citada na aula?

Próxima Aula: Como colocamos nosso código lá dentro? Deploy em Cloud (Simulação e Prática) 🚀

Aula 11 - Deploy em Cloud (Simulação e Prática) 🚀

Objetivo

Objetivo: Entender o que acontece "nos bastidores" quando enviamos nosso código para a nuvem e como usar ferramentas de PaaS para fazer o deploy de aplicações Docker de forma simplificada.

1. O que é Deploy? 📦

Deploy (ou Implantação) é o processo de tirar o seu código da sua máquina de desenvolvimento e colocá-lo em um servidor acessível a todos os usuários via internet.

2. O Fluxo de Deploy com Docker ⛴️

Quando usamos Docker, o deploy fica muito mais seguro e previsível:

graph LR
    Dev(["Desenvolvedor"]) -->|Push| Repo(["GitHub"])
    Repo -->|Build| Image(["Imagem Docker"])
    Image -->|Push| Registry(["Registry"])
    Registry -->|Pull| Cloud(["Cloud"])

Simulação de Deploy (Termynal) 💻

docker build -t app:v1 . Building image... Done docker push registry.com/app:v1 Pushing [==========>] 100MB/100MB deploy-to-cloud --image app:v1 Pulling image... OK Starting container... OK Status: Aplicação no Ar! 🚀

  1. Build: Criamos a imagem da aplicação.
  2. Push: Enviamos a imagem para um "cartório" de imagens (Registry).
  3. Run: O servidor na nuvem baixa a imagem e inicia o container.

3. Formas de fazer Deploy na Nuvem 🏗️

Existem diferentes níveis de dificuldade:

  • Dificuldade Alta (IaaS): Você cria uma VM, instala o Docker manualmente, configura o firewall e sobe o container. (EC2, Azure VM).
  • Dificuldade Média (Managed): Você usa um serviço que gerencia os containers para você. (AWS ECS, Google Cloud Run).
  • Dificuldade Baixa (PaaS): Você apenas conecta seu GitHub e a nuvem faz tudo sozinha. (Heroku, Render, Railway).

4. Prática: Conceito de Serverless Containers ⚡

Serviços como o Google Cloud Run ou AWS Fargate são o "estado da arte". Você paga apenas pelos segundos em que seu container está sendo usado. Se ninguém acessa o site, o custo é zero!

5. Variáveis de Ambiente em Produção 🔑

IMPORTANTE: Nunca coloque senhas ou chaves de API direto no código ou no Dockerfile. No deploy em nuvem, usamos as "Environment Variables" (Variaáveis de Ambiente) configuradas no painel do provedor.

6. Diferença entre Deploy e Release 🏁

  • Deploy: O código está no servidor.
  • Release: O código está disponível para o usuário final. Usando ferramentas modernas, podemos fazer o deploy de uma versão nova mas só liberá-la (release) para os usuários depois de testarmos no ambiente real.

7. Exercício de Fixação 🧠

  1. Qual a vantagem de usar um Registry (como o Docker Hub) no processo de deploy?
  2. Por que o modelo "Serverless" (como Cloud Run) é atraente economicamente para pequenas empresas?
  3. Onde devemos guardar a senha do banco de dados na hora de fazer o deploy na nuvem? No código ou em Variáveis de Ambiente?

Próxima Aula: Como criar toda essa infraestrutura sem clicar em botões? Infraestrutura como Código (IaC) 💻

Aula 12 - Infraestrutura como Código (IaC) 💻

Objetivo

Objetivo: Compreender o conceito de Infraestrutura como Código (IaC), entender a diferença entre provisionamento imperativo e declarativo, e conhecer o Terraform como a ferramenta líder de mercado.

1. O que é Infraestrutura como Código (IaC)? 🏗️

Antigamente, para criar um servidor, um analista precisava entrar no console da AWS/Azure, clicar em vários botões e preencher formulários. Com IaC, nós escrevemos um arquivo de texto (código) que descreve como a infraestrutura deve ser. O software lê esse arquivo e cria tudo automaticamente.

2. Por que usar IaC? 💎

  • Velocidade: Criar 100 servidores leva o mesmo tempo que criar 1.
  • Versionamento: Sua infraestrutura está no Git. Você sabe quem mudou o quê e quando.
  • Padronização: Garante que o ambiente de Teste seja exatamente igual ao de Produção.
  • Recuperação: Se um datacenter inteiro pegar fogo, você roda o código e recria tudo em outro lugar em minutos.

O Poder da IaC

graph LR
    Code(["Código .tf"]) -- "Terraform Init" --> Providers(["Provedores"])
    Providers -- "Terraform Plan" --> Review(["Revisão"])
    Review -- "Terraform Apply" --> Infrastructure(["Infraestrutura Real"])

Terraform na Prática (Termynal) 💻

terraform plan Terraform will perform the following actions: + aws_instance.web_server Plan: 1 to add, 0 to change, 0 to destroy. terraform apply --auto-approve aws_instance.web_server: Creating... aws_instance.web_server: Creation complete! ✅

3. Imperativo vs Declarativo ⚖️

  • Imperativo (O "Como"): Você dá ordens passo a passo. "Crie uma VM", "Instale o Docker", "Abra a porta 80". (Ex: Shell Script, AWS CLI).
  • Declarativo (O "O Que"): Você descreve o estado final desejado. "Eu quero 1 servidor com Docker e a porta 80 aberta". A ferramenta se vira para chegar lá. (Terraform usa este modelo).

4. Terraform: O Gigante da IaC 🌍

O Terraform é a ferramenta mais popular porque é "Cloud Agnostic" (funciona com quase qualquer nuvem).

# Exemplo de código Terraform (Linguagem HCL)
resource "aws_instance" "meu_servidor" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t2.micro"

  tags = {
    Name = "Servidor-Do-Curso"
  }
}

5. O Fluxo de Trabalho do Terraform 🔄

  1. Write: Escreve o código .tf.
  2. Init: O Terraform baixa os arquivos necessários para falar com a nuvem escolhida.
  3. Plan: O Terraform mostra o que ele vai fazer antes de realmente fazer ("Vou criar 2 itens e destruir 0").
  4. Apply: O Terraform executa as mudanças na nuvem.

6. O arquivo State (.tfstate) 🗂️

O Terraform guarda um arquivo (State) que é o "mapa" da sua infraestrutura atual. Nunca delete ou edite este arquivo manualmente! Ele é a memória do Terraform.

7. Exercício de Fixação 🧠

  1. Qual a principal diferença entre criar um servidor clicando em botões no navegador e criar usando código?
  2. O que significa dizer que o Terraform é "Declarativo"?
  3. Por que é importante colocar o código da infraestrutura em um repositório Git?

Próxima Aula: Como sabemos se o sistema está saudável depois do deploy? Monitoramento e Observabilidade 📊

Módulo 4 - Operações e Segurança

Aula 13 - Monitoramento e Observabilidade 📊

Objetivo

Objetivo: Entender a diferença entre Monitoramento e Observabilidade e por que é impossível gerenciar o que você não consegue medir.

1. Por que monitorar? 🤔

No mundo DevOps, não perguntamos se algo vai falhar, mas quando. O monitoramento nos permite detectar falhas antes que o cliente perceba.

  • Disponibilidade: O site está no ar?
  • Performance: O site está rápido ou lento?
  • Erros: Quantos erros 500 estamos tendo por minuto?

2. Monitoramento vs Observabilidade 🔭

  • Monitoramento: "O sistema está funcionando?" (Checks de Sim/Não, CPU, Memória). É o "O Quê".
  • Observabilidade: "Por que o sistema não está funcionando?" (Logs, Métricas, Tracing). É o "Por Quê".

3. Os 3 Pilares da Observabilidade 🏛️

  1. Tracing: O caminho de uma requisição por vários microserviços. Ferramentas: Jaeger, AWS X-Ray.

Fluxo de Observabilidade

graph LR
    APP(["Aplicação"]) -- "Eventos" --> LOGS(["Logs (ELK)"])
    APP -- "Sinais" --> MET(["Métricas (Prometheus)"])
    MET -- "Visualização" --> GRAV(["Grafana"])
    GRAV -- "Critério" --> ALERT(["Alert Manager"])

Investigando Métricas (Termynal) 💻

prometheus-query 'up{job="web-server"}' Métrica: up (status do servidor) Valor: 1 (Online) prometheus-query 'http_requests_total{status="500"}' Valor: 42 (Atenção: Aumento de erros!) Status: Alerta enviado para o Grafana! 🚨

4. O que é o Grafana? 🖼️

O Grafana é uma ferramenta de visualização. Ele se conecta ao seu banco de métricas (Prometheus) e transforma números chatos em gráficos lindos e dashboards em tempo real.

5. Alertas: O grito do servidor 🚨

Não adianta ter gráficos se ninguém olha para eles. Precisamos de alertas automáticos: * "Se o erro passar de 5% em 1 minuto, mande um Slack para o time de DevOps." * "Se o servidor atingir 90% de disco, abra um chamado no Jira."

6. Exercício de Fixação 🧠

  1. Explique a diferença entre uma Métrica e um Log.
  2. Por que dashboards de monitoramento costumam ficar em TVs nas salas de TI?
  3. Qual ferramenta você usaria para visualizar gráficos de performance: Grafana ou Elasticsearch?

Próxima Aula: Como manter tudo isso seguro? Segurança e DevSecOps 🛡️

Aula 14 - Segurança em Cloud e DevSecOps 🛡️

Objetivo

Objetivo: Entender que a segurança não deve ser a última etapa (Checkpoint), mas sim uma camada presente em todo o ciclo de desenvolvimento (Shift Left).

1. O Modelo de Responsabilidade Compartilhada 🤝

Na nuvem, a segurança é dividida entre você e o provedor (AWS/Azure/GCP): * Provedor: Cuida da segurança "DA" nuvem (Data centers físicos, rede, hardware). * Você: Cuida da segurança "NA" nuvem (Seus dados, suas senhas, suas configurações de firewall).

2. O que é DevSecOps? 🛡️🔄

É a evolução do DevOps. Significa integrar a segurança desde o primeiro dia do projeto. * Com DevSecOps: Segurança está em cada commit, em cada build e em cada deploy.

O Ciclo DevSecOps

graph LR
    Plan(["Plan"]) --> Code(["Code"])
    Code --> Scan(["SAST/SCA"])
    Scan --> Build(["Build"])
    Build --> Test(["Test"])
    Test --> Prod(["Release"])
    Prod --> Monitor(["Monitor"])
    Monitor --> Plan
    style Scan fill:#f96,stroke:#333

Verificação de Segurança (Termynal) 💻

npm audit Scanning dependencies... Found 1 high severity vulnerability npm audit fix Fixed 1 vulnerability. 0 vulnerabilities remaining. Status: Código Seguro para Deploy! 🛡️

3. Práticas Essenciais de DevSecOps 🛠️

  1. SAST (Static Application Security Testing): Analisa o código fonte em busca de vulnerabilidades antes mesmo dele rodar.
  2. SCA (Software Composition Analysis): Verifica se as bibliotecas que você baixou (npm, pip) têm vulnerabilidades conhecidas.
  3. Secret Scanning: Ferramentas que impedem você de subir senhas e chaves de API para o GitHub por acidente.

4. O Princípio do Menor Privilégio 🔑

Nunca dê permissão total para tudo. * Ruim: Dar permissão de "ADMIN" para o servidor web. * Bom: O servidor web só pode ler o banco de dados e escrever na pasta de logs.

5. Criptografia: Dados em Repouso e em Trânsito 🔐

  • Em Trânsito: Use sempre HTTPS (TLS). Os dados devem viajar criptografados pela internet.
  • Em Repouso: Os dados salvos no banco de dados e nos discos da nuvem também devem estar criptografados.

6. Exercício de Fixação 🧠

  1. O que significa "Shift Left" na segurança?
  2. No modelo de responsabilidade compartilhada, quem é responsável por garantir que o banco de dados tem uma senha forte?
  3. Qual a diferença entre SAST e SCA?

Próxima Aula: Conclusão do Curso e Próximos Passos! Finalização 🎓

Aula 15 - Projeto Prático Integrador 🏗️🚀

Objetivo

Objetivo: Integrar todos os conhecimentos adquiridos (Git, Docker, Cloud, IaC e Monitoramento) para colocar uma aplicação real no ar seguindo as melhores práticas DevOps.

1. O Desafio: A esteira de produção 🏎️

Ao longo do curso, vimos as peças separadas. Agora, vamos montar o quebra-cabeça. O objetivo é criar o fluxo completo desde o seu computador até a nuvem:

  1. Monitoramento: Validar se os logs e métricas estão subindo.

A Jornada do Projeto

graph TD
    APP(["APP Local"]) -- "Dockerize" --> IMG(["Imagem"])
    IMG -- "Git Push" --> GH(["GitHub Actions"])
    GH -- "Terraform" --> INFRA(["Cloud Infra"])
    GH -- "Deploy" --> RUN(["App no Ar"])
    RUN -- "Metrics" --> MON(["Grafana"])

Orquestrando o Lab Final (Termynal) 💻

git push origin main Triggering Integration... Terraform apply: Done (12 resources) Docker push: Done (v1.0.0) Cloud Run deploy: Done Link: https://projeto-final.a.run.app 🚀

2. Passo 1: O Repositorio 📦

Crie um novo repositório no GitHub. Organize as pastas de forma clara: * /src: Código da aplicação. * /infra: Arquivos do Terraform. * /.github/workflows: Arquivos de CI/CD. * Dockerfile: Receita do container.

3. Passo 2: A Automação (CI) 🤖

Configure o GitHub Actions para que, a cada push, ele: * Rode os testes unitários. * Analise o código com uma ferramenta de Lint. * Gere a imagem Docker e envie para o Docker Hub.

4. Passo 3: Provisionamento (IaC) 💻

Use o Terraform para criar os recursos necessários na Cloud de sua escolha (AWS/Azure/GCP). * Lembre-se de configurar o State File em um bucket remoto (S3/Cloud Storage). * Não suba senhas para o Git! Use variáveis do GitHub Secrets.

5. Passo 4: Deploy e Monitoramento 📊

No último passo do seu pipeline de CD, o código deve ser atualizado no servidor. * Valide o acesso via URL pública. * Acesse o dashboard de monitoramento e veja os gráficos de consumo de CPU aumentarem durante o deploy.

6. Checkpoint de Entrega ✅

Para considerar seu projeto concluído, responda: 1. Sua aplicação está rodando via container? 2. Consigo deletar toda a infraestrutura e recriar com um único comando terraform apply? 3. O deploy acontece automaticamente ao dar git push na branch main?

Próxima Aula: Como entrar neste mercado? Carreira e Próximos Passos 🏃‍♂️

Aula 16 - Mercado, Carreira e Próximos Passos 🏃‍♂️💼

Objetivo

Objetivo: Entender o panorama do mercado de trabalho para profissionais DevOps e como continuar evoluindo após a conclusão deste curso.

1. O Mercado de Trabalho para DevOps 📈

A demanda por profissionais que entendem de automação e nuvem nunca foi tão alta. Atualmente, o DevOps não é apenas um cargo, mas uma cultura necessária em qualquer empresa que queira escalar.

  • Cargos Comuns: Analista DevOps, Engenheiro de Confiabilidade de Sites (SRE), Engenheiro de Cloud, Arquiteto de Soluções.
  • Segmentos: De startups a bancos tradicionais, todos precisam de esteiras de CI/CD eficientes.

2. O Perfil do Profissional T-Shaped 📐

  • Vertical (Especialista): Domínio profundo em uma área específica (ex: Especialista em Kubernetes ou AWS).

O Profissional T-Shaped

graph TD
    subgraph Horizontal["Conhecimento Amplo"]
        A(["Linux"]) --- B(["Redes"])
        B --- C(["Segurança"])
        C --- D(["Dev"])
    end
    D --- E(["Cloud & Automação"])
    E --- F(["Especialista"])
    style E fill:#f9f,stroke:#333

Explorando o Mercado (Termynal) 💻

devops-jobs --search "remoto" Searching LinkedIn, Glassdoor, Indeed... Found: 1,250 open positions for DevOps Engineer Skills required: Docker, K8s, Terraform, AWS Ready to apply? [Y/n] Y Boa sorte na sua jornada! 🚀🎯

3. Próximos Passos na Jornada 🚀

Este curso foi a sua porta de entrada. Para onde ir agora? 1. Kubernetes (K8s): O padrão de mercado para orquestração de containers. 2. Certificações Cloud: AWS Certified Solutions Architect, Azure Fundamentals, Google Associate Cloud Engineer. 3. Python/Go: Aprender a criar automações mais complexas usando linguagens de programação. 4. Engenharia de Plataforma (Platform Engineering): O próximo nível do DevOps.

4. Como montar um portfólio incrível? ✨

  1. GitHub Ativo: Documente seus projetos práticos (como o da Aula 15).
  2. Blog Posts: Escreva sobre o que você aprendeu (ex: "Como Dockerizei meu primeiro app").
  3. LinkedIn: Conecte-se com a comunidade e compartilhe suas conquistas.

5. Mensagem Final 🌟

Parabéns por chegar até aqui! Você agora tem a base sólida para construir, rodar e proteger sistemas modernos na nuvem. O DevOps é uma jornada de aprendizado constante.

"A automação sem propósito é apenas complexidade. O verdadeiro valor do DevOps está nas pessoas e na colaboração."

Obrigado por fazer parte desta turma! 🎓🚀 Desejamos muito sucesso na sua carreira como profissional Cloud & DevOps!

Aula 17 - Infrastructure as Code (IaC) com Terraform e Ansible 🏗️

Objetivo Pedagógico

Objetivo: Projetar infraestruturas imutáveis e auditáveis combinando provisionamento declarativo com Terraform e gerenciamento idempotente de configurações com Ansible.

📑 1. Fundamentos Teóricos & Análise Técnica

O provisionamento manual de servidores através de consoles web é lento, inconsistente e propício ao fenômeno da Distorção de Configuração (Configuration Drift).

A Infraestrutura como Código (IaC) introduz princípios de engenharia de software na gestão de infraestruturas: 1. Provisionamento Declarativo vs. Imperativo: - No modelo imperativo, descrevem-se os passos sequenciais para atingir um estado (crie VM, instale pacote). Se executado duas vezes, causa erros ou duplicações. - No modelo declarativo (Terraform / OpenTofu), descreve-se o estado final desejado em arquivos de configuração HCL. O motor de planejamento calcula o grafo de dependências e aplica exclusivamente as mutações necessárias para alcançar o estado alvo. 2. O Estado do Terraform (State File): - O arquivo terraform.tfstate funciona como a fonte da verdade mapeando recursos declarados no código a identificadores de recursos reais na nuvem. - Deve ser obrigatoriamente persistido em backend remoto seguro (ex: S3 com DynamoDB para state locking ou Terraform Cloud), evitando corridas de concorrência entre engenheiros da equipe. 3. Idempotência com Ansible: - Enquanto o Terraform provisiona recursos fundamentais (redes VPC, subnets, clusters gerenciados e instâncias), o Ansible especializa-se na configuração de sistemas operacionais e orquestração de serviços. - Uma playbook idempotente pode ser executada centenas de vezes consecutivas resultando sempre no mesmo estado do sistema, sem efeitos colaterais indesejados.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Dev["Engenheiro DevOps"] --> HCL["Código Declarativo HCL (main.tf)"]
    HCL --> Plan["Terraform Plan (Calcula Grafo de Recursos)"]
    Plan --> State["Remote State Lock (S3 + DynamoDB)"]
    State --> Cloud["Provedor Cloud (AWS / GCP / Azure)"]
    Cloud --> VPC["Criação de VPC e Sub-redes"]
    Cloud --> Cluster["Provisionamento de Cluster K8s"]
    Cluster --> Ansible["Ansible Playbook (Configuração Idempotente)"]
    Ansible --> Nodes["Sistemas Operacionais Configurados e Protegidos"]
    style Dev fill:#e1f5fe,stroke:#01579b
    style HCL fill:#fff3e0,stroke:#e65100
    style Cloud fill:#f3e5f5,stroke:#7b1fa2
    style Cluster fill:#e8f5e9,stroke:#2e7d32
    style Nodes fill:#e0f2f1,stroke:#00695c

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Imutabilidade de Infraestrutura: Servidores com problemas não recebem patches manuais em produção; são destruídos e recriados a partir do código. - State Locking Distribuído: Mecanismo de trava que impede que dois deploys simultâneos corrompam a base de dados do estado da infraestrutura. - Modularização e Reusabilidade: Construção de módulos parametrizados para replicação consistente de ambientes (Dev, Staging, Prod). - Validação Estática com TFLint e Checkov: Auditoria de conformidade de segurança e boas práticas de nuvem antes do provisionamento real.

🛠️ 2. Implementação Prática em Infraestrutura como Código, Terraform HCL e Ansible

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// main.tf (Provisionamento de VPC e Subnets Resilientes com Terraform)
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
  backend "s3" {
    bucket         = "empresa-terraform-state-prod"
    key            = "vpc/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

variable "environment" {
  type    = string
  default = "production"
}

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name        = "vpc-${var.environment}"
    Environment = var.environment
    ManagedBy   = "Terraform"
  }
}

resource "aws_subnet" "public_1a" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "us-east-1a"
  map_public_ip_on_launch = true

  tags = {
    Name = "subnet-public-1a-${var.environment}"
  }
}

💡 Análise Passo a Passo do Código

  1. Backend Remoto com DynamoDB Lock: Protege o estado contra corrupção simultânea e garante criptografia em repouso.
  2. Parametrização via Variáveis: Permite reutilizar o código de infraestrutura para múltiplos ambientes com consistência.
  3. Tags Padronizadas de Governança: Rastreia centros de custo e automações de ciclo de vida no provedor de nuvem.

🎯 3. Próximos Passos & Sequência Didática

Aula 18 - Orquestração de Contêineres com Kubernetes (K8s) ☸️

Objetivo Pedagógico

Objetivo: Dominar a arquitetura interna do Kubernetes (Control Plane, Kubelet, etcd) e implementar deployments resilientes, serviços, ingress controllers, probes de saúde e auto-scaling horizontal de pods (HPA).

📑 1. Fundamentos Teóricos & Análise Técnica

O Kubernetes tornou-se o padrão da indústria para execução de cargas de trabalho em contêineres em ambientes de missão crítica.

A arquitetura do cluster é fundamentada na reconciliação contínua de estados (Control Loop): 1. Componentes do Control Plane: - kube-apiserver: O único componente que se comunica diretamente com a base de dados do cluster; expõe a API REST declarativa. - etcd: Armazenamento distribuído consistente e altamente disponível baseado no algoritmo Raft, guardando todo o estado do cluster. - kube-scheduler: Avalia restrições de afinidade, tolerations e recursos livres de CPU/memória para alocar novos Pods aos Worker Nodes. - kube-controller-manager: Executa loops de controle que convergem o estado real do cluster para o estado desejado declarado nos manifestos YAML. 2. Ciclo de Vida de Pods e Resiliência: - Liveness Probes: Detectam se a aplicação congelou em deadlock; caso falhe, o Kubelet reinicia o contêiner. - Readiness Probes: Detectam se a aplicação está apta a processar tráfego (ex: inicialização de banco concluída); caso falhe, o Pod é temporariamente removido dos endpoints do Service sem ser reiniciado. - Horizontal Pod Autoscaler (HPA): Ajusta o número de réplicas de Pods automaticamente com base no consumo real de CPU, memória ou métricas customizadas de tráfego.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    User["Dev / CI/CD (kubectl apply)"] --> API["kube-apiserver"]
    API --> etcd["etcd (Estado Distribuído Raft)"]
    API --> Scheduler["kube-scheduler (Alocação de Nós)"]
    API --> Controller["kube-controller-manager (Reconciliação)"]
    Scheduler --> WorkerNode["Worker Node"]
    WorkerNode --> Kubelet["Kubelet (Agente do Nó)"]
    Kubelet --> ContainerRuntime["Container Runtime (containerd)"]
    ContainerRuntime --> Pod1["Pod Réplica 1"]
    ContainerRuntime --> Pod2["Pod Réplica 2"]
    HPA["HPA: Monitora Métricas de CPU"] --> API
    style User fill:#e1f5fe,stroke:#01579b
    style API fill:#fff3e0,stroke:#e65100
    style etcd fill:#ffebee,stroke:#c62828
    style WorkerNode fill:#f3e5f5,stroke:#7b1fa2
    style Pod1 fill:#e8f5e9,stroke:#2e7d32
    style Pod2 fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Declarative Reconciliation Loop: O Kubernetes atua ininterruptamente corrigindo desvios para que o estado real corresponda ao manifesto desejado. - Isolamento por Namespaces e Cgroups: Governança de limites rígidos de CPU e memória (Resource Quotas / Limits) evitando que um Pod monopolize o nó. - Zero-Downtime Rolling Updates: Substituição progressiva de instâncias antigas por novas garantindo disponibilidade total durante releases. - Cluster Networking e CNI (Container Network Interface): Atribuição de IP único e roteável para cada Pod dentro da malha de rede do cluster.

🛠️ 2. Implementação Prática em Sistemas Distribuídos e Orquestração com Kubernetes

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// deployment_resiliente.yml (Manifesto de Deployment K8s com Probes e Auto-Scaling)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-pedidos
  namespace: producao
  labels:
    app: api-pedidos
spec:
  replicas: 3
  revisionHistoryLimit: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Permite no máximo 1 Pod extra durante atualização
      maxUnavailable: 0  # Zero indisponibilidade tolerada no rollout
  selector:
    matchLabels:
      app: api-pedidos
  template:
    metadata:
      labels:
        app: api-pedidos
    spec:
      containers:
        - name: app
          image: ghcr.io/empresa/api-pedidos:v2.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

💡 Análise Passo a Passo do Código

  1. Estratégia RollingUpdate com maxUnavailable: 0: Garante que o tráfego de usuários nunca seja direcionado para servidores fora do ar.
  2. Declaração Estrita de Recursos: Permite que o scheduler dimensione nós adequadamente e evita OOM (Out-of-Memory) no cluster.
  3. Probes de Liveness e Readiness: Separa a saúde do processo em si da prontidão para receber pacotes de rede.

🎯 3. Próximos Passos & Sequência Didática

Aula 19 - Monitoramento e Observabilidade com Prometheus e Grafana 📊

Objetivo Pedagógico

Objetivo: Conceber arquiteturas modernas de observabilidade baseadas nos Três Pilares (Métricas, Logs e Tracing) utilizando Prometheus para coleta em modelo pull, Alertmanager para roteamento de incidentes e Grafana para visualização operacional.

📑 1. Fundamentos Teóricos & Análise Técnica

Em arquiteturas distribuídas e de microsserviços, o monitoramento tradicional baseado em ping ou verificação de portas tornou-se obsoleto. A disciplina de Engenharia de Confiabilidade de Sites (SRE) estabelece o conceito de Observabilidade: a capacidade de inferir os estados internos de um sistema complexo a partir de suas saídas externas.

A observabilidade moderna estrutura-se sobre Os Três Pilares: 1. Métricas (Prometheus): - Dados numéricos de séries temporais agregáveis (Counter, Gauge, Histogram, Summary). - O Prometheus opera no Modelo Pull: o servidor busca ativamente métricas nos endpoints HTTP /metrics dos alvos (Scraping), evitando sobrecarga nos agentes e facilitando descoberta dinâmica de serviços. - Os Quatro Sinais Dourados (Google SRE): Latência, Tráfego (taxa de requisições), Erros e Saturação (uso de CPU, disco, pools de memória). 2. Logs Estruturados (Loki / ELK): - Registros de eventos com timestamp em formato JSON enriquecidos com metadados de contexto (traceId, userId, tenantId). 3. Rastreamento Distribuído (Distributed Tracing - OpenTelemetry / Tempo): - Rastreia o caminho exato percorrido por uma única requisição através de dezenas de microsserviços distintos via injeção de cabeçalhos de contexto (traceparent), destacando o span exato que causou lentidão.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    App["Microsserviço de Aplicação (/metrics)"] --> Prometheus["Prometheus Server (Scrape Pull a cada 15s)"]
    Prometheus --> TSDB["Armazenamento Time-Series Local"]
    Prometheus --> PromQL["Motor de Consultas PromQL"]
    PromQL --> Alert["Alertmanager (Deduplicação & PagerDuty/Slack)"]
    PromQL --> Grafana["Grafana Dashboards (Visualização em Tempo Real)"]
    style App fill:#e1f5fe,stroke:#01579b
    style Prometheus fill:#fff3e0,stroke:#e65100
    style TSDB fill:#ffebee,stroke:#c62828
    style Grafana fill:#f3e5f5,stroke:#7b1fa2
    style Alert fill:#e8f5e9,stroke:#2e7d32

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Métricas em Formato Aberto (OpenMetrics): Padronização do formato texto de métricas adotado por Prometheus e toda a Cloud Native Computing Foundation (CNCF). - PromQL (Prometheus Query Language): Linguagem poderosa para cálculo de taxas instantâneas (rate()), percentis de latência (histogram_quantile()) e alertas preditivos. - SLO e Error Budgets: Definição matemática da margem de erro aceitável para orientar a cadência de novas releases sem degradar a experiência do cliente. - Alertas Baseados em Sintomas: Disparo de alertas voltados para a degradação de serviço percebida pelo usuário em vez de alertas ruidosos de causa raiz.

🛠️ 2. Implementação Prática em Observabilidade de Sistemas Distribuídos e SRE

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// prometheus_rules_slo.yml (Regras de Alerta Prometheus com SLO e Taxa de Erro)
groups:
  - name: api_slo_alerts
    rules:
      # Alerta quando a taxa de erro HTTP 5xx ultrapassar 1% em uma janela de 5 minutos
      - alert: HighHttpErrorRate
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(http_requests_total[5m])) * 100 > 1.0
        for: 2m
        labels:
          severity: critical
          team: platform
        annotations:
          summary: "Taxa de erro HTTP crítica em {{ $labels.instance }}"
          description: "A taxa de erro 5xx está em {{ $value | printf '%.2f' }}%, violando o SLO de confiabilidade."

      # Alerta de latência de percentil 99 acima do threshold aceitável
      - alert: HighLatencyP99
        expr: |
          histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 0.5
        for: 3m
        labels:
          severity: warning
        annotations:
          summary: "Latência p99 degradada (> 500ms)"
          description: "99% dos usuários estão esperando mais de 500ms nas respostas da API."

💡 Análise Passo a Passo do Código

  1. Cálculo Relativo de Taxa (rate): Normaliza picos de tráfego temporários avaliando a proporção de erros em relação ao volume total de requisições.
  2. Diretiva for: 2m: Previne falsos alertas e alertas intermitentes (Alert Flapping) exigindo persistência da condição de anomalia.
  3. Mapeamento de Metadados e Severidade: Direciona o incidente automaticamente para o canal correto de resposta de engenharia.

🎯 3. Próximos Passos & Sequência Didática

Aula 20 - Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀

Objetivo Pedagógico

Objetivo: Conceber uma plataforma autônoma de nuvem orientada a GitOps com ArgoCD e Kubernetes, automatizando todo o ciclo de vida: provisionamento de infraestrutura, sincronização de manifestos declarativos, observabilidade e autorrecuperação contra drift de configuração.

📑 1. Fundamentos Teóricos & Análise Técnica

O ápice da maturidade operacional moderna é a implementação do paradigma GitOps: onde o repositório Git é a única fonte da verdade (Single Source of Truth) para todo o estado da infraestrutura e das aplicações.

O Projeto Capstone de DevOps e Cloud consolida essa visão arquitetural: 1. O Modelo GitOps com ArgoCD: - Em vez de pipelines de CI executarem comandos kubectl apply com credenciais privilegiadas de fora do cluster (Push-Based Deployment), um agente interno do cluster (ArgoCD) monitora continuamente o repositório Git (Pull-Based Deployment). - O agente detecta qualquer alteração de commit e sincroniza o estado do cluster instantaneamente. 2. Autorrecuperação e Proteção contra Configuration Drift (Self-Healing): - Se um operador tentar alterar manualmente um recurso no cluster via terminal (kubectl edit), o ArgoCD detecta a discrepância em relação ao Git e reverte a alteração automaticamente para a versão declarada no repositório. 3. Plataforma Completa Integrada: - Integração harmônica entre Ingress Controller com certificados automáticos Let's Encrypt (Cert-Manager), Service Mesh, exportadores de telemetria e balanceadores de carga em nuvem pública.

📐 Arquitetura Conceitual & Diagrama de Fluxo

graph TD
    Git["Repositório Git (Manifestos Declarativos K8s)"] --> Argo["ArgoCD (Agente GitOps Interno do Cluster)"]
    Argo --> Check{"Existe Diferença (Drift)?"}
    Check -- Sim --> Sync["Reconciliação e Auto-Sync para Estado Desejado"]
    Check -- Não --> Synced["Status: Synced & Healthy"]
    Sync --> Cluster["Cluster Kubernetes em Produção"]
    Cluster --> Observability["Prometheus & Grafana (Telemetria)"]
    Operator["Operador Manual altera porta via terminal"] -.-> Cluster
    Cluster -.-> Argo
    Note over Argo: ArgoCD detecta alteração não autorizada e sobrescreve imediatamente! (Self-Healing)
    style Git fill:#e1f5fe,stroke:#01579b
    style Argo fill:#fff3e0,stroke:#e65100
    style Cluster fill:#e8f5e9,stroke:#2e7d32
    style Observability fill:#f3e5f5,stroke:#7b1fa2

🔍 Pilares e Diretrizes Técnicas

Nesta unidade, aprofundamos os seguintes conceitos fundamentais: - Princípio da Fonte Única da Verdade: Todo e qualquer aspecto da infraestrutura deve estar versionado em repositório Git sob controle estrito de Pull Requests. - Mecanismo Pull-Based de Segurança: O cluster não expõe portas ou credenciais de administração para ferramentas de CI externas; o agente puxa as alterações de dentro da rede protegida. - Self-Healing Ativo: Reversão imediata de modificações acidentais ou maliciosas aplicadas fora do fluxo oficial de versionamento. - Auditoria e Rastreabilidade Completa: Cada mudança em produção está associada a um hash de commit assinado e aprovado no histórico do Git.

🛠️ 2. Implementação Prática em Engenharia de Plataforma (Platform Engineering), GitOps e ArgoCD

Abaixo está a implementação técnica de referência, estruturada com padrões de engenharia de software e foco em robustez:

// argocd_application_capstone.yml (Manifesto Declarativo de Aplicação GitOps no ArgoCD)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: portal-producao-platform
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: 'https://github.com/empresa-organizacao/infra-manifestos-k8s.git'
    targetRevision: HEAD
    path: environments/production
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: producao
  syncPolicy:
    automated:
      prune: true     # Remove recursos no K8s que foram excluídos do Git
      selfHeal: true  # Reverte modificações manuais externas automaticamente
    syncOptions:
      - CreateNamespace=true
      - ApplyOutOfSyncOnly=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

💡 Análise Passo a Passo do Código

  1. Diretiva selfHeal: true: Garante que qualquer alteração manual no cluster seja desfeita imediatamente pelo operador GitOps.
  2. Diretiva prune: true: Mantém o cluster limpo removendo cargas de trabalho que deixaram de existir no repositório de código.
  3. Configuração de Retry Exponencial: Garante resiliência durante momentos de indisponibilidade transitória de dependências.

🎯 3. Próximos Passos & Sequência Didática

Exercícios

🏋️ Exercícios do Curso

Lista completa das 20 unidades de exercicios organizadas em 5 módulos didáticos.

🏋️ Exercício 01 – Introdução ao DevOps e Cultura ♾️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 01 sobre Introdução ao DevOps e Cultura ♾️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Introdução ao DevOps e Cultura ♾️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Introdução ao DevOps e Cultura ♾️** fundamenta-se em princípios consolidados de engenharia de software (1. O que é DevOps?, 2. O Muro da Confusão, 3. Os 3 Pilares do DevOps ️, 4. Benefícios Práticos). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Introdução ao DevOps e Cultura ♾️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Introdução ao DevOps e Cultura ♾️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Introdução ao DevOps e Cultura ♾️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 01 Responder Quiz 01

🏋️ Exercício 02 – Cultura Ágil e DevOps ‍♂️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 02 sobre Cultura Ágil e DevOps ‍♂️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Cultura Ágil e DevOps ‍♂️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Cultura Ágil e DevOps ‍♂️** fundamenta-se em princípios consolidados de engenharia de software (1. Por que Ágil? ️, 2. O Manifesto Ágil, 3. DevOps e Scrum, 4. Conceito de Entrega Contínua (Continuous Delivery) ️). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Cultura Ágil e DevOps ‍♂️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Cultura Ágil e DevOps ‍♂️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Cultura Ágil e DevOps ‍♂️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 02 Responder Quiz 02

🏋️ Exercício 03 – Controle de Versão com Git

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 03 sobre Controle de Versão com Git, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Controle de Versão com Git, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Controle de Versão com Git** fundamenta-se em princípios consolidados de engenharia de software (1. O que é Versionamento? ️, 2. A Estrutura do Git (Os 3 Estados) ️, 3. Comandos Básicos (Mão na Massa) ️, 4. Branches: Linhas do Tempo). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Controle de Versão com Git. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Controle de Versão com Git** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Controle de Versão com Git. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 03 Responder Quiz 03

🏋️ Exercício 04 – Repositórios Remotos e GitHub

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 04 sobre Repositórios Remotos e GitHub, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Repositórios Remotos e GitHub, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Repositórios Remotos e GitHub** fundamenta-se em princípios consolidados de engenharia de software (1. O que é o GitHub? ☁️, 2. Trabalhando com Remotos, 3. Fluxo de Trabalho: Pull Requests (PR), 4. Git Flow Simplificado). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Repositórios Remotos e GitHub. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Repositórios Remotos e GitHub** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Repositórios Remotos e GitHub. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 04 Responder Quiz 04

🏋️ Exercício 05 – Integração Contínua (CI) ⚙️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 05 sobre Integração Contínua (CI) ⚙️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Integração Contínua (CI) ⚙️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Integração Contínua (CI) ⚙️** fundamenta-se em princípios consolidados de engenharia de software (1. O que é Integração Contínua (CI)?, 2. O Pipeline de CI ️, 3. Benefícios do CI, 4. Ferramentas Populares de CI ️). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Integração Contínua (CI) ⚙️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Integração Contínua (CI) ⚙️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Integração Contínua (CI) ⚙️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 05 Responder Quiz 05

🏋️ Exercício 06 – Entrega Contínua (CD)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 06 sobre Entrega Contínua (CD), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Entrega Contínua (CD), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Entrega Contínua (CD)** fundamenta-se em princípios consolidados de engenharia de software (1. O que é Entrega Contínua (CD)?, 2. O Pipeline de CD ️, 3. Estratégias de Deploy ️, 4. O papel da Infraestrutura como Código (IaC)). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Entrega Contínua (CD). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Entrega Contínua (CD)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Entrega Contínua (CD). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 06 Responder Quiz 06

🏋️ Exercício 07 – Containers e Virtualização

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 07 sobre Containers e Virtualização, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Containers e Virtualização, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Containers e Virtualização** fundamenta-se em princípios consolidados de engenharia de software (1. O Problema: "Na minha máquina funciona!" ‍♂️, 2. Containers vs Máquinas Virtuais (VMs) ⚔️, 3. O que é um Container?, 4. Como funciona o Docker? ️). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Containers e Virtualização. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Containers e Virtualização** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Containers e Virtualização. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 07 Responder Quiz 07

🏋️ Exercício 08 – Docker na Prática

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 08 sobre Docker na Prática, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Docker na Prática, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Docker na Prática** fundamenta-se em princípios consolidados de engenharia de software (1. Instalando o Docker ️, 2. Comandos Básicos do Dia a Dia ⌨️, 3. Criando sua Própria Imagem (Dockerfile), 4. Portas e Mapeamento). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Docker na Prática. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Docker na Prática** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Docker na Prática. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 08 Responder Quiz 08

🏋️ Exercício 09 – Fundamentos de Cloud Computing ☁️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 09 sobre Fundamentos de Cloud Computing ☁️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Fundamentos de Cloud Computing ☁️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Fundamentos de Cloud Computing ☁️** fundamenta-se em princípios consolidados de engenharia de software (1. O que é "A Nuvem"?, 2. Benefícios da Nuvem, 3. Modelos de Serviço (O Triângulo da Cloud), 4. Modelos de Implantação). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Fundamentos de Cloud Computing ☁️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Fundamentos de Cloud Computing ☁️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Fundamentos de Cloud Computing ☁️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 09 Responder Quiz 09

🏋️ Exercício 10 – Principais Provedores de Cloud (AWS, Azure, GCP)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 10 sobre Principais Provedores de Cloud (AWS, Azure, GCP), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Principais Provedores de Cloud (AWS, Azure, GCP), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Principais Provedores de Cloud (AWS, Azure, GCP)** fundamenta-se em princípios consolidados de engenharia de software (1. O Mercado de Cloud, 2. AWS (Amazon Web Services), 3. Microsoft Azure, 4. Google Cloud Platform (GCP)). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Principais Provedores de Cloud (AWS, Azure, GCP). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Principais Provedores de Cloud (AWS, Azure, GCP)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Principais Provedores de Cloud (AWS, Azure, GCP). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 10 Responder Quiz 10

🏋️ Exercício 11 – Deploy em Cloud (Simulação e Prática)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 11 sobre Deploy em Cloud (Simulação e Prática), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Deploy em Cloud (Simulação e Prática), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Deploy em Cloud (Simulação e Prática)** fundamenta-se em princípios consolidados de engenharia de software (1. O que é Deploy?, 2. O Fluxo de Deploy com Docker ⛴️, 3. Formas de fazer Deploy na Nuvem ️, 4. Prática: Conceito de Serverless Containers ⚡). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Deploy em Cloud (Simulação e Prática). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Deploy em Cloud (Simulação e Prática)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Deploy em Cloud (Simulação e Prática). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 11 Responder Quiz 11

🏋️ Exercício 12 – Infraestrutura como Código (IaC)

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 12 sobre Infraestrutura como Código (IaC), cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Infraestrutura como Código (IaC), definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Infraestrutura como Código (IaC)** fundamenta-se em princípios consolidados de engenharia de software (1. O que é Infraestrutura como Código (IaC)? ️, 2. Por que usar IaC?, 3. Imperativo vs Declarativo ⚖️, 4. Terraform: O Gigante da IaC). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Infraestrutura como Código (IaC). Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Infraestrutura como Código (IaC)** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Infraestrutura como Código (IaC). Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 12 Responder Quiz 12

🏋️ Exercício 13 – Monitoramento e Observabilidade

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 13 sobre Monitoramento e Observabilidade, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Monitoramento e Observabilidade, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Monitoramento e Observabilidade** fundamenta-se em princípios consolidados de engenharia de software (1. Por que monitorar?, 2. Monitoramento vs Observabilidade, 3. Os 3 Pilares da Observabilidade ️, 4. O que é o Grafana? ️). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Monitoramento e Observabilidade. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Monitoramento e Observabilidade** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Monitoramento e Observabilidade. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 13 Responder Quiz 13

🏋️ Exercício 14 – Segurança em Cloud e DevSecOps ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 14 sobre Segurança em Cloud e DevSecOps ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Segurança em Cloud e DevSecOps ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Segurança em Cloud e DevSecOps ️** fundamenta-se em princípios consolidados de engenharia de software (1. O Modelo de Responsabilidade Compartilhada, 2. O que é DevSecOps? ️, 3. Práticas Essenciais de DevSecOps ️, 4. O Princípio do Menor Privilégio). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Segurança em Cloud e DevSecOps ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Segurança em Cloud e DevSecOps ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Segurança em Cloud e DevSecOps ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 14 Responder Quiz 14

🏋️ Exercício 15 – Projeto Prático Integrador ️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 15 sobre Projeto Prático Integrador ️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Projeto Prático Integrador ️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Projeto Prático Integrador ️** fundamenta-se em princípios consolidados de engenharia de software (1. O Desafio: A esteira de produção ️, 2. Passo 1: O Repositorio, 3. Passo 2: A Automação (CI), 4. Passo 3: Provisionamento (IaC)). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Projeto Prático Integrador ️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Projeto Prático Integrador ️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Projeto Prático Integrador ️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 15 Responder Quiz 15

🏋️ Exercício 16 – Mercado, Carreira e Próximos Passos ‍♂️

🎯 Objetivo

Fixar e aplicar os conceitos essenciais da Aula 16 sobre Mercado, Carreira e Próximos Passos ‍♂️, cobrindo aspectos conceituais, implementação técnica e boas práticas da indústria.

🥉 Nível Bronze (Fixação Conceitual)

Exercício 1: Explique os fundamentos de Mercado, Carreira e Próximos Passos ‍♂️, definindo sua finalidade principal na arquitetura de software e por que esse conceito é indispensável no desenvolvimento profissional.

Gabarito Explicado O conceito de **Mercado, Carreira e Próximos Passos ‍♂️** fundamenta-se em princípios consolidados de engenharia de software (1. O Mercado de Trabalho para DevOps, 2. O Perfil do Profissional T-Shaped, 3. Próximos Passos na Jornada, 4. Como montar um portfólio incrível? ✨). Sua finalidade central é fornecer previsibilidade, padronização e manutenibilidade ao ecossistema da aplicação, garantindo que requisitos funcionais e não funcionais sejam atendidos de forma consistente e auditável.

🥈 Nível Prata (Aplicação Prática)

Exercício 2: Descreva um cenário prático de aplicação ou implementação técnica envolvendo Mercado, Carreira e Próximos Passos ‍♂️. Quais comandos, padrões de projeto ou configurações essenciais devem ser adotados para garantir uma entrega robusta?

Gabarito Explicado Em um ambiente de produção, a aplicação prática de **Mercado, Carreira e Próximos Passos ‍♂️** envolve: 1. **Configuração Padronizada:** Adoção de convenções estabelecidas e versionamento consistente das dependências e artefatos. 2. **Isolamento de Responsabilidades:** Separação clara entre camadas de regra de negócio, apresentação e infraestrutura. 3. **Validação e Testabilidade:** Estruturação orientada a testes automatizados e validação defensiva de parâmetros de entrada.

🥇 Nível Ouro (Desafio Avançado e Cenário Real)

Exercício 3: Suponha que uma falha crítica ou gargalo ocorra em produção decorrente de má implementação em Mercado, Carreira e Próximos Passos ‍♂️. Detalhe uma estratégia sistemática de diagnóstico (troubleshooting), mitigação imediata e prevenção de recorrência.

Gabarito Explicado A resolução profissional para este cenário envolve: 1. **Diagnóstico Sistemático:** Coleta e análise de logs estruturados, métricas de observabilidade e identificação da causa-raiz (*root cause analysis*). 2. **Mitigação Imediata:** Aplicação de rollback seguro, feature flags ou circuit breaker para restabelecer a operação mínima viável. 3. **Prevenção e Resiliência:** Atualização das diretrizes de revisão de código, automação de testes de regressão no pipeline de CI/CD e documentação post-mortem.

Ver Aula 16 Responder Quiz 16

Projetos

🚀 Projetos do Curso

Lista completa das 20 unidades de projetos organizadas em 5 módulos didáticos.

Projeto 01 - Cinto de Utilidades Backend 🛠️

Objetivo: Validar a instalação das ferramentas e testar a comunicação básica com uma API pública.

O Desafio

  1. Instale o Postman ou Insomnia.
  2. Realize uma requisição do tipo GET para a API pública do GitHub: https://api.github.com/users/github.
  3. Analise a resposta (JSON). Identifique os campos login, id e public_repos.
  4. Instale o Docker Desktop e rode o comando docker run hello-world no terminal para garantir que a virtualização está ativa.
  5. Crie uma conta no GitHub (se não tiver) e instale o Git.

O que entregar?

  • Print (screenshot) da resposta JSON no Postman/Insomnia.
  • Print do terminal com a mensagem de sucesso do Docker "Hello from Docker!".

Projeto 02 - Modelagem de Fluxo de Gateway 🏗️

Objetivo: Entender o roteamento e a agregação de dados em um Gateway.

O Desafio

Imagine que você tem dois serviços: - Serviço A (User): Retorna { "id": 1, "nome": "Ricardo" } - Serviço B (Orders): Retorna [ { "id": 101, "valor": 50.0 }, { "id": 102, "valor": 30.0 } ]

  1. Desenhe um diagrama (pode ser no Mermaid ou papel) onde um API Gateway recebe uma chamada em /dashboard/1 e busca os dados nos dois serviços.
  2. Escreva o JSON final que o Gateway entregaria para o Frontend, unindo as informações do usuário e seus pedidos.
  3. Pesquisa: Liste 3 ferramentas famosas de API Gateway de mercado (ex: Kong, AWS API Gateway, etc).

O que entregar?

  • O diagrama de fluxo.
  • O JSON de resposta agregada.
  • A lista de ferramentas pesquisadas.

Projeto 03 - Contrato de API de Rede Social ⚡

Objetivo: Aplicar os conceitos de recursos, verbos e JSON na modelagem de uma rede social.

O Desafio

Você deve projetar a API para o recurso "Postagens" (Posts).

  1. Liste as 5 rotas principais (CRUD) para gerenciar postagens, indicando o Verbo, a URI e o Status Code de sucesso esperado.
  2. Crie um exemplo de JSON para uma postagem que contenha:
    • id
    • autor_id
    • conteúdo (texto)
    • data_publicacao
    • tags (lista de strings)
  3. Simulação de Erro: Qual seria a URI e o Verbo para dar um "Like" em uma postagem? Projete isso.

O que entregar?

  • Tabela com as 5 rotas (Verbo, URI, Status).
  • Bloco de código com o JSON de exemplo.
  • Proposta da rota de "Like".

Projeto 04 - Criando o Primeiro Mock 🧱

Objetivo: Dominar o fluxo de documentação de contrato e simulação de servidor.

O Desafio

Você deve criar um servidor de Mock para uma API de Lista de Tarefas (ToDo).

  1. Use o Postman (Mock Server) ou o Mockoon para criar 2 rotas:
    • GET /tarefas: Deve retornar uma lista com pelo menos 3 tarefas.
    • POST /tarefas: Deve aceitar uma nova tarefa e retornar 201 Created.
  2. Documente os campos de uma tarefa (ex: id, titulo, concluida).
  3. Teste as rotas e garanta que o servidor responda corretamente no formato JSON.

O que entregar?

  • Print (screenshot) do Swagger UI ou da tela do Mock Server rodando.
  • O JSON de exemplo retornado pelo GET /tarefas.
  • Print do teste da rota POST /tarefas com sucesso.

Projeto 05 - Meu Primeiro Controller ⚙️

Objetivo: Praticar a criação de rotas e a captura de diferentes tipos de parâmetros.

O Desafio

Crie a estrutura de um Controller para um sistema de Gestão de Tarefas (To-Do). Você deve definir (em pseudocódigo ou na linguagem que preferir):

  1. Uma rota para listar todas as tarefas, permitindo um filtro opcional por status (ex: concluída ou pendente).
  2. Uma rota para buscar uma única tarefa pelo seu id.
  3. Uma rota para criar uma tarefa, recebendo titulo e descricao.
  4. Sinalize qual seria o Status Code de sucesso para cada uma das rotas acima.

O que avaliar?

  • Uso correto de Path Params vs Query Params.
  • Escolha dos verbos HTTP adequados.
  • Padronização das respostas de sucesso.

Projeto 06 - Implementando a Lógica de Negócio 🧠

Objetivo: Aplicar a separação de camadas criando um Service para validação de dados.

O Desafio

Você deve criar o UsuarioService para um sistema de cadastro.

  1. Função validarSenha(senha): Deve garantir que a senha tenha no mínimo 8 caracteres e contenha pelo menos um número.
  2. Função criarUsuario(dados):
    • Chama a validação de senha.
    • Verifica se o e-mail já está sendo usado (simule um erro se estiver).
    • Retorna o usuário criado (sem a senha!).
  3. Simule o Controller chamando esse Service e tratando o erro de "Senha Insegura" com um Status Code 400.

O que observar?

  • O Service não deve usar objetos globais como req ou res.
  • As mensagens de erro devem ser claras e informativas.
  • Uso de DTOs (retornar objeto filtrado).

Projeto 07 - Modelagem de Banco de Dados 🗄️

Objetivo: Praticar a criação de esquemas relacionais e comandos SQL básicos.

O Desafio

Modele o banco de dados para um sistema de Aluguel de Filmes:

  1. Tabelas: Crie as tabelas Clientes e Filmes.
  2. Campos:
    • Clientes deve ter id, nome e email.
    • Filmes deve ter id, titulo e genero.
  3. Relacionamento: Crie uma terceira tabela Alugueis que ligue um cliente a um filme (incluindo a data_aluguel).
  4. SQL: Escreva uma query que liste o nome do cliente e o título do filme para todos os aluguéis feitos hoje.

O que avaliar?

  • Definição correta das Chaves Primárias.
  • Uso de Chaves Estrangeiras para conectar as tabelas.
  • Clareza na estrutura das colunas.

Projeto 08 - Schema de Validação Profissional ✅

Objetivo: Praticar a criação de regras de validação para garantir a integridade da API.

O Desafio

Crie o esquema de validação (em pseudocódigo ou usando uma biblioteca como Zod/Joi) para um Cadastro de Eventos:

  1. Campos Obrigatórios: titulo (mín. 10 char), data (deve ser futura), capacidade_maxima (número positivo).
  2. Campos Opcionais: descricao (máx. 500 char), link_inscricao (formato de URL).
  3. Sanitização: O título não deve conter espaços em branco sobrando no início ou no fim (trim).
  4. Simulação: Mostre qual seria a mensagem de erro retornada se o usuário enviasse uma capacidade negativa.

O que avaliar?

  • Clareza e rigor das regras de validação.
  • Escolha dos tipos de dados corretos.
  • Mensagens de erro amigáveis ao desenvolvedor (DX).

Projeto 09 - Sistema de Login (Simulado) 🔐

Objetivo: Implementar a lógica de geração de tokens JWT para autenticação.

O Desafio

Crie uma API de simulação de login:

  1. Entrada: Receba um JSON com email e senha.
  2. Validação: Verifique se a senha tem mais de 6 caracteres.
  3. JWT: Use uma biblioteca (ou pseudocódigo) para gerar um token que contenha o id do usuário e sua permissão (ex: 'aluno').
  4. Expiração: Configure o token para ser válido por apenas 24 horas.
  5. Resposta: Retorne para o cliente um objeto contendo o token e o nome do usuário.

O que avaliar?

  • Tratamento correto de erro caso a senha seja curta.
  • Estrutura limpa do Payload do JWT.
  • Escolha de uma chave secreta segura (simulada).

Projeto 10 - Gerenciador de Permissões 🛡️

Objetivo: Implementar a lógica de proteção de rotas baseada em perfis de usuário.

O Desafio

Crie a estrutura de autorização para um Sistema de RH:

  1. Roles: Defina três tipos: ADMIN, GESTOR e FUNCIONARIO.
  2. Regras:
    • Todos podem ver o próprio perfil (GET /me).
    • Apenas GESTOR e ADMIN podem ver a lista de salários (GET /salarios).
    • Apenas ADMIN pode deletar um registro (DELETE /colaboradores/:id).
  3. Middleware: Desenhe (em desenho técnico ou código) como seria o "fluxo da cancela" (Authentication Middleware -> Authorization Middleware).

O que avaliar?

  • Separação clara entre quem é você e o que você pode fazer.
  • Uso correto dos Status Codes em caso de bloqueio.
  • Lógica de hierarquia (Admin pode tudo).

Projeto 11 - Blindagem de API 🏗️

Objetivo: Implementar camadas avançadas de segurança e renovação de tokens.

O Desafio

Fortaleça sua API de login:

  1. Helmet: Instale e configure o Helmet para proteger os Headers.
  2. CORS: Restrinja o acesso à API para que apenas o domínio http://localhost:3000 possa consultá-la.
  3. Refresh Token: Implemente uma rota /refresh que receba um refresh token, valide-o no banco (ou lista em memória) e gere um novo accessToken.
  4. Rate Limit: Adicione uma trava para que ninguém possa tentar logar mais de 5 vezes em 1 minuto.

O que avaliar?

  • Configuração correta das origens no CORS.
  • Lógica de expiração do Refresh Token (ele deve durar muito mais que o Access Token).
  • Verificação se o Helmet está realmente escondendo o header X-Powered-By.

Projeto 12 - Primeiro App React ⚛️

Objetivo: Criar e organizar componentes básicos usando React e Vite.

O Desafio

Crie uma página de Perfil de Usuário:

  1. Componente FotoPerfil: Exibe uma imagem circular.
  2. Componente InfoUsuario: Recebe nome e bio via props e exibe na tela.
  3. Componente BotaoSeguir: Um botão simples que, por enquanto, apenas exibe um alerta ao ser clicado.
  4. Layout: Organize esses componentes dentro do App.jsx usando CSS simples para centralizar o conteúdo.

O que avaliar?

  • Separação correta dos componentes em arquivos diferentes (ou funções separadas).
  • Uso correto de Props para personalizar o nome do usuário.
  • Sintaxe JSX correta (tags fechadas, className, etc).

Projeto 13 - Lista Dinâmica de Contatos 📱

Objetivo: Aplicar o uso de useState e gerenciamento de listas.

O Desafio

Crie um mini-gerenciador de contatos:

  1. Inputs: Dois campos de texto (Nome e Telefone).
  2. Botão Adicionar: Quando clicado, deve validar se os campos estão preenchidos e adicionar o contato em um Estado de Array.
  3. Lista: Exiba todos os contatos adicionados abaixo do formulário.
  4. Botão Limpar: Um botão que limpa toda a lista de contatos.

O que avaliar?

  • Uso correto do useState para os inputs e para a lista.
  • Uso do .map() para renderizar a lista de contatos.
  • Limpeza dos campos de input após a adição com sucesso.

Projeto 14 - Buscador de Repositórios 🔍

Objetivo: Consumir uma API real e gerenciar estados de carregamento.

O Desafio

Crie um app que busca repositórios do GitHub de um usuário:

  1. Input: Campo para digitar o nome do usuário do GitHub.
  2. Botão Buscar: Ao clicar, deve disparar a busca.
  3. Loading: Enquanto a API não responde, deve aparecer o texto "Buscando repositórios...".
  4. Lista: Exiba o nome de todos os repositórios públicos encontrados.
  5. Erro: Se o usuário não existir, exiba "Erro: Usuário não encontrado".

O que avaliar?

  • Uso do useEffect para carregar dados (pode ser ao carregar a página ou via clique).
  • Tratamento correto dos estados: null, loading, data e error.
  • Renderização limpa usando .map().

Projeto 15 - Sistema de Multi-Páginas 🚦

Objetivo: Implementar a navegação completa em uma SPA.

O Desafio

Transforme seu app de repositórios ou contatos em um site completo com 3 páginas:

  1. Home (/): Uma página de boas-vindas com links para as outras seções.
  2. Dashboard (/app): Onde fica a funcionalidade principal (ex: a busca de repositórios).
  3. Sobre (/sobre): Uma página contando quem criou o projeto.
  4. 404: Uma página personalizada para links quebrados.

Requisito Extra (Parâmetro)

Crie uma página de Perfil de Repositório (/repo/:id) que deve ser aberta ao clicar em um item da lista. Essa página só precisa exibir o ID que foi clicado por enquanto.

O que avaliar?

  • Configuração correta do BrowserRouter no main.jsx ou App.jsx.
  • Uso exclusivo de <Link> para navegação em menus.
  • Funcionamento correto dos parâmetros de URL com useParams.

Projeto 16 - App Final Full-Stack Integrador 🏆

Objetivo: O "TCC (Trabalho de Conclusão de Curso)" do desenvolvedor Full-Stack.

O Tema

Escolha um tema que resolva um problema real integrando o que você construiu no Backend (Módulos 1-3) com o que aprendeu no Frontend (Módulo 4).

Requisitos Mínimos

  1. Backend (Express): Uso obrigatório de rotas protegidas por JWT e validação de dados.
  2. Frontend (React): Componentização clara, uso de Hooks (useState, useEffect) e navegação com React Router.
  3. Integração: O Frontend deve consumir a sua própria API de forma assíncrona.
  4. UX/UI: Interface amigável, com tratamento de estados de carregamento e erro.
  5. Segurança: Configuração correta de CORS e Headers de segurança (Helmet).

Documentação ✨

Seu repositório no GitHub deve ter um README.md impecável, com imagens (prints) da aplicação, explicação das tecnologias usadas e instruções claras de como rodar o servidor e o cliente. Este projeto será o seu maior cartão de visitas!

Boa sorte e bom código! 🚀🚀🚀

Quizzes

🧠 Quizzes de Fixação

Lista completa das 20 unidades de quizzes organizadas em 5 módulos didáticos.

🧠 Quiz 01 – Introdução ao DevOps e Cultura ♾️

  1. Qual é o conceito fundamental e objetivo principal de Introdução ao DevOps e Cultura ♾️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Introdução ao DevOps e Cultura ♾️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Introdução ao DevOps e Cultura ♾️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Introdução ao DevOps e Cultura ♾️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Introdução ao DevOps e Cultura ♾️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Introdução ao DevOps e Cultura ♾️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Introdução ao DevOps e Cultura ♾️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Introdução ao DevOps e Cultura ♾️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Introdução ao DevOps e Cultura ♾️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Introdução ao DevOps e Cultura ♾️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 02 – Cultura Ágil e DevOps 🏃‍♂️

  1. Qual é o conceito fundamental e objetivo principal de Cultura Ágil e DevOps 🏃‍♂️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Cultura Ágil e DevOps 🏃‍♂️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Cultura Ágil e DevOps 🏃‍♂️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Cultura Ágil e DevOps 🏃‍♂️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Cultura Ágil e DevOps 🏃‍♂️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Cultura Ágil e DevOps 🏃‍♂️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Cultura Ágil e DevOps 🏃‍♂️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Cultura Ágil e DevOps 🏃‍♂️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Cultura Ágil e DevOps 🏃‍♂️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Cultura Ágil e DevOps 🏃‍♂️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 03 – Controle de Versão com Git 📜

  1. Qual é o conceito fundamental e objetivo principal de Controle de Versão com Git 📜?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Controle de Versão com Git 📜?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Controle de Versão com Git 📜, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Controle de Versão com Git 📜?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Controle de Versão com Git 📜 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Controle de Versão com Git 📜, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Controle de Versão com Git 📜?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Controle de Versão com Git 📜 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Controle de Versão com Git 📜 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Controle de Versão com Git 📜 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 04 – Repositórios Remotos e GitHub 👥

  1. Qual é o conceito fundamental e objetivo principal de Repositórios Remotos e GitHub 👥?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Repositórios Remotos e GitHub 👥?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Repositórios Remotos e GitHub 👥, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Repositórios Remotos e GitHub 👥?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Repositórios Remotos e GitHub 👥 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Repositórios Remotos e GitHub 👥, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Repositórios Remotos e GitHub 👥?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Repositórios Remotos e GitHub 👥 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Repositórios Remotos e GitHub 👥 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Repositórios Remotos e GitHub 👥 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 05 – Integração Contínua (CI) ⚙️

  1. Qual é o conceito fundamental e objetivo principal de Integração Contínua (CI) ⚙️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Integração Contínua (CI) ⚙️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Integração Contínua (CI) ⚙️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Integração Contínua (CI) ⚙️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Integração Contínua (CI) ⚙️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Integração Contínua (CI) ⚙️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Integração Contínua (CI) ⚙️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Integração Contínua (CI) ⚙️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Integração Contínua (CI) ⚙️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Integração Contínua (CI) ⚙️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 06 – Entrega Contínua (CD) 🚚

  1. Qual é o conceito fundamental e objetivo principal de Entrega Contínua (CD) 🚚?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Entrega Contínua (CD) 🚚?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Entrega Contínua (CD) 🚚, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Entrega Contínua (CD) 🚚?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Entrega Contínua (CD) 🚚 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Entrega Contínua (CD) 🚚, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Entrega Contínua (CD) 🚚?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Entrega Contínua (CD) 🚚 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Entrega Contínua (CD) 🚚 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Entrega Contínua (CD) 🚚 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 07 – Containers e Virtualização 🐳

  1. Qual é o conceito fundamental e objetivo principal de Containers e Virtualização 🐳?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Containers e Virtualização 🐳?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Containers e Virtualização 🐳, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Containers e Virtualização 🐳?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Containers e Virtualização 🐳 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Containers e Virtualização 🐳, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Containers e Virtualização 🐳?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Containers e Virtualização 🐳 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Containers e Virtualização 🐳 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Containers e Virtualização 🐳 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 08 – Docker na Prática 🚀

  1. Qual é o conceito fundamental e objetivo principal de Docker na Prática 🚀?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Docker na Prática 🚀?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Docker na Prática 🚀, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Docker na Prática 🚀?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Docker na Prática 🚀 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Docker na Prática 🚀, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Docker na Prática 🚀?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Docker na Prática 🚀 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Docker na Prática 🚀 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Docker na Prática 🚀 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 09 – Fundamentos de Cloud Computing ☁️

  1. Qual é o conceito fundamental e objetivo principal de Fundamentos de Cloud Computing ☁️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Fundamentos de Cloud Computing ☁️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Fundamentos de Cloud Computing ☁️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Fundamentos de Cloud Computing ☁️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Fundamentos de Cloud Computing ☁️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Fundamentos de Cloud Computing ☁️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Fundamentos de Cloud Computing ☁️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Fundamentos de Cloud Computing ☁️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Fundamentos de Cloud Computing ☁️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Fundamentos de Cloud Computing ☁️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 10 – Principais Provedores de Cloud (AWS, Azure, GCP) 🏢

  1. Qual é o conceito fundamental e objetivo principal de Principais Provedores de Cloud (AWS, Azure, GCP) 🏢?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Principais Provedores de Cloud (AWS, Azure, GCP) 🏢?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Principais Provedores de Cloud (AWS, Azure, GCP) 🏢, Azure, GCP) 🏢, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Principais Provedores de Cloud (AWS, Azure, GCP) 🏢?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Principais Provedores de Cloud (AWS, Azure, GCP) 🏢 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Principais Provedores de Cloud (AWS, Azure, GCP) 🏢, Azure, GCP) 🏢, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Principais Provedores de Cloud (AWS, Azure, GCP) 🏢?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Principais Provedores de Cloud (AWS, Azure, GCP) 🏢 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Principais Provedores de Cloud (AWS, Azure, GCP) 🏢 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Principais Provedores de Cloud (AWS, Azure, GCP) 🏢 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 11 – Deploy em Cloud (Simulação e Prática) 🚀

  1. Qual é o conceito fundamental e objetivo principal de Deploy em Cloud (Simulação e Prática) 🚀?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Deploy em Cloud (Simulação e Prática) 🚀?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Deploy em Cloud (Simulação e Prática) 🚀, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Deploy em Cloud (Simulação e Prática) 🚀?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Deploy em Cloud (Simulação e Prática) 🚀 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Deploy em Cloud (Simulação e Prática) 🚀, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Deploy em Cloud (Simulação e Prática) 🚀?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Deploy em Cloud (Simulação e Prática) 🚀 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Deploy em Cloud (Simulação e Prática) 🚀 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Deploy em Cloud (Simulação e Prática) 🚀 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 12 – Infraestrutura como Código (IaC) 💻

  1. Qual é o conceito fundamental e objetivo principal de Infraestrutura como Código (IaC) 💻?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Infraestrutura como Código (IaC) 💻?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Infraestrutura como Código (IaC) 💻, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Infraestrutura como Código (IaC) 💻?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Infraestrutura como Código (IaC) 💻 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Infraestrutura como Código (IaC) 💻, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Infraestrutura como Código (IaC) 💻?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Infraestrutura como Código (IaC) 💻 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Infraestrutura como Código (IaC) 💻 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Infraestrutura como Código (IaC) 💻 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 13 – Monitoramento e Observabilidade 📊

  1. Qual é o conceito fundamental e objetivo principal de Monitoramento e Observabilidade 📊?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Monitoramento e Observabilidade 📊?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Monitoramento e Observabilidade 📊, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Monitoramento e Observabilidade 📊?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Monitoramento e Observabilidade 📊 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Monitoramento e Observabilidade 📊, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Monitoramento e Observabilidade 📊?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Monitoramento e Observabilidade 📊 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Monitoramento e Observabilidade 📊 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Monitoramento e Observabilidade 📊 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 14 – Segurança em Cloud e DevSecOps 🛡️

  1. Qual é o conceito fundamental e objetivo principal de Segurança em Cloud e DevSecOps 🛡️?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Segurança em Cloud e DevSecOps 🛡️?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Segurança em Cloud e DevSecOps 🛡️, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Segurança em Cloud e DevSecOps 🛡️?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Segurança em Cloud e DevSecOps 🛡️ atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Segurança em Cloud e DevSecOps 🛡️, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Segurança em Cloud e DevSecOps 🛡️?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Segurança em Cloud e DevSecOps 🛡️ estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Segurança em Cloud e DevSecOps 🛡️ com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Segurança em Cloud e DevSecOps 🛡️ deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 15 – Projeto Prático Integrador 🏗️🚀

  1. Qual é o conceito fundamental e objetivo principal de Projeto Prático Integrador 🏗️🚀?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Projeto Prático Integrador 🏗️🚀?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Projeto Prático Integrador 🏗️🚀, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Projeto Prático Integrador 🏗️🚀?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Projeto Prático Integrador 🏗️🚀 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Projeto Prático Integrador 🏗️🚀, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Projeto Prático Integrador 🏗️🚀?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Projeto Prático Integrador 🏗️🚀 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Projeto Prático Integrador 🏗️🚀 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Projeto Prático Integrador 🏗️🚀 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 16 – Mercado, Carreira e Próximos Passos 🏃‍♂️💼

  1. Qual é o conceito fundamental e objetivo principal de Mercado, Carreira e Próximos Passos 🏃‍♂️💼?
  2. ( ) Reduzir a segurança do sistema sem análise prévia.
  3. (x) Garantir estruturação, eficiência e qualidade no desenvolvimento de software.
  4. ( ) Omitir o tratamento de erros em produção.

  5. ( ) Bloquear a execução de rotinas assíncronas.

  6. Qual benefício direto é obtido ao aplicar as melhores práticas de Mercado, Carreira e Próximos Passos 🏃‍♂️💼?

  7. (x) Maior manutenibilidade, legibilidade, desacoplamento e desempenho.
  8. ( ) Aumento indeterminado no tempo de latência das chamadas à API.
  9. ( ) Incompatibilidade com os compiladores e interpretadores modernos.

  10. ( ) Impedir a criação de testes automatizados.

  11. Em relação ao fluxo de execução e arquitetura em Mercado, Carreira e Próximos Passos 🏃‍♂️💼, Carreira e Próximos Passos 🏃‍♂️💼, assinale a alternativa correta:

  12. ( ) A lógica opera sem validação de entradas ou saídas.
  13. (x) O fluxo de dados segue validação rigorosa de entrada, processamento coeso e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de visualização.

  15. ( ) É proibido desacoplar dependências entre módulos.

  16. Qual é a conduta recomendada para manter a legibilidade do código em Mercado, Carreira e Próximos Passos 🏃‍♂️💼?

  17. (x) Seguir convenções de nomenclatura limpa, modularização e documentação clara.
  18. ( ) Utilizar variáveis globais sem restrição de acesso.
  19. ( ) Substituir nomes descritivos por identificadores de um único caractere.

  20. ( ) Desabilitar a checagem de tipos e validação estática.

  21. Como comprovar que a implementação de Mercado, Carreira e Próximos Passos 🏃‍♂️💼 atingiu os critérios de aceitação?

  22. ( ) Avaliando visualmente a quantidade total de linhas de código.
  23. (x) Executando suítes de testes unitários e de integração automatizados com cobertura adequada.
  24. ( ) Verificando a paleta de cores do editor de texto.

  25. ( ) Omitindo os relatórios de execução de testes no CI/CD.

  26. Ao tratar exceções e cenários de falha em Mercado, Carreira e Próximos Passos 🏃‍♂️💼, Carreira e Próximos Passos 🏃‍♂️💼, o desenvolvedor deve:

  27. (x) Capturar erros específicos, registrar logs rastreáveis e fornecer mensagens claras.
  28. ( ) Silenciar todas as exceções com blocos vazios.
  29. ( ) Encerrar abruptamente o processo do servidor sem notificação.

  30. ( ) Modificar variáveis de ambiente do sistema operacional.

  31. Qual o risco de ignorar as convenções e padrões recomendados em Mercado, Carreira e Próximos Passos 🏃‍♂️💼?

  32. (x) Acúmulo de débito técnico, vulnerabilidades de segurança e degradação de desempenho.
  33. ( ) Formatação automática de arquivos na IDE.
  34. ( ) Aumento espontâneo da velocidade do barramento de memória.

  35. ( ) Exclusão de arquivos de configuração do projeto.

  36. O princípio da responsabilidade única aplicado a Mercado, Carreira e Próximos Passos 🏃‍♂️💼 estabelece que:

  37. (x) Cada componente ou módulo deve ter apenas uma única razão para mudar.
  38. ( ) Todas as funções do projeto devem residir no mesmo arquivo-fonte.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os testes automatizados devem ser deletados antes da compilação de produção.

  41. Para integrar Mercado, Carreira e Próximos Passos 🏃‍♂️💼 com outros serviços e módulos do ecossistema, deve-se:

  42. (x) Utilizar interfaces bem definidas, abstrações e contratos claros (APIs/DTOs).
  43. ( ) Acessar diretamente estruturas privadas internas de outros módulos.
  44. ( ) Trafegar dados confidenciais em texto puro sem criptografia.

  45. ( ) Desativar os protocolos de comunicação da rede.

  46. A documentação técnica referente a Mercado, Carreira e Próximos Passos 🏃‍♂️💼 deve conter obrigatoriamente:

  47. (x) Requisitos funcionais, arquitetura, exemplos práticos de uso e instruções de teste.
  48. ( ) Apenas a assinatura digital do autor.
  49. ( ) Uma lista aleatória de comandos de sistema operacional.
  50. ( ) Rascunhos não revisados de reuniões antigas.

🧠 Quiz 17 – Infrastructure as Code (IaC) com Terraform e Ansible 🚀

  1. Qual o propósito principal de Infrastructure as Code (IaC) com Terraform e Ansible 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Infrastructure as Code (IaC) com Terraform e Ansible 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Infrastructure as Code (IaC) com Terraform e Ansible 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Infrastructure as Code (IaC) com Terraform e Ansible 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Infrastructure as Code (IaC) com Terraform e Ansible 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Infrastructure as Code (IaC) com Terraform e Ansible 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Infrastructure as Code (IaC) com Terraform e Ansible 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Infrastructure as Code (IaC) com Terraform e Ansible 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Infrastructure as Code (IaC) com Terraform e Ansible 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Infrastructure as Code (IaC) com Terraform e Ansible 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 18 – Orquestração de Contêineres com Kubernetes (K8s) 🚀

  1. Qual o propósito principal de Orquestração de Contêineres com Kubernetes (K8s) 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Orquestração de Contêineres com Kubernetes (K8s) 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Orquestração de Contêineres com Kubernetes (K8s) 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Orquestração de Contêineres com Kubernetes (K8s) 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Orquestração de Contêineres com Kubernetes (K8s) 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Orquestração de Contêineres com Kubernetes (K8s) 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Orquestração de Contêineres com Kubernetes (K8s) 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Orquestração de Contêineres com Kubernetes (K8s) 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Orquestração de Contêineres com Kubernetes (K8s) 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Orquestração de Contêineres com Kubernetes (K8s) 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 19 – Monitoramento e Observabilidade com Prometheus e Grafana 🚀

  1. Qual o propósito principal de Monitoramento e Observabilidade com Prometheus e Grafana 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Monitoramento e Observabilidade com Prometheus e Grafana 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Monitoramento e Observabilidade com Prometheus e Grafana 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Monitoramento e Observabilidade com Prometheus e Grafana 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Monitoramento e Observabilidade com Prometheus e Grafana 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Monitoramento e Observabilidade com Prometheus e Grafana 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Monitoramento e Observabilidade com Prometheus e Grafana 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Monitoramento e Observabilidade com Prometheus e Grafana 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Monitoramento e Observabilidade com Prometheus e Grafana 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Monitoramento e Observabilidade com Prometheus e Grafana 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

🧠 Quiz 20 – Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀

  1. Qual o propósito principal de Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀?
  2. ( ) Reduzir o espaço em disco sem validação.
  3. (x) Garantir estruturação, eficiência e robustez no processamento do sistema.
  4. ( ) Desativar os testes unitários automatizados.

  5. ( ) Substituir a documentação técnica por código legado.

  6. Qual benefício direto é obtido ao aplicar os padrões de Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀?

  7. (x) Maior manutenibilidade, legibilidade e desempenho.
  8. ( ) Aumento no tempo de resposta das chamadas à API.
  9. ( ) Incompatibilidade com compiladores modernos.

  10. ( ) Bloqueio da execução assíncrona.

  11. Em relação à arquitetura de Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀, assinale a alternativa correta:

  12. ( ) O módulo opera de forma totalmente isolada sem interface de dados.
  13. (x) O fluxo de dados segue validação de entrada, processamento e verificação de saída.
  14. ( ) As regras de negócio devem ser codificadas diretamente na camada de apresentação.

  15. ( ) Não há suporte para testes de integração.

  16. Qual a melhor prática ao implementar Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀?

  17. (x) Manter o código coeso, desacoplado e devidamente documentado.
  18. ( ) Utilizar variáveis globais sem controle de acesso.
  19. ( ) Omitir o tratamento de erros em produção.

  20. ( ) Desabilitar a checagem de tipos estáticos.

  21. Como verificar se a implementação de Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀 atingiu os objetivos de qualidade?

  22. ( ) Observando o tamanho do arquivo fonte em bytes.
  23. (x) Executando testes automatizados de cobertura e benchmarks de desempenho.
  24. ( ) Verificando a cor do tema do editor de código.

  25. ( ) Aguardando reclamações dos usuários finais em produção.

  26. Ao lidar com exceções em Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀, deve-se:

  27. (x) Capturar falhas específicas e fornecer mensagens informativas com rastreamento.
  28. ( ) Ignorar todos os erros com blocos vazios try-catch.
  29. ( ) Encerrar o sistema imediatamente sem log.

  30. ( ) Modificar o sistema operacional hospedeiro.

  31. Qual o impacto do mau uso dos conceitos de Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀?

  32. (x) Degradação de desempenho, vulnerabilidades de segurança e débito técnico.
  33. ( ) Redução automática no uso de memória RAM.
  34. ( ) Melhoria na taxa de transferência de dados da rede.

  35. ( ) Formatação automática de arquivos Markdown.

  36. O princípio da responsabilidade única aplicado a Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀 determina que:

  37. (x) Cada classe ou função deve ter apenas uma razão para mudar.
  38. ( ) Todas as funções do sistema devem residir no mesmo arquivo.
  39. ( ) O banco de dados deve ser executado na mesma thread do frontend.

  40. ( ) Os comentários de código devem ser removidos antes da compilação.

  41. Na integração de Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀 com outros componentes do ecossistema:

  42. (x) Deve-se utilizar interfaces bem definidas e contratos claros (APIs/DTOs).
  43. ( ) Deve-se utilizar acesso direto às estruturas privadas de outros módulos.
  44. ( ) É proibido transmitir dados pela rede.

  45. ( ) Todos os dados devem ser trafegados em formato de texto bruto desformatado.

  46. A documentação técnica referente a Projeto Capstone: Infraestrutura Cloud Kubernetes Autônoma 🚀 deve conter:

  47. (x) Requisitos, diagramas de fluxo, exemplos de uso e instruções de teste.
  48. ( ) Apenas o nome do autor do código.
  49. ( ) Lista de reprodução de músicas recomendadas.
  50. ( ) Histórico completo de conversas do suporte.

Slides

Configuração

Configuração de Ambiente 🛠️

Antes de colocar a mão no pipeline, é fundamental ter seu "cinto de utilidades" pronto. Siga os guias abaixo para configurar cada parte do ecossistema DevOps.

  • Git, GitHub e Containers --- Configure versionamento, GitHub CLI e Docker para automatizar builds e rodar serviços localmente. Configurar Git e Docker

  • Cloud e Infraestrutura como Código --- Crie sua conta em um provedor cloud e instale as ferramentas de linha de comando e Terraform. Configurar Cloud

Dica de Produtividade

Recomendamos o uso do Visual Studio Code como editor unificado. Com as extensões certas, ele cobre Git, Docker e Infraestrutura como Código sem precisar trocar de ferramenta.

Setup Git e Containers ⚙️

Para acompanhar os módulos de Fundamentos e CI/CD, você precisa configurar seu ambiente com as ferramentas certas.

1. Editor de Código (IDE)

Recomendamos o Visual Studio Code por sua leveza e ecossistema de extensões.

  • Baixar VS Code
  • Extensões Recomendadas: Docker, GitLens, YAML, Remote - Containers.

2. Git 🔧

Base de tudo em versionamento e automação.

  • Baixar Git
  • Verificação: No terminal, digite git --version.
  • Configure seu nome e e-mail: git config --global user.name "Seu Nome" e git config --global user.email "voce@exemplo.com".

3. GitHub CLI 🐙

Facilita automações e interação com Pull Requests direto do terminal.

4. Docker 🐳

Essencial para os módulos de containers e virtualização.

  • Baixar Docker Desktop
  • Verificação: No terminal, digite docker --version e depois docker run hello-world.

5. Console/Terminal 💻

  • Windows: Recomendamos o Windows Terminal com PowerShell 7 ou Git Bash.
  • Mac/Linux: O terminal nativo ou Zsh (Oh My Zsh).

Pronto!

Com essas ferramentas instaladas, você já pode versionar projetos, automatizar builds e rodar seus primeiros containers.

Setup Cloud e Infraestrutura como Código ☁️

O módulo de Cloud Computing exige acesso a um provedor cloud e às ferramentas de linha de comando que automatizam o deploy.

1. Conta em um Provedor Cloud

Escolha um (ou mais) para acompanhar os exemplos do curso — todos oferecem camada gratuita:

2. CLI do Provedor Escolhido 📡

  • AWS CLI: Instalar — verificação: aws --version.
  • Azure CLI: Instalar — verificação: az --version.
  • gcloud CLI (GCP): Instalar — verificação: gcloud --version.

3. Infraestrutura como Código (IaC) 🧱

  • Terraform: Baixar Terraform — verificação: terraform --version.
  • Extensão VS Code: HashiCorp Terraform (syntax highlighting e autocomplete).

4. Orquestração de Containers (Opcional) ⎈

Caso o curso avance para Kubernetes:

  • kubectl: Instalar — verificação: kubectl version --client.
  • Minikube (cluster local para testes): Instalar.

Dica de Segurança

Nunca commite chaves de acesso (access key/secret key) direto no código. Use variáveis de ambiente ou um gerenciador de segredos (AWS Secrets Manager, Azure Key Vault, etc.) — o módulo de DevSecOps volta a esse tema em detalhe.

Sobre

Sobre o Curso

🎓 APIs e Microsserviços Profissionais

Este curso foi projetado para capacitar desenvolvedores na criação de arquiteturas distribuídas modernas, focando na integração entre backends escaláveis e frontends dinâmicos do tipo SPA.

🎯 Objetivos do Curso

  • Arquitetura Distribuída --- Compreender a transição de monólitos para microsserviços e a importância da comunicação eficiente entre serviços.

  • Domínio de APIs REST --- Dominar a modelagem, implementação e documentação de APIs seguindo as melhores práticas do mercado.

  • Segurança Avançada --- Implementar sistemas de autenticação e autorização robustos utilizando JWT e controle de acesso baseado em perfis.

  • Frontend Moderno (SPA) --- Desenvolver interfaces ricas e reativas, conectando-as perfeitamente ao ecossistema de APIs backend.

📚 O Que Você Vai Aprender

Módulo 1 – Serviços e Microsserviços

  • Conceitos de Microsserviços vs Monólitos
  • Arquitetura e API Gateways
  • Modelagem de APIs RESTful
  • Documentação com Swagger e Mocks

Módulo 2 – Manipulação de Dados

  • Implementação de Endpoints (Backend)
  • Persistência com ORM e SQL
  • Testes Unitários com Mocks
  • Testes Integrados e Deploy

Módulo 3 – Autenticação e Segurança

  • Estratégias Web (Cookies vs Tokens)
  • Implementação de JWT
  • Criptografia e Proteção de Rotas
  • Autorização RBAC (Perfis)

Módulo 4 – Aplicações Web SPA

  • Conceitos de SPA e Renderização
  • Componentização e Templates
  • Gerenciamento de Estados e Eventos
  • Roteamento e Projeto Integrador

🛠️ Metodologia

Foco 100% prático e orientado a projetos. Cada módulo culmina em uma etapa funcional de um sistema completo, garantindo que ao final do curso você tenha um portfólio robusto de arquitetura fullstack.

Pronto para dominar o Backend? Começar Agora

Roadmap do Projeto: APIs e Microsserviços 🚀

Este documento rastreia a evolução do curso.

✅ Fase 1: Planejamento (Concluído)

  • Definição Syllabus (16 Aulas)
  • Estrutura Backend-first com integração SPA
  • Configuração MkDocs Material

✅ Fase 2: Conteúdo Base (Concluído)

  • Criação das 16 Aulas (Markdown)
  • Criação dos 16 Quizzes (HTML)
  • Criação dos 16 Conjuntos de Exercícios
  • Criação dos 16 Slides (RevealJS)

✅ Fase 3: Projetos e UX (Concluído)

  • Definição dos 16 Projetos práticos
  • Documentação Swagger/OpenAPI integrada
  • Diagramação Mermaid de arquitetura de serviços

🚀 Fase 4: Lançamento e Manutenção

  • Deploy GitHub Pages (GitHub Actions)
  • Atualização para novas versões de frameworks (Spring/Node/React)
  • Inclusão de exemplos de mensageria (RabbitMQ/Kafka)

Status Atual: Finalizado / Manutenção Última Atualização: 19/02/2026

Materiais Complementares 📚

Bem-vindo à seção de materiais complementares do curso de DevOps e Cloud. Aqui você encontra recursos adicionais para apoiar seus estudos e aprofundar seu conhecimento técnico.

  • Slides

    • Acompanhe o conteúdo teórico com slides dinâmicos.

  • Exercícios

    • Pratique a implementação de microsserviços e rotas REST.

  • Quizzes

    • Valide seu aprendizado com testes rápidos por módulo.

  • Projetos

    • Construa um ecossistema completo para seu portfólio.

  • Ambiente

    • Guias de instalação (Docker, IDEs, Postman).

🏷️ Índice de Tags Didáticas

Navegue pelas aulas, exercícios e projetos do curso organizados por temas, tecnologias e conceitos fundamentais:

tags.md:145-167/name

Versão para Impressão

Esta página foi gerada automaticamente para impressão.