Verificación de conocimientos - Fundamentos programáticos
Un script de un desarrollador crea un servidor con un POST a /cloudapi/v6/datacenters/{dcId}/servers, y luego emite inmediatamente una segunda llamada para adjuntar un Volume a ese servidor. La llamada a Volume falla intermitentemente con un 404. ¿Cuál es la solución correcta?
La provisión de IONOS es asíncrona: un POST devuelve 202 Accepted con el recurso en estado BUSY, y un 404 justo después de la creación significa "no listo aún", no "faltante". Usted debe sondear la URL de estado de la solicitud desde el encabezado Location hasta que esté DONE antes de cualquier llamada dependiente. Las reintentaciones ajustadas desperdician el presupuesto de límite de velocidad sin abordar la causa, y depth solo controla el tamaño de la carga de respuesta.
Un trabajo programado que genera un token de portador fresco en cada ejecución comienza a fallar con errores de autenticación después de varias semanas, y el Token Manager muestra decenas de tokens. ¿Cuál es el límite subyacente y el patrón correcto?
Un usuario puede generar hasta 100 tokens de autenticación, por lo que un script que acuña un nuevo token por ejecución eventualmente agota la cuota. El patrón correcto es emitir un token con ámbito y TTL corto por servicio o entorno, capturarlo en el momento de su creación (el valor se muestra solo una vez) y reutilizarlo hasta que expire, luego rotarlo. Un token de larga duración compartido viola el principio de privilegios mínimos, y los TTL de los tokens se eligen de un conjunto fijo que va desde 1 hora hasta 365 días, no una hora fija.
Un desarrollador enumera recursos con GET /cloudapi/v6/datacenters y procesa los elementos devueltos, pero más tarde descubre que algunos recursos nunca fueron vistos por el script. La colección tiene más de 1000 entradas. ¿Qué sucedió y cómo debe manejarse?
Los puntos de conexión de la lista devuelven colecciones paginadas con un limit predeterminado de 1000 y un offset predeterminado de 0, por lo que una sola llamada solo ve la primera página. La solución es iterar, aumentando offset por el tamaño de la página hasta que una página devuelva menos de limit elementos. El parámetro depth controla cuánto del árbol de recursos anidados se incluye por elemento, no cuántos elementos se devuelven, y 429 es la respuesta de límite de velocidad, no relacionada con la paginación.
Un desarrollador agrega un cubo de IONOS Object Storage como un backend de estado remoto de Terraform, pero terraform init falla con errores sobre el Servicio de Token de Seguridad y un ID de cuenta que falta. ¿Qué cambio soluciona el bloque del backend?
El backend de S3 asume AWS e intenta llamadas exclusivas de AWS (STS, búsqueda de ID de cuenta) que IONOS Object Storage no implementa, por lo que se requieren las banderas skip_* más un punto final de IONOS explícito (por ejemplo, https://s3.eu-central-1.ionoscloud.com). IONOS Object Storage es compatible con S3 y funciona bien como backend, pero se autentica con una clave de acceso y una clave secreta, no con un token de portador. IONOS no proporciona una tabla de bloqueo de DynamoDB, por lo que agregar una no es una opción.
Un desarrollador quiere poner un servidor que se creó anteriormente con un curl script bajo la gestión de Terraform sin recrearlo. ¿Cuál es el enfoque correcto?
Las importaciones de IONOS utilizan un ID compuesto que une el ID del centro de datos y el ID del recurso (dc_id/server_id), y el flujo de trabajo es escribir un bloque de recursos coincidente, importar, luego ajustar el HCL hasta que terraform plan informe que no hay cambios. Terraform no adopta automáticamente los recursos existentes en apply, y terraform refresh solo actualiza el estado de los recursos ya gestionados. Eliminar y recrear derrota el objetivo de preservar el servidor existente.