CNCF Certified Cloud Native Platform Engineer
Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen CNPE. Lee de arriba a abajo o salta a una sección.
Aprovisionar y gestionar infraestructura multi-nube utilizando APIs declarativas nativas de Kubernetes.
Utilizar Crossplane. Instalar CRDs de proveedores de nube (p. ej., provider-aws). Definir abstracciones de plataforma con Composition y CompositeResourceDefinition (XRD).
Por qué: Unifica la gestión de aplicaciones e infraestructura bajo un único plano de control y flujo de trabajo GitOps, abstrayendo los detalles específicos del proveedor de los desarrolladores.
Gestionar el ciclo de vida (crear, actualizar, eliminar) de múltiples clústeres Kubernetes en diferentes proveedores de forma declarativa.
Implementar Cluster API (CAPI) con los proveedores de infraestructura relevantes (p. ej., CAPA para AWS, CAPZ para Azure). Definir clústeres como recursos de Kubernetes en un clúster de gestión.
Por qué: Trata el ciclo de vida del clúster como código, habilitando GitOps para los propios clústeres. CAPI MachineHealthChecks proporciona remediación automatizada de nodos.
Proporcionar un fuerte aislamiento entre las cargas de trabajo de los inquilinos en una plataforma Kubernetes compartida.
Combinar pools de nodos dedicados (cómputo), NetworkPolicies (red), RBAC (API), ResourceQuotas (recurso) y Pod Security Standards (seguridad). Considerar clústeres virtuales (vCluster) para el aislamiento del plano de control.
Por qué: Se requiere una estrategia de defensa en profundidad. Ninguna característica por sí sola proporciona un aislamiento completo. Cada capa aborda un aspecto diferente de la tenencia.
Gestionar configuraciones y cargas de trabajo para un gran número de clústeres secundarios desde un punto central.
Designar un clúster "hub" para alojar herramientas del plano de control de la plataforma (ArgoCD, Flux, Crossplane, motores de políticas). Los clústeres "spoke" ejecutan cargas de trabajo y se gestionan desde el hub.
Por qué: Centraliza la gestión, la aplicación de políticas y la observabilidad, simplificando las operaciones multi-clúster y asegurando la consistencia.
Proporcionar a los equipos de desarrollo entornos aislados, similares a cluster-admin, sin la sobrecarga de clústeres físicos.
Utilizar vCluster. Cada vCluster ejecuta un plano de control de K8s separado como pods dentro de un namespace del clúster anfitrión, compartiendo los nodos trabajadores del anfitrión.
Por qué: Ofrece un fuerte aislamiento a nivel de API a un costo menor que los clústeres completos. El sincronizador de vCluster materializa los recursos necesarios en el clúster anfitrión.
Asegurar la recuperación ante desastres para cargas de trabajo con estado con bajo RPO/RTO.
Utilizar un controlador CSI que admita la replicación de datos síncrona o asíncrona entre regiones/clústeres (p. ej., Rook-Ceph, Portworx).
Por qué: La replicación es crítica para la disponibilidad de datos en caso de fallo regional. Las instantáneas locales o los niveles de alto rendimiento no abordan la recuperación ante desastres entre sitios.
Mejorar la disponibilidad de las aplicaciones distribuyendo réplicas a través de dominios de fallo.
Utilizar Pod Topology Spread Constraints en las especificaciones de las cargas de trabajo. Definir `topologyKey` (p. ej., `topology.kubernetes.io/zone`) y `whenUnsatisfiable: ScheduleAnyway` o `DoNotSchedule`.
Por qué: Evita que todas las réplicas de un servicio se programen en una única zona o en un único nodo, mitigando el impacto de fallos de infraestructura localizados.
Gestionar políticas y RBAC para equipos con estructuras organizativas jerárquicas.
Implementar el Hierarchical Namespace Controller (HNC). Crear relaciones de namespace padre-hijo para propagar RBAC, NetworkPolicies y ResourceQuotas.
Por qué: HNC simplifica la gestión al permitir que los administradores de la plataforma establezcan políticas a nivel de equipo/organización (namespace padre) que son heredadas automáticamente por todos los sub-namespaces.
Implementar estrategias de despliegue avanzadas y automatizadas como canary o blue-green con análisis basado en métricas y reversión.
Utilizar Argo Rollouts. Definir un recurso Rollout con una estrategia (p. ej., canary) que incluya configuración de enrutamiento de tráfico (para una service mesh) y un AnalysisTemplate que haga referencia a un proveedor de métricas como Prometheus.
Por qué: Desacopla el despliegue de la lógica de la aplicación. Automatiza el cambio y análisis de tráfico, promoviendo de forma segura las versiones y revirtiendo automáticamente en caso de fallo, reduciendo el riesgo de despliegue.
Gestionar secretos en un flujo de trabajo GitOps sin almacenar credenciales en texto plano en Git.
Utilizar Sealed Secrets (encripta secretos para un clúster específico) o External Secrets Operator (sincroniza desde Vault, gestores de secretos de AWS/GCP/Azure). Confirmar solo el secreto encriptado o el recurso de referencia a Git.
Por qué: Mantiene los datos sensibles fuera de Git mientras permite que los secretos se gestionen de forma declarativa como parte del flujo de trabajo GitOps, manteniendo una única fuente de verdad.
Automatizar la creación y gestión de aplicaciones ArgoCD para múltiples clústeres, entornos o microservicios.
Utilizar un ApplicationSet. Definir una plantilla para la aplicación y usar un generador (p. ej., clúster, git, matriz) para crear dinámicamente aplicaciones basadas en listas de clústeres, directorios Git u otras fuentes.
Por qué: Elimina la creación manual de aplicaciones, permitiendo la gestión escalable de cientos de aplicaciones o clústeres desde una única definición.
Proporcionar entornos de vista previa efímeros para que los desarrolladores prueben cambios en una pull request.
Utilizar ArgoCD ApplicationSet con un generador de Pull Request. Crea automáticamente una aplicación cuando se abre una PR y la elimina cuando la PR se cierra/fusiona.
Por qué: Permite a los desarrolladores validar cambios en un entorno en vivo antes de fusionar, mejorando la calidad del código y reduciendo los problemas de integración, sin gestión manual del entorno.
Gestionar un conjunto grande y complejo de aplicaciones y componentes de plataforma con ArgoCD de forma estructurada.
Implementar el patrón App-of-Apps. Una aplicación raíz gestiona otras aplicaciones hijo, que a su vez pueden gestionar otras aplicaciones, creando una estructura jerárquica.
Por qué: Proporciona un único punto de entrada para iniciar un clúster o entorno, al tiempo que permite una gestión modular basada en equipos de conjuntos de aplicaciones individuales.
Asegurar que los recursos se desplieguen en el orden correcto (p. ej., CRDs antes de CRs, infraestructura antes de aplicaciones).
En ArgoCD, utilizar Sync Waves y comprobaciones de estado de recursos. En Flux, utilizar `dependsOn` en recursos Kustomization o HelmRelease.
Por qué: Los sistemas declarativos aplican los recursos en paralelo por defecto. Se requieren mecanismos de ordenación explícitos para gestionar las dependencias entre recursos.
Implementar un pipeline GitOps completo utilizando Flux.
Combinar controladores de Flux: Source Controller (para fuentes Git/Helm/OCI), Kustomize Controller (para aplicar manifiestos) y Helm Controller (para HelmReleases). Utilizar Notification Controller para alertas.
Por qué: Flux es un conjunto componible de controladores especializados. Comprender el papel de cada uno es clave para construir y solucionar problemas de entrega continua basada en Flux.
Asegurar que el estado del clúster en vivo coincida continuamente con el estado deseado en Git, revirtiendo cualquier cambio manual.
Configurar la aplicación ArgoCD con `syncPolicy.automated.selfHeal: true`. ArgoCD detectará la desviación y se sincronizará automáticamente para revertir cambios no autorizados.
Por qué: La auto-curación es un principio central de GitOps que impone Git como la única fuente de verdad y previene la desviación de configuración, lo cual es crítico para el cumplimiento y la estabilidad.
Promover versiones de aplicaciones a través de entornos (desarrollo -> staging -> producción) con puertas de auditoría y aprobación adecuadas.
Utilizar directorios o ramas separadas por entorno en Git. Promover cambios creando pull requests (p. ej., de la rama/directorio de staging a producción). Aplicar revisiones de PR.
Por qué: Aprovecha Git para las pistas de auditoría y aprobaciones. El proceso de PR se convierte en la puerta de promoción formal, asegurando que los cambios se revisen antes de llegar a producción.
Implementar multi-tenencia en una instancia compartida de ArgoCD, restringiendo a los equipos a sus propios recursos.
Crear proyectos ArgoCD para cada equipo. Configurar proyectos para restringir repositorios Git de origen, clústeres/namespaces de destino y tipos de recursos permitidos. Integrar con SSO y mapear grupos a roles de proyecto.
Por qué: Los proyectos son el mecanismo principal para el aislamiento multi-inquilino y RBAC en ArgoCD, habilitando el despliegue seguro de aplicaciones de autoservicio.
Diseñar una API de autoservicio para que los desarrolladores aprovisionen infraestructura sin necesidad de conocimientos específicos de la nube.
Definir una API de alto nivel con un CompositeResourceDefinition (XRD). Implementar la API con una Composition que mapee los campos de alto nivel a recursos gestionados subyacentes. Los desarrolladores interactúan con un simple Composite Resource Claim (XRC).
Por qué: Este modelo de tres capas (Claim -> Composition -> Managed Resource) separa la API de cara al usuario de la implementación, proporcionando una abstracción limpia y habilitando la gobernanza de la plataforma.
Permitir a los desarrolladores iniciar nuevos proyectos, microservicios o infraestructura de forma declarativa y en cumplimiento con los estándares organizacionales.
Crear Backstage Software Templates. La plantilla define parámetros de entrada (una UI de formulario) y una serie de acciones de scaffolder (p. ej., obtener esqueleto, crear repositorio Git, registrar en el catálogo).
Por qué: Automatiza los flujos de trabajo de "ruta dorada", reduciendo la carga cognitiva del desarrollador, asegurando la consistencia y acelerando la configuración del proyecto de minutos a segundos.
Crear un lugar único y centralizado para descubrir todo el software, servicios, APIs y su propiedad dentro de una organización.
Implementar el Backstage Software Catalog. Ingerir descriptores de entidad `catalog-info.yaml` de repositorios Git para construir un grafo buscable de componentes de software y sus relaciones.
Por qué: El catálogo es el núcleo de un IDP, proporcionando descubribilidad y una base para otras características como TechDocs, API docs y visibilidad del estado de CI/CD.
Un operador de Kubernetes necesita limpiar recursos externos (p. ej., almacenamiento en la nube, registros DNS) cuando se elimina un Custom Resource.
Utilizar finalizers. En el controlador, añadir un finalizer al CR en la creación. En el bucle de reconciliación, si `deletionTimestamp` está establecido, realizar la lógica de limpieza y luego eliminar el finalizer.
Por qué: Los finalizers evitan que Kubernetes elimine un recurso hasta que el controlador haya completado exitosamente sus tareas de limpieza, evitando recursos externos huérfanos.
Proporcionar a las cargas de trabajo de Kubernetes acceso seguro y de corta duración a las APIs del proveedor de la nube sin gestionar credenciales estáticas.
Utilizar soluciones de Workload Identity del proveedor de la nube (AWS IRSA, GCP Workload Identity, Azure Workload Identity). Esto vincula un ServiceAccount de Kubernetes a un rol de IAM de la nube, permitiendo a los pods obtener credenciales temporales.
Por qué: Elimina el riesgo de credenciales estáticas de larga duración. Es el patrón más seguro para otorgar permisos de la nube a los pods.
Comunicar el estado y progreso de la reconciliación de un recurso personalizado a los usuarios y herramientas de automatización.
Habilitar el subrecurso de estado en la definición del CRD. El controlador debe actualizar el estado con condiciones (p. ej., `Type: Ready`, `Status: True`) y el estado observado.
Por qué: Separa el estado deseado (spec) del estado observado (status). Proporciona un mecanismo estándar y observable para que los clientes comprendan la salud y la preparación del recurso.
Evolucionar las APIs de la plataforma (CRDs) sin romper los clientes o usuarios existentes.
Seguir las convenciones de versionado de API de Kubernetes (v1alpha1 -> v1beta1 -> v1). Al introducir cambios disruptivos, crear una nueva versión e implementar un webhook de conversión para traducir entre versiones almacenadas y servidas.
Por qué: Los webhooks de conversión permiten que el servidor API sirva múltiples versiones de un recurso simultáneamente mientras mantiene una única versión de almacenamiento, permitiendo una evolución elegante de la API.
Crear alertas accionables basadas en objetivos de fiabilidad del servicio que equilibren la sensibilidad con la evitación de la fatiga por alertas.
Definir SLOs y calcular presupuestos de error. Implementar alertas de múltiples ventanas y múltiples tasas de consumo que se activan cuando la tasa de consumo del presupuesto de error amenaza el SLO.
Por qué: Las alertas basadas en el consumo del presupuesto de error son más significativas que las alertas de umbral simples. Vincula directamente las alertas al impacto para el usuario y las violaciones de SLO.
Implementar un pipeline unificado e independiente del proveedor para recolectar, procesar y exportar señales de observabilidad (traces, metrics, logs).
Desplegar el OpenTelemetry Collector. Configurar pipelines con receptores (p. ej., OTLP, Jaeger), procesadores (p. ej., batch, attributes) y exportadores (p. ej., Prometheus, Loki, Tempo, backends de proveedor).
Por qué: Desacopla la instrumentación del backend de observabilidad, permitiendo a la plataforma cambiar o añadir backends sin re-instrumentar aplicaciones. Proporciona un punto central para el procesamiento y enriquecimiento.
Configurar Prometheus de forma declarativa para descubrir y recolectar métricas de las cargas de trabajo de Kubernetes.
Utilizar el Prometheus Operator. Crear Custom Resources `ServiceMonitor` o `PodMonitor` que utilizan selectores de etiquetas para definir qué servicios o pods debe recolectar Prometheus.
Por qué: Proporciona una forma nativa de Kubernetes para gestionar las configuraciones de recolección, integrándose sin problemas con los despliegues de aplicaciones y los flujos de trabajo de GitOps.
Durante una investigación de incidentes, navegar rápidamente de una métrica anómala (p. ej., pico de latencia) a las solicitudes específicas que la causaron.
Utilizar Prometheus exemplars. Instrumentar aplicaciones para adjuntar IDs de traza a las observaciones de métricas. Configurar Prometheus y Grafana para mostrar exemplars, proporcionando enlaces directos de métricas a trazas en un backend de tracing como Tempo o Jaeger.
Por qué: Reduce drásticamente el MTTR al vincular directamente el "qué" (métrica) con el "por qué" (traza), eliminando los esfuerzos de correlación manual.
Establecer una línea base para monitorear la salud de cualquier servicio crítico o de cara al usuario.
Monitorear las cuatro "Señales Doradas": Latency (tiempo de respuesta), Traffic (solicitudes por segundo), Errors (tasa de solicitudes fallidas) y Saturation (utilización de recursos).
Por qué: Estas cuatro señales proporcionan una visión integral y de alto nivel de la salud del servicio y la experiencia del usuario, aplicable a casi cualquier tipo de servicio.
Proporcionar a los equipos visibilidad del costo de sus cargas de trabajo de Kubernetes para chargeback o showback.
Desplegar una herramienta de código abierto como OpenCost o Kubecost. Estas herramientas asignan los costos de la nube a los recursos de Kubernetes (pods, namespaces, labels) basándose en sus solicitudes y uso de recursos.
Por qué: Traduce las facturas de infraestructura en datos de costos significativos y centrados en la aplicación, permitiendo a los equipos comprender y optimizar su consumo de recursos.
Reducir el ruido de las alertas durante interrupciones a gran escala suprimiendo las alertas sintomáticas.
Configurar `inhibit_rules` en Alertmanager. Por ejemplo, inhibir todas las alertas para un clúster específico si ya se está disparando una alerta de "ClusterUnreachable".
Por qué: Evita una "tormenta de alertas" silenciando las alertas de menor prioridad que son síntomas de una alerta de mayor prioridad y causa raíz, permitiendo que el personal de guardia se concentre en el problema real.
Probar proactivamente la resiliencia de la plataforma y las aplicaciones inyectando fallos de manera controlada.
Utilizar una herramienta de chaos engineering como Chaos Mesh o Litmus. Definir experimentos con un radio de impacto limitado (p. ej., namespaces o etiquetas específicas) y condiciones de parada automatizadas basadas en SLOs o métricas críticas.
Por qué: Va más allá de la respuesta reactiva a incidentes para encontrar proactivamente debilidades en el sistema antes de que causen interrupciones en producción.
Elegir un motor de políticas para aplicar barandillas en una plataforma Kubernetes.
Elegir Kyverno para políticas basadas en YAML nativas de Kubernetes o OPA/Gatekeeper para un lenguaje de políticas más potente y de propósito general (Rego).
Por qué: Kyverno tiene una barrera de entrada más baja para los ingenieros de Kubernetes. OPA/Gatekeeper es más flexible y puede usarse fuera de Kubernetes, pero tiene una curva de aprendizaje más pronunciada.
Implementar políticas de plataforma que puedan bloquear recursos no conformes, añadir valores predeterminados o crear automáticamente recursos relacionados.
Utilizar un motor de políticas como Kyverno. Utilizar reglas `validate` para bloquear/auditar, reglas `mutate` para añadir valores predeterminados (p. ej., securityContext, labels) y reglas `generate` para crear recursos (p. ej., NetworkPolicy predeterminada).
Por qué: Los diferentes tipos de políticas sirven para diferentes propósitos. Combinarlas permite una estrategia de gobernanza robusta y multifacética que tanto impone como ayuda a los usuarios a cumplir.
Aplicar endurecimiento de seguridad básico para todos los pods que se ejecutan en la plataforma.
Utilizar Pod Security Standards (PSS) a través del controlador de admisión de seguridad de pods incorporado. Etiquetar los namespaces con `pod-security.kubernetes.io/enforce=baseline` o `restricted`.
Por qué: PSS proporciona un mecanismo estandarizado e incorporado para prevenir problemas de seguridad comunes como la escalada de privilegios y el acceso al namespace del host, formando una capa de seguridad fundamental.
Asegurar que solo las imágenes de contenedor de confianza, construidas por el pipeline oficial de CI/CD, puedan ser desplegadas en el clúster.
Implementar la firma de imágenes en CI usando Sigstore/Cosign. Utilizar un motor de políticas (Kyverno, Gatekeeper) como controlador de admisión para verificar las firmas de las imágenes contra una clave de confianza antes de permitir la creación de un pod.
Por qué: La verificación criptográfica proporciona fuertes garantías sobre la procedencia e integridad de la imagen, evitando el despliegue de imágenes manipuladas o no autorizadas.
Implementar un modelo de seguridad de confianza cero donde la comunicación de servicio a servicio se autentica mediante identidad criptográfica de carga de trabajo, no por ubicación de red.
Utilizar SPIFFE/SPIRE para emitir identidades criptográficas de corta duración y rotables (SVIDs) a las cargas de trabajo. Aplicar TLS mutuo (mTLS) usando una service mesh, que valida los SVIDs en cada solicitud.
Por qué: Traslada la seguridad de los controles de perímetro de red a la identidad centrada en la carga de trabajo, proporcionando una autenticación fuerte incluso para el tráfico interno y limitando el radio de impacto de un nodo o pod comprometido.
Aislar cargas de trabajo a nivel de red, aplicando una postura de "default-deny" y permitiendo solo las rutas de comunicación requeridas.
Implementar Kubernetes NetworkPolicies. Aplicar una política de default-deny a cada namespace, luego añadir políticas específicas de ingreso/egreso que permitan el tráfico basado en etiquetas de pod/namespace.
Por qué: Reduce la superficie de ataque de movimiento lateral. El compromiso de un pod no otorga automáticamente acceso de red a todos los demás servicios en el clúster.
Crear una pista de auditoría completa e inalterable de todas las acciones realizadas en el servidor API de Kubernetes para seguridad y cumplimiento.
Habilitar el registro de auditoría de Kubernetes en el servidor API. Configurar una política de auditoría para registrar eventos relevantes (p. ej., todas las solicitudes de escritura). Enviar los registros de auditoría a un backend de almacenamiento seguro e inmutable o SIEM.
Por qué: Los registros de auditoría son esenciales para la investigación de incidentes, la elaboración de informes de cumplimiento (p. ej., PCI-DSS, SOC2) y la detección de actividad anómala de la API.
