Choosing a Hybrid Authentication Method
Every organisation moving to Azure has to answer one question before anything else: when a user types their password, who checks it. Password hash sync copies a hash of the hash of the password into Microsoft Entra ID, so the cloud validates the sign-in on its own and keeps working even if the on-premises estate is unreachable. Pass-through authentication sends the credential to a lightweight agent inside your network that asks Active Directory in real time, so no password material of any kind lives in the cloud, but the agents become part of the sign-in path. Federation hands the whole sign-in to AD FS or another identity provider on-premises, which is the most control and by far the most infrastructure to keep alive. Microsoft's own guidance leans towards password hash sync unless something specific rules it out, and even where federation is required, enabling password hash sync alongside it gives you a fallback and lets Entra ID compare credentials against known leaked ones. The design question on the exam is almost never which is technically better, it is which requirement in the scenario eliminates the simpler options.
Exam tip. Read the constraint, not the preference. Words like smart card, existing third-party MFA at authentication, or sign-in hours force federation. A phrase about resilience when the datacentre is down is pointing you straight at password hash sync.
Conditional Access as the Real Access Decision Point
Conditional Access is where authentication stops being a yes or no question. Every sign-in arrives carrying signals: which user, which application, what device, from where, and how risky the attempt looks. A Conditional Access policy takes those signals as conditions and applies a control, which can be a block, a plain grant, or a grant on the condition of multifactor authentication, a compliant device, an approved client app or accepted terms of use. This is the mechanism behind almost every access requirement you will be asked to design for, because plain role assignments cannot express anything about circumstance. Security defaults exist as a fixed on or off baseline for tenants with nothing better available, and per-user MFA is the legacy approach that cannot express exceptions. Whenever a requirement mentions a location, a device state, a specific application, or an exemption for a break-glass account, the answer is Conditional Access. Design also means planning for the policy engine itself: excluding emergency access accounts, running policies in report-only mode first, and remembering that a badly scoped block policy can lock every administrator out of the tenant at once.
Exam tip. If a requirement can be written as when X, require Y, it is a Conditional Access policy. Per-user MFA and security defaults are only correct when the scenario explicitly has no licensing or no need for exceptions.
Managed Identities, Service Principals and Credential-Free Design
Applications need to authenticate just as much as people do, and the design goal is always the same: get to a state where there is no secret for anyone to leak, rotate or forget. A managed identity is a service principal that Azure creates and whose credentials Azure rotates for you, attached to a resource that can request tokens from the platform without ever holding a key. A system-assigned managed identity is bound to one resource and is deleted with it, which is clean for a single long-lived service. A user-assigned managed identity is a standalone resource you create once, grant permissions once, and attach to as many workloads as you like, which is what you want when instances come and go or when several services share the same access. Service principals with client secrets or certificates remain necessary for things that do not run on an Azure resource, such as a pipeline in another system, and for those, workload identity federation lets an external token be exchanged for an Azure one so that even then no secret needs to be stored. The wrong answer on this exam is almost always the one that puts a connection string or a key into application configuration.
Exam tip. If the resource runs in Azure, the answer involves a managed identity. Choose user-assigned when the scenario mentions multiple resources sharing access or instances being recreated, and system-assigned when it is one durable resource with its own permissions.
Azure RBAC and the Discipline of Least Privilege
Azure RBAC answers exactly one question: who is allowed to perform which operations on which resources. A role assignment binds a security principal to a role definition at a scope, and it flows downward from that scope, so an assignment at a management group reaches every subscription, resource group and resource beneath it. Good design means assigning at the highest scope that is still correct and to groups rather than individuals, because a hierarchy full of one-off assignments at resource level is impossible to review. The built-in roles are deliberately coarse, and the three that matter most on the exam are Contributor, which can manage resources but cannot grant access, User Access Administrator, which can grant access but cannot manage resources, and Owner, which is both and should be rare. Custom roles exist for the cases where nothing built in is close enough, but they are yours to maintain forever, so the correct instinct is to reach for one only after checking the catalogue. RBAC also does not stand alone: deny assignments and resource locks can override it, and Privileged Identity Management is what turns a standing assignment into one that has to be activated and justified.
Exam tip. When a question asks for the least privilege that still works, walk the built-in roles from the narrowest upward and stop at the first one that covers the stated action. If the required action is granting access to others, the answer is User Access Administrator, not Owner.
Azure Policy: Enforcing What Resources Look Like
RBAC decides who may act, and Azure Policy decides what the result is allowed to be. A policy definition is a rule evaluated against resource properties, and its effect determines what happens when the rule matches. Deny stops the deployment. Audit lets it proceed and records it as non-compliant. Modify and Append change the resource as it is created, which is how a missing tag gets filled in. DeployIfNotExists and AuditIfNotExists look at a related resource rather than the one being deployed, which is how diagnostic settings and agents get attached to everything automatically. The distinction that catches people out is that Deny only ever applies at deployment time, so an estate that is already non-compliant stays that way until you use a Modify or DeployIfNotExists policy together with a remediation task, which sweeps existing resources using a managed identity. Definitions are grouped into initiatives so a whole regulatory standard reports as a single compliance figure, and assignments are made at management group or subscription scope so the same governance lands everywhere without being recreated by hand. Exemptions and exclusion scopes are the supported way to handle the exceptions that always exist.
Exam tip. The giveaway word is existing. Deny and Audit only act at deployment time, so any question about bringing the current estate into line is asking for DeployIfNotExists or Modify with a remediation task.
Designing the Management Group and Subscription Hierarchy
The resource hierarchy is the skeleton every other governance decision hangs on. Management groups sit above subscriptions and exist so a policy assignment or role assignment can be made once and inherited by everything beneath, which is the only way governance stays consistent as the estate grows. Subscriptions are the natural boundary for billing, for quota headroom and for a genuinely different governance regime, so the usual reason to create another one is that a workload needs a different policy set, a separate bill, or room away from another workload's limits. Resource groups sit inside subscriptions and group things that share a lifecycle, meaning the resources you would deploy, update and eventually delete together. A good hierarchy is shallow and organised around how governance differs, not around the org chart, because reporting lines change far more often than compliance requirements do. Common patterns separate platform subscriptions holding shared networking, identity and management from landing zone subscriptions holding workloads, with sandbox and decommissioned branches kept apart so their policies can be looser or stricter without affecting anyone else.
Exam tip. When a scenario asks where to apply something so it reaches everything and stays consistent, the answer is a management group. When it asks for isolation of billing or quota, the answer is a separate subscription.
Identity Governance: Privileged Access and Access Reviews
Access granted is easy, access removed is hard, and identity governance exists to close that gap. Privileged Identity Management changes the shape of privileged access entirely: instead of holding a role permanently, an administrator is made eligible for it and has to activate it, optionally with approval, a justification, multifactor authentication and a time limit after which it expires by itself. That turns a standing target into a short, audited window, and it works for both Entra ID roles and Azure resource roles. Access reviews handle the other half of the problem by making a named reviewer periodically confirm that each person still needs their group membership, application assignment or role, with automatic removal of anything not approved, so entitlements decay rather than accumulate. Entitlement management goes further and packages the groups, applications and sites that a role needs into an access package that people request, an approver signs off and that expires on a schedule, which is how partner and contractor access is granted at scale without anyone building it by hand. Together these are what a scenario means when it says access must be justified, temporary and reviewed.
Exam tip. Requirements about no standing privilege, approval before elevation, or time-limited administration point at Privileged Identity Management. Requirements about periodically confirming that access is still needed point at access reviews.
Designing the Azure Monitor Data Platform
Azure Monitor holds two fundamentally different kinds of data and most design mistakes come from confusing them. Metrics are lightweight numeric samples on a timeline, collected automatically for every resource, cheap to keep and fast enough to alert on within a minute or two. Logs are structured records stored in a Log Analytics workspace and queried with KQL, which makes them far richer and far better for correlation and investigation, at more cost and more latency. Most platform log data does not exist until you ask for it: a diagnostic setting on each resource is what routes its resource logs and metrics somewhere, and the three destinations answer three different needs. Log Analytics is for anything you want to query, alert on or correlate. A storage account is for cheap long retention where nobody queries the data unless there is an audit. An event hub is for streaming into a third-party SIEM or another consumer. Workspace design is the other big decision, and the guidance is to use as few workspaces as the requirements allow, because cross-workspace queries and alert rules get unwieldy quickly, and to separate only for data residency, isolation or chargeback that cannot be met with resource-context access.
Exam tip. Match the destination to the verb in the requirement. Query and alert means Log Analytics, retain cheaply for years means a storage account, and send to an external SIEM means an event hub.
Alerting, Autoscale and Getting Signal Instead of Noise
An alert design has three parts: what condition is evaluated, what happens when it fires, and who is expected to do something about it. Metric alerts evaluate numeric time series and are the cheapest and fastest, which makes them the default for anything expressible as a threshold on a platform metric. Log search alerts run a KQL query on a schedule and are the answer when the condition needs records joined or counted, at the cost of more latency and more expense. Activity log alerts fire on control plane events such as a resource being deleted or a service health advisory being published, and they are how you notice governance and platform events rather than performance ones. Whatever fires, the response lives in an action group, a reusable object that holds the emails, SMS messages, webhooks, Logic Apps, runbooks and ITSM connectors that should run, so the alert stays about the condition and the response can be changed without touching it. Good design also means dynamic thresholds where the normal range varies, alert processing rules to suppress noise during planned maintenance, and a hard rule that every alert should have a documented action, because an alert nobody acts on trains people to ignore the ones that matter.
Exam tip. If the condition is a number on a chart, recommend a metric alert. Reach for a log search alert only when the scenario describes something no single metric captures, such as counting a particular error string across services.
Key Vault, Managed HSM and Customer-Managed Keys
Azure Key Vault is the design answer to every requirement that mentions a secret, a certificate or an encryption key, and the interesting decisions are about how access to it is controlled and how strong the key protection has to be. Access can be managed either with the older vault access policies or with Azure RBAC, and RBAC is the recommendation because permissions are then managed, scoped and audited exactly like every other Azure resource, right down to an individual secret, instead of living in a separate model that only applies to vaults. The service tiers matter when regulation is involved: standard protects keys in software, premium backs them with hardware security modules in a shared pool, and Managed HSM gives you a single-tenant pool with its own access model and administrative separation for the cases where an organisation must be the only party in control. Customer-managed keys are the other half of the picture. Azure encrypts data at rest everywhere by default with platform-managed keys, and moving to customer-managed keys does not change whether the data is encrypted, it changes who holds the key, which is what lets you rotate on your own schedule and revoke access to the data entirely. Any vault holding production secrets should have soft delete and purge protection on, because they are what stop a deletion becoming permanent.
Exam tip. Requirements about controlling, rotating or revoking the encryption key point at customer-managed keys in Key Vault. Requirements about sole control, single tenancy or a hardware boundary point specifically at Managed HSM.