Verificación de conocimientos - Fundamentos programáticos
Un script de un desarrollador crea un servidor con un POST a /cloudapi/v6/datacenters/{dcId}/servers, e inmediatamente realiza una segunda llamada para adjuntar un volumen a ese servidor. La llamada al volumen falla intermitentemente con un 404. ¿Cuál es la corrección correcta?
La aprovisionamiento de IONOS CLOUD es asíncrono: un POST devuelve 202 Accepted con el recurso en estado BUSY, y un 404 inmediatamente después de la creación significa "aún no está listo", no "no existe". Debe realizar consultas periódicas a la URL de estado de la solicitud de la cabecera Location hasta DONE antes de cualquier llamada dependiente. Los reintentos frecuentes agotan el presupuesto de límites de tasa sin abordar la causa, y depth solo controla el tamaño de la carga de la respuesta.
Un trabajo programado que genera un nuevo token de portador 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 emite un nuevo token por ejecución eventualmente agota la cuota. El patrón correcto es emitir un token con ámbito específico 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, y luego rotarlo. Un único token de larga duración compartido viola el principio de privilegio mínimo, y los TTL de los tokens se eligen de un conjunto fijo que va desde 1 Hora hasta 365 Días, no un fijo de 1 hora.
Un desarrollador lista 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é ocurrió y cómo debe gestionarse?
Los puntos de acceso de 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 en línea por elemento, no cuántos elementos se devuelven, y 429 es la respuesta de límite de tasa, sin relación con la paginación.
Un desarrollador agrega un bucket de IONOS CLOUD Object Storage como backend de estado remoto de Terraform, pero terraform init falla con errores relacionados con el Security Token Service y una identificación de cuenta ausente. ¿Qué cambio corrige el bloque de backend?
El backend de S3 asume que se trata de AWS e intenta realizar llamadas exclusivas de AWS (STS, búsqueda de identificación de cuenta) que IONOS CLOUD Object Storage no implementa, por lo que se requieren las banderas skip_* junto con un endpoint explícito de IONOS CLOUD (por ejemplo, https://s3.eu-central-1.ionoscloud.com). IONOS CLOUD Object Storage es compatible con S3 y funciona correctamente como backend, pero se autentica con una Access Key y una Secret Key, no con un token bearer. IONOS CLOUD no proporciona una tabla de bloqueo de DynamoDB, por lo que agregar una no es una opción.
Un desarrollador desea poner bajo la gestión de Terraform un servidor que se creó anteriormente con un script curl, sin volver a crearlo. ¿Qué enfoque es el correcto?
Las importaciones de IONOS CLOUD 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 consiste en escribir un bloque ionoscloud_server correspondiente, importar y luego ajustar el HCL hasta que terraform plan informe que no hay cambios. Terraform no adopta automáticamente recursos existentes al ejecutar apply, y terraform refresh solo actualiza el estado de recursos ya gestionados. Eliminar y volver a crear el servidor va en contra del objetivo de conservar el servidor existente.