Google PCNE: Automatización de red, gobernanza y operaciones de costos — Guía de estudio

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Forma parte de la Google Professional Cloud Network Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La automatización de redes, la gobernanza y las operaciones de costos en Google Cloud son disciplinas inseparables que determinan la fiabilidad, seguridad y economía con que operan tus redes a escala. Una práctica eficaz combina una jerarquía de recursos bien estructurada y un modelo de IAM con privilegios mínimos con la infraestructura como código y flujos de trabajo orientados a eventos, todo ello respaldado por presupuestos, cuotas y auditabilidad claros. El estado final es un aprovisionamiento predecible, cambios manuales mínimos, evidencia de cumplimiento defendible y una economía unitaria transparente para las redes.

Gobernanza y control de acceso

• Jerarquía de recursos

  • Organización → Carpetas → Proyectos es el plano de control para la herencia de permisos y las barreras de protección de políticas (policy guardrails). Ubica producción y no producción en carpetas separadas para aislar políticas y cuotas. Usa etiquetas en VPCs, subredes, routers, reglas de reenvío e instancias para la asignación de costos y la selección de recursos.
  • Shared VPC consolida el enrutamiento y la conectividad en un proyecto anfitrión (host) mientras delega el cómputo a proyectos de servicio. Comparte solo las subredes que cada proyecto de servicio necesita para seguir el principio de exponer las redes de forma explícita y para reducir la exposición no intencionada de rutas.

• IAM y privilegio mínimo

  • Separa la administración de redes de la administración de seguridad. El rol Compute Network Admin otorga control total sobre las construcciones de red y acceso de solo lectura a las reglas de firewall, mientras que Security Admin gestiona las reglas de firewall y los certificados SSL. Esta separación evita operadores con privilegios excesivos y se alinea con el control de cambios.
  • Otorga roles específicos:
    • Para modificar reglas de firewall, usa Security Admin en la Shared VPC.
    • Para gestionar VLAN attachments y otros recursos de red centrales, el rol Compute Network Admin es el adecuado.
    • Para la automatización sobre recursos específicos, otorga permisos a nivel de recurso en lugar de roles a nivel de proyecto cuando sea factible, o crea un rol personalizado limitado a los permisos requeridos.
  • Prefiere la suplantación de identidad de cuentas de servicio (service account impersonation) y los tokens de corta duración en lugar de claves persistentes. Deshabilita la creación de claves de cuentas de servicio a través de políticas de organización siempre que sea posible. Usa Workload Identity Federation para eliminar las claves por completo en automatizaciones on-prem o multicloud.
  • Sigue el principio de acceso con privilegios mínimos para las tareas del plano de datos. Por ejemplo, un trabajo que lee desde Cloud Storage solo necesita el rol de visualizador de objetos de almacenamiento (storage object viewer) en el bucket de destino, no un rol amplio de editor en el proyecto.

• Políticas de organización

  • Aplica la política de “sin IP externa” para las VM por defecto; usa Private Google Access y Cloud NAT para alcanzar las APIs de Google sin direcciones públicas.
  • Restringe el peering y el uso compartido externo a patrones aprobados (por ejemplo, limita las configuraciones de VPC peering para evitar la proliferación descontrolada).
  • Restringe la creación y el uso de claves de cuentas de servicio para limitar la proliferación de credenciales.
  • Modos de fallo y contrapartidas:
    • Roles heredados demasiado amplios a nivel de carpeta pueden otorgar silenciosamente acceso de escritura a muchos proyectos. Revisa las asignaciones de roles (role bindings) con un análisis de permisos efectivos.
    • Bloquear que las VM tengan IP externas sin planificar el uso de Private Google Access y NAT provoca interrupciones al llamar a los servicios de Google.
    • Convertir una VPC de modo automático a modo personalizado sin refactorizar las plantillas que asumían subredes automáticas rompe los despliegues; a partir de ese momento, referencia explícitamente las subredes personalizadas.

Automatización, IaC y operaciones orientadas a eventos

• Infraestructura como código con Terraform

  • Usa un diseño modular: un módulo por cada primitiva (VPC, subred, firewall, Cloud Router, Cloud NAT, interconnect attachment), y luego compón pilas (stacks) de entorno. Versiona los módulos y fija las versiones en las pilas que los consumen para controlar los despliegues.
  • Almacena el estado de forma remota con un sistema de bloqueo (por ejemplo, Cloud Storage con bloqueo estilo Dynamo a través de un patrón de back-end) para prevenir cambios concurrentes. Cifra y respalda el estado; trátalo como información sensible.
  • Gestión de la deriva (drift):
    • Fuerza los cambios a través de pull requests y terraform plan en CI para revelar la diferencia entre lo previsto y lo real. Ejecuta detecciones de deriva programadas (plan -detailed-exitcode) y emite alertas cuando aparezca una deriva.
    • Evita cambios ad-hoc con gcloud en producción; si son necesarios arreglos de emergencia, regístralos y reconcíliarlos en el código inmediatamente.
  • Idempotencia y barreras de protección: Siempre planifica, revisa y aplica. Usa aplicaciones selectivas (targeted applies) para minimizar el radio de impacto. Utiliza la validación de variables y la política como código (por ejemplo, Sentinel u OPA) para bloquear antipatrones como CIDR superpuestos o firewalls abiertos.

• gcloud, APIs y flujos de trabajo

  • Usa gcloud y REST para tareas operativas de baja latencia, pero envuélvelos en scripts repetibles. Maneja la consistencia eventual y los límites de tasa de la API con reintentos y retroceso exponencial (exponential backoff).
  • Operaciones orientadas a eventos:
    • Usa Cloud Scheduler + Pub/Sub + Cloud Run/Cloud Functions para automatizar tareas rutinarias como verificaciones de cuota, auditorías de utilización de NAT o muestreo de registros de firewall.
    • Transmite (stream) los registros de Admin Activity y Data Access a Pub/Sub para disparar flujos de trabajo de barrera de protección (por ejemplo, revertir automáticamente un cambio no autorizado en una regla de firewall).
  • Fragmentos de ejemplo
    • Otorgar un rol:
      • gcloud projects add-iam-policy-binding PROJECT –member=user:alice@example.com –role=roles/compute.networkAdmin
    • Crear una ruta para las APIs de Google para evitar una ruta por defecto hacia un NGFW:
      • gcloud compute routes create google-apis-egress –network=NET –destination-range=199.36.153.8/30 –next-hop-gateway=default-internet-gateway –priority=800

• Escollos operativos

  • Las condiciones de carrera (race conditions) cuando múltiples pipelines gestionan recursos compartidos (por ejemplo, firewalls en una VPC común) causan inestabilidad (flapping). Usa convenciones de propiedad y pipelines con alcance a nivel de carpeta.
  • La inestabilidad de la API bajo alto paralelismo dispara errores de cuota; limita (throttle) y agrupa las operaciones en lotes (batch) por región y tipo de recurso.

Gestión de costos, cuotas y capacidad

• Cuotas y límites de API

  • Realiza un seguimiento de las cuotas por proyecto y por región (direcciones, reglas de reenvío, reglas de firewall, adjuntos de interconexión, routers). Automatiza el monitoreo de cuotas y solicita aumentos antes de que se implementen nuevos entornos. Incorpora verificaciones de cuotas previas en la CI para fallar rápidamente.
  • Aprovisiona a escala con:
    • Sharding regional (crea recursos por región para evitar la contención de cuotas regionales).
    • Preasignación (reserva direcciones y configura routers antes de los eventos de máxima demanda).
    • Despliegues por etapas (crea, valida y luego adjunta los backends).

• Economía de la topología y el egreso

  • El tráfico entre regiones dentro de una misma VPC incurre en costos de egreso entre regiones. Ubica las cargas de trabajo que se comunican en la misma región o replica los datos regionalmente cuando la latencia y el costo son importantes.
  • Para usuarios cerca de us-east1 y europe-west1, una única VPC con subredes regionales permite la comunicación privada RFC1918, minimizando la sobrecarga de NAT y peering, al tiempo que permite políticas y enrutamiento simples.
  • Usa VPC Network Peering para una conectividad de baja sobrecarga entre proyectos o departamentos sin NAT y sin enrutamiento transitivo; mantén CIDRs que no se superpongan. Usa VPCs separadas para aislar departamentos que no deben comunicarse.
  • Cloud CDN reduce el egreso y mejora la latencia para el tráfico HTTP(S); un balanceador de carga HTTP(S) global es el plano de control para la CDN. Un balanceador de carga de red no mejorará la latencia global para las aplicaciones web porque carece de distribución en el borde y de caché.
  • Elige la interconexión sabiamente: Dedicated Interconnect con adjuntos de VLAN en un proyecto anfitrión centraliza la administración y reduce el costo por proyecto para una conectividad on-prem grande y compartida. Cloud VPN con Cloud Router es adecuado para una conectividad rápida y cifrada entre organizaciones, con la posibilidad de evolucionar a una interconexión más adelante.

• Asignación de costos, presupuestos y pronósticos

  • Etiqueta todos los recursos de red con labels para departamento, entorno y centro de costos. Exporta los datos de facturación a BigQuery y deriva los costos unitarios (por ejemplo, $/GB de egreso por servicio).
  • Crea presupuestos a nivel de proyecto, carpeta o label. Envía alertas a Pub/Sub y conéctalas a respondedores de ChatOps o Cloud Run. Automatiza acciones en caso de sobrecosto (por ejemplo, reducir el muestreo de logs o reducir la escala de entornos de prueba no críticos).
  • Optimiza el egreso:
    • Prefiere Private Google Access y Cloud NAT en lugar de IPs externas para controlar las rutas de egreso y centralizar la facturación.
    • Para topologías de túnel forzado, agrega rutas personalizadas para las APIs de Google hacia la puerta de enlace de internet predeterminada o configura Private Google Access para on-prem para evitar el hairpinning a través de firewalls de terceros.
    • Pronostica la capacidad analizando los VPC Flow Logs y los logs del balanceador de carga; correlaciónalo con la estacionalidad. Dimensiona correctamente las puertas de enlace NAT y la capacidad de interconexión antes de los picos de demanda.

Auditabilidad y excelencia operativa

• Registro y evidencia

  • Cloud Audit Logs:
    • Los registros de Admin Activity capturan los cambios en el plano de control de VPC, rutas, firewalls, routers y balanceadores de carga; están siempre activos. Reténgalos de forma centralizada y enrútelos a un proyecto de seguridad con CMEK si es necesario.
    • Los registros de Data Access para las API de red pueden tener un volumen alto; actívelos de forma selectiva y aplique muestreo o sinks (receptores).
  • VPC Flow Logs y Firewall Rules Logging proporcionan evidencia del plano de datos para la respuesta a incidentes y el cumplimiento normativo. Almacénelos durante el horizonte de retención requerido e indícelos con BigQuery para las investigaciones.
  • Registros de cambios: Exija que cada cambio de red se origine desde IaC con un artefacto de plan inmutable y una referencia de ticket. Para cambios manuales excepcionales, capture el comando gcloud, el operador, la marca de tiempo y la justificación en un registro central.

• Credenciales seguras y control de riesgos de la automatización

  • Elimine las claves de cuentas de servicio de larga duración. Use IAM Conditions para limitar el alcance de la automatización por recurso, tiempo o IP. Proteja los permisos de alto riesgo (por ejemplo, compute.firewalls.update, compute.routers.updateBgpPeer) con flujos de trabajo de aprobación.
  • Aplique el mínimo privilegio a CI/CD, use cuentas de servicio por entorno y rote los tokens con frecuencia. Use VPC Service Controls para la protección del perímetro de servicio donde existan riesgos de exfiltración de datos.

• Runbooks, ciclo de vida y mejora continua

  • Mantenga runbooks para operaciones rutinarias: incorporar un proyecto a una Shared VPC, crear un VPC peering, establecer una Cloud VPN con IKEv2, promover reglas de Cloud Armor en vista previa (preview) para que se apliquen.
  • Defina políticas de ciclo de vida:
    • Promoción de Sandbox → Staging → Producción con módulos de Terraform idénticos y variables específicas de la región.
    • Playbooks de desmantelamiento para eliminar de forma segura el peering, el NAT y las rutas.
  • Mejora continua:
    • Las revisiones posteriores a un incidente deben retroalimentar los módulos (por ejemplo, añadiendo una denegación de egreso por defecto con listas de permisos explícitas, o el registro de NAT por defecto).
    • Revise regularmente las políticas de organización, las etiquetas y los presupuestos para detectar desviaciones de la postura deseada.

Escenario de problema práctico

Contoso Retail opera en Norteamérica y Europa. Los usuarios y servicios se ejecutan principalmente en us-east1 y europe-west1. El equipo de seguridad requiere una ruta por defecto a un NGFW de terceros, que no haya IP externas en las VM y una conectividad on-prem centralizada. La empresa también necesita una asignación de costos clara por departamento y barreras de protección (guardrails) automatizadas.

1. Establecer la gobernanza y la topología

• Cree un proyecto anfitrión (host) de Shared VPC con una única VPC y dos subredes regionales en us-east1 y europe-west1. Justificación: Una VPC con subredes regionales permite la comunicación directa RFC1918 entre regiones con enrutamiento y políticas simples, minimizando la sobrecarga por proyecto.
• Comparta solo las subredes necesarias con tres proyectos de servicio (Marketing, Supply, Finance). Justificación: Compartir a nivel de subred limita la exposición de rutas y firewalls, al tiempo que se preserva el control centralizado.
• Cree una VPC separada para un sistema heredado (legacy) de Finanzas que debe estar aislado; establezca peering solo con Marketing y Supply donde sea necesario. Justificación: El VPC peering proporciona conectividad privada de baja latencia para los dos departamentos, al tiempo que preserva el aislamiento de Finanzas.

2. Configurar el acceso seguro a los servicios de Google sin IP públicas

• Habilite el Private Google Access en todas las subredes compartidas. Justificación: Las instancias sin IP externas pueden alcanzar las API de Google de forma privada.
• Dado que la ruta por defecto se dirige a un NGFW, añada una ruta estática personalizada para 199.36.153.8/30 hacia la puerta de enlace de internet por defecto. Justificación: Esto asegura que las llamadas a las API de Google no hagan hairpinning a través del firewall, reduciendo la latencia y evitando un único punto de congestión.

3. Centralizar la conectividad on-prem

• Despliegue Dedicated Interconnect y adjuntos de VLAN (VLAN attachments) en el proyecto anfitrión de Shared VPC, conectándolos a un Cloud Router por región. Justificación: Una interconexión centralizada reduce costos y la duplicación operativa; Cloud Router proporciona enrutamiento dinámico para el crecimiento.
• Otorgue el rol Compute Network Admin a los operadores de red y Security Admin al equipo de seguridad. Justificación: Aplica el principio de mínimo privilegio y la separación de funciones; los administradores de red no pueden cambiar los firewalls sin la aprobación de seguridad.

4. Automatizar el aprovisionamiento y las barreras de protección (guardrails)

• Implemente módulos de Terraform para VPC, subredes, routers, NAT, peering y políticas de firewall. Almacene el estado de forma remota con bloqueo; exija revisiones de pull-request con terraform plan en el CI. Justificación: Cambios repetibles y versionados con control de desviaciones minimizan las interrupciones.
• Añada una política de OPA para bloquear CIDR superpuestos y el ingreso abierto 0.0.0.0/0 a subredes internas. Justificación: Previene errores de configuración comunes en el momento de la revisión.
• Use Cloud Scheduler para publicar verificaciones diarias de cuota en Pub/Sub; un servicio de Cloud Run llama a la Service Usage API para verificar el margen disponible (headroom) para direcciones, reglas de reenvío y adjuntos de interconexión. Justificación: Evita fallos de despliegue debido al agotamiento de la cuota.

5. Optimizar costos y asignarlos con precisión

• Aplique las etiquetas env, dept y service a todos los recursos de red a través de Terraform. Exporte la facturación a BigQuery y defina presupuestos por departamento con alertas a Pub/Sub. Justificación: Una asignación de costos transparente y alertas tempranas sobre picos de consumo permiten una acción proactiva.
• Coloque un balanceador de carga HTTP(S) global al frente de las propiedades web públicas y habilite Cloud CDN. Justificación: Mejora la latencia para los usuarios globales y reduce el egreso al servir contenido cacheado en el borde de la red.

6. Fortalecer la auditabilidad y la respuesta a incidentes

• Enrute los registros de Admin Activity y Firewall Rules Logging a un proyecto de registro central con CMEK. Justificación: Los registros de cambios a prueba de manipulaciones y la evidencia del plano de datos satisfacen el cumplimiento normativo.
• Para clientes sospechosos de comportamiento abusivo, despliegue una regla de Cloud Armor en modo de vista previa (preview mode) en el balanceador de carga HTTP(S) y revise los registros antes de aplicarla. Justificación: Minimiza la interrupción para el usuario mientras se valida la mitigación.

7. Documentar e iterar

• Publique runbooks para incorporar un proyecto a una Shared VPC, crear un VPC peering entre Marketing y Supply, y construir una Cloud VPN basada en políticas para socios que no dispongan de BGP. Justificación: La ejecución estandarizada reduce el MTTR y la varianza.
• Después de cada ventana de cambio, capture métricas (tiempo de despliegue, errores, egreso $/GB, tasa de aciertos de caché) y retroalimente las mejoras en los módulos y políticas. Justificación: La mejora continua integra la fiabilidad y el control de costos en las operaciones diarias.

← Observabilidad de red · Todos los dominios

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →