Assign a managed identity to the application and grant it access to Key Vault secrets is correct.

Using a managed identity lets the application authenticate to Azure Active Directory without any credentials stored in code or configuration files. When you grant the managed identity appropriate access to Key Vault the application can obtain short lived access tokens and retrieve secrets at runtime which eliminates the need to manage or rotate embedded secrets manually.

Register a service principal and embed its client secret inside the application code is wrong because embedding a client secret in code creates a long lived credential that can be leaked from source repositories or runtime environments. A service principal can be used securely if its secret or certificate is stored and rotated safely but embedding the secret is not secure.

Store Key Vault secrets in the application source repository is wrong because putting secrets in source control exposes them to anyone with repository access and defeats the purpose of a secrets store. Key Vault is intended to keep secrets out of code and repositories and to provide controlled access at runtime.

Use a storage account shared access signature to access Key Vault is wrong because shared access signatures are specific to Azure Storage and do not provide a mechanism to authenticate to Key Vault. Using a SAS in place of proper identity based access would not give secure, auditable access to Key Vault secrets.

Full AWS Practitioner Certification Question