Verificación de conocimientos - Infraestructura como código
Un desarrollador ejecuta un ionoscloud_autoscaling_group bajo carga sostenida y aumenta los valores de cores y ram en la configuración de réplicas, esperando que las réplicas existentes aumenten de tamaño. Las réplicas en ejecución mantienen el mismo tamaño. ¿Qué afirmación explica mejor este comportamiento?
VM Auto Scaling escala horizontalmente: agrega y elimina réplicas completas de servidores en lugar de redimensionarlas. Los cambios en la configuración de réplicas surten efecto en las réplicas recién creadas, por lo que las réplicas que ya están en ejecución conservan su tamaño original. Para manejar más carga, deje que el grupo se escale hacia afuera agregando réplicas, o reemplace las réplicas existentes para que se aplique el nuevo tamaño.
Los servidores de aplicaciones de TaskBoard se encuentran en una LAN privada sin IP pública asignada. Necesitan acceder a internet para instalar actualizaciones de paquetes y llamar a APIs externas, pero no deben ser alcanzables desde internet. ¿Qué recurso de Terraform proporciona esta conectividad solo de salida?
Un gateway NAT proporciona conectividad a internet solo de salida, permitiendo que los servidores privados inicien conexiones para actualizaciones y llamadas externas, mientras permanecen inalcanzables desde internet. Asignar una ionoscloud_ipblock a cada servidor les otorgaría entrada pública, lo que invalidaría el requisito de aislamiento, y un balanceador de carga gestiona el tráfico entrante, no la salida privada.
Un desarrollador aprovisiona un grupo de nodos de Managed Kubernetes y un ionoscloud_application_loadbalancer, y luego escribe reglas de ionoscloud_firewall (NSG) y espera que protejan tanto los nodos de trabajo como el ALB. Las reglas parecen tener efecto en las NIC de servidores independientes, pero no en los nodos de MKS ni en el ALB. ¿Por qué?
Los NSG se adjuntan a nivel de VM o NIC, y los nodos de un grupo de nodos de Managed Kubernetes están excluidos de la aplicación de NSG, al igual que el ALB administrado. Para controlar el tráfico hacia esos recursos, debe utilizar sus propios mecanismos (por ejemplo, reglas de listener y de reenvío en el ALB) en lugar de depender de reglas de NSG que se vinculen a ellos.
El servidor de API de TaskBoard lee de un ionoscloud_s3_bucket para los archivos adjuntos. El desarrollador configura el cliente S3 de la aplicación con el token de portador de la API de IONOS CLOUD utilizado para el resto de su automatización con Terraform, pero cada solicitud devuelve un error de autenticación. ¿Cuál es la solución correcta?
Object Storage de IONOS CLOUD expone una API compatible con S3 y se autentica con un par de Access Key y Secret Key, no con el token de portador utilizado para la API de IONOS CLOUD. El desarrollador debe aprovisionar un ionoscloud_s3_key y proporcionar la Access Key y la Secret Key resultantes al cliente S3; los tokens de portador y la autenticación básica no funcionan con el endpoint de S3.
Un desarrollador aprovisiona un ionoscloud_kafka_cluster y emite los servidores de inicio 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 Kafka de IONOS CLOUD se autentica con mTLS, por lo que la aplicación se conecta utilizando el certificado del cliente en lugar de un token de portador, una Access Key o una autenticación básica. Las cadenas de conexión, las credenciales y los certificados extraídos del estado de Terraform deben marcarse como sensibles para que no se expongan en la salida de planificación o aplicación, y nunca deben confirmarse en un repositorio.