3.1-GCP-ACE
|
|
Título del Test:
![]() 3.1-GCP-ACE Descripción: Associate Cloud Engineer GCP |



| Comentarios |
|---|
NO HAY REGISTROS |
|
Una empresa necesita conectar rápidamente su red local con una VPC mediante túneles cifrados sobre Internet y alta disponibilidad. ¿Qué debe usar?. HA VPN con Cloud Router. Direct Peering. Cloud CDN. VPC Network Peering. Una compañía necesita una conexión física dedicada de gran capacidad entre su centro de datos y Google y puede llegar a una ubicación de colocación admitida. ¿Qué opción debe elegir?. Classic VPN. Dedicated Cloud Interconnect. VPC Network Peering. Cloud NAT. La empresa necesita Interconnect, pero no puede conectarse físicamente a una instalación de Google. ¿Qué debe usar?. Direct Peering. Private Google Access. Partner Interconnect mediante un proveedor compatible. Una IP externa por VM. Quieres que las rutas aprendidas desde on-premises se actualicen automáticamente cuando cambie la red. ¿Qué componente debes configurar?. Cloud DNS. Una ruta estática por instancia. Cloud NAT. Cloud Router con BGP. Varios proyectos de la misma organización deben desplegar recursos en subredes administradas centralmente por el equipo de red. ¿Qué debes configurar?. Shared VPC con un proyecto host y proyectos de servicio. Un túnel VPN entre cada par de proyectos. Una red predeterminada por proyecto. Direct Peering. Dos VPC de organizaciones distintas deben comunicarse por IP privadas sin compartir la administración de una misma red. ¿Qué opción encaja mejor?. Shared VPC. VPC Network Peering configurado en ambos lados. Cloud CDN. Cloud Armor. Tras emparejar VPC-A con VPC-B y VPC-B con VPC-C, A no puede llegar a C. ¿Cuál es la causa?. Falta una dirección IP externa. Cloud Router solo funciona con IPv6. VPC Network Peering no es transitivo. Shared VPC bloquea todas las rutas. Una empresa solo quiere mejorar el acceso público a APIs de Google mediante intercambio de tráfico, sin conectividad privada a sus VPC. ¿Qué servicio corresponde?. HA VPN. Partner Interconnect. Shared VPC. Direct Peering. Una aplicación HTTP global debe usar una única IP anycast, terminar TLS y dirigir /images y /api a backends diferentes. ¿Qué debes configurar?. Un Application Load Balancer externo global con URL map. Un passthrough Network Load Balancer regional. Cloud VPN. Un balanceador interno TCP. Debes distribuir tráfico TCP no HTTP conservando la IP de origen y sin terminación proxy. ¿Qué tipo de balanceador debes usar?. Application Load Balancer. Passthrough Network Load Balancer. Cloud CDN. IAP. Una aplicación interna HTTP debe balancearse entre backends privados y no debe ser accesible desde Internet. ¿Qué debes elegir?. Balanceador externo global. Cloud CDN público. Application Load Balancer interno. Direct Peering. El balanceador sigue enviando tráfico a una VM cuyo proceso web ha fallado aunque la VM está encendida. ¿Qué falta configurar correctamente?. Una instantánea programada. Un presupuesto. Un registro DNS privado. Un health check que pruebe el endpoint de la aplicación. Una web global sirve contenido estático idéntico a millones de usuarios y quiere reducir latencia y carga de origen. ¿Qué debe habilitar en el backend del balanceador?. Cloud CDN. Cloud NAT. Cloud Router. VPC Service Controls. Quieres que un conjunto de VM idénticas se repare y escale automáticamente. ¿Qué recurso debes utilizar?. Un grupo no administrado. Un managed instance group basado en una instance template. VM independientes creadas a mano. Un bucket de Cloud Storage. Un MIG debe añadir instancias cuando la CPU media supere el objetivo y retirarlas cuando baje. ¿Qué debes configurar?. Una reserva fija. Un URL map. Autoscaling basado en utilización de CPU con mínimos y máximos. Una ACL de bucket. Una aplicación tarda varios minutos en inicializarse y el autoscaler oscila porque evalúa demasiado pronto las VM nuevas. ¿Qué debes ajustar?. El TTL de DNS. La clase de Cloud Storage. La IP externa del balanceador. El período de inicialización o estabilización del autoscaler. |




