4.2Identity, Access, and Security

The foundation of secure cloud use is identity. We have shifted from defending at the perimeter (the corporate network) to "identity is the new perimeter." This section covers identity management (authentication, authorization, Entra ID, RBAC) and the surrounding security mindset (Zero Trust, defense in depth, Defender for Cloud) together.

4.2.1Authentication and authorization

Authentication (AuthN, "who you are") and authorization (AuthZ, "what you can access") are different concepts. The order is always authenticate → authorize: confirm identity first, then decide "may you act on this resource." Exams frequently swap these two terms in options.

Use Azure Key Vault to protect secrets. Centrally and securely manage API keys, connection strings, certificates, and encryption keys; apps and services retrieve them via managed identity instead of hard-coding secrets, with access controlled by Microsoft Entra ID and RBAC.

4.2.2Microsoft Entra ID and stronger authentication

• Microsoft Entra ID (formerly Azure AD): the cloud identity/access management service that manages sign-in for users, groups, and apps.
• Multi-factor authentication (MFA): strengthens identity proof with a second factor (phone approval, code, etc.) beyond a password.
• Passwordless: sign in more securely without a password at all, using passkeys, Windows Hello, or the Authenticator app.
• Single sign-on (SSO): sign in once to access many services.
• Conditional Access: grants or challenges access based on conditions like location, device, or risk (e.g., require MFA off-network).
• External ID (B2B/B2C): handles external users such as partners (B2B) and customers (B2C).

4.2.3Authorization in practice: RBAC

Authorization is implemented by RBAC (role-based access control): grant permissions by assigning "to whom (user/group), which role (Reader/Contributor/Owner, etc.), at what scope (the previous chapter scopes: management group down to resource)." The principle is least privilege—give the right people the right access at the right scope, no more. Assignments inherit down the scope, so broad roles applied high can over-grant.

4.2.4Entra ID vs on-premises AD DS

Microsoft Entra ID is a cloud identity service for web/SaaS apps and devices, using modern protocols (OAuth/OpenID Connect/SAML). Active Directory Domain Services (AD DS) is the on-premises domain (managing in-house PCs/servers with Kerberos/LDAP). They are different: Entra ID is not domain-join or Group Policy. In hybrid setups, Entra Connect synchronizes and links them.

4.2.5Security mindset

Zero Trust is the modern principle of "never trust, always verify." Do not implicitly trust traffic just because it is inside the corporate network; verify identity, device, and context on every access (Conditional Access and MFA are implementations). Its companion is defense in depth—layering protections so that if one is breached, the next still holds.

Tying this together for visibility and hardening is Microsoft Defender for Cloud. It scores your resources security posture (Secure Score), detects misconfigurations and threats, and recommends fixes. Its role is to continuously assess the portion you own under the shared responsibility model (configuration, identity, data, and so on) and surface prioritized remediations.

4.2.6Section summary

• Authenticate (who) → authorize (what); authorization is implemented by RBAC (least privilege, scope inheritance)
• Entra ID = cloud identity: MFA/SSO/passwordless/Conditional Access/external ID; ≠ AD DS (on-prem)
• Zero Trust = always verify / defense in depth = layered / Defender for Cloud = score and harden posture