Microsoft AZ-801: Encryption, Certificates and PKI — Study Guide

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Part of the Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Encryption and public key infrastructure form the trust foundation of a Windows Server–centric hybrid environment. Administrators must be able to harden data at rest with BitLocker and EFS, establish and operate an enterprise PKI with AD CS and an Online Responder, automate certificate lifecycle through templates and autoenrollment, and integrate cloud-native certificate management via Azure Key Vault. The following sections detail the architecture, prerequisites, deployment patterns, and operational controls that consistently show up in real-world Windows Server hybrid estates.

BitLocker and EFS on Windows Server

BitLocker Drive Encryption protects volumes using a combination of the TPM and key protectors. TPM 2.0 is the current baseline recommendation; TPM 1.2 remains supported, but TPM 2.0 with UEFI and Secure Boot provides stronger binding of the boot chain to TPM Platform Configuration Registers (PCRs). For servers, require TPM+PIN on operating system volumes to add an online factor, mitigating cold-boot and offline attacks. Configure this via Group Policy under BitLocker Drive Encryption (Require additional authentication at startup; Allow enhanced PINs for startup). Where no TPM exists, a USB startup key is possible but inferior operationally and less secure.

Recovery key governance is mandatory. In AD DS environments, escrow recovery information to computer objects (msFVE-RecoveryInformation) via Group Policy (Choose how BitLocker-protected operating system drives can be recovered; Back up recovery passwords and key packages to AD DS). In Azure AD–joined scenarios, recovery keys are escrowed to the Azure AD device object and discoverable to authorized administrators in the Devices blade; Intune policies can require Azure AD escrow. Validate escrow before enabling encryption at scale.

Network Unlock eliminates manual PIN entry for domain-joined servers in secure datacenter subnets during unattended reboots. Prerequisites include TPM-protected OS volumes, UEFI firmware, wired connectivity without 802.1X gating at pre-boot, DHCP broadcast reachability, and a Windows Deployment Services server with the Network Unlock feature and a server authentication certificate issued from an enterprise CA using the Network Unlock template. Configure the BitLocker GPOs to enable Network Unlock and ensure the CA’s OCSP/CRL are reachable by the WDS server. Network Unlock does not apply to mobile or wireless hosts.

Pre-provisioning accelerates large-scale deployments by encrypting used space as early as Windows PE during imaging. In MDT/Configuration Manager task sequences, use the Pre-provision BitLocker step (manage-bde -on C: -used -skiphardwaretest) to begin encryption before the full OS deploys; switch to full protection after domain join and policy application.

Manage BitLocker centrally with Microsoft Endpoint Manager. Intune (MDM) enforces silent encryption with TPM-only protectors for Azure AD–joined devices and escrows keys to Azure AD; requiring a startup PIN precludes silent encryption and requires user interaction. For domain-joined servers and mixed estates, use Configuration Manager BitLocker Management (the successor to MBAM) for compliance reporting, escrow, portals, and key rotation. Always design for auditable escrow and owner mapping.

EFS is per-file encryption bound to user EFS certificates. A file encryption key (FEK) is generated per file and encrypted with the user’s EFS public key. In absence of an enterprise CA, Windows issues a self-signed EFS certificate, which impedes recovery and central control. In enterprise deployments, issue EFS certificates from AD CS using the Basic EFS template, and designate Data Recovery Agents (DRAs) via GPO (Public Key Policies, Encrypting File System) to ensure recoverability of user-encrypted files. The cipher command-line tool remains essential: cipher /e and /d encrypt or decrypt; cipher /r generates DRA key pairs; cipher /u updates encrypted files to use the current EFS cert. Use BitLocker for volume-level protection and EFS only when per-user or per-file separation is required, recognizing that EFS requires user logon and certificate availability.

AD CS Hierarchy and Online Responder

A resilient enterprise PKI uses a tiered CA hierarchy. The offline root CA is the trust anchor and must be physically and logically isolated, powered on only to sign subordinate CA requests and publish CRLs. Use long validity (for example, 10–20 years), large RSA key sizes (at least 4096 where feasible), and publish CDP/AIA to highly available, path-consistent URLs. Never issue end-entity certificates from the root.

Subordinate (issuing) CAs are domain-joined, online, and short-lived (for example, 3–5 years) with constrained key usage and EKUs. They issue computer, user, and service certificates and publish frequent CRLs with overlap to avoid outage during publication delays. Prefer HSM-backed private keys on issuing CAs to reduce key exfiltration risk. Configure registry- or policy-based restrictions on templates and issuance to enforce least privilege.

Revocation checking must be fast and reliable. An Online Responder (OCSP) reduces client latency by answering per-certificate status queries instead of downloading full CRLs. Install the Online Responder role service, enroll responders for an OCSP Response Signing certificate via a dedicated v3 template, and configure a Revocation Configuration that points to the issuing CA and its CRLs using the Microsoft CRL-based Revocation Provider. Ensure the CA includes an OCSP URL in the Authority Information Access extension so clients know where to query.

For scale and resilience, deploy an OCSP array. Designate an array controller to replicate revocation configurations to member responders. Load-balance the array using Windows NLB or an external load balancer with a health probe that confirms OCSP responsiveness and fresh signing certificates. Pin short OCSP signing cert lifetimes and autoenroll renewal to minimize risk exposure. Monitor CRL freshness and OCSP cache lifetime to prevent stale responses.

Templates, Autoenrollment, Key Archival, and Credential Roaming

Certificate templates govern request constraints, subject name, key usages, and issuance requirements. Version 2 templates (introduced with Windows Server 2003 Enterprise) allow customization and support autoenrollment with CSP-based keys. Version 3 templates (Windows Server 2008 and later) add CNG support, ECC, and Suite B algorithms. Choose v3 when you need CNG/ECC; choose v2 for maximum legacy compatibility. Tie templates to a single issuing CA set to contain blast radius.

Autoenrollment turns certificate lifecycle into policy-driven plumbing. Configure Group Policy under Computer Configuration or User Configuration, Windows Settings, Security Settings, Public Key Policies, Certificate Services Client – Auto-Enrollment. Enable it with Renew expired certificates, Update certificates that use certificate templates, and Remove revoked/expired certificates. Autoenrollment requires template permissions: principals must have Read and Autoenroll; Enroll suffices for manual enrollment only. Scope by security groups to avoid unexpected certificate issuance and control volume.

Key archival protects data if a private key is lost. Enable Archive the subject’s encryption private key on the template for encryption-only certificates (for example, EFS, S/MIME). Designate Key Recovery Agents (KRAs) by issuing them KRA certificates from the Key Recovery Agent template and configure the CA to archive keys. Recovery is limited to archivable key types; traditionally, RSA Key Exchange (legacy CSP) is supported, while CNG/ECC private key archival is not supported by AD CS key archival. Do not enable archival for signing-only templates.

Credential Roaming synchronizes user certificates, private keys, and DPAPI master keys across domain-joined devices by storing them in AD. Enable it via Group Policy under User Configuration, Administrative Templates, System, Credential Roaming, and scope to trusted users. This improves user experience for EFS, S/MIME, and client auth certificates across multiple machines without roaming profiles. Validate directory schema support and plan for interaction with Windows Hello for Business and third-party credential managers to avoid conflicts or duplication.

TLS/SSL Lifecycle and Azure Key Vault Integration

Modern TLS depends on correct certificate semantics. Always include Server Authentication EKU, and prefer SHA-256 or stronger signatures with at least 2048-bit RSA or appropriate ECC curves. Subject Alternative Name (SAN) must list every hostname clients use; the legacy Subject CN alone is insufficient for modern clients. Wildcard certificates (*.contoso.com) simplify multi-host deployments in one DNS zone but do not match multi-level names (app.dev.contoso.com) or different zones; carefully evaluate risk concentration when wildcard private keys are deployed broadly. For multi-zone needs, prefer SAN certificates or multiple targeted certificates.

Standardize CSRs with certreq or IIS, maintain key custody policies, and automate renewal well before NotAfter to permit staged rollouts and OCSP/CRL propagation. On domain-joined web servers, autoenrollment with a Web Server v3 template can automate issuance and renewal; use subject name supply in the request with appropriate approvals. Apply TLS 1.2/1.3-only server configurations, enable ECDHE cipher suites for forward secrecy, and remove deprecated SHA-1 and export-grade ciphers.

Azure Key Vault extends certificate lifecycle to the cloud. You can import existing PFX/PEM certificates, generate new ones with a Key Vault–integrated certificate authority (for example, DigiCert) using a certificate policy, and set auto-rotation so Key Vault requests renewal and maintains the latest version. The certificate object wraps a Key Vault key and a secret, enabling exportable PFX workflows or HSM-backed non-exportable keys depending on policy. Applications and services retrieve current versions via RBAC or access policies and managed identities. Key Vault references let services such as Azure App Service and Azure Functions pull certificates and secrets by reference without embedding them in configuration. For Windows Server workloads in Azure or hybrid, use the Azure Key Vault VM extension or custom automation with managed identities to fetch and install updated certificates into the Windows certificate store and trigger service restarts, ensuring zero-touch renewals across web servers, reverse proxies, and application gateways.

Practical Problem Scenario

Adobe Inc. must standardize encryption and PKI across two on-premises datacenters and Azure-hosted Windows Server workloads. They require unattended server restarts in datacenters, automated web certificate renewals, per-file encryption recovery, and minimal user friction.

Build a two-tier PKI with an offline root CA and two online issuing CAs

Why: An offline root CA creates a high-assurance trust anchor, while short-lived issuing CAs limit exposure and support high availability. The hierarchy enables separation of duties, scalable template scoping, and safe CRL/AIA publication.

Deploy an OCSP Online Responder array behind a load balancer

Why: OCSP gives low-latency revocation answers for web and application servers at scale. An array with health-checked load balancing prevents single points of failure and ensures clients get fresh status without downloading large CRLs.

Author v3 certificate templates for Web Server, OCSP Response Signing, and Computer Authentication; v2 templates for EFS and S/MIME with key archival

Why: v3 enables CNG/ECC for modern TLS and responder signing; v2 maximizes client compatibility for EFS/S/MIME and supports key archival for encryption keys. Template scoping enforces least privilege issuance.

Enable autoenrollment via Group Policy and assign Read/Autoenroll on templates to scoped security groups

Why: Autoenrollment removes manual steps, handles renewals before expiry, and cleans up revoked/expired certs. Security group scoping avoids over-issuance and adheres to least privilege.

Implement BitLocker on all servers with TPM+PIN for OS volumes; escrow recovery keys to AD DS

Why: TPM+PIN increases resistance to offline attacks; AD DS escrow guarantees recoverability. Servers meet uptime goals while ensuring compliance-grade auditability of key custody.

Configure Network Unlock using WDS with the Network Unlock feature in datacenter subnets

Why: Unattended reboots after patching without local console access are enabled while retaining TPM+PIN security controls outside the datacenter. UEFI+TPM and wired DHCP meet the technical prerequisites.

Manage BitLocker posture with Configuration Manager BitLocker Management and reporting

Why: Configuration Manager provides mature server coverage, compliance dashboards, and self-service/recovery workflows, reducing operational overhead in a mixed on-premises and Azure environment.

Issue EFS certificates from AD CS and configure DRAs via GPO; require users to back up EFS certs

Why: Central issuance plus DRAs guarantee business continuity for file-level encryption. DRA keys are tightly controlled to prevent abuse while maintaining recovery options.

Centralize TLS certificates for Internet-facing workloads in Azure Key Vault with managed CA integration and auto-rotation; distribute to Windows Server via managed identity automation

Why: Key Vault offloads renewal, centralizes secrets, supports versioning, and enables secure, automated deployment to servers. Auto-rotation eliminates expirations and aligns with zero-touch operations.

Enable Credential Roaming for a scoped set of users who require EFS and S/MIME across multiple devices

Why: Credential Roaming synchs certificates and DPAPI keys, ensuring users can decrypt and sign across workstations without manual export/import, improving productivity and reducing support tickets.

← Azure Arc and Hybrid Server Management · All domains · Windows Server Update and Patch Management →

Practice these questions → · Timed practice on ExamRoll.io →