1.2-GCP-ACE

Una aplicación heredada busca siempre su servidor de licencias en 10.30.4.10. Vas a migrar el servidor a Compute Engine y no puedes modificar la aplicación. ¿Qué deberías hacer?. Reservar 10.30.4.10 como dirección IP interna estática en la subred y asignarla a la VM. Asignar una dirección interna efímera y confiar en que nunca cambie. Reservar 10.30.4.10 como dirección IP externa global. Crear un rango de alias con 0.0.0.0/0.

Una VM pública debe conservar la misma dirección después de detenerse y arrancar de nuevo. ¿Qué deberías hacer?. Utilizar una IP externa efímera y reiniciar la VM diariamente. Reservar una dirección IP externa estática y asignarla a la VM. Añadir un rango de alias IP interno. Habilitar el Acceso privado a Google.

El equipo ha reservado varias IP externas estáticas y no las ha asignado a ningún recurso. Quiere reducir costes. ¿Qué debería hacer?. Mantenerlas indefinidamente porque las IP sin usar son siempre gratuitas. Convertirlas en rutas para que dejen de facturarse. Liberar las direcciones que no necesite, porque las IP estáticas reservadas y sin usar generan cargos. Asociarlas a Cloud DNS, porque un registro DNS elimina el cargo de la IP.

Las políticas de seguridad prohíben IP públicas en las VMs. Un grupo de VMs privadas debe descargar parches desde Internet, pero no debe aceptar conexiones iniciadas desde Internet. ¿Qué deberías configurar?. Una regla de entrada que permita 0.0.0.0/0. Acceso privado a Google como único mecanismo. Una IP externa estática en cada VM. Cloud NAT para la subred de las VMs.

Una VM sin IP externa debe leer objetos de Cloud Storage, y la empresa no quiere proporcionar salida general a Internet. ¿Qué deberías habilitar?. Acceso privado a Google en la subred de la VM. Cloud NAT con una regla de entrada pública. Una IP pública efímera en la VM. VPC Network Peering con Cloud Storage.

Una subred contiene VMs privadas. Deben acceder tanto a Cloud Storage como a repositorios de paquetes públicos en Internet. ¿Qué configuraciones necesitas? (Selecciona dos). Una regla de entrada pública en cada VM. Una IP externa por VM. Acceso privado a Google para la subred. Cloud NAT para la salida a Internet.

Has eliminado y recreado una VM y su dirección IP interna ha cambiado. Otras VMs deben encontrarla sin mantener una IP codificada. ¿Qué deberías utilizar?. La dirección de broadcast de la subred. Una dirección externa efímera. El nombre DNS interno de la instancia. La IP del servidor de metadatos como destino de la aplicación.

Necesitas publicar registros DNS autoritativos para example.com con alta disponibilidad y sin administrar servidores DNS. ¿Qué servicio deberías utilizar?. OS Login. Cloud NAT. Compute Engine metadata server. Cloud DNS.

Una VM ejecuta varios contenedores y cada uno debe ser direccionable mediante una IP interna propia, sin crear una interfaz de red por contenedor. ¿Qué deberías configurar?. Un rango de alias IP tomado de un rango principal o secundario de la subred. Una IP externa estática para cada contenedor. Una VPC independiente por contenedor. Una ruta predeterminada distinta por proceso.

Has creado una ruta personalizada hacia una aplicación, pero el tráfico sigue sin llegar a la VM de destino. ¿Qué deberías comprobar a continuación?. Que la VM tenga una SSD local. Que una regla de firewall permita el tráfico correspondiente. Que exista una imagen personalizada en el proyecto. Que la cuenta de facturación use la misma moneda que la región.

La tabla de rutas de una VM contiene 0.0.0.0/0 y 10.40.2.0/24. El destino es 10.40.2.15. ¿Qué ruta elegirá la VPC?. Ambas rutas y duplicará los paquetes. 0.0.0.0/0, porque las rutas predeterminadas siempre tienen prioridad. 10.40.2.0/24, porque es la coincidencia más específica. Ninguna, porque una VM solo puede tener una ruta.

Has permitido una conexión TCP de entrada desde un cliente a una VM. No existe una regla de entrada separada para los paquetes de respuesta hacia el cliente. ¿Por qué puede responder la VM?. Porque las rutas anulan siempre las reglas de firewall. Porque todas las conexiones de entrada están permitidas implícitamente. Porque Cloud DNS crea automáticamente una regla de respuesta. Porque las reglas de firewall de VPC tienen estado y permiten el tráfico de retorno de una conexión aceptada.

Creas una VPC personalizada y no añades ninguna regla de firewall. ¿Qué comportamiento implícito debes esperar?. Se deniega la entrada y se permite la salida. Se permite toda la entrada y se deniega toda la salida. Se permiten automáticamente SSH, RDP e ICMP desde Internet. Se deniega tanto entrada como salida sin excepciones.

Dos reglas de firewall coinciden con el mismo tráfico: una regla de prioridad 900 lo deniega y otra de prioridad 1000 lo permite. ¿Cuál se aplica?. La regla de prioridad 1000, porque el número mayor tiene mayor prioridad. La regla de prioridad 900, porque el número menor tiene mayor prioridad. Las dos y el resultado es siempre permitir. Ninguna hasta reiniciar todas las VMs.

Un grupo de servidores web se recrea con frecuencia y recibe IP efímeras diferentes. Quieres que una regla de firewall de entrada se aplique automáticamente a todas las VMs web. ¿Qué deberías usar?. Una IP externa compartida configurada en todas las interfaces. La IP efímera actual de cada VM codificada en la regla. Una etiqueta de red común como destino de la regla. El nombre del disco de arranque como origen.

Las VMs de aplicación y de base de datos utilizan cuentas de servicio distintas. Solo las VMs de aplicación deben conectarse al puerto TCP 5432 de las VMs de base de datos. ¿Qué diseño es más seguro y mantenible?. Asignar la misma IP externa a las VMs de aplicación y de base de datos. Permitir TCP 5432 desde 0.0.0.0/0 a todas las VMs. Crear una regla de salida que permita todos los protocolos a todo Internet. Crear una regla de entrada para TCP 5432 cuyo origen y destino se identifiquen mediante las cuentas de servicio correspondientes.

Una VM solo puede iniciar conexiones HTTPS hacia un servicio externo concreto. El equipo quiere restringir el resto del tráfico saliente. ¿Qué debería configurar?. Reglas de firewall de salida que permitan el destino y puerto requeridos y denieguen el resto con las prioridades adecuadas. Una regla de entrada que permita TCP 443 desde 0.0.0.0/0. Una ruta sin reglas de firewall. Una imagen personalizada con HTTPS habilitado.

Una aplicación se ejecuta en una única zona y debe seguir disponible si esa zona falla. Quieres mantener la latencia regional y evitar un despliegue multirregional. ¿Qué deberías hacer?. Crear más instancias en la misma zona. Distribuir las instancias entre al menos dos zonas de la misma región y balancear el tráfico. Reservar varias IP externas para una sola VM. Realizar únicamente una instantánea mensual.

Una aplicación global debe resistir fallos regionales y dirigir a los usuarios hacia una región disponible cercana. ¿Qué arquitectura cumple mejor el requisito?. Una única VM con una SSD local grande. Todas las VMs en una única zona con IPs efímeras. Recursos en varias regiones detrás de un balanceador de cargas global. Una VPC distinta por usuario final.

Dos VMs de la misma zona intercambian grandes cantidades de datos. Quieres minimizar los cargos de red. ¿Qué deberías hacer?. Reservar una IP externa sin asignarla. Usar sus direcciones IP externas. Enviar el tráfico a otra región antes de devolverlo. Usar sus direcciones IP internas.