Verificación de conocimientos - Infraestructura como código
Un desarrollador ejecuta un ionoscloud_autoscaling_group bajo carga sostenida y aumenta los valores cores y ram en la configuración de réplica, esperando que las réplicas existentes crezcan. Las réplicas en ejecución siguen siendo del mismo tamaño. ¿Cuál es la declaración que mejor explica este comportamiento?
VM Auto Scaling se escala horizontalmente: agrega y elimina réplicas de servidor completas en lugar de cambiar su tamaño. Los cambios en la configuración de réplica surten efecto en réplicas recién creadas, por lo que las réplicas que ya están en ejecución mantienen su tamaño original. Para manejar más carga, permita que el grupo se escale horizontalmente agregando réplicas, o reemplace las réplicas existentes para que el nuevo tamaño se aplique.
Los servidores de aplicaciones de TaskBoard se encuentran en una nube privada LAN sin una IP pública asignada. Necesitan acceder a internet para instalar actualizaciones de paquetes y llamar a APIs externas, pero no deben ser accesibles desde internet. ¿Qué recurso de Terraform proporciona esta conectividad solo de salida?
Una puerta de enlace NAT proporciona conectividad a internet solo de salida, lo que permite que los servidores privados inicien conexiones para actualizaciones y llamadas externas mientras permanecen inaccesibles desde internet. Asignar un ionoscloud_ipblock a cada servidor les daría ingreso público, lo que derrotaría el requisito de aislamiento, y un Load Balancer maneja el tráfico de entrada, no la salida privada.
Un desarrollador proporciona un Managed Kubernetes Node pool y un ionoscloud_application_loadbalancer, luego escribe ionoscloud_firewall (NSG) reglas y espera que protejan tanto el Worker Nodes como el ALB. Las reglas parecen surtir efecto en las NIC de servidores independientes, pero no en los nodos MKS ni en el ALB. ¿Por qué?
Los NSG se adjuntan al nivel VM o NIC, y los nodos del grupo Managed Kubernetes Node pool se excluyen de la aplicación de NSG, al igual que el Managed ALB. Para controlar el tráfico a esos recursos, usted debe utilizar sus propios mecanismos (por ejemplo, reglas de escucha y reenvío en el ALB) en lugar de confiar en las reglas NSG que se adjuntan a ellos.
El servidor API de TaskBoard lee desde un ionoscloud_s3_bucket para archivos adjuntos. El desarrollador configura el cliente S3 de la aplicación con el token de portador IONOS API utilizado para el REST de su Terraform de automatización, pero cada solicitud devuelve un error de autenticación. ¿Cuál es la solución correcta?
IONOS Object Storage expone un API compatible con S3 y se autentica con un par de clave de acceso y clave secreta, y no con el token de portador utilizado para el API de IONOS Cloud. El desarrollador debe provisionar un ionoscloud_s3_key y proporcionar la clave de acceso y la clave secreta resultantes al cliente S3; los tokens de portador y la autenticación básica no funcionan con el punto de conexión S3.
Un desarrollador proporciona un ionoscloud_kafka_cluster y muestra los servidores de arranque y el certificado del cliente desde Terraform para que la aplicación pueda conectarse. ¿Cuáles dos prácticas manejan correctamente esta salida para un entorno de producción?
El plano de datos de IONOS Kafka se autentica con mTLS, por lo que la aplicación se conecta utilizando el certificado del cliente en lugar de un token de portador, clave de acceso o autenticación básica. Las cadenas de conexión, credenciales y certificados extraídos del estado de Terraform deben marcarse como sensibles para que no se expongan en la salida del plan o la aplicación, y nunca deben comprometerse en un repositorio.