ESEN

← Letra chica por examen

Google Cloud · Professional

PCNE · Professional Cloud Network Engineer

Google Cloud Certified - Professional Cloud Network Engineer

Vigente↗ Guía oficial🃏 Practicar estos gotchas

DNS privado híbrido (on-premises ↔ nube)

Red● verificado hace 34 días◌ sin revisor externo

Hacia targets Type 1 y 2 las consultas salen desde 35.199.192.0/19; con Type 2, on-premises necesita ruta

Cloud DNS usa el rango 35.199.192.0/19 para todos los clientes, y es el origen de las consultas a targets Type 1 y Type 2 (IP interna de VPC y on-premises por VPN o Interconnect). Los targets Type 3 usan los rangos de Google Public DNS, y en Type 4 el rango depende de las IPs a las que resuelve el nombre. Para un target Type 2, on-premises necesita una ruta a 35.199.192.0/19 cuyo next hop esté en la misma VPC, por un túnel Cloud VPN o un attachment de Interconnect. Con BGP eso es un anuncio de ruta custom en la sesión BGP del Cloud Router.

Suma para:PCNEPCA
⚑ Reportar desactualizado

Ver en el patrón →

Seguridad● verificado hace 34 días◌ sin revisor externo

Con routing estándar, un destino que no es RFC 1918 se consulta por internet

El default de una forwarding zone decide la ruta según la IP del destino: RFC 1918 va por la VPC, cualquier otra va por internet. Si tu DNS on-premises usa IPs públicas reutilizadas internamente o rangos no RFC 1918, las consultas salen a internet y no llegan. forwarding_path = "private" fuerza siempre la VPC.

Suma para:PCNE
⚑ Reportar desactualizado

Ver en el patrón →

Red● verificado hace 34 días◌ sin revisor externo

La inbound policy toma una IP de cada subnet, no una por región ni dos por endpoint

No hay endpoints que dimensionar: la policy reserva una IP interna del rango primario de cada subnet de la VPC (menos las de propósito especial), así que una VPC con muchas subnets tiene muchas IPs de entrada. Lo que cuenta para la respuesta es la región del túnel o attachment por donde llegó la consulta, no la de la subnet de la IP. Poné la policy en la VPC que tiene la VPN o el Interconnect.

Suma para:PCNEACE
⚑ Reportar desactualizado

Ver en el patrón →

Red● verificado hace 34 días◌ sin revisor externo

VPC Network Peering no comparte las zonas privadas; hacen falta peering zones

VPC Network Peering no comparte automáticamente la información de DNS, así que una VPC peereada no resuelve por sí sola las zonas de la VPC hub. En hub-and-spoke, cada spoke necesita una DNS peering zone hacia el hub, y el DNS peering transitivo llega a un solo salto. Es la diferencia con Azure, donde un ruleset se linkea a VNets que ni siquiera están peereadas.

Suma para:PCNEPCA
⚑ Reportar desactualizado

Ver en el patrón →

Ingesta privada de objetos con expiración (TTL)

Red● verificado hace 34 días◌ sin revisor externo

Private Google Access da alcance a las APIs de Google; filtrar el origen del bucket es otro control

Las VMs que solo tienen IP interna pueden usar Private Google Access para llegar a las APIs y servicios de Google. Eso resuelve el alcance, no el filtrado de origen. Bucket IP filtering permite restringir el acceso al bucket según rangos de IP del cliente y redes VPC, y funciona junto con IAM.

Suma para:PCNEPCA
⚑ Reportar desactualizado

Ver en el patrón →

Web API privada Zero Trust con PostgreSQL sin contraseñas

Red● verificado hace 34 días◌ sin revisor externo

La IP privada de Cloud SQL viaja por un VPC peering que no es transitivo

Private services access se implementa con VPC Network Peering hacia la red de Google. Solo permite conexiones desde una VPC, y el peering no ofrece ruteo transitivo: otra VPC peereada con la tuya no llega a la base. Si tu topología es hub-and-spoke, evaluá Private Service Connect en lugar de PSA.

Suma para:PCNEPCA
⚑ Reportar desactualizado

Ver en el patrón →