Een applicatie op EC2 gebruikte voorheen IAM-gebruikerstoegangssleutels die waren opgeslagen in omgevingsvariabelen om DynamoDB aan te roepen via boto. De ontwikkelaar heeft een instantiële rol met dezelfde machtigingen gekoppeld en vervolgens de IAM-gebruiker verwijderd. Na het herstarten tonen de app-logs AccessDeniedException, maar de ontwikkelaar kan DynamoDB CLI-commando's uitvoeren met zijn persoonlijke account op de server. Wat is de MEEST waarschijnlijke oorzaak van de uitzondering?

De meest waarschijnlijke oorzaak is dat de applicatie nog steeds probeert de referenties uit de omgevingsvariabelen te gebruiken, zelfs nadat de IAM-gebruiker is verwijderd. Hoewel de IAM-rol aan de instantie is gekoppeld, zal de AWS SDK standaard eerst zoeken naar referenties in omgevingsvariabelen (zoals AWSACCESSKEYID en AWSSECRETACCESSKEY). Als deze variabelen nog steeds aanwezig zijn en verwijzen naar een niet-bestaande of ongeldige IAM-gebruiker, zal de applicatie proberen deze te gebruiken en een AccessDeniedException krijgen. De SDK zal pas de instantierol gebruiken als er geen omgevingsvariabelen zijn geconfigureerd. De andere opties zijn minder waarschijnlijk: IAM-beleid wordt doorgaans zeer snel doorgegeven. De AWS SDK ondersteunt wel degelijk referenties die zijn verkregen via een instantierol; dit is de aanbevolen methode. Als de security group toegang tot 169.254.169.254 (de metadata service) zou blokkeren, zou de instantierol helemaal niet kunnen worden opgehaald, wat een andere fout zou veroorzaken. De CLI-commando's werken wel, wat suggereert dat de instantie toegang heeft tot DynamoDB.