CNCF Certified Cloud Native Platform Engineer
Última revisão: maio de 2026
Uma referência rápida dos padrões arquiteturais que o exame CNPE avalia. Leia de cima a baixo ou pule para uma seção.
Provisionar e gerenciar infraestrutura multi-cloud usando APIs declarativas nativas do Kubernetes.
Use Crossplane. Instale CRDs de provedor de nuvem (ex: provider-aws). Defina abstrações de plataforma com Composition e CompositeResourceDefinition (XRD).
Por quê: Unifica o gerenciamento de aplicações e infraestrutura sob um único painel de controle e fluxo de trabalho GitOps, abstraindo especificidades do provedor dos desenvolvedores.
Gerenciar o ciclo de vida (criar, atualizar, excluir) de múltiplos clusters Kubernetes em diferentes provedores de forma declarativa.
Implemente Cluster API (CAPI) com provedores de infraestrutura relevantes (ex: CAPA para AWS, CAPZ para Azure). Defina clusters como recursos Kubernetes em um cluster de gerenciamento.
Por quê: Trata o ciclo de vida do cluster como código, habilitando GitOps para os próprios clusters. MachineHealthChecks do CAPI fornecem remediação automatizada de nós.
Fornecer isolamento robusto entre cargas de trabalho de inquilinos em uma plataforma Kubernetes compartilhada.
Combine pools de nós dedicados (computação), NetworkPolicies (rede), RBAC (API), ResourceQuotas (recurso) e Pod Security Standards (segurança). Considere clusters virtuais (vCluster) para isolamento do painel de controle.
Por quê: É necessária uma estratégia de defesa em profundidade. Nenhuma característica única oferece isolamento completo. Cada camada aborda um aspecto diferente da tenancy.
Gerenciar configurações e cargas de trabalho para um grande número de clusters downstream a partir de um ponto central.
Designe um cluster "hub" para hospedar ferramentas de painel de controle da plataforma (ArgoCD, Flux, Crossplane, engines de política). Clusters "spoke" executam cargas de trabalho e são gerenciados a partir do hub.
Por quê: Centraliza o gerenciamento, a aplicação de políticas e a observabilidade, simplificando as operações multi-cluster e garantindo consistência.
Fornecer às equipes de desenvolvimento ambientes isolados, semelhantes a cluster-admin, sem a sobrecarga de clusters físicos.
Use vCluster. Cada vCluster executa um painel de controle K8s separado como pods dentro de um namespace do cluster host, compartilhando os nós de worker do host.
Por quê: Oferece isolamento robusto em nível de API a um custo menor do que clusters completos. O sincronizador do vCluster materializa os recursos necessários no cluster host.
Garantir recuperação de desastres para cargas de trabalho stateful com baixo RPO/RTO.
Use um driver CSI que suporte replicação de dados síncrona ou assíncrona entre regiões/clusters (ex: Rook-Ceph, Portworx).
Por quê: A replicação é crítica para a disponibilidade de dados em caso de falha regional. Snapshots locais ou tiers de alta performance não abordam DR entre sites.
Melhorar a disponibilidade da aplicação distribuindo réplicas por domínios de falha.
Use Pod Topology Spread Constraints nas especificações da carga de trabalho. Defina `topologyKey` (ex: `topology.kubernetes.io/zone`) e `whenUnsatisfiable: ScheduleAnyway` ou `DoNotSchedule`.
Por quê: Impede que todas as réplicas de um serviço sejam agendadas em uma única zona ou em um único nó, mitigando o impacto de falhas localizadas de infraestrutura.
Gerenciar políticas e RBAC para equipes com estruturas organizacionais hierárquicas.
Implemente o Hierarchical Namespace Controller (HNC). Crie relações de namespace pai-filho para propagar RBAC, NetworkPolicies e ResourceQuotas.
Por quê: O HNC simplifica o gerenciamento permitindo que administradores de plataforma definam políticas em nível de equipe/organização (namespace pai) que são automaticamente herdadas por todos os sub-namespaces.
Implementar estratégias de implantação avançadas e automatizadas como canary ou blue-green com análise baseada em métricas e rollback.
Use Argo Rollouts. Defina um recurso Rollout com uma estratégia (ex: canary) que inclua configuração de roteamento de tráfego (para uma service mesh) e um AnalysisTemplate referenciando um provedor de métricas como Prometheus.
Por quê: Desacopla a implantação da lógica da aplicação. Automatiza o desvio e a análise de tráfego, promovendo lançamentos com segurança e realizando rollback automático em caso de falha, reduzindo o risco de implantação.
Gerenciar segredos em um fluxo de trabalho GitOps sem armazenar credenciais em texto claro no Git.
Use Sealed Secrets (criptografa segredos para um cluster específico) ou External Secrets Operator (sincroniza de Vault, gerentes de segredos AWS/GCP/Azure). Comite apenas o segredo criptografado ou o recurso de referência para o Git.
Por quê: Mantém dados sensíveis fora do Git, ao mesmo tempo que permite que os segredos sejam gerenciados declarativamente como parte do fluxo de trabalho GitOps, mantendo uma única fonte de verdade.
Automatizar a criação e o gerenciamento de Aplicações ArgoCD para múltiplos clusters, ambientes ou microsserviços.
Use um ApplicationSet. Defina um template para a Aplicação e use um gerador (ex: cluster, git, matrix) para criar Aplicações dinamicamente com base em listas de clusters, diretórios Git ou outras fontes.
Por quê: Elimina a criação manual de Aplicações, permitindo o gerenciamento escalável de centenas de aplicações ou clusters a partir de uma única definição.
Fornecer ambientes de preview efêmeros para desenvolvedores testarem mudanças em um pull request.
Use ArgoCD ApplicationSet com um gerador de Pull Request. Ele cria automaticamente uma Aplicação quando um PR é aberto e a exclui quando o PR é fechado/mesclado.
Por quê: Permite que os desenvolvedores validem as mudanças em um ambiente ativo antes de mesclar, melhorando a qualidade do código e reduzindo problemas de integração, sem gerenciamento manual do ambiente.
Gerenciar um conjunto grande e complexo de aplicações e componentes de plataforma com ArgoCD de forma estruturada.
Implemente o padrão App-of-Apps. Uma Aplicação raiz gerencia outras Aplicações filhas, que por sua vez podem gerenciar outras Aplicações, criando uma estrutura hierárquica.
Por quê: Fornece um único ponto de entrada para inicializar um cluster ou ambiente, ao mesmo tempo que permite o gerenciamento modular e baseado em equipes de conjuntos de aplicações individuais.
Garantir que os recursos sejam implantados na ordem correta (ex: CRDs antes de CRs, infraestrutura antes de aplicações).
No ArgoCD, use Sync Waves e verificações de saúde de recursos. No Flux, use `dependsOn` em recursos Kustomization ou HelmRelease.
Por quê: Sistemas declarativos aplicam recursos em paralelo por padrão. Mecanismos de ordenação explícitos são necessários para gerenciar dependências entre recursos.
Implementar um pipeline GitOps completo usando Flux.
Combine os controladores Flux: Source Controller (para fontes Git/Helm/OCI), Kustomize Controller (para aplicar manifests) e Helm Controller (para HelmReleases). Use Notification Controller para alertas.
Por quê: Flux é um conjunto composable de controladores especializados. Compreender o papel de cada um é fundamental para construir e solucionar problemas de entrega contínua baseada em Flux.
Garantir que o estado do cluster ativo corresponda continuamente ao estado desejado no Git, revertendo quaisquer alterações manuais.
Configure a Aplicação ArgoCD com `syncPolicy.automated.selfHeal: true`. O ArgoCD detectará o drift e sincronizará automaticamente para reverter alterações não autorizadas.
Por quê: A auto-recuperação é um princípio central do GitOps que impõe o Git como a única fonte de verdade e previne o drift de configuração, o que é crítico para conformidade e estabilidade.
Promover versões de aplicações entre ambientes (dev -> staging -> prod) com auditoria e portões de aprovação adequados.
Use diretórios ou branches separados por ambiente no Git. Promova as mudanças criando pull requests (ex: do branch/diretório de staging para prod). Aplique revisões de PR.
Por quê: Aproveita o Git para trilhas de auditoria e aprovações. O processo de PR se torna o portão de promoção formal, garantindo que as mudanças sejam revisadas antes de chegar à produção.
Implementar multi-tenancy em uma instância ArgoCD compartilhada, restringindo as equipes aos seus próprios recursos.
Crie Projetos ArgoCD para cada equipe. Configure os projetos para restringir repositórios Git de origem, clusters/namespaces de destino e tipos de recursos permitidos. Integre com SSO e mapeie grupos para funções de projeto.
Por quê: Projetos são o principal mecanismo para isolamento multi-tenant e RBAC no ArgoCD, permitindo a implantação segura de aplicações em autoatendimento.
Projetar uma API de autoatendimento para desenvolvedores provisionarem infraestrutura sem precisar de conhecimento específico da nuvem.
Defina uma API de alto nível com um CompositeResourceDefinition (XRD). Implemente a API com uma Composition que mapeia os campos de alto nível para recursos gerenciados subjacentes. Os desenvolvedores interagem com um simples Composite Resource Claim (XRC).
Por quê: Este modelo de três camadas (Claim -> Composition -> Managed Resource) separa a API voltada para o usuário da implementação, fornecendo uma abstração limpa e possibilitando a governança da plataforma.
Permitir que desenvolvedores inicializem novos projetos, microsserviços ou infraestrutura de forma declarativa e em conformidade com os padrões organizacionais.
Crie Backstage Software Templates. O template define parâmetros de entrada (uma UI de formulário) e uma série de ações do scaffolder (ex: buscar esqueleto, criar repositório Git, registrar no catálogo).
Por quê: Automatiza fluxos de trabalho de "golden path", reduzindo a carga cognitiva do desenvolvedor, garantindo consistência e acelerando a configuração do projeto de minutos para segundos.
Criar um local único e centralizado para descobrir todos os softwares, serviços, APIs e sua propriedade dentro de uma organização.
Implemente o Backstage Software Catalog. Ingeste descritores de entidade `catalog-info.yaml` de repositórios Git para construir um grafo pesquisável de componentes de software e suas relações.
Por quê: O catálogo é o núcleo de um IDP, fornecendo descoberta e uma base para outras funcionalidades como TechDocs, documentação de API e visibilidade do status de CI/CD.
Um operador Kubernetes precisa limpar recursos externos (ex: armazenamento em nuvem, registros DNS) quando um Custom Resource é excluído.
Use finalizadores. No controlador, adicione um finalizador ao CR na criação. No loop de reconciliação, se `deletionTimestamp` estiver definido, execute a lógica de limpeza e então remova o finalizador.
Por quê: Finalizadores impedem que o Kubernetes exclua um recurso até que o controlador tenha concluído com sucesso suas tarefas de limpeza, prevenindo recursos externos órfãos.
Fornecer às cargas de trabalho Kubernetes acesso seguro e de curta duração às APIs do provedor de nuvem sem gerenciar credenciais estáticas.
Use soluções de Workload Identity de provedores de nuvem (AWS IRSA, GCP Workload Identity, Azure Workload Identity). Isso vincula um Kubernetes ServiceAccount a uma função IAM da nuvem, permitindo que os pods obtenham credenciais temporárias.
Por quê: Elimina o risco de credenciais estáticas de longa duração. É o padrão mais seguro para conceder permissões de nuvem a pods.
Comunicar o estado e o progresso da reconciliação de um recurso customizado de volta para usuários e ferramentas de automação.
Habilite o subrecurso de status na definição do CRD. O controlador deve atualizar o status com condições (ex: `Type: Ready`, `Status: True`) e o estado observado.
Por quê: Separa o estado desejado (spec) do estado observado (status). Fornece um mecanismo padrão e observável para os clientes entenderem a saúde e a prontidão do recurso.
Evoluir APIs de plataforma (CRDs) sem quebrar clientes ou usuários existentes.
Siga as convenções de versionamento de API do Kubernetes (v1alpha1 -> v1beta1 -> v1). Ao introduzir mudanças disruptivas, crie uma nova versão e implemente um webhook de conversão para traduzir entre as versões armazenadas e servidas.
Por quê: Webhooks de conversão permitem que o servidor de API sirva múltiplas versões de um recurso simultaneamente, mantendo uma única versão de armazenamento, possibilitando uma evolução de API graciosa.
Criar alertas acionáveis baseados em metas de confiabilidade de serviço que equilibram sensibilidade com a prevenção de fadiga de alerta.
Defina SLOs e calcule orçamentos de erro. Implemente alertas multi-janela, multi-taxa de consumo que disparam quando a taxa de consumo do orçamento de erro ameaça o SLO.
Por quê: Alertas sobre a queima do orçamento de erro são mais significativos do que alertas de limite simples. Eles vinculam diretamente os alertas ao impacto voltado para o usuário e às violações de SLO.
Implementar um pipeline unificado e agnóstico de fornecedor para coletar, processar e exportar sinais de observabilidade (traces, métricas, logs).
Implante o OpenTelemetry Collector. Configure pipelines com receivers (ex: OTLP, Jaeger), processors (ex: batch, attributes) e exporters (ex: Prometheus, Loki, Tempo, backends de fornecedores).
Por quê: Desacopla a instrumentação do backend de observabilidade, permitindo que a plataforma troque ou adicione backends sem re-instrumentar aplicações. Fornece um ponto central para processamento e enriquecimento.
Configurar declarativamente o Prometheus para descobrir e coletar métricas de cargas de trabalho Kubernetes.
Use o Prometheus Operator. Crie Custom Resources `ServiceMonitor` ou `PodMonitor` que usam seletores de label para definir quais serviços ou pods o Prometheus deve coletar.
Por quê: Fornece uma maneira nativa do Kubernetes para gerenciar configurações de coleta, integrando-se perfeitamente com implantações de aplicações e fluxos de trabalho GitOps.
Durante a investigação de um incidente, navegar rapidamente de uma métrica anômala (ex: pico de latência) para as requisições específicas que a causaram.
Use exemplars do Prometheus. Instrumente aplicações para anexar IDs de trace a observações de métricas. Configure Prometheus e Grafana para exibir exemplars, fornecendo links diretos de métricas para traces em um backend de tracing como Tempo ou Jaeger.
Por quê: Reduz drasticamente o MTTR ao vincular diretamente o "o quê" (métrica) ao "porquê" (trace), eliminando esforços de correlação manual.
Estabelecer uma linha de base para monitorar a saúde de qualquer serviço crítico ou voltado para o usuário.
Monitore os quatro "Sinais Dourados": Latência (tempo de resposta), Tráfego (requisições por segundo), Erros (taxa de requisições falhas) e Saturação (utilização de recursos).
Por quê: Esses quatro sinais fornecem uma visão abrangente e de alto nível da saúde do serviço e da experiência do usuário, aplicável a quase qualquer tipo de serviço.
Fornecer às equipes visibilidade sobre o custo de suas cargas de trabalho Kubernetes para chargeback ou showback.
Implante uma ferramenta de código aberto como OpenCost ou Kubecost. Essas ferramentas alocam custos de nuvem para recursos Kubernetes (pods, namespaces, labels) com base em suas requisições e uso de recursos.
Por quê: Traduz faturas de infraestrutura em dados de custo significativos e centrados na aplicação, permitindo que as equipes entendam e otimizem seu consumo de recursos.
Reduzir o ruído de alertas durante interrupções em larga escala suprimindo alertas sintomáticos.
Configure `inhibit_rules` no Alertmanager. Por exemplo, inibir todos os alertas para um cluster específico se um alerta "ClusterUnreachable" já estiver ativo.
Por quê: Evita uma "tempestade de alertas" silenciando alertas de menor prioridade que são sintomas de um alerta de causa raiz de maior prioridade, permitindo que a equipe de plantão se concentre no problema real.
Testar proativamente a resiliência da plataforma e da aplicação injetando falhas de forma controlada.
Use uma ferramenta de engenharia de caos como Chaos Mesh ou Litmus. Defina experimentos com um raio de impacto limitado (ex: namespaces ou labels específicas) e condições de parada automatizadas baseadas em SLOs ou métricas críticas.
Por quê: Vai além da resposta reativa a incidentes para encontrar proativamente fraquezas no sistema antes que causem interrupções na produção.
Escolher um motor de política para aplicar guardrails em uma plataforma Kubernetes.
Escolha Kyverno para políticas nativas de Kubernetes baseadas em YAML ou OPA/Gatekeeper para uma linguagem de política mais poderosa e de propósito geral (Rego).
Por quê: Kyverno tem uma barreira de entrada menor para engenheiros de Kubernetes. OPA/Gatekeeper é mais flexível e pode ser usado fora do Kubernetes, mas tem uma curva de aprendizado mais acentuada.
Implementar políticas de plataforma que podem bloquear recursos não conformes, adicionar valores padrão ou criar automaticamente recursos relacionados.
Use um motor de política como Kyverno. Use regras `validate` para bloquear/auditar, regras `mutate` para adicionar padrões (ex: securityContext, labels) e regras `generate` para criar recursos (ex: NetworkPolicy padrão).
Por quê: Diferentes tipos de políticas servem a propósitos diferentes. Combiná-los permite uma estratégia de governança robusta e multifacetada que tanto impõe quanto ajuda os usuários a cumprir.
Aplicar o endurecimento de segurança básico para todos os pods em execução na plataforma.
Use Pod Security Standards (PSS) através do controlador de admissão Pod Security integrado. Rotule os namespaces com `pod-security.kubernetes.io/enforce=baseline` ou `restricted`.
Por quê: O PSS fornece um mecanismo padronizado e integrado para prevenir problemas de segurança comuns como escalonamento de privilégios e acesso ao namespace do host, formando uma camada de segurança fundamental.
Garantir que apenas imagens de contêiner confiáveis, construídas pelo pipeline oficial de CI/CD, possam ser implantadas no cluster.
Implemente a assinatura de imagens em CI usando Sigstore/Cosign. Use um motor de política (Kyverno, Gatekeeper) como um controlador de admissão para verificar as assinaturas de imagem contra uma chave confiável antes de permitir a criação de um pod.
Por quê: A verificação criptográfica oferece fortes garantias sobre a proveniência e integridade da imagem, prevenindo a implantação de imagens adulteradas ou não autorizadas.
Implementar um modelo de segurança de confiança zero onde a comunicação serviço-a-serviço é autenticada por identidade criptográfica de carga de trabalho, não por localização de rede.
Use SPIFFE/SPIRE para emitir identidades criptográficas de curta duração e rotacionáveis (SVIDs) para cargas de trabalho. Aplique mutual TLS (mTLS) usando uma service mesh, que valida SVIDs em cada requisição.
Por quê: Move a segurança dos controles de perímetro de rede para a identidade centrada na carga de trabalho, fornecendo autenticação forte mesmo para tráfego interno e limitando o raio de explosão de um nó ou pod comprometido.
Isolar cargas de trabalho no nível da rede, aplicando uma postura de "default-deny" e permitindo apenas os caminhos de comunicação necessários.
Implemente Kubernetes NetworkPolicies. Aplique uma política de "default-deny" a cada namespace, então adicione políticas de ingress/egress específicas que permitam o tráfego com base em labels de pod/namespace.
Por quê: Reduz a superfície de ataque de movimento lateral. O comprometimento de um pod não concede automaticamente acesso à rede a todos os outros serviços no cluster.
Criar um rastro de auditoria abrangente e à prova de adulteração de todas as ações realizadas no servidor de API Kubernetes para segurança e conformidade.
Habilite o log de auditoria do Kubernetes no servidor de API. Configure uma política de auditoria para registrar eventos relevantes (ex: todas as requisições de escrita). Envie os logs de auditoria para um backend de armazenamento seguro e imutável ou SIEM.
Por quê: Logs de auditoria são essenciais para investigação de incidentes, relatórios de conformidade (ex: PCI-DSS, SOC2) e detecção de atividade anômala de API.
