Objectives in this domain

Design and implement authentication and authorization methods, including Microsoft Entra service principals, managed identities, GitHub Apps, and Azure DevOps service connections and permissions.
Section 4.1hard
Design and implement a strategy for managing sensitive information in automation, including Azure Key Vault, secretless authentication, and workload identity federation.
Section 4.2hard
Automate security and compliance scanning, including dependency, code, secret, and licensing scanning with GitHub Advanced Security and Microsoft Defender for Cloud.
Section 4.3hard

Sample question from this domain

Free sampleDevelop a Security and Compliance Planhard

A platform team stores database connection strings and API keys in "Azure Key Vault" and wants their web application on "Azure App Service" to read them with no secret ever placed in app settings or code, while access can be revoked centrally if the app is compromised. They also want the secrets to be authorised through Microsoft Entra role assignments rather than legacy vault access policies. Which two measures together satisfy these requirements? Select TWO.

AEnable a system-assigned managed identity on the App Service and grant that identity a Key Vault data-plane RBAC role such as Key Vault Secrets User on the vault. Correct
BStore the vault access in the application's appsettings.json file as a connection string so the runtime can present it to the vault when it requests each secret.
CReference each secret from an App Service application setting using a Key Vault reference so the platform resolves the value from the vault at runtime instead of holding the literal secret. Correct
DCreate a long-lived service principal client secret, store it as an App Service setting, and add a classic vault access policy granting that principal Get on secrets.

Combine an App Service managed identity holding a Key Vault data-plane RBAC role with Key Vault references so secrets resolve at runtime without being stored. A managed identity removes any stored credential and is governed by Microsoft Entra, and assigning it a Key Vault data-plane RBAC role makes access centrally revocable. Key Vault references then let App Service settings resolve secret values from the vault at runtime under that identity, so no literal secret lives in configuration or source.

Why A is correct: A system-assigned managed identity gives the app an Entra identity with no stored credential, and granting it the Key Vault Secrets User RBAC role authorises secret reads centrally and revocably, meeting both requirements exactly.

Why B is wrong: Placing any credential in appsettings.json is precisely the stored secret the team wants to avoid, so although it would technically authenticate it violates the no-secret-in-settings constraint.

Why C is correct: A Key Vault reference lets App Service settings point at the vault and resolve the value at runtime using the app's managed identity, so the literal secret is never stored in configuration or code.

Why D is wrong: This both stores a long-lived secret in app settings and uses the legacy access-policy model the team is moving away from, so it fails the no-stored-credential and RBAC-authorisation requirements.

Other domains in this exam

Design and Implement Processes and Communications13% of the exam
Design and Implement a Source Control Strategy13% of the exam
Design and Implement Build and Release Pipelines53% of the exam
Implement an Instrumentation Strategy8% of the exam

See also the AZ-400 cert hub, the study guide, and the cheat sheet.