3 Power Tips + Power Link I11

Las PTs de este issue muestran cómo, incluso en la nube (en este caso Azure), siguen aplicando conceptos clásicos de sistemas: distinguir entre ejecución y estado, entender la irreversibilidad de ciertos valores (como secrets) y operar en ausencia de un mapeo explícito entre componentes.

Power Tip #1 El exit code es local, no de Azure

El comando volvió con 0 y la app sigue cayéndose.

• az reporta éxito al recibir el ACK del control plane.
• El recurso queda en Updating o Creating por minutos.
• El siguiente paso del script lo encuentra "no listo" y falla raro.

az resource show --ids "$id" --query "properties.provisioningState" -o tsv

provisioningState es un testigo más confiable del control plane.

Power Tip #2 El valor del secret se entrega una sola vez

La alerta de vencimiento de un secret se "resolvió" pero la app igual se cae.

• credential reset devolvió el password en stdout.
• Lo perdiste antes de guardarlo en el vault.
• Entra ID considera el secret válido. Nadie puede usarlo.

az ad app credential reset --append ... --query password -o tsv

Si se perdió el valor generado, no se puede recuperar. Como perder una clave privada SSH: podés crear otra, pero no reconstruir la anterior.

Power Tip #3 El mapeo no vive donde uno espera

Sabés que la app usa un secret de un KV. No sabés cuál.

• App Registration no declara qué KV la consume.
• Key Vault no mantiene, por defecto, una relación nativa con la App Registration que originó el secret.
• El nombre del secret en KV es convención del equipo responsable, no metadato de Azure.

for kv in $(az keyvault list --query "[].name" -o tsv); do
  az keyvault secret list --vault-name "$kv" \
    --query "[?contains(name, 'mi-superpower-app')].{kv:'$kv',name:name}" -o tsv
done

Si para rotar un secret tenés que salir a buscarlo, no está definido en ningún lado qué secret usa esa app.