1-GCP-ACE

Acabas de recibir acceso a un proyecto de Google Cloud y necesitas crear un bucket y una VM desde una terminal sin instalar herramientas en tu portátil. También quieres conservar tus scripts entre sesiones. ¿Qué deberías usar?. Cloud Shell, que incluye la CLI de Google Cloud y almacenamiento persistente para tu directorio personal. Cloud Mobile App, porque permite ejecutar cualquier script de Bash de forma persistente. La consola de Google Cloud, porque es la única interfaz que permite crear recursos. Una VM de Compute Engine creada previamente por el administrador.

Administras dos proyectos con cuentas, regiones y zonas predeterminadas distintas. Quieres alternar entre ambos desde la CLI sin volver a escribir todas las propiedades cada vez. ¿Qué deberías hacer?. Crear una VPC distinta para cada configuración de gcloud. Crear una configuración de gcloud para cada proyecto y activar la que corresponda. Cambiar el archivo de imagen de cada VM antes de ejecutar un comando. Abrir una cuenta de facturación diferente para cada comando.

Tienes varias configuraciones de gcloud y necesitas consultar las propiedades de una configuración inactiva utilizando el menor número de pasos. ¿Qué debes hacer?. Activarla y después ejecutar gcloud config list. Ejecutar gcloud compute instances list sin indicar proyecto. Ejecutar gcloud config configurations describe con el nombre de la configuración. Eliminar temporalmente la configuración activa.

Tu equipo quiere probar Jenkins en Google Cloud. Necesita una implementación funcional en pocos minutos y no quiere configurar manualmente la VM, el software, el almacenamiento y la red. ¿Qué opción debería utilizar?. Crear una imagen vacía y esperar a que Google instale Jenkins automáticamente. Crear una SSD local y copiar manualmente todos los binarios. Crear una zona de Cloud DNS para instalar Jenkins. Desplegar una solución preconfigurada desde Google Cloud Marketplace.

Vas a migrar una aplicación empresarial antigua que requiere un sistema operativo personalizado, acceso administrativo completo y software con dependencias específicas. ¿Qué servicio de procesamiento deberías elegir?. Compute Engine. Cloud Run functions. Cloud DNS. Cloud Storage.

Tu empresa ha empaquetado una aplicación compuesta por varios microservicios en contenedores. Necesita controlar la configuración de Kubernetes y escalar cada microservicio por separado. ¿Qué opción es la más adecuada?. Cloud DNS. Google Kubernetes Engine. Una única VM de núcleo compartido. Una imagen de máquina.

Un equipo quiere desplegar una aplicación web desde código y no desea administrar servidores, clústeres ni aprovisionamiento de infraestructura. La aplicación encaja en los entornos de ejecución admitidos por App Engine. ¿Qué debería elegir?. Una SSD local. Un nodo de usuario único. App Engine. Cloud NAT.

Tienes una imagen de contenedor sin estado que expone HTTP, recibe pocas solicitudes al día y debe escalar a cero para minimizar costes. ¿Dónde deberías desplegarla?. Cloud DNS. Una VM de Compute Engine encendida permanentemente. Un nodo de usuario único. Cloud Run.

Necesitas ejecutar una pequeña función cada vez que se publica un mensaje en un tema de Pub/Sub. Quieres una solución orientada a eventos y sin administrar servidores. ¿Qué deberías usar?. Cloud Run functions. Una VM con un trabajo cron que consulte Pub/Sub constantemente. Cloud DNS. Un disco persistente regional.

¿Qué interfaces permiten administrar recursos de Google Cloud directamente? (Selecciona dos). Un hotspot Wi-Fi específico de Google Cloud. La consola de Google Cloud. La CLI de Google Cloud desde Cloud Shell. Un servicio telefónico que interpreta comandos de voz.

Has creado un proyecto nuevo y un comando para crear VMs falla porque el servicio no está disponible en el proyecto. La cuenta tiene permisos suficientes. ¿Qué deberías comprobar primero?. Que Cloud NAT esté configurado en todas las regiones. Que exista una dirección IP externa estática sin usar. Que la API de Compute Engine esté habilitada en el proyecto correcto. Que el proyecto tenga una imagen de máquina propia.

Tu organización quiere separar las VMs de producción y pruebas en subredes diferentes, pero todas deben comunicarse mediante IP internas sin configurar conectividad entre redes. ¿Qué diseño deberías utilizar?. Dos proyectos sin ninguna conexión de red. Dos VPC independientes con rangos superpuestos. Una VPC automática y dos subredes con el mismo rango CIDR. Una VPC personalizada con dos subredes de rangos no superpuestos.

Una aplicación tiene VMs en europe-west1 y us-central1 dentro de la misma VPC. Necesitas que se comuniquen de forma privada utilizando el diseño más sencillo. ¿Qué deberías hacer?. Usar sus direcciones IP internas y permitir el tráfico necesario en el firewall. Crear una Cloud VPN entre las dos subredes de la misma VPC. Asignar IP externas a todas las VMs y enviar el tráfico por Internet. Crear una VPC distinta para cada zona.

Vas a crear una red para una aplicación que solo se desplegará en dos regiones. El equipo de red debe elegir exactamente los rangos CIDR y evitar que aparezcan subredes nuevas al incorporarse regiones de Google. ¿Qué modo de VPC debes usar?. Modo automático. Modo personalizado. Red predeterminada sin cambios. Una red heredada sin subredes.

Tu proyecto utiliza una VPC de modo automático, pero ahora necesitas controlar manualmente todas las subredes futuras. ¿Qué deberías tener en cuenta antes de convertirla a modo personalizado?. Después de convertirla, todas las subredes deben compartir el mismo CIDR. La conversión elimina todas las VMs del proyecto. La conversión es posible, pero no se puede volver posteriormente a modo automático. Solo se puede convertir una VPC si no tiene reglas de firewall.

Quieres distribuir dos VMs entre dos zonas de la misma región para tolerar un fallo zonal y aplicarles la misma política de red. ¿Qué deberías hacer?. Colocar ambas VMs en una única zona y reservar dos IP externas. Crear una subred global diferente para cada VM. Crear dos VPC y conectarlas mediante direcciones IP externas. Colocar ambas VMs en la misma subred regional, una en cada zona.

Una subred personalizada con rango 10.20.0.0/24 se ha quedado sin direcciones. El rango 10.20.0.0/23 no se superpone con ninguna otra subred y quieres conservar las VMs existentes. ¿Qué deberías hacer?. Expandir el rango principal de la subred a 10.20.0.0/23. Eliminar la subred y volver a crearla con el rango mayor. Crear otra subred con el mismo rango 10.20.0.0/24. Reducir el rango a 10.20.0.0/25.

Después de expandir una subred de /24 a /22, el equipo descubre que reservó más direcciones de las necesarias. ¿Qué puede hacer para volver a /24?. Puede reducirlo mientras todas las VMs estén detenidas. No puede reducir el rango principal; deberá planificar otra alternativa. Puede reducirlo si habilita Cloud NAT. Puede reducirlo únicamente desde Cloud Shell.

Estás calculando la capacidad útil de una subred IPv4 primaria. ¿Cuántas direcciones del rango reserva Google Cloud y no puedes asignar a VMs?. Dos. Ocho. Cuatro. Ninguna.

Una VM de backend solo debe comunicarse con recursos internos y con servicios de Google mediante conectividad privada. ¿Cuál es la configuración mínima de direcciones de la VM?. Ninguna dirección IP si utiliza DNS interno. Una dirección interna y una externa obligatoriamente. Una dirección externa y un rango de alias obligatoriamente. Una dirección IP interna; la dirección externa es opcional.

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.

Los administradores deben conectarse por SSH a VMs privadas desde Internet. No quieres asignar IP públicas ni mantener un host bastión. ¿Qué deberías configurar?. Túneles TCP de Identity-Aware Proxy y los permisos IAM necesarios. Cloud NAT, porque acepta conexiones SSH iniciadas desde Internet. Acceso privado a Google, porque publica el puerto 22. Una regla de firewall de entrada sin ningún mecanismo de acceso.

Una empresa tiene muchos usuarios que administran VMs Linux. Quiere vincular el acceso SSH a identidades de Google, revocarlo mediante IAM y evitar distribuir claves manualmente. ¿Qué debería usar?. Una única clave SSH privada compartida. OS Login. Una IP externa estática por usuario. Cloud DNS con una zona privada.

El grupo operaciones necesita iniciar sesión en VMs Linux y ejecutar comandos con sudo. OS Login ya está habilitado. ¿Qué rol deberías conceder?. roles/dns.reader. roles/compute.osLogin. roles/compute.osAdminLogin. roles/compute.networkViewer.

Has creado una VM Windows y necesitas conectarte mediante RDP siguiendo el flujo administrado por Google Cloud. ¿Qué deberías hacer?. Publicar un registro DNS sin configurar credenciales ni firewall. Utilizar la clave privada JSON de la cuenta de servicio como contraseña de Windows. Habilitar OS Login y conectarte mediante TCP 22. Generar o restablecer las credenciales de Windows para la VM y permitir TCP 3389 desde orígenes autorizados.

Estás preparando acceso administrativo a una VM Linux y otra Windows. ¿Qué reglas de firewall podrías necesitar? (Selecciona dos). Permitir TCP 22 para SSH hacia la VM Linux. Permitir TCP 3389 para RDP hacia la VM Windows. Permitir UDP 53 como sustituto de SSH. Permitir todo el tráfico desde 0.0.0.0/0 a ambas VMs.

Debes automatizar la creación repetible de una VM con una configuración compleja. Quieres reducir errores antes de escribir el comando definitivo. ¿Qué enfoque es útil?. Crear manualmente una VM diferente cada vez sin registrar la configuración. Configurar primero una instancia equivalente en la consola y revisar el comando o la solicitud REST equivalente. Usar Cloud DNS para generar los parámetros de la VM. Modificar directamente el XML de Daypo.

Una aplicación debe permanecer disponible durante el mantenimiento planificado del host. La VM admite migración en vivo. ¿Qué política deberías seleccionar?. Convertir la VM en Spot durante el mantenimiento. Finalizar siempre la VM y desactivar el reinicio automático. Migrar la instancia de VM durante el mantenimiento del host. Eliminar el disco de arranque al comenzar el mantenimiento.

Una VM estándar debe volver a iniciarse automáticamente después de un fallo del host, pero no después de que un administrador la detenga intencionadamente. ¿Qué opción deberías habilitar?. Un rango de alias IP. Protección contra eliminación. Una instantánea programada cada minuto. Reinicio automático en la política de disponibilidad.

Has detenido una VM para ahorrar. ¿Qué recursos pueden seguir generando cargos? (Selecciona dos). Los discos persistentes conectados. Las direcciones IP externas estáticas reservadas. Las CPU virtuales de la VM detenida. La memoria de la VM detenida.

Una VM con 2 vCPU y 4 GB de memoria necesita 8 GB. Quieres modificarla con seguridad. ¿Qué deberías hacer?. Añadir un metadato llamado required-memory-size sin detenerla. Detener la VM, seleccionar un tipo de máquina adecuado o personalizado y volver a iniciarla. Crear una regla de firewall con 8 GB como destino. Confiar en que la migración en vivo aumente la memoria automáticamente.

Debes mantener actualizada una flota de VMs Linux y Windows y conocer qué instancias incumplen la política de parches. ¿Qué funciones de VM Manager deberías usar? (Selecciona dos). Rangos de alias IP. Informes de cumplimiento de parches. Implementaciones de parches programadas. Registros DNS públicos automáticos.

Tienes un trabajo de procesamiento por lotes que guarda puntos de control, tolera interrupciones y puede reintentar tareas. Quieres minimizar el coste de cómputo. ¿Qué opción deberías considerar?. Cloud DNS Premium. Nodos de usuario único con compromiso permanente. Una única VM estándar sin mecanismo de reintento. VMs Spot.

¿Para cuál de las siguientes cargas NO deberías elegir una VM Spot como única instancia?. Una base de datos de producción con estado que no tolera interrupciones. Un trabajo por lotes idempotente. Un renderizado distribuido que reintenta tareas. Un cálculo que guarda puntos de control frecuentes.

Los tipos predefinidos ofrecen 4 vCPU con demasiada memoria o 2 vCPU con muy poca. La aplicación necesita una proporción concreta y estable. ¿Qué deberías hacer?. Elegir siempre el tipo predefinido más grande disponible. Crear un tipo personalizado de máquina con la combinación necesaria de vCPU y memoria, si la serie lo admite. Añadir una segunda dirección IP interna para obtener más memoria. Aumentar el disco, porque eso incrementa automáticamente la RAM.

Necesitas alojar servidores web, pequeños microservicios y entornos de desarrollo sin requisitos extremos de CPU, memoria o GPU. ¿Qué familia de máquinas deberías evaluar primero?. Optimizada para aceleradores. Optimizada para memoria. Uso general. Un nodo de usuario único obligatoriamente.

Una aplicación de transcodificación realiza cálculos intensivos y el coste de licencia depende del número de núcleos. Quieres el mayor rendimiento posible por núcleo. ¿Qué familia deberías considerar?. Cloud Shell. Núcleo compartido de bajo consumo. Optimizada únicamente para almacenamiento. Optimizada para procesamiento.

Vas a ejecutar una base de datos SAP HANA que necesita una relación de memoria por vCPU muy superior a la de las máquinas de uso general. ¿Qué familia debes elegir?. Optimizada para memoria. Optimizada para aceleradores gráficos. Núcleo compartido. Una VM Spot de tamaño mínimo.

Una carga de entrenamiento utiliza CUDA y requiere varias GPU NVIDIA. ¿Qué familia de máquinas deberías considerar?. Uso general sin aceleradores. Optimizada para aceleradores. Optimizada solo para memoria sin GPU. Una red de modo automático.

Tu equipo entrena un modelo grande de aprendizaje automático con multiplicaciones de matrices y lotes efectivos grandes. Quiere un acelerador especializado de Google con alta eficiencia energética. ¿Qué debería evaluar?. Una IP externa estática. Cloud DNS. Cloud TPU. Un disco persistente estándar como acelerador de cálculo.

Una carga regulada exige aislamiento físico respecto a las VMs de otros clientes y quiere reutilizar licencias por núcleo existentes. ¿Qué opción deberías considerar?. Una VPC de modo automático. VMs de núcleo compartido. Cloud Shell. Nodos de usuario único.

El equipo de seguridad quiere reducir el riesgo de rootkits de arranque y comprobar la integridad de las VMs. ¿Qué debería habilitar?. VMs protegidas con arranque seguro, vTPM y supervisión de integridad. Una IP externa efímera. Una red sin reglas de firewall. Una SSD local sin cifrado.

Una aplicación procesa información extremadamente sensible y debe mantener los datos cifrados incluso mientras se utilizan en memoria. No quieres reescribir la aplicación. ¿Qué opción deberías evaluar?. Una IP interna estática. Confidential VM. Cloud NAT. Una instantánea de archivo como memoria activa.

Una aplicación crítica se ejecuta en una VM de un proyecto compartido. Quieres evitar que otro equipo elimine la instancia accidentalmente. ¿Qué deberías hacer?. Convertirla en VM Spot. Deshabilitar el reinicio automático. Habilitar la protección contra eliminación en la VM. Eliminar su disco de arranque.

Debes eliminar una VM, pero quieres conservar su disco de arranque para recuperar archivos más tarde. ¿Qué deberías hacer antes de eliminarla?. Liberar la dirección IP interna del disco. Convertir el disco en SSD local. Activar una regla de firewall de entrada. Desactivar la eliminación automática del disco de arranque.

Has instalado y endurecido un sistema operativo con el software corporativo. Debes crear muchas VMs nuevas con esa misma base. ¿Qué recurso deberías crear?. Una imagen personalizada y después crear las VMs desde ella. Una instantánea independiente por cada VM futura. Una zona DNS que contenga el software. Una regla de firewall que instale los paquetes.

Necesitas una copia de seguridad que capture la configuración, los metadatos, los permisos y los datos de varios discos de una VM para poder clonarla. ¿Qué recurso se ajusta mejor?. Una instantánea de un único disco. Una imagen de máquina. Una plantilla de instancia sin discos. Un rango de alias IP.

Una VM crítica necesita copias de seguridad diarias de su disco persistente, conservación durante siete días y limpieza automática de copias antiguas. Quieres una configuración mínima. ¿Qué deberías hacer?. Copiar archivos con un script local sin política de retención. Crear manualmente una imagen completa cada día. Asociar una programación de instantáneas diaria con retención de siete días. Crear una SSD local secundaria.

Una base de datos debe seguir accediendo a sus datos inmediatamente si falla una zona. La aplicación puede arrancar una VM de sustitución en otra zona de la misma región. ¿Qué almacenamiento deberías elegir?. Disco persistente zonal sin copia ni instantáneas. SSD local de una única VM. Disco RAM. Disco persistente regional replicado entre dos zonas.

Una carga procesa grandes archivos principalmente con E/S secuencial y prioriza capacidad económica sobre IOPS. ¿Qué tipo de Persistent Disk deberías considerar primero?. pd-standard. pd-ssd. pd-extreme con IOPS aprovisionadas al máximo. SSD local para datos que deben sobrevivir a la detención.

Una base de datos necesita baja latencia y muchas operaciones de E/S aleatorias, y los datos deben persistir después de detener la VM. ¿Qué opción es la más adecuada?. Disco persistente estándar como primera opción de máximo rendimiento aleatorio. Disco persistente SSD. Disco RAM sin copia de seguridad. SSD local si es obligatorio conservar los datos al detener la VM.

Una aplicación de uso general necesita almacenamiento SSD persistente con un equilibrio entre coste y rendimiento, pero no requiere las IOPS por GB de pd-ssd. ¿Qué tipo deberías elegir?. SSD local. pd-standard obligatoriamente. pd-balanced. Disco RAM.

Una aplicación crea datos temporales que puede reconstruir y necesita la latencia de almacenamiento más baja posible en la VM. ¿Qué opción deberías considerar?. Cloud DNS. Disco persistente regional como opción de menor latencia local. Una instantánea como disco escribible. SSD local.

Una aplicación espera un sistema de archivos para una caché muy pequeña y extremadamente rápida. Puede regenerar los datos después de un reinicio. ¿Qué opción podrías usar?. Un sistema de archivos tmpfs como disco RAM. Una instantánea estándar montada directamente en lectura y escritura. Cloud DNS. Una IP de alias.

Un disco persistente conectado a una VM se está quedando sin espacio. Quieres ampliarlo sin sustituir la VM. ¿Qué debes tener en cuenta?. Solo puedes ampliarlo eliminando primero la VM. Puedes aumentar el disco mientras está conectado, pero no puedes reducirlo después. Puedes reducirlo libremente si la VM está detenida. Al ampliarlo se convierte automáticamente en SSD local.

Necesitas mover los datos de un disco persistente HDD a un nuevo disco SSD situado en otra zona. ¿Qué deberías hacer?. Cambiar el registro DNS del disco. Convertir directamente una SSD local de otra VM en el disco de origen. Crear una instantánea del disco y restaurarla en un disco SSD nuevo en la zona de destino. Crear una regla de firewall que copie los bloques automáticamente.

¿Qué afirmaciones sobre las instantáneas estándar son correctas? (Selecciona dos). Se pueden usar para crear un disco nuevo y no sobrescriben directamente el disco de origen. Incluyen siempre las etiquetas, los metadatos y la configuración completa de la VM. Son el mecanismo de copia de seguridad de una SSD local después de detenerla. Son incrementales de forma predeterminada.

Una flota de VMs debe instalar el mismo agente al arrancar y cada instancia necesita consultar su propio ID y proyecto sin credenciales adicionales. ¿Qué diseño deberías usar?. Una secuencia de comandos de inicio que consulte el servidor de metadatos. Una clave SSH privada compartida dentro de la imagen. Una IP externa distinta codificada en cada script. Un registro DNS público por paquete instalado.

La mayoría de tus VMs están en europe-west1-b y quieres evitar especificar la zona en cada comando de gcloud. ¿Qué deberías hacer?. Añadir la zona a una regla de firewall. Configurar compute/zone en la configuración activa de gcloud. Cambiar el nombre de todas las VMs para que termine en europe-west1-b. Crear una dirección IP externa global.

Debes estimar el coste mensual de varias VMs, discos y tráfico de red antes del despliegue. Los precios varían según región y consumo. ¿Qué herramienta deberías usar?. El servidor de metadatos de una VM. Cloud DNS. La calculadora de precios de Google Cloud. Una instantánea del disco de arranque.

Una aplicación de una VM se ha bloqueado. Quieres realizar una acción equivalente a pulsar el botón de reset, aceptando que se pierda el contenido de la memoria pero sin dejar la instancia en estado TERMINATED. ¿Qué deberías hacer?. Crear una instantánea y reducir el disco. Detener la VM. Eliminar la VM. Restablecer la VM.