Crisp answer: Entra ID (formerly Azure Active Directory) is Microsoft's cloud identity platform. It handles authentication (who you are) and authorisation (what you can do) for Azure resources, Microsoft 365, and any app registered in the tenant.
Core objects:
User: A person with a username and password
Group: Collection of users, used to assign permissions in bulk
Service Principal: An identity for an application or automated process
Managed Identity: A service principal managed by Azure — no credentials
to store or rotate
App Registration: Registers an external app with Entra ID for SSO or API access
Managed Identity — most important for engineers:
System-assigned: tied to a specific resource (VM, AKS pod, Function App)
Created and deleted with the resource
One resource = one identity
User-assigned: Independent resource, can be assigned to multiple services
Persists when the service is deleted
Use when multiple services share the same permissions
Why it matters: eliminates credentials in code. Instead of storing
a service account password in a secret, the VM or pod authenticates
to Key Vault, Storage, or SQL using its managed identity.
Example:
# VM with managed identity calling Key Vault — no credentials needed
az keyvault secret show --vault-name my-vault --name my-secret
# The CLI automatically uses the VM's managed identity token
RBAC — Role-Based Access Control:
Azure RBAC is separate from Entra ID RBAC:
Entra ID RBAC: controls what you can do inside Entra ID (manage users,
manage groups, manage app registrations)
Azure RBAC: controls what you can do with Azure resources
(start VMs, read storage, deploy resources)
Azure RBAC roles:
Owner: full access including assigning roles
Contributor: full access but cannot assign roles
Reader: read only
+ 100s of built-in roles: Storage Blob Data Reader, AKS Cluster Admin, etc.
+ Custom roles: define exactly which actions are allowed
Role assignments are scoped:
Management group → Subscription → Resource Group → Resource
(wider scope = more resources covered)
Conditional Access:
Policies that gate access based on conditions:
Who: specific users, groups, or all users
What app: all apps, or specific ones (Azure portal, Office 365)
Where: named locations, countries, compliant devices
What risk: sign-in risk level from Identity Protection
Common policies:
- Require MFA for all admin portal access
- Block access from outside the UK
- Require compliant device for sensitive apps
- Block legacy authentication protocols (POP3, IMAP — bypass MFA)
Privileged Identity Management (PIM):
Just-in-time privileged access:
- Admins do not have permanent Global Admin or Owner rights
- They request elevated access for a specific time window (e.g. 2 hours)
- Request can require approval and MFA
- All activations logged for audit
Why it matters: reduces the blast radius if an admin account is compromised.
A compromised account with no standing privileges cannot do much.
What to say in the interview:
"My day-to-day Entra ID work covers managed identities for Azure workloads — replacing service account credentials with identity-based auth for Key Vault, Storage, and SQL. For access control I use Entra ID groups assigned to Azure RBAC roles at the resource group scope, which keeps permission management simple as the team grows. For security I enforce Conditional Access: MFA required for all Azure portal access, block legacy auth protocols, and require compliant devices for sensitive workloads. At RHS I partnered with the security team on Zero Trust adoption which involved tightening Conditional Access policies and rolling out PIM for privileged roles."