Eine Lambda-Funktion, die AWS-Konten über die Organizations-API erstellt, läuft derzeit im Management-Konto. Sie müssen diese Lambda-Funktion in ein separates AWS-Konto verschieben, aber ihr weiterhin erlauben, Konten in der Organisation zu erstellen, wobei ihre Fähigkeiten auf Organizations beschränkt sind. Welcher Ansatz erfüllt diese Anforderung, bevor die Lambda-Funktion im dedizierten Konto bereitgestellt wird?

Die korrekte Option beschreibt den standardmäßigen und sichersten Ansatz für die kontoübergreifende Rollenübernahme (cross-account role assumption). Da die Organizations-API nur vom Management-Konto aus aufgerufen werden kann, muss eine Rolle im Management-Konto erstellt werden, die die erforderlichen Berechtigungen (z.B. organizations:CreateAccount) besitzt. Die Vertrauensrichtlinie dieser Rolle muss dann der Lambda-Ausführungsrolle im dedizierten Konto erlauben, sie zu übernehmen. Der Lambda-Code im dedizierten Konto wird aktualisiert, um diese Management-Konto-Rolle vor dem Aufruf der Organizations-API zu übernehmen. Dies stellt sicher, dass die Berechtigungen im Management-Konto bleiben und nur bei Bedarf über die vertrauenswürdige Rolle zugänglich sind. Die Option zur delegierten Administration für Organizations ist falsch, da die CreateAccount-API nicht delegiert werden kann; sie muss immer vom Management-Konto aus aufgerufen werden. Die Option, die Rolle vom Lambda-Service-Principal übernehmen zu lassen, ist falsch, da die Rolle von der Lambda-Ausführungsrolle im dedizierten Konto übernommen werden muss, nicht vom Service-Principal selbst. Die Control Tower-Option ist falsch, da die Anforderung spezifisch die Organizations-API betrifft und Control Tower eine höhere Abstraktionsebene darstellt, die hier nicht direkt gefragt ist.