What's changed: Deepened AZ-400 Chapter 4 (added comparison tables, scenarios, FAQs, exam traps, deep-dive paragraphs to each section; localized figures to Japanese)
4.3Compliance and Governance
Understand control and trails—approvals/audit logs, Azure Policy, environment protection (checks), license/compliance management, and separation of duties. Meet regulatory requirements while shipping fast.
In regulated environments, control and trails are essential. Approvals, policy, and audit logs make who-approved/changed-what traceable.
4.3.1Governance mechanisms
- Approvals/environment checks: enforce human approval or conditions (branch/time/template) before prod.
- Azure Policy: enforce organizational guardrails (allowed resources/mandatory encryption).
- Audit logs: record approvals/changes/deployments for traceability.
- Separation of duties: separate builders from approvers/deployers for internal control.
Common on AZ-400: human gate before prod = approvals, enforce environment conditions = checks (branch/time/template), org guardrails = Azure Policy, operation records = audit logs, builder ≠ approver = separation of duties. Even under regulation, keep automation—balance control and speed with gates/approvals.
AZ-400 governance probes "embedding regulatory requirements into the pipeline without losing automation speed." Environment checks combine approvals (responsible manual sign-off), branch control (deploy only from protected branches), business hours (no out-of-hours deploys), required templates (run only from approved templates), and Azure Monitor/external API queries to control deployment to production resources. Org-wide guardrails are enforced by Azure Policy (allowed resources/regions, mandatory encryption, required tags via Deny/Audit/remediation), applied company-wide through the same management group inheritance as AZ-305. Audit logs record "who approved/changed/deployed what, when" for incident analysis, compliance audit, and SIEM. Separation of duties (SoD) splits code authors from production approvers/deployers to prevent unilateral fraud/error (approval policy forbids self-approval). License compliance manages OSS licenses from dependency scanning (SCA) results. Crucially, embedding these controls as gates/approvals within automation preserves auditability and speed without reverting to manual work. The key is to run DevOps fast while meeting regulation via environment checks + Azure Policy + audit logs + separation of duties.
| Control goal | Means | Key point |
|---|---|---|
| Human approval for prod | Environment approvals | Responsible sign-off; no self-approval |
| Enforce deploy conditions | Environment checks | Branch/time/template/query |
| Org guardrails | Azure Policy | Allowed resources/encryption via Deny/Audit |
| Traceability/internal control | Audit logs + SoD | Operation records; builder ≠ approver |
Scenario: A financial org requires "production deploys only from protected branches, within business hours, approved by someone other than the author, with all operations auditable," while keeping automation. → Set approvals (non-author) + branch control + business hours checks on the production environment (SoD via approval policy forbidding self-approval). Enforce allowed resources/mandatory encryption org-wide with Azure Policy. Track all approvals/changes/deploys in audit logs. This meets regulation while preserving pipeline automation.
FAQ: Approvals vs gates (checks) in governance? Approvals are controls needing "final human judgment" (go/no-go for a production release, change advisory board sign-off). Gates/checks are "machine-checkable conditions" (protected branch, business hours, monitoring health, required template). Regulatory requirements combine both—human approval plus automated checks for layered control—while automating the decidable parts to keep speed.
Exam trap: Reverting to manual work by abandoning automation (pipelines) for compliance is wrong—AZ-400 embeds controls as gates/approvals in the pipeline, balancing automation and auditability. Also, letting "the author approve their own production deploy" violates separation of duties—forbid self-approval in the approval policy and require a non-author approver.
4.3.2Section summary
- Control = approvals/environment checks + Azure Policy
- Trails = audit logs / internal control = separation of duties
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Restrict production deploys to specific branches and business hours only. What?
Q2. For compliance, a person other than the author must approve production deploys. What is this called?
Q3. Trace who approved/changed/deployed what and when. What?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.