TL;DR: A managed identity is a service principal whose credential Azure creates, rotates and injects, so nothing is stored anywhere. Use system-assigned for a single resource, user-assigned when several resources share an identity, and keep client secrets for the cases that genuinely run outside Azure.
How to approach it
Define the three objects in one line each (application registration, service principal, managed identity) because candidates mix them up and the distinction is the whole answer. Then make the case on credential lifetime rather than convenience, since that is what a security-minded interviewer is listening for.
A strong answer
In Entra ID, an application registration is the global definition of an application. A service principal is the instance of it inside your tenant, and that is the thing you assign roles to. A managed identity is a service principal that Azure creates and whose credential it owns.
The traditional path is an app registration with a client secret or a certificate. The application holds a tenant ID, a client ID and that secret, and exchanges them for a token. Every part of that works, and the secret is now in a configuration file, a pipeline variable or a Key Vault you still need a credential to reach. It expires, usually at the least convenient moment, and rotating it means coordinating a change across every consumer. This is the chicken-and-egg problem that makes secret management circular.
A managed identity removes the credential entirely. Enable it on a VM, an App Service, a Function, an AKS workload or a container instance, and the platform provisions an identity and makes a local token endpoint available to that resource. The SDK asks the local endpoint for a token, and the platform proves the resource's identity without anything being stored. There is no secret to rotate, to leak, or to check into git.
Two kinds:
System-assigned is tied to one resource's lifecycle. It is created with the resource and deleted with it, one-to-one. Right for a single application that needs its own identity and should lose it when the resource goes away.
User-assigned is a standalone resource you create and attach to many. Right when several resources share a role, or when the identity must outlive any one of them, or when you need role assignments to exist before the compute does, which is the usual reason in an infrastructure-as-code pipeline: you cannot assign roles to a system-assigned identity that does not exist yet.
In code it is one object, with the SDK trying credential sources in order:
var credential = new DefaultAzureCredential();
var client = new SecretClient(new Uri(vaultUrl), credential);
DefaultAzureCredential uses the managed identity in Azure and falls back to the developer's own login locally, so the same code runs in both places without a branch.
For AKS specifically, the current mechanism is workload identity: the pod gets a projected service account token, Entra ID federates with the cluster's OIDC issuer, and the pod exchanges its token for an Azure one. Same principle, and it means a Kubernetes service account maps to an Azure identity without a secret in the cluster.
Where a client secret is still correct: something running outside Azure entirely, such as an on-premises job or a third-party system. Then use a certificate rather than a secret where possible, keep the lifetime short, and store it in Key Vault.
What interviewers probe next
"What permissions does the identity get?" None by default. You assign Azure RBAC roles scoped as narrowly as possible, and for Key Vault check whether the vault uses the RBAC model or the older access policies, because assigning the wrong one is the most common reason access still fails.
"How does the token endpoint work?" A local endpoint the resource can reach, backed by the platform, returning a short-lived token for a requested resource. The SDK caches and refreshes it, which is why token lifetime rarely appears in application code.
"Why did it work in one namespace and fail in another?" On AKS with workload identity, the federated credential names a specific service account and namespace. Move the workload and the federation no longer matches, which produces an authentication failure that looks like a permissions problem.
Common mistakes
Using an app registration with a client secret by default, then needing a secret to reach the secret store.
Choosing system-assigned when infrastructure code has to assign roles before the compute exists.
Assigning roles at subscription scope because the narrower scope did not work first time, which usually means the wrong Key Vault permission model rather than the wrong scope.
Forgetting that a system-assigned identity is destroyed and recreated with its resource, which invalidates every role assignment that referenced it.